# Proposal: more accurate seq(from, to, length=n) Classic List Threaded 3 messages Reply | Threaded
Open this post in threaded view
|

## 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)) . ______________________________________________ [hidden email] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

## Re: Proposal: more accurate seq(from, to, length=n)

 Suharto, My 2c inline. On Fri, Sep 7, 2018 at 2:34 PM, Suharto Anggono Suharto Anggono via R-devel <[hidden email]> 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)))  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 > ______________________________________________ > [hidden email] 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]] ______________________________________________ [hidden email] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

## Re: Proposal: more accurate seq(from, to, length=n)

 In reply to this post by R devel mailing list I just thought that returning a more accurate result was better and that (1:10)/10 was an obvious way to calculate. It turned out that it was not that easy. I found that calculation that I proposed previously was not accurate for seq(-5, 5, length=101). I then thought of from + (0:(length.out - 1))/((length.out - 1)/(to - from)) , that is dividing by (1/by) instead of multiplying by 'by'. But I then found that 1/(1/49) didn't give 49. So, now I am proposing dividing by (1/by) selectively, like from + if (abs(to - from) < length.out - 1 && abs(to - from) >= 2^(-22)  # exact with 16 significant digits ) (0:(length.out - 1))/((length.out - 1)/(to - from)) else (0:(length.out - 1))*((to - from)/(length.out - 1)) Not changing 'seq.default' is fine, too. -------------------------------------------- On Sat, 8/9/18, Gabe Becker <[hidden email]> wrote:  Subject: Re: [Rd] Proposal: more accurate seq(from, to, length=n)  Cc: "r-devel" <[hidden email]>  Date: Saturday, 8 September, 2018, 5:38 AM  Suharto,  My 2c  inline.  On Fri,  Sep 7, 2018 at 2:34 PM, Suharto Anggono Suharto Anggono via  R-devel <[hidden email]>  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)))   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  ______________________________ ________________  [hidden email]  mailing list  https://stat.ethz.ch/mailman/ listinfo/r-devel  --  Gabriel Becker, Ph.DScientistBioinformatics and  Computational BiologyGenentech Research ______________________________________________ [hidden email] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel