Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

sqrt problems in "rounded" mode

Developers
James
2011-04-23
2012-11-20
  • James
    James
    2011-04-23

    In version "reduce-algebra-20101007", setting "off nat;", I am confused about the treatment of complex numbers in "rounded" mode, with or without "complex" mode.  In particular, with "on rounded", "sqrt(s^2);" gives "abs(s)", considering that "s" could have a non-zero imaginary part, and "sqrt(2*(s^2));" gives "1.41421356237*abs(s)", which is reasonable, but then "sqrt(2/(s^2))" gives "(2/s**2)**0.5", while in "rounded" mode, which seems like a bug.

    Am I missing something?  Should there be any difference between a quotient and a product here?  It seems to me that, in "rounded" mode, the square-root of the numerator can be taken, even on the chance that "s" could be complex.

    And then, this failure to evaluate the numerical quantities becomes annoying when trying to simply find some numeric result.  For instance, "(2*pi)*sqrt((2*e)/(s^2));" gives "6.28318530718*(5.43656365692/s**2)**0.5", instead of simply "14.6501512067/abs(s)", which would be more useful.

    James

     
  • James
    James
    2011-04-24

    I just checked the new version "Reduce (Free CSL version), 14-Apr-11".  There is the same odd behavior with quotient and product in "sqrt" with the "on rounded;" switch.  I also finally thought to check just "sqrt(2*s);" and "sqrt(2/s);".  The later still gives "(2/s)**0.5".  Maybe there is a switch that changes this behavior?  I've tried "on combineexpt;", "on div;" and "on fullroots;" - just guessing - but there is no change in the output.

    Thanks
    James

     
  • Arthur Norman
    Arthur Norman
    2011-04-26

    OK - I can see that sqrt(2/s) and sqrt(2*s) are treated differently by simpexpt2 in alg/simp.red when *precise is on. And I can see a comment

    %    The next lines did not allow, e.g., sqrt(a/b) => sqrt(a)/sqrt(b).
    %    when precise is on and there is a risk of
    %    E.g., sqrt(a/b) neq sqrt(a)/sqrt(b) when a=1, b=-1.
    %    We allow however the denominator to be a positive number.

    around there, so I *suspect* that although the simplification that moves sqrt(2) out of the numerator may be safe it needs extra stuff there to implement it.

    If you go "off precise;" the code allows itself to be more sloppy (eg it does not put in abs for the result of sqrt(x^2)), but when you are just wanting to evaluate someting to end up with a number it is very possibly what you want???

                Arthur

     
  • James
    James
    2011-05-12

    Yes!  Thanks for finding that Arthur!

    James

     
  • James
    James
    2011-05-12

    Thinking about this distinction between "sqrt(a/b)" and "sqrt(a)/sqrt(b)" - with respect to being "precise", and noticing that "reduce" also has a distinct "precise_complex" switch, I'm wondering, what would be the actual "mathematically correct" interpretation?  If we think in terms of rotations in the complex plane, there is always the implication of complex numbers whenever the sqrt function is involved.  In the context of complex numbers, then, the presumption that "sqrt(4)=2" is no more correct than the presumption that "b" is positive in "sqrt(a/b)", simply because "(-2)^2" is also a solution of "sqrt(4)".  So, to be "precise", and especially, to be "complexly precise", is to suppose that "sqrt(a)" must be treated with the same care as "sqrt(1/b)".

    But "reduce" might be said to fail here, where setting "on precise_complex;" shows "sqrt(4);" as simply "2", instead of showing "+2" and "-2".

    And even then, saying that "sqrt(a/b) neq sqrt(a)/sqrt(b)" would not be appropriate and would not be "correct", whether "b" is negative or not, simply because, if the math is followed properly, there is the same complex result.  We are NOT going to suggest that "division" or "multiplicative inversion" and "exponentiation" do not commute.  They should.  They do!  But there may exist multiple solutions, even when talking about "principal solutions", if we suppose that  the first "left rotation" and first "right rotation" are equally valid as "principal solutions".

    So, I am becoming doubtful that "reduce" is "doing the right thing" here, sometimes converting "sqrt(a/b)" and sometimes NOT converting "sqrt(a/b)", or making a distinction between "sqrt(a/b)" and "sqrt(a)/sqrt(b)".  Yes, something should be done to distinguish the possible multiple solutions, but then "don't execute the sqrt" unless all the branches are included!

    And also, in the thread "output format request or bug", it may be that this "maybe sometimes/maybe not" conversion code may be the source of other problems, having to do with "reduce" NOT having a single canonical internal format for an expression, or perhaps NOT having a consistent internal state, such that the output display format changes uncontrollably, or even displays incorrectly in some cases.

    Thoughts?

    Thanks
    James

     
  • Arthur Norman
    Arthur Norman
    2011-05-13

    The whole area that "on precise" addresses is a horrid one that has hurt many algebra systems other than Reduce. The expression sqrt(z) may be being worked on with a supposition that z is real or it could be that the case of z being complex (or at least sqty(x) being complex) must be allowed for. Some people want to think in terms of princciple values while others thing Galois theory and all the roots. People who are pedantic about it s algebra (as distinct from analysis) may never use the notation sqrt(z) but will instead prefer Groebner base technology. Algebraic value arithmetic with a (minimal) polynomial and a bounding range can do arithmetic sort of perfectly but at huge cost.

    "on precise" is an engineering response to some of these issues not a perfect solution. With "off precise" calculaton is sloppy and informal - but LOTS of people really want that and HAT it if some clown puts a gratuitous "abs" where they were not wanting it. With "on precise" the system is more cautious. I would hate to claim it was never incorrect.

    Lots of "simplification" matters are either undecidable or jolly hard to make work well, so bunches of the things you observe as anomalies are where the current code gets to. It may be trivial to fix just a single example, but to "fix" all variants on it without introducing hurt elsewhere may not be so easy! But Reduce these day is open source so anybody who is looking for a project can inspect ALL the coee and try suggesting patches. But I hope they will test the way they inteact with all the packages and all the other flags and imagine how other mathematicians (eg pure vs. applied!) might react.

    There have been papers in the literature about the treatment of sqrt, log etc etc - but as well as the issue of what one might like to do there is also the issue of where Reduce starts from….

    So in short, you should not evcen expect that two expressions that YOU can see to be equalivalent will always simplify to the same form (especially under all possible switch settings) omce you go beyond simple rational functions. Sorry.

              Arthur