[sage-devel] Re: hash for algebraic field
Robert Bradshaw wrote:
>> sage: x = SR.var('x')
>> sage: bool(arctan(1+abs(x)) == pi/2 - arctan(1/(1+abs(x
>> False
>
> Better returning True when the CAS isn't strong enough to prove
> equality (which may well be most of the time).
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
or whatever else they really have in mind?
(I don't even know if there is a method to test that two symbolic
expressions are syntactically identical!)
I'm only trying to say that
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;
2. I'd vastly prefer the first version of equality people will try
to be something as simple as possible, whose limitations are
easy to discover and understand.
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. As I (sort of)
understand what is going on, I can live with it and only use == when I
know beforehand what coercions may happen. But trying to put myself in
the shoes of a new user discovering the pitfalls of the existing ==, I
think I would lose all confidence in Sage (which may not be such a bad
thing, after all).
>> 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}
Fair enough, Python is even more broken than I thought! ;-/
> Can you think of any reason you'd want to do this?
No, that was just another case where the consequences of how == works
may not be that easy to understand.
But here is a similar example right from the Sage library (adapted from
http://wiki.sagemath.org/EqualityCoercion):
sage: FiniteEnumeratedSet(GF(3))
{0, 1, 2}
sage: add(FiniteEnumeratedSet([0,1,2]))
0
>> sage: {42, QQbar(42)}
>> {42, 42}
>> sage: {42, SR(42)}
>> {42}
>> sage: {2^100, SR(2^100)}
>> {1267650600228229401496703205376, 1267650600228229401496703205376}
>
> Hash is not as good as it could/should be for large symbolic integers.
> And for AA/QQbar.
And do you honestly think this will ever be fixed for all sage objects?
Or that unexpected inconsistencies such as the above are better than
"4/2!=2"? (After all, 4/2 and 2 *are not* equal. Otherwise
2.is_invertible() would be True.)
>> sage: eq = SR(GF(2)(0)) == SR(2); eq
>> 0 == 2
>> sage: bool(eq)
>> True
>
> Yeah, SR is weird. Especially with elements that don't embed into CC.
Actually this example is the only one that is not a bug in my eyes--just
yet another pitfall of ==.
Anyway, thank you very much for your comments. I now understand these
design choices a bit better, though I'm still very far from convinced.
--
Marc
--
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.
[sage-devel] Re: Hard time building sage to review a ticket
Julien Puydt wrote: I wanted to help review #14364. The (very old) testjava.sh foo, or was that a typo? So I cloned sage, Not immediately clear to me what you mean by that; which version of Sage? Already built and up-to-date? checked out the ticket's branch, exported SAGE_ATLAS_LIB and MAKE, then "make". Failure: some packages (cvxopt and scipy from memory) don't find the linear algebra libs. Fair enough, I started again, without SAGE_ATLAS_LIB this time. Of course, that added a few hours to the build time... and got build errors here and there... (about things unrelated to the ticket). Did I do something wrong? Is there a known problem? I just created a new branch based on 6.3.beta3 (already built), pulled u/jdemeyer/ticket/14364, ran 'sage -f jmol' (since the patch level of the spkg didn't change, which is probably ok), then ran 'sage -b', and 'sage -t --long src/sage/interfaces/jmoldata.py' works for me. Or did *I* miss something? -leif -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- 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.
[sage-devel] Is _hash_ used?
Dear list, The tutorial[1] mentions - More generally, Sage-specific special methods are usually named ``_meth_`` rather than ``__meth__``. For example, lots of classes implement ``_hash_`` which is used and cached by ``__hash__``. This seemed a bit strange to me, as I have seen __hash__ quite often. So I did $ git grep \\b_hash_\\b and found only a few handfuls of matches for _hash_. Also __hash__ of SageObject[2] is just hash(self.__repr__()), so there is no caching there. It seems to me that _hash_ is not used as suggested in the tutorial, or am I missing something? Regards, Erik Massop [1] src/doc/en/thematic_tutorials/tutorial-objects-and-classes.rst [2] src/sage/structure/sage_object.pyx -- 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.
[sage-devel] PDF manual Vs proper documentation of categories
Hello guys ! I wanted to ask you if you had ever found the pdf version of the manual useful for anything, or if we could just give it up. The problem we have is that the category/ folder contains things like class A: class B: class C: class D: def Hey(): pass and that function "Hey" does not appear in the doc as a result. A ticket [1] was opened for this 4 years ago but it got stuck because documenting these functions leads Sphinx to generate a LaTeX document that does not compile, because "the nesting is too important". This should of course remind us that we cannot trust LaTeX with anything, but more importantly we *DO* need those functions to appear in the documentation. So well. Given that the ticket is already 4 years old, if everybody agrees that the pdf documentation is totally useless, we could just throw it away and have all our functions appear in the doc at zero cost. Have fun ! Nathann P.S. : If you never opened the PDF version of the manual you can see for yourself how useless it is to find any info by going there : http://www.sagemath.org/pdf/en/reference/ (yes, many doctests cross the margins) [1] http://trac.sagemath.org/ticket/9107 -- 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.
[sage-devel] Re: PDF manual Vs proper documentation of categories
(remember that removing the pdf manual can also save trees, for it is likely that some people got the idea to print these files :-P) On 12 June 2014 14:43, Nathann Cohen wrote: > Hello guys ! > > I wanted to ask you if you had ever found the pdf version of the manual > useful for anything, or if we could just give it up. > > The problem we have is that the category/ folder contains things like > > class A: > class B: > class C: > class D: > def Hey(): > pass > > and that function "Hey" does not appear in the doc as a result. A ticket > [1] was opened for this 4 years ago but it got stuck because documenting > these functions leads Sphinx to generate a LaTeX document that does not > compile, because "the nesting is too important". > > This should of course remind us that we cannot trust LaTeX with anything, > but more importantly we *DO* need those functions to appear in the > documentation. > > So well. Given that the ticket is already 4 years old, if everybody agrees > that the pdf documentation is totally useless, we could just throw it away > and have all our functions appear in the doc at zero cost. > > Have fun ! > > Nathann > > P.S. : If you never opened the PDF version of the manual you can see for > yourself how useless it is to find any info by going there : > http://www.sagemath.org/pdf/en/reference/ > (yes, many doctests cross the margins) > > [1] http://trac.sagemath.org/ticket/9107 > -- 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.
Re: [sage-devel] Re: PDF manual Vs proper documentation of categories
The Magma Handbook has 5583 pages -- remember the mission statement! Of course I never look at the Sage pdf reference (OK, I just did -- it is rather beautiful) John On 12 June 2014 13:45, Nathann Cohen wrote: > (remember that removing the pdf manual can also save trees, for it is likely > that some people got the idea to print these files :-P) > > > On 12 June 2014 14:43, Nathann Cohen wrote: >> >> Hello guys ! >> >> I wanted to ask you if you had ever found the pdf version of the manual >> useful for anything, or if we could just give it up. >> >> The problem we have is that the category/ folder contains things like >> >> class A: >> class B: >> class C: >> class D: >> def Hey(): >> pass >> >> and that function "Hey" does not appear in the doc as a result. A ticket >> [1] was opened for this 4 years ago but it got stuck because documenting >> these functions leads Sphinx to generate a LaTeX document that does not >> compile, because "the nesting is too important". >> >> This should of course remind us that we cannot trust LaTeX with anything, >> but more importantly we *DO* need those functions to appear in the >> documentation. >> >> So well. Given that the ticket is already 4 years old, if everybody agrees >> that the pdf documentation is totally useless, we could just throw it away >> and have all our functions appear in the doc at zero cost. >> >> Have fun ! >> >> Nathann >> >> P.S. : If you never opened the PDF version of the manual you can see for >> yourself how useless it is to find any info by going there : >> http://www.sagemath.org/pdf/en/reference/ >> (yes, many doctests cross the margins) >> >> [1] http://trac.sagemath.org/ticket/9107 > > > -- > 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. -- 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.
[sage-devel] Re: PDF manual Vs proper documentation of categories
Hi Nathann, On 2014-06-12, Nathann Cohen wrote: > (remember that removing the pdf manual can also save trees, for it is > likely that some people got the idea to print these files :-P) Some people print html pages... Anyway: I have never used the pdf manual, and if it is correct that the line wrapping of examples in the pdf manual is incorrect then the pdf manual *is* broken and hence breaking the pdf manual more is no argument to prevent #9107 from being merged. But I am author and thus biased. That said, if someone has an idea how to either teach LaTeX to accept higher levels of recursion, or to create LaTeX code that achieves a nice output without excessive nesting, then this would be good for a follow-up ticket of #9107. Best regards, Simon -- 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.
[sage-devel] Re: PDF manual Vs proper documentation of categories
I don't usually read the pdf docs either, but it is the only test that the
math in doctstrings actually validates. Sphnix doesn't know if the
`\frac{1}{2}` in the doctstring is admissible math, and if not it'll only
fail in the browser when the end-user tries to read the docs...
On Thursday, June 12, 2014 1:43:27 PM UTC+1, Nathann Cohen wrote:
>
> Hello guys !
>
> I wanted to ask you if you had ever found the pdf version of the manual
> useful for anything, or if we could just give it up.
>
> The problem we have is that the category/ folder contains things like
>
> class A:
> class B:
> class C:
> class D:
> def Hey():
> pass
>
> and that function "Hey" does not appear in the doc as a result. A ticket
> [1] was opened for this 4 years ago but it got stuck because documenting
> these functions leads Sphinx to generate a LaTeX document that does not
> compile, because "the nesting is too important".
>
> This should of course remind us that we cannot trust LaTeX with anything,
> but more importantly we *DO* need those functions to appear in the
> documentation.
>
> So well. Given that the ticket is already 4 years old, if everybody agrees
> that the pdf documentation is totally useless, we could just throw it away
> and have all our functions appear in the doc at zero cost.
>
> Have fun !
>
> Nathann
>
> P.S. : If you never opened the PDF version of the manual you can see for
> yourself how useless it is to find any info by going there :
> http://www.sagemath.org/pdf/en/reference/
> (yes, many doctests cross the margins)
>
> [1] http://trac.sagemath.org/ticket/9107
>
--
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.
Re: [sage-devel] Re: PDF manual Vs proper documentation of categories
On 12 June 2014 14:54, Volker Braun wrote:
> I don't usually read the pdf docs either, but it is the only test that the
> math in doctstrings actually validates. Sphnix doesn't know if the
> `\frac{1}{2}` in the doctstring is admissible math, and if not it'll only
> fail in the browser when the end-user tries to read the docs...
That is a good reason. Indeed, just yesterday I was about to commit
come changes when I decided to "./sage -docbuild reference pdf"
because last time a pdf error delayed Volker merging my branch (quite
correct!). And I discovered tha I had put `\Q` in several places
instead of `\QQ`, which would not have looked nice on the web page.
What I do not do is have very nested classes...
John
>
>
>
>
>
> On Thursday, June 12, 2014 1:43:27 PM UTC+1, Nathann Cohen wrote:
>>
>> Hello guys !
>>
>> I wanted to ask you if you had ever found the pdf version of the manual
>> useful for anything, or if we could just give it up.
>>
>> The problem we have is that the category/ folder contains things like
>>
>> class A:
>> class B:
>> class C:
>> class D:
>> def Hey():
>> pass
>>
>> and that function "Hey" does not appear in the doc as a result. A ticket
>> [1] was opened for this 4 years ago but it got stuck because documenting
>> these functions leads Sphinx to generate a LaTeX document that does not
>> compile, because "the nesting is too important".
>>
>> This should of course remind us that we cannot trust LaTeX with anything,
>> but more importantly we *DO* need those functions to appear in the
>> documentation.
>>
>> So well. Given that the ticket is already 4 years old, if everybody agrees
>> that the pdf documentation is totally useless, we could just throw it away
>> and have all our functions appear in the doc at zero cost.
>>
>> Have fun !
>>
>> Nathann
>>
>> P.S. : If you never opened the PDF version of the manual you can see for
>> yourself how useless it is to find any info by going there :
>> http://www.sagemath.org/pdf/en/reference/
>> (yes, many doctests cross the margins)
>>
>> [1] http://trac.sagemath.org/ticket/9107
>
> --
> 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.
--
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.
[sage-devel] Re: hash for algebraic field
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.000])
(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.
Re: [sage-devel] Re: Hard time building sage to review a ticket
Hi, Le 12/06/2014 10:12, leif a écrit : Julien Puydt wrote: I wanted to help review #14364. The (very old) testjava.sh foo, or was that a typo? So I cloned sage, Not immediately clear to me what you mean by that; which version of Sage? Already built and up-to-date? checked out the ticket's branch, exported SAGE_ATLAS_LIB and MAKE, then "make". Failure: some packages (cvxopt and scipy from memory) don't find the linear algebra libs. Fair enough, I started again, without SAGE_ATLAS_LIB this time. Of course, that added a few hours to the build time... and got build errors here and there... (about things unrelated to the ticket). Did I do something wrong? Is there a known problem? I just created a new branch based on 6.3.beta3 (already built), pulled u/jdemeyer/ticket/14364, ran 'sage -f jmol' (since the patch level of the spkg didn't change, which is probably ok), then ran 'sage -b', and 'sage -t --long src/sage/interfaces/jmoldata.py' works for me. Or did *I* miss something? Here are the steps I followed yesterday: git clone git://git.sagemath.org/sage cd sage ln -s ../upstream upstream export SAGE_ATLAS_LIB=/usr/lib export MAKE="make -j 4" git checkout -b testjava remotes/origin/u/jdemeyer/ticket/14364 make I followed them again today, and it failed again, this time in ppl because "'ptrdiff_t' does not name a type" -- so not the same problem. Sigh... Snark on #sagemath -- 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.
Re: [sage-devel] Re: PDF manual Vs proper documentation of categories
On Thursday, June 12, 2014 10:03:55 AM UTC-4, John Cremona wrote:
>
> On 12 June 2014 14:54, Volker Braun >
> wrote:
> > I don't usually read the pdf docs either, but it is the only test that
> the
> > math in doctstrings actually validates. Sphnix doesn't know if the
> > `\frac{1}{2}` in the doctstring is admissible math, and if not it'll
> only
> > fail in the browser when the end-user tries to read the docs...
>
> That is a good reason. Indeed, just yesterday I was about to commit
> come changes when I decided to "./sage -docbuild reference pdf"
> because last time a pdf error delayed Volker merging my branch (quite
> correct!). And I discovered tha I had put `\Q` in several places
> instead of `\QQ`, which would not have looked nice on the web page.
>
>
+1 to this argument.
--
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.
Re: [sage-devel] Re: PDF manual Vs proper documentation of categories
> +1 to this argument. Indeed, it is a good argument. We have to do something about this undocumented functions, though. Oh, and it would be cool if --warn-links was the default for doc building, too :-P Nathann -- 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.
Re: [sage-devel] Re: Hard time building sage to review a ticket
Sounds like your gcc is broken... try "export SAGE_INSTALL_GCC=yes && make" On Thursday, June 12, 2014 4:48:43 PM UTC+1, Snark wrote: > > make > > I followed them again today, and it failed again, this time in ppl > because "'ptrdiff_t' does not name a type" -- so not the same problem. > > -- 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.
Re: [sage-devel] Re: hash for algebraic field
On Thu, Jun 12, 2014 at 8:41 AM, Nils Bruin wrote:
> 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)
Also, I think we're at least consistent here. Do you have any examples where
sage: bool((lhs - rhs).simplify_full() == 0) != bool(lhs == rhs)
The fact that equality of symbolic expressions is undecidable in
general, and even more limited in implementation, is something that we
just have to live with.
>> 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.
I'll second this. Are there *any* computer algebra systems (or
programming languages for that matter) out there such that 4/2 != 2 !=
2.0? Code would simply be too hard to write.
>> 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.
+1
Forcing users to use a method, and using == for something else, would
not solve these issues.
>> 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.000])
>
>> (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.
All the is_X methods are with respect to their parent, by design.
sage: R. = ZZ[]
sage: (x^2 - 2).is_irreducible()
True
sage: R. = RR[]
sage: (x^2 - 2).is_irreducible()
False
sage: R. = QQ[sqrt(2)][]
sage: (x^2 - 2).is_irreducible()
False
- Robert
--
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.
Re: [sage-devel] Re: hash for algebraic field
On Thu, Jun 12, 2014 at 12:50 AM, Marc Mezzarobba wrote:
> But here is a similar example right from the Sage library (adapted from
> http://wiki.sagemath.org/EqualityCoercion):
>
> sage: FiniteEnumeratedSet(GF(3))
> {0, 1, 2}
> sage: add(FiniteEnumeratedSet([0,1,2]))
> 0
Um, isn't that what you want? The sum of the elements of GF(p^e) for
any odd prime is zero, which is a handy property.
>>> sage: {42, QQbar(42)}
>>> {42, 42}
>>> sage: {42, SR(42)}
>>> {42}
>>> sage: {2^100, SR(2^100)}
>>> {1267650600228229401496703205376, 1267650600228229401496703205376}
>>
>> Hash is not as good as it could/should be for large symbolic integers.
>> And for AA/QQbar.
>
> And do you honestly think this will ever be fixed for all sage objects?
For the common ones at least. And sometimes elements should not define
hash, as normalizing them is expensive, if even possible.
> Or that unexpected inconsistencies such as the above are better than
> "4/2!=2"? (After all, 4/2 and 2 *are not* equal.
Yes.
- Robert
--
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.
Re: [sage-devel] Re: hash for algebraic field
2014-06-12 19:10 UTC+02:00, Robert Bradshaw : > On Thu, Jun 12, 2014 at 8:41 AM, Nils Bruin wrote: >> 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) > > Also, I think we're at least consistent here. Do you have any examples > where > > sage: bool((lhs - rhs).simplify_full() == 0) != bool(lhs == rhs) > > The fact that equality of symbolic expressions is undecidable in > general, and even more limited in implementation, is something that we > just have to live with. We have to live with them but not to let Sage answers False when it actually does not know the answer... -- 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.
Re: [sage-devel] Re: hash for algebraic field
2014-06-12 19:13 UTC+02:00, Robert Bradshaw :
> On Thu, Jun 12, 2014 at 12:50 AM, Marc Mezzarobba
> wrote:
>
>> But here is a similar example right from the Sage library (adapted from
>> http://wiki.sagemath.org/EqualityCoercion):
>>
>> sage: FiniteEnumeratedSet(GF(3))
>> {0, 1, 2}
>> sage: add(FiniteEnumeratedSet([0,1,2]))
>> 0
>
> Um, isn't that what you want? The sum of the elements of GF(p^e) for
> any odd prime is zero, which is a handy property.
In two fresh Sage consoles
{{{
sage: sum(FiniteEnumeratedSet([0,1,2]))
3
}}}
and
{{{
sage: FiniteEnumeratedSet(GF(3))
sage: sum(FiniteEnumeratedSet([0,1,2]))
0
}}}
Because FiniteEnumeratedSet has a cache on the input!
sage: {42, QQbar(42)}
{42, 42}
sage: {42, SR(42)}
{42}
sage: {2^100, SR(2^100)}
{1267650600228229401496703205376, 1267650600228229401496703205376}
>>>
>>> Hash is not as good as it could/should be for large symbolic integers.
>>> And for AA/QQbar.
>>
>> And do you honestly think this will ever be fixed for all sage objects?
>
> For the common ones at least. And sometimes elements should not define
> hash, as normalizing them is expensive, if even possible.
Are we allowed to through errors for them?
Vincent
--
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.
Re: [sage-devel] Re: hash for algebraic field
On Thu, Jun 12, 2014 at 10:19 AM, Vincent Delecroix
<20100.delecr...@gmail.com> wrote:
> 2014-06-12 19:13 UTC+02:00, Robert Bradshaw :
>> On Thu, Jun 12, 2014 at 12:50 AM, Marc Mezzarobba
>> wrote:
>>
>>> But here is a similar example right from the Sage library (adapted from
>>> http://wiki.sagemath.org/EqualityCoercion):
>>>
>>> sage: FiniteEnumeratedSet(GF(3))
>>> {0, 1, 2}
>>> sage: add(FiniteEnumeratedSet([0,1,2]))
>>> 0
>>
>> Um, isn't that what you want? The sum of the elements of GF(p^e) for
>> any odd prime is zero, which is a handy property.
>
> In two fresh Sage consoles
> {{{
> sage: sum(FiniteEnumeratedSet([0,1,2]))
> 3
> }}}
> and
> {{{
> sage: FiniteEnumeratedSet(GF(3))
> sage: sum(FiniteEnumeratedSet([0,1,2]))
> 0
> }}}
>
> Because FiniteEnumeratedSet has a cache on the input!
Indeed -- no question that this is definitely a bug. Somebody open a
ticket (if they haven't already).
But I would rather blame the use of caching rather than equality
testing. We can certainly fix this bug without changing the
definition of "==".
>
> sage: {42, QQbar(42)}
> {42, 42}
> sage: {42, SR(42)}
> {42}
> sage: {2^100, SR(2^100)}
> {1267650600228229401496703205376, 1267650600228229401496703205376}
Hash is not as good as it could/should be for large symbolic integers.
And for AA/QQbar.
>>>
>>> And do you honestly think this will ever be fixed for all sage objects?
>>
>> For the common ones at least. And sometimes elements should not define
>> hash, as normalizing them is expensive, if even possible.
>
> Are we allowed to through errors for them?
If you do not define hash for an object (or throw an error), then it
is not possible to use that object in many data structures, e.g., as
keys in dictionaries, in sets, etc. It is possible to use it in
lists. Whether or not this is OK, depends on what you're trying to
do.
If hash wasn't defined on any SR elements, then instead of
sage: {42, SR(42)}
set([42])
we would get an error, such as:
TypeError: unhashable type: ...
The drawback is that we would also get errors on this:
sage: {pi, e}
TypeError: unhashable type: ...
-- William
--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org
--
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.
Re: [sage-devel] Re: hash for algebraic field
On Thursday, June 12, 2014 6:44:44 PM UTC+1, William wrote: > > > sage: sum(FiniteEnumeratedSet([0,1,2])) > > 3 > > sage: FiniteEnumeratedSet(GF(3)) > > sage: sum(FiniteEnumeratedSet([0,1,2])) > > 0 > > But I would rather blame the use of caching rather than equality > testing. The issue is and remains that you must not put objects with different parents in an associative container (the cache, in this case). So its really the interaction of caching with our "==". The very same issue has been brought up before (e.g. https://groups.google.com/d/msg/sage-devel/0nnsxFQ0bfw/wd5abo9Kj7gJ). Just removing the caching here isn't that easy, FiniteEnumeratedSet really is just a UniqueRepresentation. I'm pretty sure there are similar issues in other UniqueRepresentations... Really, caching ought to apply a stricter comparison that our "== after coercion". IMHO we should require that the parents match before coercion, that is, use (parent(x), x) as cache dictionary key. Otherwise there will always be cases where an incorrectly primed cache will give you wrong answers. Not to mention the impossibility to test a cached_function/method that it does not depend on the previous inputs. -- 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.
Re: [sage-devel] Re: Hard time building sage to review a ticket
Hi, Le 12/06/2014 18:42, Volker Braun a écrit : Sounds like your gcc is broken... try "export SAGE_INSTALL_GCC=yes && make" Oh! Excellent point! I have gcc 4.9.0, which is a fairly recent version! Trying to compile sage 6.2 with it (from the tarball) ; adding -k to the MAKE export so I get a list of problems : (1) cvxopt and scipy fail to compile because linear algebra libs aren't found ; (2) ppl compiled. Point (1) is what bothered me enough with the git checkout to start the thread, and I'll obviously need to investigate further. Point (2)... well... it's not a breakage if it compiles, but last time it gave issues... so there's still something to understand. Am I the only one using a recent gcc? Snark on #sagemath -- 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.
[sage-devel] Re: Hard time building sage to review a ticket
Julien Puydt wrote: Hi, Le 12/06/2014 18:42, Volker Braun a écrit : Sounds like your gcc is broken... try "export SAGE_INSTALL_GCC=yes && make" Oh! Excellent point! I have gcc 4.9.0, which is a fairly recent version! Trying to compile sage 6.2 with it (from the tarball) ; adding -k to the MAKE export so I get a list of problems : (1) cvxopt and scipy fail to compile because linear algebra libs aren't found ; (2) ppl compiled. Point (1) is what bothered me enough with the git checkout to start the thread, and I'll obviously need to investigate further. Point (2)... well... it's not a breakage if it compiles, but last time it gave issues... so there's still something to understand. Am I the only one using a recent gcc? The few (C++) issues with GCC 4.9 were fixed before Sage 6.2 (and GCC 4.9.0 :-) ) got released, namely PPL and Lcalc. Don't recall the ticket number right now, but you can also search sage-devel for the corresponding thread. -leif -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- 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.
Re: [sage-devel] Re: hash for algebraic field
On Thu, Jun 12, 2014 at 10:19 AM, Vincent Delecroix
<20100.delecr...@gmail.com> wrote:
> 2014-06-12 19:13 UTC+02:00, Robert Bradshaw :
>> On Thu, Jun 12, 2014 at 12:50 AM, Marc Mezzarobba
>> wrote:
>>
>>> But here is a similar example right from the Sage library (adapted from
>>> http://wiki.sagemath.org/EqualityCoercion):
>>>
>>> sage: FiniteEnumeratedSet(GF(3))
>>> {0, 1, 2}
>>> sage: add(FiniteEnumeratedSet([0,1,2]))
>>> 0
>>
>> Um, isn't that what you want? The sum of the elements of GF(p^e) for
>> any odd prime is zero, which is a handy property.
>
> In two fresh Sage consoles
> {{{
> sage: sum(FiniteEnumeratedSet([0,1,2]))
> 3
> }}}
> and
> {{{
> sage: FiniteEnumeratedSet(GF(3))
> sage: sum(FiniteEnumeratedSet([0,1,2]))
> 0
> }}}
>
> Because FiniteEnumeratedSet has a cache on the input!
Oh, ouch. +1 to using (parent(x), x) as the key.
On Thu, Jun 12, 2014 at 12:51 PM, Jori Mantysalo wrote:
> Just a side note:
>
> On Thu, 12 Jun 2014, Robert Bradshaw wrote:
>
>> I'll second this. Are there *any* computer algebra systems (or
>> programming languages for that matter) out there such that 4/2 != 2 !=
>> 2.0? Code would simply be too hard to write.
>
> Ada, I guess. It should give error if you try to compare integer with float.
Ah, no wonder it's so widely used :).
--
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.
[sage-devel] Re: hash for algebraic field
Volker Braun gmail.com> writes: > > sage: FiniteEnumeratedSet(GF(3)) > > sage: sum(FiniteEnumeratedSet([0,1,2])) > > 0 > But I would rather blame the use of caching rather than equality > testing. > Just removing the caching here isn't that easy, FiniteEnumeratedSet really is just a UniqueRepresentation. I'm pretty sure there are similar issues in other UniqueRepresentations... For one thing it illustrates that FiniteEnumeratedSet (due to being a full-blown parent and hence having UniqueRepresentation) is a rather heavy-weight object. Note that "equality" of FiniteEnumeratedSet is going to be a bit funny when construction from arguments starts to use an equivalence test more strict than "==": It means that we can have two enumerated sets V = FiniteEnumeratedSet(GF(3)) W = FiniteEnumeratedSet([0,1,2]) such that all( any(v==w for w in W) for v in V) and all( any(v==w for v in V) for w in W) and not( V == W ) (having UniqueRepresentation and not EqualityById would be horrible) > Really, caching ought to apply a stricter comparison that our "== after coercion". IMHO we should require that the parents match before coercion, that is, use (parent(x), x) as cache dictionary key. Otherwise there will always be cases where an incorrectly primed cache will give you wrong answers. Not to mention the impossibility to test a cached_function/method that it does not depend on the previous inputs. And since the arguments get processed already in order to get hashed, it would probably be quite doable to process them such that SageElement instances get replaced by (elt.parent(), elt), or perhaps better: if objects provide a "_cache_key_" method, use its value. -- 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.
Re: [sage-devel] Re: hash for algebraic field
>>> I'll second this. Are there *any* computer algebra systems (or >>> programming languages for that matter) out there such that 4/2 != 2 != >>> 2.0? Code would simply be too hard to write. >> >> Ada, I guess. It should give error if you try to compare integer with float. > > Ah, no wonder it's so widely used :). Right. ;-) In FriCAS you get (1=1.0)@Boolean if you type that in a session, but ... (200) -> )compile foo.spad Compiling FriCAS source code from file /home/hemmecke/foo.spad using old system compiler. FOO abbreviates package Foo initializing NRLIB FOO for Foo compiling into NRLIB FOO compiling exported foo : () -> Boolean ** comp fails at level 3 with expression: ** error in function foo (= (|Sel| (|Integer|) 1) (|Sel| (|Float|) 1)) ** level 3 ** $x:= (Sel (Float) (One)) $m:= (Integer) $f:= |$Information| #) (|foo| #) (|$DomainsInScope| # # #) ($ # #) ...))) >> Apparent user error: Cannot coerce (call (XLAM ignore 1)) of mode (Integer) to mode (Float) for the source code: )abbrev package FOO Foo Foo: with foo: () -> Boolean == add foo(): Boolean == (1$Integer = 1$Float) In other words. For the compilation, there will be no automatic coercion, but in a interactive session, FriCAS will try to find respective types so that the function (here it is =: (%, %)-> % ) is available. I.e. in the above case it finds coerce: Integer -> Float and thus uses =: (Float, Float)-> Float in a session. Maybe that is not what you want or even can do in Sage, but I find this programming vs. interactive session distinction rather good. I don't like if my program suddenly behaves differently only because someone has slightly changed the coercion system. As a programmer I would like to have control on whether I consider the integer 1 equal to the 2 by 2 unit matrix. We do the same in mathematics. Rational numbers are pair of integers modulo ... so how can they be equal to an integer? Yes, we have an embedding. The question is simply whether one wants a system that hides that embedding (coercion) or a sytem that makes that coercion explicit. I think FriCAS makes a good compromise with this. Just my 2 cents. Ralf -- 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.
