The problems with whether or not + is associative in certain circumstances have been around since people started rounding numbers. These problems are not unique to multiprocessing.
As to moving data around between various memories - I am not really clear on the architecture of multi-core systems, but don't they consist of multiple processors, each processor having its own cache but sharing a common main memory? If so, then there is not a problem of having to move blocks of data among different main memories. On Dec 20, 2007 12:08 AM, Mark D. Niemiec <[EMAIL PROTECTED]> wrote: > Viktor Cerovski <[EMAIL PROTECTED]> wrote: > > > An implicit assumption in such parallelization of +/ is that + is > > associative. > > This, strictly speaking, is true neither for floating point numbers nor > > for machine integers. Furthermore, for extended precision integers > > associativity holds but it might still be desirable to be able to > control > > the order of execution to make time and/or space smaller. > > While it cannot be made associative for floating point (without a lot of > work), > the only bar to associativity for machine integers is in cases where an > intermediate sum overflows an integer and is promoted to floating point. > > On 32-bit machines, floating-point numbers have more precision (53 bits), > so the only way you could lose data (and associativity) is by adding a > list of > 2^(53-32), or around 2 million or more very large numbers. > > On 64-bit machines, however, floating-point has less precision than > integers, so > integer overflow will likely lose associativity. > > (Then again, this is an implementation issue. It would be very easy for a > distributed implementation to compute sums of integers using double > machine words, and then only convert to floating point if the final > result won't fit in a single machine word - not only is this faster, but > it also guarantees accuracy and associativity. This can only overflow on > 32-bit machines for arrays with more than 4 billion items - and you would > run out of memory and address space long before that. And on 64-bit > machines, > it would take an array of more than 64 million terabytes. I'm not overly > concerned.) > > -- Mark D. Niemiec <[EMAIL PROTECTED]> > > > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
