[GiNaC-list] matrix::solve()-related problems
Vladimir V. Kisil
kisilv at maths.leeds.ac.uk
Thu Jan 18 17:06:09 CET 2018
>>>>> On Thu, 18 Jan 2018 15:48:32 +0100, Vitaly Magerya <vmagerya at gmail.com> said:
VM> On 01/18/2018 03:19 PM, Vladimir V. Kisil wrote:
>> From time to time I am asking myself either .is_zero() needs to
>> call .normal() first and then make the test. This would look more
>> natural in my opinion.
VM> It will, but usually if you've called normal() on something you
VM> don't want to throw the result away, you want to store it. This
VM> is because normal() is slow (GCDs and stuff). Auto-normal()ing
VM> in is_zero() and throwing away the result is a waste, and can be
VM> a major performance hit for some applications.
VM> On a related note: when testing for zero you don't really need
VM> the full normal() calculation, which involves canceling common
VM> divisors of numerator and denominator -- you can keep those in;
VM> if you have any in the final result, then the expression is not
VM> a zero anyway. Basically, there's a place for normal()
VM> equivalent which never calls gcd().
VM> On another related note: there's a flag that tells you if an
VM> expression is expanded (status_flag::expanded), which presumably
VM> exists so that expand() repeated twice would be a quick
VM> no-op. There's no such flag for normal() though, and I'd argue
VM> it's much more needed there than in expand(). With such a flag
VM> you could pretty much put normal() all over the place without
VM> fearing for wasted computation: performance-minded code would
VM> have already normal()ized whatever it's passing into is_zero()
VM> and the like, so no performance penalty there, and more careless
VM> code would get the benefit of always obtaining correct results
VM> even when it forgot to normal()ize it's expressions.
I agree with all your points.
--
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/
More information about the GiNaC-list
mailing list