[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