@Carl Love Dear friends. After trying for quite some time to develop an effective algorithm myself I realized I would have to consult your solution. It was not as difficult to read as I first imagined and I have to say that you really developed a beautiful algorithm there. It is quite simple and straightforward yet the way in which it produces a sorted list of sorted partitions is a bit like magic. That just goes to show that a couple of decisive insights can really make a difference. I implemented your algorithm in Perl and posted it at the Math Stackexchange Link including due credit for your work. Congratulations. The Perl runs as fast as the Maple code and the memory footprint is no more than what it needs to be. As for just counting the partitions without generating them, I might investigate. (It appears from the OEIS entry that there is a recursive formula.) I am also grateful to acer for alerting me to some of the obvious defects of my first answer.

Marko Riedel

@Carl Love That sounds good. There is no question that your algorithm is better than what I have. Do note however that my algorithm also produces the factorings. It looks to me like order is key here (e.g. the defining advantage of your solution.) I have seen this in other settings. My Perl program also computes all factorizations. I think it is interesting that Perl turns out to be so much faster than Maple in spite of the fact that I did not optimize my memory management and just coded the thing straightforwardly. Some people argue that Perl's days are over. I disagree. I use it for prototyping all the time and it is very effective. Furthermore it does not require an investment in order to start working with algorithms. Those Perl designers put a lot of effort into their work because they knew it would be deployed as a sysadmin tool and speed and memory usage would be crucial.

@Kitonum Can you maybe describe your algorithm in mathematical notation? Thank you.

Regards,

Marko Riedel

@acer Thanks very much for this good improvement. The reason I sorted is that op(op(t)) does not always produce the table entries in sorted order, e.g. consider

t := table([seq(rand() mod 315 = rand() mod 30, k=1..20)]);
op(op(t));

On my machine (Maple 15) this will produce

[13 = 22, 15 = 22, 262 = 27, 266 = 23, 146 = 20, 148 = 22, 161 = 6, 189 = 11, 59 = 26, 302 = 0,
    197 = 27, 192 = 9, 80 = 18, 92 = 26, 100 = 18, 227 = 26, 119 = 23, 254 = 10, 124 = 15,
    244 = 18]

Am I missing something here? I will remember the trick with the set conversion occuring at the end of the algorithm.

Regards, Marko Riedel

I guess I would need to know wether these lists of assignments hash to the same value regardless of the order.

I just realized they don't. Consider this:

> s:= {};
                                         s := {}

> s := s union {[2=3, 3=4]};
                                  s := {[2 = 3, 3 = 4]}

> s := s union {[3=4, 2=3]};
                          s := {[2 = 3, 3 = 4], [3 = 4, 2 = 3]}

So do we need the sort after all?

@ecterrab Thank you for your comment, it introduced me to several tricks that I'm sure will be useful in the future. (Your explanation also applies to the second program I posted.) I think your concluding observation should definitely go as a warning into the help page for ilog. In fact the reason I used ilog is that I thought it had a more efficient implementation when used with an integer base on a positive integer argument like repeated squaring given that my experience told me that Maple can in theory handle integers of arbitrary sizes. Now I see that this is not the case. Maybe you should consider changing this. To be honest this is a case of the classic question "bug or feature" and even having understood what is going on I would nonetheless tend to qualify this as a bug rather than a feature.

@Carl Love 

The catch is of course that switching the order of summation is the first step in the manual evaluation of this series. If I know how to take that first step then I don't need Maple to get the closed form. The point was that I asked Maple before it occured to me to switch the order of summation and it was at that time that I would have wanted Maple to give me a helping hand. BTW it is perfectly okay that Maple would have difficulty with the first sum since an intermediate hypergeometric appears that is difficult to deal with. In that case I would expect Maple to say FAIL rather than return an incorrect answer. That kind of behaviour would increase usability and reliability and build trust in the outputs of the Maple engine. You are invited to test other popular CAS and discover how they deal with this sum.

@Thomas Richard Thank you for the kind remark. Be sure to include rational functions of finite Dirichlet series in your effort. As for undergraduate math, when I got my education complex variables was a third year course. ;-)

More good news. The command "limit((s-2*Pi*I*3/log(2))/(2^s-1), s=2*Pi*I*3/log(2));" also works properly. I usually do a sanity check before I import Maple results into my work, but I am genuinely worried I may have imported a couple of wrong residues because I sometimes do not verify the more complicated ones.

Thanks very much sir. Please post a link with formatting instructions for pasting Maple session output from a mono-spaced terminal window. I made quite an effort to locate such instructions on your site, but to no avail. Thanks again. BTW the good news is that the command "singular" gets it right when applied to "1/(2^s-1)."

I had in fact tried the integral but I didn't manage to manipulate it the right way. ;-) In order to establish asymptotic order of growth you would also need a lower bound, but given what you have obtained already, it would probably be a routine calculation. You will discover that in fact I have all terms of the expansion, not just the first, if you read the original post that triggered this.

Best regards,

Marko Riedel

I had in fact tried the integral but I didn't manage to manipulate it the right way. ;-) In order to establish asymptotic order of growth you would also need a lower bound, but given what you have obtained already, it would probably be a routine calculation. You will discover that in fact I have all terms of the expansion, not just the first, if you read the original post that triggered this.

Best regards,

Marko Riedel

Dear Sir, I always work with the command line interface which is why I did not post a worksheet. I pasted my code into a worksheet just now and it seems to work fine. See attachments.

Here is the worksheet: petersen.mw

Marko Riedel

@acer Thanks ever so much. But the effort that I need to split the sum and then combine and format the two results is almost equivalent to the exact calculation (shown in the link). If I know this much about the sum I probably know how to calculate it using pen and paper. I do believe Maple should display the simple answer immediately like Mathematica does in this case.

Best regards,

Marko

Hello there,

I would like to thank you for your interesting comment, which made fascinating reading. I truly love Maple and I hope to help make it better. However, did you read the numeric results in my original post? These are all zero, as are the values I computed in my stackexchange post. Would you please point out my errror? Alternatively, is there a mistake in your multiseries solution?

Best regards,

Marko Riedel

I have now watched my Maple process compute

int(cosh(7/367*x)/cosh(x), x=0..infinity);

and it is still doing something, not sure what exactly, but it has stopped printing those status messages about the memory being used that serve as an indicator that the process is still alive. My process monitor "top" (Linux) shows the process at 100% CPU usage.

Best regards,

Marko Riedel