On Sun, 16 Jul 2006 17:11:50 +0200 "Henrik Sundberg" <[EMAIL PROTECTED]> wrote:
> 2006/7/16, Henrik Sundberg <[EMAIL PROTECTED]>: > > 2006/7/16, Andy Pepperdine <[EMAIL PROTECTED]>: > > > On Sunday 16 July 2006 06:48, Andrius Aštrauskas wrote: > > > > On Fri, 14 Jul 2006 13:32:45 +0200 > > > > > > > > Jurgen Stigter <[EMAIL PROTECTED]> wrote: > > > > > /I am using version 2.0 of OpenOffice.org. My problem is :/ > > > > > > > > > > The MOD function is returning -512 instead of 0 (though each > > > > > of the factors is divisable by 23): > > > > > MOD (9951585559 *370469809;23) results in -512, but when I > > > > > copy the formula and put it in another cell, the result is > > > > > -320 while > > > > > MOD (9951585559;23) results in 0 > > > > > MOD (370469809;23) results 0 > > > > > > This is almost certainly due to an integer overflow. There will > > > be a limit to the size of exact integer values. I don't know how > > > big they can be; perhaps someone else can say. > > > > log2 (9951585559) => 33.21 bits > > log2(370469809) => 28.46 bits > > > > The product needs 61.68 bits, less than 63 (one taken by the sign). > > I.e. 64 bit arithmetics ought to work. > > > > both MOD (9951585559 *370469809;23) and MOD ((9951585559 > > *370469809)-1;23) gives the result 0 for me (XP, OOO 2.03), implying > > overflow. But why? > > > > MOD (9951585559-1;23) gives 22, so it works for more than 32 bits. > > > > Are the integers handled as float numbers when they are big enough? > > 9951585559 *370469809 is displayed as 3,69E+018, implying this and > > making sense to the result. > > I tried a little more, by making a table in calc. > X 2^X =MOD(2^X;23)-MOD(2^X-1;23) > =(2^X+1)-(2^X) 47 140737488355328 > 1 1 48 > 281474976710656 1 0 > 49 562949953421312 > 1 0 50 > 1,13E+015 1 0 > 51 2,25E+015 > 1 0 52 > 4,50E+015 0 0 > 53 9,01E+015 > 0 0 > > The third column indicates that 64-bit float values are used. I.e. > With a 52-bit mantissa according to: > http://en.wikipedia.org/wiki/IEEE_floating-point_standard > > The fourth column indicates that something is wrong. > > I think that numeral values always are represented as double precision > float values and therefore that integer values above ~2^52 are > meaningless. > > My table indicates that integer values above 2^47 does not work. This > might be a bug. At least you know upgrade will not help :-). On 2.0.3 your table gives the same results. By the way, the largest integer I can enter in a cell is 999999999999997; 999999999999998 and 999999999999999 both result in 1000000000000000, and when I double-click the cell (to copy the 15 zeros), and after pressing Return there appear 1000000000000000 again :-) Andrius > > > > In this particular case, you can rewrite the formula because: > > > a*b (mod p) = a (mod p) * b (mod p) > > > > Not really. Max(a*b (mod p))=p-1; Max(a (mod p) * b (mod > > p))=(p-1)**2. (a (mod p) * b (mod p)) (mod p) might work. > > /$ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
