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