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

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

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

R devel mailing list
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)

Gabe Becker
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)))

[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)

R devel mailing list
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)))
 [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