R devel - Sep 2018 - Proposal: more accurate seq(from, to, length=n)

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 <becker.gabe at gene.com> wrote:

 Subject: Re: [Rd] Proposal: more accurate seq(from, to, length=n)

 Cc: "r-devel" <r-devel at r-project.org>
 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 <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.DScientistBioinformatics and
 Computational BiologyGenentech Research