Suharto Anggono Suharto Anggono
2018-Sep-07 21:34 UTC
[Rd] Proposal: more accurate seq(from, to, length=n)
In R, seq(0, 1, 0.1) gives the same result as (0:10)*0.1. It is not the same as c(0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1) , as 0.1 is not represented exactly. I am fine with it. In R, seq(0, 1, length=11) gives the same result as seq(0, 1, 0.1). However, for seq(0, 1, length=11), it is more accurate to return c(0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1) . It can be obtained by (0:10)/10. When 'from', 'to', and 'length.out' are specified and length.out > 2, I propose for function 'seq.default' in R to use something like from + ((0:(length.out - 1))/(length.out - 1)) * (to - from) instead of something like from + (0:(length.out - 1)) * ((to - from)/(length.out - 1)) .
Suharto, My 2c inline. On Fri, Sep 7, 2018 at 2:34 PM, Suharto Anggono Suharto Anggono via R-devel <r-devel at r-project.org> wrote:> In R, > seq(0, 1, 0.1) > gives the same result as > (0:10)*0.1. > It is not the same as > c(0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1) , > as 0.1 is not represented exactly. I am fine with it. > > In R, > seq(0, 1, length=11) > gives the same result as > seq(0, 1, 0.1). > However, for > seq(0, 1, length=11), > it is more accurate to return > c(0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1) .It can be obtained by> (0:10)/10. > > When 'from', 'to', and 'length.out' are specified and length.out > 2, I > propose for function 'seq.default' in R to use something like > from + ((0:(length.out - 1))/(length.out - 1)) * (to - from) > instead of something like > from + (0:(length.out - 1)) * ((to - from)/(length.out - 1)) . >In your example case under 3.50 on my system these two expressions give results which return TRUE from all.equal, which is the accepted way of comparing non-integer numerics in R for "sameness".> from = 0> to = 1> length.out = 11> all.equal(from + ((0:(length.out - 1))/(length.out - 1)) * (to - from),from + (0:(length.out - 1)) * ((to - from)/(length.out - 1))) [1] TRUE Given that I'm wondering what the benefit you're looking for here is that would outweigh the very large set of existing code whose behavior would technically change under this change. Then again, it wouldn't change with respect to the accepted all.equal test, so I guess you could argue that either there's "no change" or the change is ok? I'd still like to know what practical problem you're trying to solve though. if you're looking for the ability to use == to compare non integer sequences generated different ways, as far as I understand the answer is that you shouldn't be expecting to be able to do that. Best, ~G> ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >-- Gabriel Becker, Ph.D Scientist Bioinformatics and Computational Biology Genentech Research [[alternative HTML version deleted]]