On 10/14/07, Jonathan Bober <[EMAIL PROTECTED]> wrote: > > I have to run somewhere for a little while, but I just realized that > there might be a bug for small input (1000 being small enough). You may > want to try something bigger to see if it works correctly. > > Also, at > > http://developer.apple.com/documentation/DeveloperTools/Conceptual/LowLevelABI/Articles/32bitPowerPC.html > > I found the following: > > (*) In Mac OS X v10.4 and later and GCC 4.0 and later, the size of the > long double extended precision data type is 16 bytes (it's made up of > two 8-byte doubles). In earlier versions of Mac OS X and GCC, long > double is equivalent to double. You should not use the long double type > when you use GCC 4.0 or later to develop or in programs targeted at Mac > OS X versions earlier than 10.4. >
I've disabled use of your implementation on ppc os x completely (use pari instead), and disabled yours for n < 3000. It seems fine for anything bigger. If you fix it for n < 3000 before the release that would be good. -- William > I'll probably be back looking at this in a little while. > > On Sun, 2007-10-14 at 14:53 -0700, William Stein wrote: > > On 10/14/07, Jonathan Bober <[EMAIL PROTECTED]> wrote: > > > > > > I'm not sure right now, but I'm thinking about it. > > > > > > You could try setting > > > > > > long_double_precision = double_precision > > > > > > wherever it is initialized. (This is around line 140 somewhere.) If you > > > do this it will just skip the part of the computation where it uses long > > > doubles (For some reason I have a feeling that there might be something > > > funny about the long double type on PPC OS X - but I don't know what > > > that reason is, so I could be wrong.) > > > > Hi, > > > > It turns out that number_of_partitions with your algorithm is wrong > > for input 1000 on x86_64, but *right* on ppc... > > This threw me off for a while. I kept trying to lower precision > > on ppc with my test case being 1000 and of course it was always > > right on ppc but wrong on x86_64, so I thought the opposite. > > > > > > > > > > Similarly, you could play with setting qd_precision = dd_precision to > > > skip the part of the computation with quad_doubles, or set everything to > > > double_precision, so that it only uses either mpfr or standard doubles, > > > etc. > > > > > > Another thing to try is using just a little bit more precision. See > > > around line 572, in the function compute_extra_precision(). You could > > > turn the 5 into, say, a 15 or a 30 to see what happens. If that works, > > > then you can try to experiment to see what the smallest number that > > > works is. > > > > > > On Sun, 2007-10-14 at 14:40 -0600, William Stein wrote: > > > > Hi Jon, > > > > > > > > Your number_of_partitions code is in the current sage-2.8.7.rc1, > > > > and it works on all but one machine we tested in on. Unfortunately > > > > -- JUST AS YOU SUSPECTED -- it doens't work on PPC OS X. It runs, > > > > but gives wrong answers. Any ideas how to fix your code to still > > > > work on OS X PPC, even slowly? > > > > > > > > William > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
