Dear all, I use GiNaC to perform analytic calculation, but when I try to use .numer() and .denom() methods, I get a wrong result. 1. expr.numer()/expr.denom() is not always equal to the original expression!!! 2. Using .numer_denom() method could always get the correct answer. I attach a simple code source file and logger file to check that problem. The logger file will be different when you run the code on your computer. Yours, Yang
Hi,
On Thu, 23 Aug 2018 13:22:06 +0800 (GMT+08:00), 杨强 <acrobat@mail.ustc.edu.cn> said:
> Dear all, I use GiNaC to perform analytic calculation, but when I > try to use .numer() and .denom() methods, I get a wrong result. > 1. expr.numer()/expr.denom() is not always equal to the original > expression!!! 2. Using .numer_denom() method could always get the > correct answer. It is not actually a bug. Since a/b = (-a)/(-b), numer() and denom() are only defined up to a sign. Thus their separate evaluation may lead to expr.numer()/expr.denom() with the opposite sign to expr. I am proposing a patch to tutorial reminding that, Best wishes, Vladimir -- Vladimir V. Kisil http://www.maths.leeds.ac.uk/~kisilv/ Book: Geometry of Mobius Transformations http://goo.gl/EaG2Vu Software: Geometry of cycles http://moebinv.sourceforge.net/
Hi Vladimir, Yang's expectation, that applying numer() and denom() to the same expression would produce expressions with consistent signs, is reasonable. Even if the potential inconsistency of results is well documented, it will remain unexpected behavior by many users, potentially leading to errors. The fact that consistent signs will sometimes be produced may make it difficult to detect or debug those errors. The potential inconsistency of sign results also suggests that the concepts of numerator and denominator aren't well defined, which is unsettling even if there is a good underlying reason. The explanation given, because a/b = (-a)/(-b), seems insufficient to justify an interface that can lead to errors. Would enforcement of consistent signs result in a performance penalty? Respectfully, -Mark On Thu, Aug 23, 2018 at 6:31 PM Vladimir V. Kisil <kisilv@maths.leeds.ac.uk> wrote:
Hi,
On Thu, 23 Aug 2018 13:22:06 +0800 (GMT+08:00), 杨强 < acrobat@mail.ustc.edu.cn> said:
> Dear all, I use GiNaC to perform analytic calculation, but when I > try to use .numer() and .denom() methods, I get a wrong result.
> 1. expr.numer()/expr.denom() is not always equal to the original > expression!!! 2. Using .numer_denom() method could always get the > correct answer.
It is not actually a bug. Since a/b = (-a)/(-b), numer() and denom() are only defined up to a sign. Thus their separate evaluation may lead to expr.numer()/expr.denom() with the opposite sign to expr.
I am proposing a patch to tutorial reminding that,
Best wishes, Vladimir -- Vladimir V. Kisil http://www.maths.leeds.ac.uk/~kisilv/ Book: Geometry of Mobius Transformations http://goo.gl/EaG2Vu Software: Geometry of cycles http://moebinv.sourceforge.net/
_______________________________________________ GiNaC-list mailing list GiNaC-list@ginac.de https://www.cebix.net/mailman/listinfo/ginac-list
Dear Mark,
On Thu, 23 Aug 2018 23:32:29 -0400, Mark Rahner <rahner@alum.mit.edu> said:
MR> Hi Vladimir, Yang's expectation, that applying numer() and MR> denom() to the same expression would produce expressions with MR> consistent signs, is reasonable. Even if the potential MR> inconsistency of results is well documented, it will remain MR> unexpected behavior by many users, potentially leading to MR> errors. The fact that consistent signs will sometimes be MR> produced may make it difficult to detect or debug those errors. MR> The potential inconsistency of sign results also suggests that MR> the concepts of numerator and denominator aren't well defined, MR> which is unsettling even if there is a good underlying reason. MR> The explanation given, because a/b = (-a)/(-b), seems MR> insufficient to justify an interface that can lead to errors. MR> Would enforcement of consistent signs result in a performance MR> penalty? I see your point. However, it is more then just performance penalty on the stake. The behaviours of these two functions depends on normal() method. And what shall be the normal form of, say, (1-x)/(y-1)? Why not (x-1)/(1-y)? Since there is no definite reason why one shall be preferred to another, each time GiNaC will run normal() method either of them may appear. To deal with a user's natural expectation we may rename numer() and denum() to, say, numer_up_to_a_sign() and denumr_up_to_a_sign(). But this seems to be overdone. Alternatively, we may be add few more lines of warnings and explanation to the tutorial just before numer() and denum() are introduced. Best wishes, Vladimir -- Vladimir V. Kisil http://www.maths.leeds.ac.uk/~kisilv/ Book: Geometry of Mobius Transformations http://goo.gl/EaG2Vu Software: Geometry of cycles http://moebinv.sourceforge.net/ MR> Respectfully, -Mark MR> On Thu, Aug 23, 2018 at 6:31 PM Vladimir V. Kisil MR> <kisilv@maths.leeds.ac.uk> wrote: >> Hi, >> >> >>>>> On Thu, 23 Aug 2018 13:22:06 +0800 (GMT+08:00), 杨强 < >> acrobat@mail.ustc.edu.cn> said: >> >> > Dear all, I use GiNaC to perform analytic calculation, but when >> I > try to use .numer() and .denom() methods, I get a wrong >> result. >> >> >> > 1. expr.numer()/expr.denom() is not always equal to the >> original > expression!!! 2. Using .numer_denom() method could >> always get the > correct answer. >> >> It is not actually a bug. Since a/b = (-a)/(-b), numer() and >> denom() are only defined up to a sign. Thus their separate >> evaluation may lead to expr.numer()/expr.denom() with the >> opposite sign to expr. >> >> I am proposing a patch to tutorial reminding that, >> >> Best wishes, Vladimir >> -- >> Vladimir V. Kisil http://www.maths.leeds.ac.uk/~kisilv/ Book: >> Geometry of Mobius Transformations http://goo.gl/EaG2Vu Software: >> Geometry of cycles http://moebinv.sourceforge.net/
participants (3)
-
Mark Rahner
-
Vladimir V. Kisil
-
杨强