I think these classes are targeted at use cases such as gathering
real-time statistics of profiling or business data, where data comes in
from various sources in real-time and statistics are sampled in
real-time too...
For bulk processing, the new streams API seems more appropriate. I think
the user might be able to control the order of operations applied
(j.u.stream.Spliterator API indicates that the spliting of work among
FJP threads could be controled and we can hope that the order of
reduction of intermediary results would also be controllable by the user
or at least defined).
Can streams API developers shed some light on that?
Regards, Peter
On 01/14/2013 07:18 AM, Howard Lovatt wrote:
If you make a binary tree and sum it, the rounding errors aren't that bad and
this algorithm is easy to parallelise.
Higham, Nicholas J 1993 the accuracy of floating point summation SIAM Sci Comp
14 (4) 783-799
Also see Wikipedia for a description of Kahan summation and a general
discussion of this topic.
Why not commit to binary tree reductions and that will allow everyone to
understand what is going on and design lambdas accordingly.
-- Howard.
Sent from my iPad
On 13/01/2013, at 2:04 AM, Doug Lea <d...@cs.oswego.edu> wrote:
On 01/11/13 21:37, Joe Darcy wrote:
I would prefer to cautionary note along the lines of "if you want numerical
accuracy, take care to use a summation algorithm with defined worst-case
behavior."
(Varying magnitude is not so much of a problem if you add things up in the right
order.)
Thanks. I do not believe such an algorithm exists, because
no ordering control is possible, and all other known accuracy
improvements (like Kahn) require multiword atomicity, which we
explicitly do not provide.
Which leaves me thinking that the current disclaimer (below)
is the best we can do.
-Doug
"The order of accumulation within or across threads is not guaranteed.
Thus, this class may not be applicable if numerical stability is
required, especially when combining values of substantially different
orders of magnitude."
