similar to: prettyNum inserts leading commas (PR#1548)

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"

In R-1.5.0pre (2002-04-08) on Solaris 2.6, the window that X11() creates has a title like: R Graphics: Device 2 (ACTIVE) o iyeP )( y except the funny characters at the end have umlauts and other accents (i.e. extended ASCII characters), and they may be different each time X11() is invoked. There is no loss of functionality; it just looks a little ugly. I saw this behavior in R-1.3.?, it

FWIW, it doesn't seem to be happening on Mac OS: > format(2^30, digits=0) [1] "1.e+09" > prettyNum(12345.6, digits=0) [1] "1.e+04" A glibc misfeature? -pd > On 22 Mar 2019, at 10:10 , Martin Maechler <maechler at stat.math.ethz.ch> wrote: > > Thank you, Robert for raising this here ! > >>>>>> Robert McGehee

? Fri, 23 May 2025 11:47:33 +0000 Marttila Mikko via R-devel <r-devel at r-project.org> ?????: > When called with a numeric vector, the `replace.zero` argument is > disregarded. > > > prettyNum(0, zero.print = "- ", replace.zero = TRUE) > [1] "-" > Warning message: > In .format.zeros(x, zero.print, replace = replace.zero) : >

Thank you, Marttila and Ivan, As the original author of prettyNum() {etc ..}, I will commit such a bug fix to R-devel (and probably port it to R 4.5.0 patched) quite soon (but not yet today). Best regards, Martin Maechler >>>>> Ivan Krylov via R-devel >>>>> on Fri, 23 May 2025 17:14:57 +0300 writes: > ? Fri, 23 May 2025 11:47:33 +0000 >

Dear list, I'd like to report a bug in `prettyNum()`. When called with a numeric vector, the `replace.zero` argument is disregarded. > prettyNum(0, zero.print = "- ", replace.zero = TRUE) [1] "-" Warning message: In .format.zeros(x, zero.print, replace = replace.zero) : 'zero.print' is truncated to fit into formatted zeros; consider 'replace=TRUE' A

Thanks for the contribution Mikko! For testing future patches, you can actually do it right in the web browser, thanks to Heather Turner's R Dev Container, see instructions here https://contributor.r-project.org/r-dev-env/container_setup/ Best Toby On Mon, May 26, 2025 at 6:28?PM Martin Maechler <maechler at stat.math.ethz.ch> wrote: > Thank you, Marttila and Ivan, > > As

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 it's not limited to my box at least. I see the problem in both R 3.5.3 and R 3.3.2. options(scipen=-100) prettyNum(1, digits=0) [1] "%#4.0-1e" prettyNum(2,

You fed it two characters, "dash" and "space" and it only wanted one character so it truncated to the first character and warned you that that's what it did. If you had your space before the dash, it would have used that as your replacement character > prettyNum(0, zero.print = " - ", replace = TRUE) [1] " " Warning message: In .format.zeros(x,

Dear list, Have I stumbled upon a bug, or am I holding `prettyNum()` wrong? Please see below. Best, Mikko > prettyNum(0, zero.print = "- ", replace.zero = TRUE) [1] "-" Warning message: In .format.zeros(x, zero.print, replace = replace.zero) : 'zero.print' is truncated to fit into formatted zeros; consider 'replace=TRUE' > prettyNum(0, zero.print =

Tim, The purpose of the `replace.zero` argument is to allow longer replacements. See for example the behaviour with a character vector input: > prettyNum("0", zero.print = "- ", replace.zero = TRUE) [1] "- " I'm pretty sure this is a bug, and have now posted the relevant details on r-devel. A fix would be below. Best, Mikko diff --git

R> order(1, na.last=NA) Error in apply(sapply(z, is.na), 1, any) : dim(X) must have a positive length This bug appears unrelated to PR#1906, and so the fix of 8/15 doesn't help. It comes from the line inside order(): ok <- !apply(sapply(z, is.na), 1, any) where z=list(1) in my example. sapply() returns a single-element vector, not a matrix, making apply() unhappy. This might

I sent a message to <r-announce at stat.math.ethz.ch> last Thursday ("New package: colSums"), and still haven't seen it echoed on r-help or on the web archive (in fact there is no r-announce web archive for 2002). Is something broken? Did I need to use <r-announce at lists.R-project.org> instead? -- -- David Brahm (brahm at alum.mit.edu)

help(library) says: "`.Last.lib' is called when a package is loaded." Probably should be "...is detached." -- David Brahm (brahm@alum.mit.edu) --please do not edit the information below-- Version: platform = sparc-sun-solaris2.6 arch = sparc os = solaris2.6 system = sparc, solaris2.6 status = major = 1 minor = 3.1 year = 2001

I have a Date x Stock (223 x 520) matrix of "trading volume". I can calculate a 5-day (past) average in about 1 second using: R> apply(vol, 1, filter, filter=c(0, rep(1/5,5)), sides=1) I would like to do the same with a 5-day median, e.g.: R> mymed <- function(x, n=5) { R> r <- rep(NA, length(x)) R> for (i in (n+1):length(x)) r[i] <- median(x[i-(1:n)]) R>

R> round(100000/3, -2) - 33300 [1] -7.275958e-12 I would have hoped for 0. The problem seems to be specifically for negative "digits". This is in 1.3.1 on Solaris 2.6 (full description at bottom). [Apologies for making everyone read this 3 times; my bug.report() burped.] Peter Dalgaard <p.dalgaard@biostat.ku.dk> says the problem is in fround.c, which reads in part:

On Oct 22, I sent an empty bug report (#1138) because bug.report() "ate my message". Paul Gilbert opened a new bug report (#1158) for this problem. I'm now convinced it's because I had an apostrophe in the subject line ("round() doesn't"). The bug.report documentation specifically warns against this, but the bug.report() function could also check for it! I

Environment variables set with Sys.putenv() "disappear" spontaneously (and somewhat randomly) when I load large datasets. This was reported in R-help by Dave Kane on June 4, 2001; I have not seen any further discussion. I'm not sure if I can report it as a "bug", since it is not entirely reproducible. Could someone try this and see if you have trouble too? The following

Hello, When I merge two dataframes, each created by read.table and containing no factors, the result has columns which have been converted to factor. I think this is a bug (and may be related to some fixed bugs, eg PR#1102, PR#1121), but will await comments before submitting. Also, I'm not sure if the bug is in merge() or in read.table(). I am using R-1.4.0 patch 1/13/02 on Solaris 2.6.

Environment variables set with Sys.putenv() disappear (i.e. become "") after a while, especially after heavy-duty I/O. Example: R> x <- matrix(1., 3000, 3000) R> save(x, file="myx.RData") R> Sys.putenv(HOME="/tmp") R> while (Sys.getenv("HOME") != "") {cat("ok\n"); load("myx.RData")} The loop prints