On Thursday, June 12, 2014 12:48:37 AM UTC-7, Marc Mezzarobba wrote:
>
> Sure. But why not have
>
> sage: bool(sin(x)^2+cos(x)^2==1)
> True
>
> return False as well, and let the user test that
>
> (rhs-lhs).simplify_full() == 0
>
That would probably be even desirable if you want to make SR more generally
usable in sage (imagine, say a cached function with SR elements as
arguments. You would probably end up with a routine that gets *slower* as
its cache fills)
1. the behavior of == is already full of subtleties (and bugs),
> so I don't think arguments such as "4/2==2 is surprising for
> new users" are very strong;
>
If 4/2==2 were to raise an exception, I agree, but we've already seen that
internal usage of "==" precludes that option. Having 2/2 != 1 would just
make too much code that is traditionally valid in all kinds of programming
languages and computer algebra systems have insidious bugs to be socially
acceptable.
Yes, it is great to have a rich equality predicate that automatically
> does the right thing in many cases. The only problem is, I know I cannot
> trust its output, and I am convinced that I never will because the
> issues discussed in this thread are basically unfixable.
I think that's correct. "equality" is a fluid term in mathematics that may
appear to have a consistent meaning throughout in mathematics, but in fact
it's a local decision which equivalence relations will be called "equality"
in mathematics literature. And even within well-defined domains the thing
that's decided to mean equality can turn out to be undecidable.
> I think I would lose all confidence in Sage (which may not be such a bad
> thing, after all).
>
Or more generally, in math software. This problem is not limited to sage
(although it may be worse because we get to blame python for some of the
choices)
>> sage: {t.parent() for t in {R(42), 42}}
> >> {Integer Ring}
> >> sage: {t.parent() for t in {42, R(42)}}
> >> {Univariate Polynomial Ring in y over Rational Field}
> >
> > Totally, just like Python's
> >
> > {type(t) for t in {0, 0.0}} == {float}
>
> You can make these examples more fun by ensuring you can control the order
in which the set gets constructed:
sage: {t.parent() for t in set([42, R(42)])}
set([Integer Ring])
sage: {t.parent() for t in set([R(42), 42])}
set([Univariate Polynomial Ring in y over Rational Field])
sage: set([0, 0.0])
set([0])
sage: set([0.0, 0])
set([0.000000000000000])
(After all, 4/2 and 2 *are not* equal. Otherwise 2.is_invertible() would be
> True.)
>
That is not such an uncontroversial statement. With ZZ regarded as a subset
of QQ (quite a valid thing to do) we should have 4/2 == 2. In that view one
should as whether 2 is invertible *in ZZ* , so it would be the
is_invertible method that is flawed.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
