search for: zeroed

? 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 >

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, 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

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 =

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

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

Hi, Dear R-help I know there are some R package to deal with zero-inflated count data. But I am now looking for R package to deal with zero-inflated continuous data. The response variable (Y) in my dataset contains a larger mount of zero and the Non-zero response are quite right skewed. Now what i am doing is first to use a logistic regression on covariates (X) to estimate the probability of Y

..., it means that these requests are advisory (since trim is), and > we can just ignore them if the server does not support trim. What qemu-img sends shouldn't be a NBD_CMD_TRIM request (which is indeed advisory), but a NBD_CMD_WRITE_ZEROES request. qemu-img relies on the image actually being zeroed after this. Kevin

Folks, If I have a vector such as the following: x <- c(0, -1, -1, -1, 0, 0, 1, -1, 1, 0) and I want to replace the zeroes by the nearest non-zero number to the left, is there a more elegant way to do this than the following loop? y <- x for (i in 2 : length(x)) { if (y[i] == 0) { y[i] <- y[i - 1] } } > y [1] 0 -1 -1 -1 -1 -1 1 -1 1 1 You can see the

Add coverage for the previous patch. Although most plugins don't change can_fua or can_fast_zero on the fly, the code should still not abort when calling .zero with a flag that was permitted by the previous open but not permitted by the current open. Signed-off-by: Eric Blake <eblake@redhat.com> --- tests/Makefile.am | 2 + tests/test-retry-zero-flags.sh | 126

Hello Imagine I have a vector with ones and zeroes I write it compactly: 1111111100001111111111110000000001111111111100101 I need to get a new vector replacing the "N" ones following the zeroes to new zeroes. For example for N = 3 1111111100001111111111110000000001111111111100101 becomes 1111111100000001111111110000000000001111111100000 I can do it with a for loop but I've read

Hi, I recently updated to R 3.0.1. I'm running linux ubuntu 12.04. I realized that I have to update all the installed packages so I run > update.packages(checkBuilt=TRUE) as described here http://www.r-bloggers.com/r-3-0-0-is-released-whats-new-and-how-to-upgrade/ . The first thing it did was telling me that it will not update several packages. When it was finished I used the warnings

On 2/17/20 9:13 AM, Max Reitz wrote: > Hi, > > It’s my understanding that without some is_zero infrastructure for QEMU, > it’s impossible to implement this flag in qemu’s NBD server. You're right that we may need some more infrastructure before being able to decide when to report this bit in all cases. But for raw files, that infrastructure already exists: does block_status at

...individual small write requests for unallocated >> parts of the image later on. At one point, there was a proposal to have the NBD protocol add something where the server could advertise to the client if it is known at initial connection time that the export is starting life with ALL sectors zeroed. (Easy to prove for a just-created sparse file, a bit harder to prove for a block device although at least some iscsi devices do have queries to learn if the entire device is unallocated). This has not yet been implemented in the NBD protocol, but may be worth doing; it is something that is sligh...

Hi everyone, I have a matrix that has a combination of zeros and NAs. When I perform certain calculations on the matrix, the zeros generate "Inf" values. Is there a way to either convert the zeros in the matrix to NAs, or only perform the calculations if not zero (i.e. like using something similar to an !all(is.na() construct)? Thanks, rcoder -- View this message in context:

Hi All, APFloat::fusedMultiplyAdd currently computes the wrong signed zero when small negative results are truncated back to zero in standard precision. The following snippet handles the signedness in fusedMultiplyAdd: /* If two numbers add (exactly) to zero, IEEE 754 decrees it is a positive zero unless rounding to minus infinity, except that adding two like-signed zeroes gives that

Hello, everyone, There's a problem about zero in R and I really need your help. I have a vector shown as x=c(0.1819711,0.4811463,0.1935151,0.1433675), The sum of this vector is shown as 1 in R, but when I type 1-sum(x), the value is not zero, but -2.220446e-16. I can accept that this value is quite small and could be seen as zero, but there would be a problem when it's not really

> -----Original Message----- > From: Stefan Hajnoczi [mailto:stefanha at redhat.com] > Sent: Thursday, June 7, 2018 9:10 PM > To: Liu, Changpeng <changpeng.liu at intel.com> > Cc: virtualization at lists.linux-foundation.org; cavery at redhat.com; > jasowang at redhat.com; pbonzini at redhat.com; Wang, Wei W > <wei.w.wang at intel.com> > Subject: Re: [PATCH v6]

> -----Original Message----- > From: Stefan Hajnoczi [mailto:stefanha at redhat.com] > Sent: Thursday, June 7, 2018 9:10 PM > To: Liu, Changpeng <changpeng.liu at intel.com> > Cc: virtualization at lists.linux-foundation.org; cavery at redhat.com; > jasowang at redhat.com; pbonzini at redhat.com; Wang, Wei W > <wei.w.wang at intel.com> > Subject: Re: [PATCH v6]