double in summary.c : isum

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

double in summary.c : isum

Matthew Dowle

Hi,

Please consider the following :

> x = as.integer(2^30-1)
[1] 1073741823
> sum(c(rep(x, 10000000), rep(-x,9999999)))
[1] 1073741824

Tested on 2.15.2 and a recent R-devel (r62132).

I'm wondering if s in isum could be LDOUBLE instead of double, like
rsum, to fix this edge case?

https://svn.r-project.org/R/trunk/src/main/summary.c

Thanks,
Matthew

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: double in summary.c : isum

Prof Brian Ripley
On 20/03/2013 12:56, Matthew Dowle wrote:

>
> Hi,
>
> Please consider the following :
>
>> x = as.integer(2^30-1)
> [1] 1073741823
>> sum(c(rep(x, 10000000), rep(-x,9999999)))
> [1] 1073741824
>
> Tested on 2.15.2 and a recent R-devel (r62132).
>
> I'm wondering if s in isum could be LDOUBLE instead of double, like
> rsum, to fix this edge case?

No, because there is no guarantee that LDOUBLE differs from double (and
platform on which it does not).

Users really need to take responsibility for the numerical stability of
calcuations they attempt.  Expecting to sum 20 million large numbers
exactly is unrealistic.

There are cases where 64-bit integer accumulators would be beneficial,
and this is one.  Unfortunately C11 does not require them but some
optional moves in that direction are planned.

>
> https://svn.r-project.org/R/trunk/src/main/summary.c
>
> Thanks,
> Matthew
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel


--
Brian D. Ripley,                  [hidden email]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: double in summary.c : isum

Matthew Dowle
On 23.03.2013 12:01, Prof Brian Ripley wrote:

> On 20/03/2013 12:56, Matthew Dowle wrote:
>>
>> Hi,
>>
>> Please consider the following :
>>
>>> x = as.integer(2^30-1)
>> [1] 1073741823
>>> sum(c(rep(x, 10000000), rep(-x,9999999)))
>> [1] 1073741824
>>
>> Tested on 2.15.2 and a recent R-devel (r62132).
>>
>> I'm wondering if s in isum could be LDOUBLE instead of double, like
>> rsum, to fix this edge case?
>
> No, because there is no guarantee that LDOUBLE differs from double
> (and platform on which it does not).

That's a reason for not using LDOUBLE at all isn't it? Yet src/main/*.c
has 19 lines using LDOUBLE e.g. arithmetic.c and cum.c as well as
summary.c.

I'd assumed LDOUBLE was being used by R to benefit from long double (or
equivalent) on platforms that support it (which is all modern Unix, Mac
and Windows as far as I know). I do realise that the edge case wouldn't
be fixed on platforms where LDOUBLE is defined as double.

What have I misunderstood?

>
> Users really need to take responsibility for the numerical stability
> of calcuations they attempt.  Expecting to sum 20 million large
> numbers exactly is unrealistic.

Trying to take responsibility, but you said no. Changing from double to
LDOUBLE would mean that something that wasn't realistic, was then
realistic (on platforms that support long double).

And it would bring open source R into line with TERR, which gets the
answer right, on 64bit Windows at least. But I'm not sure I should be as
confident in TERR as I am in open source R because I can't see its
source code.


> There are cases where 64-bit integer accumulators would be
> beneficial, and this is one.  Unfortunately C11 does not require them
> but some optional moves in that direction are planned.
>
>>
>> https://svn.r-project.org/R/trunk/src/main/summary.c
>>
>> Thanks,
>> Matthew
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: double in summary.c : isum

Duncan Murdoch-2
On 13-03-23 10:20 AM, Matthew Dowle wrote:

> On 23.03.2013 12:01, Prof Brian Ripley wrote:
>> On 20/03/2013 12:56, Matthew Dowle wrote:
>>>
>>> Hi,
>>>
>>> Please consider the following :
>>>
>>>> x = as.integer(2^30-1)
>>> [1] 1073741823
>>>> sum(c(rep(x, 10000000), rep(-x,9999999)))
>>> [1] 1073741824
>>>
>>> Tested on 2.15.2 and a recent R-devel (r62132).
>>>
>>> I'm wondering if s in isum could be LDOUBLE instead of double, like
>>> rsum, to fix this edge case?
>>
>> No, because there is no guarantee that LDOUBLE differs from double
>> (and platform on which it does not).
>
> That's a reason for not using LDOUBLE at all isn't it? Yet src/main/*.c
> has 19 lines using LDOUBLE e.g. arithmetic.c and cum.c as well as
> summary.c.
>
> I'd assumed LDOUBLE was being used by R to benefit from long double (or
> equivalent) on platforms that support it (which is all modern Unix, Mac
> and Windows as far as I know). I do realise that the edge case wouldn't
> be fixed on platforms where LDOUBLE is defined as double.

I think the problem is that there are two opposing targets in R:  we
want things to be as accurate as possible, and we want them to be
consistent across platforms. Sometimes one goal wins, sometimes the
other.  Inconsistencies across platforms give false positives in tests
that tend to make us miss true bugs.  Some people think we should never
use LDOUBLE because of that.  In other cases, the extra accuracy is so
helpful that it's worth it.  So I think you'd need to argue that the
case you found is something where the benefit outweighs the costs.
Since almost all integer sums are done exactly with the current code, is
it really worth introducing inconsistencies in the rare inexact cases?

Duncan Murdoch


>
> What have I misunderstood?
>
>>
>> Users really need to take responsibility for the numerical stability
>> of calcuations they attempt.  Expecting to sum 20 million large
>> numbers exactly is unrealistic.
>
> Trying to take responsibility, but you said no. Changing from double to
> LDOUBLE would mean that something that wasn't realistic, was then
> realistic (on platforms that support long double).
>
> And it would bring open source R into line with TERR, which gets the
> answer right, on 64bit Windows at least. But I'm not sure I should be as
> confident in TERR as I am in open source R because I can't see its
> source code.
>
>
>> There are cases where 64-bit integer accumulators would be
>> beneficial, and this is one.  Unfortunately C11 does not require them
>> but some optional moves in that direction are planned.
>>
>>>
>>> https://svn.r-project.org/R/trunk/src/main/summary.c
>>>
>>> Thanks,
>>> Matthew
>>>
>>> ______________________________________________
>>> [hidden email] mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: double in summary.c : isum

Prof Brian Ripley
On 24/03/2013 15:01, Duncan Murdoch wrote:

> On 13-03-23 10:20 AM, Matthew Dowle wrote:
>> On 23.03.2013 12:01, Prof Brian Ripley wrote:
>>> On 20/03/2013 12:56, Matthew Dowle wrote:
>>>>
>>>> Hi,
>>>>
>>>> Please consider the following :
>>>>
>>>>> x = as.integer(2^30-1)
>>>> [1] 1073741823
>>>>> sum(c(rep(x, 10000000), rep(-x,9999999)))
>>>> [1] 1073741824
>>>>
>>>> Tested on 2.15.2 and a recent R-devel (r62132).
>>>>
>>>> I'm wondering if s in isum could be LDOUBLE instead of double, like
>>>> rsum, to fix this edge case?
>>>
>>> No, because there is no guarantee that LDOUBLE differs from double
>>> (and platform on which it does not).
>>
>> That's a reason for not using LDOUBLE at all isn't it? Yet src/main/*.c
>> has 19 lines using LDOUBLE e.g. arithmetic.c and cum.c as well as
>> summary.c.
>>
>> I'd assumed LDOUBLE was being used by R to benefit from long double (or
>> equivalent) on platforms that support it (which is all modern Unix, Mac
>> and Windows as far as I know). I do realise that the edge case wouldn't

Actually, you don't know.  Really only on almost all Intel ix86: most
other current CPUs do not have it in hardware.  C99/C11 require long
double, but does not require the accuracy that you are thinking of and
it can be implemented in software.

Note that even on ix86 this is something that can be switched on or off
in the CPU: last time I looked (years ago) it was off by default in
Microsoft compilers.

All C99 requires is that long double is at least as precise as double.
C11 recommends in §F.2

Recommended practice
2 The long double type should match an IEC 60559 extended format.

Notice the 'an': there are two such formats, and both are in use on R
platforms.  But then some OS/compiler suppliers have never paid any heed
to ISO standards.

>> be fixed on platforms where LDOUBLE is defined as double.
>
> I think the problem is that there are two opposing targets in R:  we
> want things to be as accurate as possible, and we want them to be
> consistent across platforms. Sometimes one goal wins, sometimes the
> other.  Inconsistencies across platforms give false positives in tests
> that tend to make us miss true bugs.  Some people think we should never
> use LDOUBLE because of that.  In other cases, the extra accuracy is so
> helpful that it's worth it.  So I think you'd need to argue that the
> case you found is something where the benefit outweighs the costs. Since
> almost all integer sums are done exactly with the current code, is it
> really worth introducing inconsistencies in the rare inexact cases?

But as I said lower down, a 64-bit integer accumulator would be helpful,
C99/C11 requires one at least that large and it is implemented in
hardware on all known R platforms.  So there is a way to do this pretty
consistently across platforms.


>
> Duncan Murdoch
>
>
>>
>> What have I misunderstood?
>>
>>>
>>> Users really need to take responsibility for the numerical stability
>>> of calcuations they attempt.  Expecting to sum 20 million large
>>> numbers exactly is unrealistic.
>>
>> Trying to take responsibility, but you said no. Changing from double to
>> LDOUBLE would mean that something that wasn't realistic, was then
>> realistic (on platforms that support long double).
>>
>> And it would bring open source R into line with TERR, which gets the
>> answer right, on 64bit Windows at least. But I'm not sure I should be as
>> confident in TERR as I am in open source R because I can't see its
>> source code.
>>
>>
>>> There are cases where 64-bit integer accumulators would be
>>> beneficial, and this is one.  Unfortunately C11 does not require them
>>> but some optional moves in that direction are planned.
>>>
>>>>
>>>> https://svn.r-project.org/R/trunk/src/main/summary.c
>>>>
>>>> Thanks,
>>>> Matthew
>>>>
>>>> ______________________________________________
>>>> [hidden email] mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>


--
Brian D. Ripley,                  [hidden email]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: double in summary.c : isum

Matthew Dowle
On 25.03.2013 09:20, Prof Brian Ripley wrote:

> On 24/03/2013 15:01, Duncan Murdoch wrote:
>> On 13-03-23 10:20 AM, Matthew Dowle wrote:
>>> On 23.03.2013 12:01, Prof Brian Ripley wrote:
>>>> On 20/03/2013 12:56, Matthew Dowle wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Please consider the following :
>>>>>
>>>>>> x = as.integer(2^30-1)
>>>>> [1] 1073741823
>>>>>> sum(c(rep(x, 10000000), rep(-x,9999999)))
>>>>> [1] 1073741824
>>>>>
>>>>> Tested on 2.15.2 and a recent R-devel (r62132).
>>>>>
>>>>> I'm wondering if s in isum could be LDOUBLE instead of double,
>>>>> like
>>>>> rsum, to fix this edge case?
>>>>
>>>> No, because there is no guarantee that LDOUBLE differs from double
>>>> (and platform on which it does not).
>>>
>>> That's a reason for not using LDOUBLE at all isn't it? Yet
>>> src/main/*.c
>>> has 19 lines using LDOUBLE e.g. arithmetic.c and cum.c as well as
>>> summary.c.
>>>
>>> I'd assumed LDOUBLE was being used by R to benefit from long double
>>> (or
>>> equivalent) on platforms that support it (which is all modern Unix,
>>> Mac
>>> and Windows as far as I know). I do realise that the edge case
>>> wouldn't
>
> Actually, you don't know.  Really only on almost all Intel ix86: most
> other current CPUs do not have it in hardware.  C99/C11 require long
> double, but does not require the accuracy that you are thinking of
> and
> it can be implemented in software.

This is very interesting, thanks. Which of the CRAN machines don't
support LDOUBLE with higher accuracy than double, either in hardware or
software?  Yes I had assumed that all CRAN machines would do. It would
be useful to know for something else I'm working on as well.

>>> be fixed on platforms where LDOUBLE is defined as double.
>>
>> I think the problem is that there are two opposing targets in R:  we
>> want things to be as accurate as possible, and we want them to be
>> consistent across platforms. Sometimes one goal wins, sometimes the
>> other.  Inconsistencies across platforms give false positives in
>> tests
>> that tend to make us miss true bugs.  Some people think we should
>> never
>> use LDOUBLE because of that.  In other cases, the extra accuracy is
>> so
>> helpful that it's worth it.  So I think you'd need to argue that the
>> case you found is something where the benefit outweighs the costs.
>> Since
>> almost all integer sums are done exactly with the current code, is
>> it
>> really worth introducing inconsistencies in the rare inexact cases?
>
> But as I said lower down, a 64-bit integer accumulator would be
> helpful, C99/C11 requires one at least that large and it is
> implemented in hardware on all known R platforms.  So there is a way
> to do this pretty consistently across platforms.

That sounds much better. Is it just a matter of changing s to be
declared as uint64_t?

>>
>> Duncan Murdoch
>>
>>
>>>
>>> What have I misunderstood?
>>>
>>>>
>>>> Users really need to take responsibility for the numerical
>>>> stability
>>>> of calcuations they attempt.  Expecting to sum 20 million large
>>>> numbers exactly is unrealistic.
>>>
>>> Trying to take responsibility, but you said no. Changing from
>>> double to
>>> LDOUBLE would mean that something that wasn't realistic, was then
>>> realistic (on platforms that support long double).
>>>
>>> And it would bring open source R into line with TERR, which gets
>>> the
>>> answer right, on 64bit Windows at least. But I'm not sure I should
>>> be as
>>> confident in TERR as I am in open source R because I can't see its
>>> source code.
>>>
>>>
>>>> There are cases where 64-bit integer accumulators would be
>>>> beneficial, and this is one.  Unfortunately C11 does not require
>>>> them
>>>> but some optional moves in that direction are planned.
>>>>
>>>>>
>>>>> https://svn.r-project.org/R/trunk/src/main/summary.c
>>>>>
>>>>> Thanks,
>>>>> Matthew
>>>>>
>>>>> ______________________________________________
>>>>> [hidden email] mailing list
>>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>> ______________________________________________
>>> [hidden email] mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: double in summary.c : isum

Matthew Dowle
On 25.03.2013 11:27, Matthew Dowle wrote:

> On 25.03.2013 09:20, Prof Brian Ripley wrote:
>> On 24/03/2013 15:01, Duncan Murdoch wrote:
>>> On 13-03-23 10:20 AM, Matthew Dowle wrote:
>>>> On 23.03.2013 12:01, Prof Brian Ripley wrote:
>>>>> On 20/03/2013 12:56, Matthew Dowle wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Please consider the following :
>>>>>>
>>>>>>> x = as.integer(2^30-1)
>>>>>> [1] 1073741823
>>>>>>> sum(c(rep(x, 10000000), rep(-x,9999999)))
>>>>>> [1] 1073741824
>>>>>>
>>>>>> Tested on 2.15.2 and a recent R-devel (r62132).
>>>>>>
>>>>>> I'm wondering if s in isum could be LDOUBLE instead of double,
>>>>>> like
>>>>>> rsum, to fix this edge case?
>>>>>
>>>>> No, because there is no guarantee that LDOUBLE differs from
>>>>> double
>>>>> (and platform on which it does not).
>>>>
>>>> That's a reason for not using LDOUBLE at all isn't it? Yet
>>>> src/main/*.c
>>>> has 19 lines using LDOUBLE e.g. arithmetic.c and cum.c as well as
>>>> summary.c.
>>>>
>>>> I'd assumed LDOUBLE was being used by R to benefit from long
>>>> double (or
>>>> equivalent) on platforms that support it (which is all modern
>>>> Unix, Mac
>>>> and Windows as far as I know). I do realise that the edge case
>>>> wouldn't
>>
>> Actually, you don't know.  Really only on almost all Intel ix86:
>> most
>> other current CPUs do not have it in hardware.  C99/C11 require long
>> double, but does not require the accuracy that you are thinking of
>> and
>> it can be implemented in software.
>
> This is very interesting, thanks. Which of the CRAN machines don't
> support LDOUBLE with higher accuracy than double, either in hardware
> or software?  Yes I had assumed that all CRAN machines would do. It
> would be useful to know for something else I'm working on as well.
>
>>>> be fixed on platforms where LDOUBLE is defined as double.
>>>
>>> I think the problem is that there are two opposing targets in R:  
>>> we
>>> want things to be as accurate as possible, and we want them to be
>>> consistent across platforms. Sometimes one goal wins, sometimes the
>>> other.  Inconsistencies across platforms give false positives in
>>> tests
>>> that tend to make us miss true bugs.  Some people think we should
>>> never
>>> use LDOUBLE because of that.  In other cases, the extra accuracy is
>>> so
>>> helpful that it's worth it.  So I think you'd need to argue that
>>> the
>>> case you found is something where the benefit outweighs the costs.
>>> Since
>>> almost all integer sums are done exactly with the current code, is
>>> it
>>> really worth introducing inconsistencies in the rare inexact cases?
>>
>> But as I said lower down, a 64-bit integer accumulator would be
>> helpful, C99/C11 requires one at least that large and it is
>> implemented in hardware on all known R platforms.  So there is a way
>> to do this pretty consistently across platforms.
>
> That sounds much better. Is it just a matter of changing s to be
> declared as uint64_t?

Typo. I meant int64_t.

>
>>>
>>> Duncan Murdoch
>>>
>>>
>>>>
>>>> What have I misunderstood?
>>>>
>>>>>
>>>>> Users really need to take responsibility for the numerical
>>>>> stability
>>>>> of calcuations they attempt.  Expecting to sum 20 million large
>>>>> numbers exactly is unrealistic.
>>>>
>>>> Trying to take responsibility, but you said no. Changing from
>>>> double to
>>>> LDOUBLE would mean that something that wasn't realistic, was then
>>>> realistic (on platforms that support long double).
>>>>
>>>> And it would bring open source R into line with TERR, which gets
>>>> the
>>>> answer right, on 64bit Windows at least. But I'm not sure I should
>>>> be as
>>>> confident in TERR as I am in open source R because I can't see its
>>>> source code.
>>>>
>>>>
>>>>> There are cases where 64-bit integer accumulators would be
>>>>> beneficial, and this is one.  Unfortunately C11 does not require
>>>>> them
>>>>> but some optional moves in that direction are planned.
>>>>>
>>>>>>
>>>>>> https://svn.r-project.org/R/trunk/src/main/summary.c
>>>>>>
>>>>>> Thanks,
>>>>>> Matthew
>>>>>>
>>>>>> ______________________________________________
>>>>>> [hidden email] mailing list
>>>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>
>>>> ______________________________________________
>>>> [hidden email] mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>
>>>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: double in summary.c : isum

Matthew Dowle
On 25.03.2013 11:31, Matthew Dowle wrote:

> On 25.03.2013 11:27, Matthew Dowle wrote:
>> On 25.03.2013 09:20, Prof Brian Ripley wrote:
>>> On 24/03/2013 15:01, Duncan Murdoch wrote:
>>>> On 13-03-23 10:20 AM, Matthew Dowle wrote:
>>>>> On 23.03.2013 12:01, Prof Brian Ripley wrote:
>>>>>> On 20/03/2013 12:56, Matthew Dowle wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Please consider the following :
>>>>>>>
>>>>>>>> x = as.integer(2^30-1)
>>>>>>> [1] 1073741823
>>>>>>>> sum(c(rep(x, 10000000), rep(-x,9999999)))
>>>>>>> [1] 1073741824
>>>>>>>
>>>>>>> Tested on 2.15.2 and a recent R-devel (r62132).
>>>>>>>
>>>>>>> I'm wondering if s in isum could be LDOUBLE instead of double,
>>>>>>> like
>>>>>>> rsum, to fix this edge case?
>>>>>>
>>>>>> No, because there is no guarantee that LDOUBLE differs from
>>>>>> double
>>>>>> (and platform on which it does not).
>>>>>
>>>>> That's a reason for not using LDOUBLE at all isn't it? Yet
>>>>> src/main/*.c
>>>>> has 19 lines using LDOUBLE e.g. arithmetic.c and cum.c as well as
>>>>> summary.c.
>>>>>
>>>>> I'd assumed LDOUBLE was being used by R to benefit from long
>>>>> double (or
>>>>> equivalent) on platforms that support it (which is all modern
>>>>> Unix, Mac
>>>>> and Windows as far as I know). I do realise that the edge case
>>>>> wouldn't
>>>
>>> Actually, you don't know.  Really only on almost all Intel ix86:
>>> most
>>> other current CPUs do not have it in hardware.  C99/C11 require
>>> long
>>> double, but does not require the accuracy that you are thinking of
>>> and
>>> it can be implemented in software.
>>
>> This is very interesting, thanks. Which of the CRAN machines don't
>> support LDOUBLE with higher accuracy than double, either in hardware
>> or software?  Yes I had assumed that all CRAN machines would do. It
>> would be useful to know for something else I'm working on as well.
>>
>>>>> be fixed on platforms where LDOUBLE is defined as double.
>>>>
>>>> I think the problem is that there are two opposing targets in R:  
>>>> we
>>>> want things to be as accurate as possible, and we want them to be
>>>> consistent across platforms. Sometimes one goal wins, sometimes
>>>> the
>>>> other.  Inconsistencies across platforms give false positives in
>>>> tests
>>>> that tend to make us miss true bugs.  Some people think we should
>>>> never
>>>> use LDOUBLE because of that.  In other cases, the extra accuracy
>>>> is so
>>>> helpful that it's worth it.  So I think you'd need to argue that
>>>> the
>>>> case you found is something where the benefit outweighs the costs.
>>>> Since
>>>> almost all integer sums are done exactly with the current code, is
>>>> it
>>>> really worth introducing inconsistencies in the rare inexact
>>>> cases?
>>>
>>> But as I said lower down, a 64-bit integer accumulator would be
>>> helpful, C99/C11 requires one at least that large and it is
>>> implemented in hardware on all known R platforms.  So there is a
>>> way
>>> to do this pretty consistently across platforms.
>>
>> That sounds much better. Is it just a matter of changing s to be
>> declared as uint64_t?
>
> Typo. I meant int64_t.

But even 64-bit integer might under or overflow. Which is one of the
reasons for accumulating in double (or LDOUBLE) isn't it? To save a
test for over/underflow on each iteration.

>
>>
>>>>
>>>> Duncan Murdoch
>>>>
>>>>
>>>>>
>>>>> What have I misunderstood?
>>>>>
>>>>>>
>>>>>> Users really need to take responsibility for the numerical
>>>>>> stability
>>>>>> of calcuations they attempt.  Expecting to sum 20 million large
>>>>>> numbers exactly is unrealistic.
>>>>>
>>>>> Trying to take responsibility, but you said no. Changing from
>>>>> double to
>>>>> LDOUBLE would mean that something that wasn't realistic, was then
>>>>> realistic (on platforms that support long double).
>>>>>
>>>>> And it would bring open source R into line with TERR, which gets
>>>>> the
>>>>> answer right, on 64bit Windows at least. But I'm not sure I
>>>>> should be as
>>>>> confident in TERR as I am in open source R because I can't see
>>>>> its
>>>>> source code.
>>>>>
>>>>>
>>>>>> There are cases where 64-bit integer accumulators would be
>>>>>> beneficial, and this is one.  Unfortunately C11 does not require
>>>>>> them
>>>>>> but some optional moves in that direction are planned.
>>>>>>
>>>>>>>
>>>>>>> https://svn.r-project.org/R/trunk/src/main/summary.c
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Matthew
>>>>>>>
>>>>>>> ______________________________________________
>>>>>>> [hidden email] mailing list
>>>>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>>
>>>>> ______________________________________________
>>>>> [hidden email] mailing list
>>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>>
>>>>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel