similar to: bug in format.default: trim=TRUE does not always work as advertised (PR#9114)

Hi! If I use format() on numeric vector, na.encode argument does not have any e= ffect. This was reported before: - https://stat.ethz.ch/pipermail/r-help/2007-October/143881.html - http://tolstoy.newcastle.edu.au/R/e2/devel/06/09/0360.html It works for other (say character) classes! > format(c("a", NA), na.encode=3DTRUE) [1] "a " "NA" >

Hmisc includes a latex function which typesets objects in latex. A great time saver. I am using it to create a large number of tables in a loop in conjuction with prettyNum to place '000s separators in the numbers (i.e. 1,000,000 not 1000000). This converts the numbers to strings. The Hmisc/latex default is to left justify characters - which doesn't work in this case. Hmisc/latex

Full_Name: Dirk Jacob Version: R 2.8.1 and 2.9.1 OS: Win XP Submission from: (NULL) (153.96.32.62) I want to convert numbers to strings like: > inputs= c(0.3+0*(1:12) ) > (format(inputs,digits=3,scientific=T,collapse=" ")) and it works [1] "3e-01" "3e-01" "3e-01" "3e-01" "3e-01" "3e-01" "3e-01"

A client cannot attempt TRIM on a read-only connection (we already filter it in connections.c with EROFS); as such, it makes no sense to query the plugin's .can_trim nor to advertise TRIM support to the client on such a connection, similar to how we do not advertise WRITE_ZEROES. FUA only has defined meanings on write operations, but the NBD protocol allows us to advertise it on reads and to

Hi I've imported some data from a oracle database and the strings have a lot of blank space (because of the delimiter). I want to remove these blanks space with something similar to a trim function. I don't find a trim function or something similar. Can someone give a help on this ? Thanks EJ -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-help

I feel like an idiot posting this because every language I've ever seen has a string function that trims blanks off strings (off the front or back or both). Ideally, it would process whole data frames/matrices etc but I don't even see one that processes a single string. But I've searched and I don't even see that. There's a strtrim function but it does something completely

Hello, helpeRs, I have a vector of numbers from 1-365 (days of the year) that I would like to convert to a date. There are no NA's and no missing values. I did not insert leading zero's for numbers less than 100. Using the syntax: dat$doy.1 <- as.numeric(format(dat$doy, "%j" )) I get the following error message: Error in prettyNum(.Internal(format(x, trim, digits,

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

>>>>> peter dalgaard >>>>> on Fri, 22 Mar 2019 17:30:19 +0100 writes: > 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? It seems (and note we are talking about format.default()

Dataframe cust has Date-type column open.date. I wish to set up another column, with (first day of) the quarter of open.date. To be comprehensive (of course, improvement suggestions are welcome), month = function(date) { return(as.numeric(format(date,"%m"))) } first.day.of.month = function(date) { return(date + 1 - as.numeric(format(date,"%d"))) } first.day.of.quarter =

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

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,

Under R-1.5.0 on Solaris 2.6: R> prettyNum(123456789, big.mark=",") [1] ",123,456,789" and that bad behavior (leading comma) spills into formatC as well: R> formatC(123456789, digits=0, format="f", big.mark=",") [1] ",123,456,789" Looks to me like a bug in src/library/base/R/format.R, in function prettyNum: B.[i.big] <-

(I see this in both R-patched r43124 and R-devel r43233.) In the Argument section of ?mean: trim the fraction (0 to 0.5) of observations to be trimmed from each end of x before the mean is computed. Values outside that range are taken as the nearest endpoint. Then in the Value section: If trim is non-zero, a symmetrically trimmed mean is computed with a fraction of trim observations

> On Jan 10, 2014, at 12:58 PM, Elliot Dierksen wrote: >> I am using NUT 2.6.5 as part of FreeNAS 9.2.0. I am using an APC >> Smart-UPS >> 5000 RM DL4 with a AP9619 network management card. NUT properly detects >> when the UPS goes on battery and initiates a shutdown after the >> configured >> time. The problem I have is that I am using a 208V unit on a 240V

Hi -- I'm looking for alternatives to regex for a fairly simply 'reformatting' problem. Alternatives only because a lot of folks have trouble parsing/interpreting regex expressions, and I'm looking for suggestions for something more 'transparent'. Here is an example of what I'm trying to do. Take the following string, which I call x, and for each character in the

Hi I am not sure if it is more readable > paste(paste(unlist(strsplit(x,"")),".", sep=""), collapse="") [1] "1.0.1.1.0.1.1.1." If you did not want last dot, it is a bit shorter. > paste(unlist(strsplit(x,"")),collapse=".") [1] "1.0.1.1.0.1.1.1" > Cheers Petr Tento e-mail a jak?koliv k n?mu p?ipojen?

--- mllib/common_utils.ml | 29 +++++++++++++++++++++++++++++ mllib/common_utils.mli | 8 ++++++++ 2 files changed, 37 insertions(+) diff --git a/mllib/common_utils.ml b/mllib/common_utils.ml index 64bf3d3..34e1285 100644 --- a/mllib/common_utils.ml +++ b/mllib/common_utils.ml @@ -49,6 +49,35 @@ module String = struct and len = length str in len >= sufflen && sub str

On Jan 10, 2014, at 12:58 PM, Elliot Dierksen wrote: > I am using NUT 2.6.5 as part of FreeNAS 9.2.0. I am using an APC Smart-UPS > 5000 RM DL4 with a AP9619 network management card. NUT properly detects > when the UPS goes on battery and initiates a shutdown after the configured > time. The problem I have is that I am using a 208V unit on a 240V circuit. > That means the normal

We already have support in the file driver for punching holes during .zero with the may_trim flag (via FALLOC_FL_PUNCH_HOLE), so we should use the same mechanism to support .trim. Note that the NBD spec says that trim is advisory (we can return success even if we did nothing); but at the same time, it's nicer to avoid advertising the feature if we know for sure we can't do it, so we also