[sage-devel] Re: number_of_partitions returns wrong results under the Windows Subsystem for Linux

I've opened ticket #29600. Best, Sebastian On Monday, April 27, 2020 at 5:04:28 AM UTC+2, Travis Scrimshaw wrote: > > I also suspect it comes from some kind of rounding or precision issue, > likely in MPFR since nearly all of the computations are d

[sage-devel] Re: number_of_partitions returns wrong results under the Windows Subsystem for Linux

I also suspect it comes from some kind of rounding or precision issue, likely in MPFR since nearly all of the computations are done there. At least this is not super pressing since the Bober implementation is not the default implementation, but it is definitely something that should be fixed. B

[sage-devel] Re: number_of_partitions returns wrong results under the Windows Subsystem for Linux

see also #28549 . On Monday, April 20, 2020 at 9:23:52 AM UTC+2, Sebastian Oehms wrote: > > The existenz of the problem already appeared in Friedrich Wiemer's status > report >

Re: [sage-devel] Re: number_of_partitions

On Friday, 21 September 2012 17:09:25 UTC+8, Jeroen Demeyer wrote: > > On 2012-09-21 10:52, Volker Braun wrote: > > If there is an implementation that is *always* faster than the > > alternatives then it makes no sense to keep others around. > ...unless you have a simple but slow algorithm whi

Re: [sage-devel] Re: number_of_partitions

On Friday, September 21, 2012 5:09:25 AM UTC-4, Jeroen Demeyer wrote: > > On 2012-09-21 10:52, Volker Braun wrote: > > If there is an implementation that is *always* faster than the > > alternatives then it makes no sense to keep others around. > ...unless you have a simple but slow algorithm

[sage-devel] Re: number_of_partitions

On Friday, 21 September 2012 14:09:19 UTC+10, Dima Pasechnik wrote: > > This decreases the pedagogical value of Sage code for no good reason. > > Hi Dima, If you reread my post you will see that ALL of the current functionality of number_of_partitions is still supported by Partitions(*).cardin

Re: [sage-devel] Re: number_of_partitions

On 2012-09-21 10:52, Volker Braun wrote: > If there is an implementation that is *always* faster than the > alternatives then it makes no sense to keep others around. ...unless you have a simple but slow algorithm which can be used to check the result of the complicated fast algorithm. -- You rec

[sage-devel] Re: number_of_partitions

If there is an implementation that is *always* faster than the alternatives then it makes no sense to keep others around. The pedagogical value of being able to pick a slow algorithm is really limited (especially if the only thing that changes is the time it takes to spit out the same number),

[sage-devel] Re: number_of_partitions

On Friday, 21 September 2012 10:25:45 UTC+8, Andrew Mathas wrote: > > Among other things, the patch > #13072cleans up > sage.combinat.partition. I would like some input as to should > happen to the function number_of_partitions. > > Arguably, if

[sage-devel] Re: number_of_partitions

On 10/14/07, Jonathan Bober <[EMAIL PROTECTED]> wrote: > On Sun, 2007-10-14 at 15:13 -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. > > > > OK, your new code on x86_64 gets essentially every sing

[sage-devel] Re: number_of_partitions

On Sun, 2007-10-14 at 15:13 -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. > > OK, your new code on x86_64 gets essentially every single > number_of_partitions(n) wrong for 242 <= n <= 2833, and > see

[sage-devel] Re: number_of_partitions

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.a

[sage-devel] Re: number_of_partitions

On 10/14/07, Jonathan Bober <[EMAIL PROTECTED]> wrote: > > I'm not sure right now, but I'm thinking about it. OK, your new code on x86_64 gets essentially every single number_of_partitions(n) wrong for 242 <= n <= 2833, and seems right for everything else. > > You could try setting > > long_doub

[sage-devel] Re: number_of_partitions

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

[sage-devel] Re: number_of_partitions

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 t

[sage-devel] Re: number_of_partitions

On 10/14/07, William Stein <[EMAIL PROTECTED]> 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

[sage-devel] Re: number_of_partitions

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

[sage-devel] Re: number_of_partitions

I've been meaning to get around to pointing these out: http://trac.sagemath.org/sage_trac/ticket/468 http://trac.sagemath.org/sage_trac/ticket/486 The first contains a patch to fix the problem where quad_double screws up the fpu precision on x86 machines, and the second contains a patch to sign