2009/1/4 mabshoff <michael.absh...@mathematik.uni-dortmund.de>:
>
>
>
> On Jan 3, 5:05 pm, "William Stein" <wst...@gmail.com> wrote:
>> On Sat, Jan 3, 2009 at 4:48 PM, mabshoff
>>
>>
>>
>> <michael.absh...@mathematik.uni-dortmund.de> wrote:
>>
>> > On Jan 3, 4:33 pm, calcp...@aol.com wrote:
>>
>> > Hi AJG,
>>
>> >> Exactly, the function log base 2 of x is not defined at 0.
>> >> So, why won't sage return some sort of domain error?
>>
>> > We call numpy for the numerical roots and I guess this might be a bug
>> > there, but we will check. Somebody please open a ticket for this.
>>
>> >> I noticed something similar when I plotted (x^2-1)/(x-1) and got the
>> >> graph of x+1.
>> >> I was hoping for a removeable discontinuity to show in the graph!
>> >> IE a hole in y=x+1 at x=1.
>>
>> > Ouch, I think this might explain the problem:
>>
>> > ----------------------------------------------------------------------
>> > | Sage Version 3.2.3.final, Release Date: 2009-01-02 |
>> > | Type notebook() for the GUI, and license() for information. |
>> > ----------------------------------------------------------------------
>> > sage: f=(x^2-1)/(x-1); f
>> > (x^2 - 1)/(x - 1)
>> > sage: f.simplify()
>> > (x^2 - 1)/(x - 1)
>> > sage: f.simplify_full()
>> > x + 1
>> > sage:
>>
>> > Not sure is this is an issue with Maxima, but I would guess so.
>> > simplify_full() shouldn't do this since it is clearly mathematically
>> > not equivalent.
>>
>> It's documented in the Maxima documentation, where one finds
>> "cancelling the greatest common divisor of the numerator and
>> denominator..." in the docs for ratexpand, which is called in the
>> course of the above. Who says simplify_full() shouldn't do the above?
>
> Well, for me simplification implies equivalence operations. But Maxima
> seems to be more careful here than MMA. But then I don't do symbolic
> manipulation, but I must say I am very surprised.
>
>> Mathematica also does the above simplification:
>>
>> sage: mathematica.eval('Simplify[(x^2-1)/(x-1)]')
>> 1 + x
>
> That looks plain wrong to me assuming equivalence operations, but
> maybe the MMA documentation defines what Simplify does.
>
This gets to the heart of something which has has bugged students and
computer algebra systems from the year dot.
>From one point of view, (x^2-1)/(x-1) defines a "rational function" in
one variable, i.e. an element of the field of all rational functions,
denoted CC(x) if the coefficients come from CC (say). In this
algebraic context, the element just defined is the same as the element
x+1 and the simplification is 100% valid.
>From another point of view, (x^2-1)/(x-1) is a formula defining a
function of x for all values of x where the function is "defined", so
-- as this is a fraction -- excluding any values where the denominator
evaluates to 0. In that case it defines a function on the punctured
domain where x!=1. In this case, as the original poster remarks, it's
a removable singularity and if we define the function's value at x=1
to be 2 then we get back the function x+1.
Things get much more complicated when there are side conditions (and,
taken to the extreme, would probably lead on to full-scale algebraic
geometry, schemes and all. For example, if you are interested in
functions f(x,y) on the circle x^2+y^2=1, then x/(1-y)=(1+y)/x; the
first expression is "defined" except at (0,1), while the second is
defined except at either (0,1) and (0,-1). There are examples where
no one expression gives you something which is "defined" in the naive
sense everywhere the function is defined.
What this shows is that there is no magic simple solution which will
work and keep everyone happy in all such situations. I think that
cancelling common factors from a fraction is perfectly sensible, even
though it enlarges the domain of definition of the functions. So I am
happy with a computer algebra system simplifying (x^2-1)/(x-1) to x+1.
On the other hand, I know from teaching experience that there are
situations where one would want to keep the two separate.
John
>> I don't think there is any claim that simplify(expr) gives back a 100%
>> mathematically equivalent expression. However, the types of changes
>> that occur are well defined.
>
> Ok. Maybe the Sage documentation ought to make this clearer then.
>
>> > My suspicion is that we probably call simplify_full()
>> > before plotting and/or feeding it into _fast_float(). Someone please
>> > open another ticket for this one.
>>
>> I do not think fast_float calls simplify_full.
>
> Ok, but I am curious how this bug happens then. But I am sure someone
> more familiar with the plotting code will find out.
>
>> William
>
> Cheers,
>
> Michael
> >
>
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to
sage-support-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sage-support
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
