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