Dear all, I think there is a problem with the numer_denom function with large polynomial fractions. I added "bug.txt" to the attachment, which is an input file for ginsh. Using the version of GiNaC shipped with current stable Ubuntu, I get the result "out-installed". Here, "/" is contained in numerator and denominator, which should not be the case, if I understood the functionality of numer_denom right. Using git version of GiNaC, I get "out-git.txt". Here, braces are used in numerator and denominator, which also seems strange to me. Do I understand something wrong or is this a bug? Best regards, Moritz Hahn
Hi! On 11/10/2010 04:22 PM, Ernst Moritz Hahn wrote:
I think there is a problem with the numer_denom function with large polynomial fractions. I added "bug.txt" to the attachment, which is an input file for ginsh. Using the version of GiNaC shipped with current stable Ubuntu, I get the result "out-installed". Here, "/" is contained in numerator and denominator, which should not be the case, if I understood the functionality of numer_denom right. Using git version of GiNaC, I get "out-git.txt". Here, braces are used in numerator and denominator, which also seems strange to me.
Do I understand something wrong or is this a bug?
Is anything wrong? I don't know. Please, try to reduce example output you send to the mailing list as much as possible. Nobody wants to discussing output of excessive length. There is nothing wrong with brackets in numerator and denominator, I would say. The functions numer(), denom() and numer_denom() do not claim to expand their results, right? Here is a simpler variant:
numer_denom((1+a)*c/2); {(1+a)*c,2} numer((1+a)*c/2); (1+a)*c denom((1+a)*c/2); 2
On the other hand, the result computed by the installed version leaves room for improvement, as it treats numerator and denominator as polynomials over the rationals, as opposed to polynomials over the integers. This change in behavior seems to be a consequence of Alexei Sheplyakov's patch edf1ae46a926d0a718063c149b78c1b9a7ec2043. It first featured in release 1.5.8. Bye! -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
Hi Richard, thanks for the answer!
Is anything wrong? I don't know. Please, try to reduce example output you send to the mailing list as much as possible. Nobody wants to discussing output of excessive length.
OK, sorry about that. I assumed the normal form to be expanded, as I thought the representation would be the same for equal rational functions. When using GiNaC, I did not see an example where this was not the case for smaller terms before. Regards, Moritz
Hello, On Wed, Nov 17, 2010 at 01:06:39AM +0100, Richard B. Kreckel wrote:
On 11/10/2010 04:22 PM, Ernst Moritz Hahn wrote:
I think there is a problem with the numer_denom function with large polynomial fractions. I added "bug.txt" to the attachment, which is an input file for ginsh. Using the version of GiNaC shipped with current stable Ubuntu,
Could you please specify the exact version of GiNaC you use? (I have no idea what is shipped with Ubuntu, sorry).
I get the result "out-installed". Here, "/" is contained in numerator and denominator, which should not be the case, if I understood the functionality of numer_denom right.
As far as I can see the problem is caused by GCD miscalculation bug. It has been fixed ~ 6 months ago (by commit edf1ae46a, see http://www.ginac.de/ginac.git?p=ginac.git;a=commit;h=edf1ae46a).
Using git version of GiNaC, I get "out-git.txt". Here, braces are used in numerator and denominator, which also seems strange to me.
Braces are OK. numer_denom returns a list consisting of numerator and denominator, and GiNaC prints lists as { element0, element1, ... elementN }.
Is anything wrong? I don't know. Please, try to reduce example output you send to the mailing list as much as possible.
I think reducing this particular example is a bit non-trivial, and is not a user's job.
On the other hand, the result computed by the installed version leaves room for improvement, as it treats numerator and denominator as polynomials over the rationals, as opposed to polynomials over the integers.
I don't think so. As far as I understand it's a result of GCD miscalculation: numer_denom thinks A and B are relatively prime and returns them as is.
This change in behavior seems to be a consequence of Alexei Sheplyakov's patch edf1ae46a926d0a718063c149b78c1b9a7ec2043. It first featured in release 1.5.8.
This confirms my hypothesis, but I need to check it more carefully (there might be some more bugs in GCD code). Best regards, Alexei
Hi! On 11/18/2010 04:55 PM, Alexei Sheplyakov wrote:
On 11/10/2010 04:22 PM, Ernst Moritz Hahn wrote:
Using git version of GiNaC, I get "out-git.txt". Here, braces are used in numerator and denominator, which also seems strange to me.
Braces are OK. numer_denom returns a list consisting of numerator and denominator, and GiNaC prints lists as { element0, element1, ... elementN }.
Both results in the original post contained exactly one pair of curly *braces*: They were both of the form {N, D}. I assume he meant round *parenthesis*, of which there are many since edf1ae46a92 was committed.
(there might be some more bugs in GCD code).
Sorry, I see now that you are right. The old and new computed numerators differ by a factor 282901891126422365/highA. That factor certainly shouldn't contain a highA. Also, computing the GCD of the original A and B segfaults over here. Cheers -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
Hi all, one user of my tool which uses GiNaC sent me a debug output where the problem that (non-integer) rational numbers appear in numerator or denumerator of numer_denom(...) also occurs in the development version. Is this example of use? Should I send it to the mailing list or to one of the authors? Again, it is quite large. Best regards, Moritz Am Thursday, den 18.11.2010, 22:50 +0100 schrieb Richard B. Kreckel:
Hi!
On 11/18/2010 04:55 PM, Alexei Sheplyakov wrote:
On 11/10/2010 04:22 PM, Ernst Moritz Hahn wrote:
Using git version of GiNaC, I get "out-git.txt". Here, braces are used in numerator and denominator, which also seems strange to me.
Braces are OK. numer_denom returns a list consisting of numerator and denominator, and GiNaC prints lists as { element0, element1, ... elementN }.
Both results in the original post contained exactly one pair of curly *braces*: They were both of the form {N, D}. I assume he meant round *parenthesis*, of which there are many since edf1ae46a92 was committed.
(there might be some more bugs in GCD code).
Sorry, I see now that you are right. The old and new computed numerators differ by a factor 282901891126422365/highA. That factor certainly shouldn't contain a highA. Also, computing the GCD of the original A and B segfaults over here.
Cheers -richy.
Hello, On Sun, Nov 21, 2010 at 07:49:55PM +0100, Ernst Moritz Hahn wrote:
one user of my tool which uses GiNaC sent me a debug output where the problem that (non-integer) rational numbers appear in numerator or denumerator of numer_denom(...) also occurs in the development version.
Is this example of use?
Yes.
Should I send it to the mailing list or to one of the authors? Again, it is quite large.
If it's less than 10 -- 20 Mb, please email it to me. If it's bigger, please put it somewhere on the web and send me a link. Best regards, Alexei
Hello, On Thu, Nov 18, 2010 at 10:50:23PM +0100, Richard B. Kreckel wrote:
Sorry, I see now that you are right. The old and new computed numerators differ by a factor 282901891126422365/highA. That factor certainly shouldn't contain a highA.
I think the new one is correct (also I've cross-checked it with Maxima).
Also, computing the GCD of the original A and B segfaults over here.
Got a simpler example: gcd(1/282901891126422365*(x + y), 165888/282901891126422365*(x - y)); I've posted the patch to ginac-devel. Best regards, Alexei.
Hello,
Could you please specify the exact version of GiNaC you use? (I have no idea what is shipped with Ubuntu, sorry).
The version which was shipped with Ubuntu Lucid is 1.5.5-1. The other version was the latest in the Git repository when writing the mail.
As far as I can see the problem is caused by GCD miscalculation bug. It has been fixed ~ 6 months ago (by commit edf1ae46a, see http://www.ginac.de/ginac.git?p=ginac.git;a=commit;h=edf1ae46a).
I see, I'll continue using the repository version.
I assume he meant round *parenthesis*, of which there are many since edf1ae46a92 was committed.
Yes. Best regards, Moritz
participants (3)
-
Alexei Sheplyakov
-
Ernst Moritz Hahn
-
Richard B. Kreckel