similar to: Formatting in formatC and format (PR#129)

Displaying 20 results from an estimated 3000 matches similar to: "Formatting in formatC and format (PR#129)"

2002 Nov 16
0
formatC with format="fg" displays number in exponential notation (PR#2299)
Full_Name: Frederic Schutz Version: 1.6.1 OS: Linux Submission from: (NULL) (128.250.252.193) The result of the following commands: > formatC(9.9, 1, format="fg") [1] "1e+01" > formatC(99.9, 1, format="fg") [1] "1e+02" does not seem to be coherent with what the help page says: > format: equal to `"d"' (for integers),
2005 Nov 22
2
(PR#8337) formatC adds leading space -- on some Windoze
>>>>> "KevinW" == Kevin Wright <kwright68 at gmail.com> >>>>> on Mon, 21 Nov 2005 18:13:36 +0100 (CET) writes: KevinW> Full_Name: Kevin Wright KevinW> Version: 2.2.0 KevinW> OS: Windows 2000 ^^^^^^^ this must be part of the problem KevinW> Submission from: (NULL) (170.54.58.4) KevinW> Apologies if
2000 Jan 04
0
formatC (bug and fix) (PR#394)
OK: > formatC(as.double(c(1,0,NA))) [1] "1" "0" "NA" NOT OK: > formatC(as.integer(c(1,0,NA))) [1] "0" "1072693248" "NA" > formatC(as.integer(c(0,1,NA))) [1] "0" "0" "NA" BUG TRACED TO R-code of formatC() where x[!Ok] <- 0 unintendedly changes the storage.mode of x to
2008 Jun 09
1
Bug/Error in formatC? (Was: Why doesn't formatC( x, digits=2, format= "g")...)
Hi all After posting what follows, Duncan Murdoch suggested perhaps a bug in formatC, or an error on documentation. Any comments? In particular, bug, error or not, any ideas about how I can consistently get two significant figures to print? P. ---------- Original Message ---------- Hi all I am not a C programmer, but I am trying to understand formatC to get consistent printing of
2001 Oct 26
1
Bug or new concept in formatC?
As a sequel to my previous mail on cut, formatC does not produce what I have been taught is significant digits: > x <- c(1.0793,1.0796, 11.0954, 11.0736 ) > formatC(x,digits=3,format="g") [1] "1.08" "1.08" "11.1" "11.1" (3,3,3,3) significant digits OK > formatC(x,digits=3,format="f") [1] "1.079"
1999 Feb 26
1
Re: trailing zeroes
> Date: Fri, 26 Feb 1999 09:59:39 +0000 > From: Bendix Carstensen <bxc at svs.dk> > When you require 2 digits you expect to find 5.96 printed Correction, _you_ expect! Very few computer programs do that. You cannot `require' two digits by options(digits=2): ?options says digits: controls the number of digits to print when print- ing numeric values. It is a
2008 Jun 06
2
Why doesn't formatC( x, digits=2, format="g") doesn't always give 2 sig figs?
Hi all I am not a C programmer, but I am trying to understand formatC to get consistent printing of reals to a given number of significant digits. Can someone please explain this to me? These first three give what I expect on reading ?formatC: > formatC(0.0059999, digits=2,format="fg",flag="#") [1] "0.0060" > formatC(0.59999,
2009 Jan 27
1
small bug in base::formatC (PR#13474)
Full_Name: Bernd Bischl Version: 2.8.1 OS: Windows XP Professional Submission from: (NULL) (129.217.207.95) Hi, there seems to be a small bug in formatC: formatC("foo", format="s", mode="charcacter") Error in formatC("foo", format = "s", mode = "charcacter") : 'mode' must be "double" ("real") or
2002 Mar 13
1
Commas in formatC
formatC() is great for formatting numbers! But it would be even better if it could optionally insert commas (or semicolons), e.g. R> formatC(1234567.89, digits=2, format="f", commas=T) [1] "1,234,567.89" Here's a snippet of code that does that, which could more or less just be inserted into at the end of formatC if any R-core guru were so inclined. "r"
2007 May 25
0
documented/undocumented behavior of as.double(formatC(x, digits=17))
Some days ago, there was a discussion about the command formatC(exp(1),digits=100,width=-1) Converting a double value to a string, from which the double may be reconstructed exactly, may be useful. So, I did some experimentation with it in my linux installation of R-2.5.0. I generated a vector x of a large number of random doubles (random sign, random mantissa with 53 significant bits and
2019 May 30
1
Possible bug in formatC
I do not know if this is a bug or a case of improper documentation. The documentation for formatC() implies that the difference between the options format="f" and format="g" is that with "g", scientific format is sometimes used. There is another difference between them that is not mentioned in the documentation. drop0trailing=FALSE is ignored when format is set to
2012 Feb 23
3
I'm sure I'm missing something with formatC() or sprintf()
I have a four-digit string I want to convert to five digits. Take the following frame: zip 2108 60321 60321 22030 91910 I need row 1 to read '02108'. This forum directed me to formatC previously (thanks!) That usually works but, for some reason, it's not in this instance. Neither of the syntaxes below change '2108' to '02108.' The values in cand_receipts[,1] are of
2006 Jan 24
1
No scientific notation in format
Hi I have a data.frame with the following numbers (first column are month numbers) 07,0,0,0,0.315444056314174,0,0,0,12.5827462764176,0.079194498691732, 0.0280828101707015,0,0.0695808222378877 08,0,0,105600,0.393061160316545,0,0,0,8.95551253153947,0.0880023174276553, 0.285714285714286,0,0.0669139911789158 09,0,0,0,0,12.5,0,0,13.5135887094281,0.0557531529154668,0,0, 0.0487526139182026
2000 Jan 12
0
inconsistencies between formatC(), format() and format.char()
Dear R-Developers, Just a note: there are some inconsistencies between formatC(), format() and format.char() and cross calling between these functions. On the one hand > cat(format('{"}'), "\n") {\"} > cat(format.char('{"}'), "\n") {\"} is by default format.char(, flag="-") and thus by default calling format() >
2006 Jan 23
1
formatC slow? (or how can I make this function faster?
I'm trying to convert a matrix of capture occasions to format that an external program can read. The job is to basically take a row of matrix, like > smp[1,] [1] 1 1 0 1 1 1 0 0 0 0 and convert it to the equivalent string "1101110000" I'm having problems doing this in a speedy way. The simplest solution (calc_history below, using apply, paste and collapse) takes about 2
2018 Oct 25
1
small bug in formatC?
formatC(0.0001, digits = 3, format = "f", zero.print="< 0.01") Error in strrep(" ", nc - i1) : invalid 'times' value The problem, if it is one, is in .format.zeros: .format.zeros("0.000", "xxxxxx") Error in strrep(" ", nc - i1) : invalid 'times' value R version 3.5.1. David [[alternative HTML version deleted]]
2005 Feb 11
3
formatC with illegal input crashes Rgui (PR#7686)
Full_Name: Peter Ehlers Version: rw2001pat (2005-02-03) OS: Win XP Submission from: (NULL) (136.159.61.115) formatC(1, flag="s") crashes Rgui. Similarly for flag=[SnZ]. Stupid input, of course, but I'm error-prone. Peter
2019 Mar 22
0
prettyNum digits=0 not compatible with scientific notation
Thank you, Robert for raising this here ! >>>>> Robert McGehee >>>>> on Thu, 21 Mar 2019 20:56:19 +0000 writes: > R developers, > Seems I get a bad result ("%#4.0-1e" in particular) when trying to use prettyNum digits=0 with scientific notation. I tried on both my Linux box and on an online R evaluator and saw the same problem, so
2019 Jun 20
2
base::format adds extraneous whitespace for some inputs
Dear R Core Team, First of all, thank you for your amazing work on developing and maintaining this wonderful language. I just stumbled upon the following behavior in R version 3.6.0: format(9.91, digits = 2, nsmall = 2) format(9.99, digits = 2, nsmall = 2) yield "9.91" and " 9.99" with an extraneous whitespace. My expected output for the second command is
2019 Jun 20
0
base::format adds extraneous whitespace for some inputs
I can reproduce this. It has to do with whether the value rounds down to 9 or up to 10, and thus needs another space, I think. I agree that it shouldn't happen, but at least you can get rid of the space by using trim = TRUE. # rounds to 9 vs 10 format(9.95, digits = 2) format(9.96, digits = 2) format(9.95, digits = 2, nsmall = 2) format(9.96, digits = 2, nsmall = 2) format(9.95, digits =