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

Suharto Anggono Suharto Anggono @uh@rto_@nggono @ending from y@hoo@com
Sat Sep 8 13:00:17 CEST 2018

```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 using gene.com> wrote:

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

Cc: "r-devel" <r-devel using 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 using 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)

from + (0:(length.out - 1)) * ((to - from)/(length.out - 1))
.

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

______________________________ ________________

R-devel using r-project.org
mailing list

https://stat.ethz.ch/mailman/
listinfo/r-devel

--
Gabriel Becker, Ph.DScientistBioinformatics and
Computational BiologyGenentech Research

```