Re: [sage-devel] Re: Deleting depreciated is_functions
Well, I wrote a script to delete some of the is_* functions, but it turned out to be a little more complicated of a task then I thought it would be, so this patch doesn't delete as many as I was aiming for but at least it's a start: http://trac.sagemath.org/sage_trac/ticket/12824 -Jim On Thu, Mar 29, 2012 at 6:38 AM, Florent Hivert wrote: > > Hi Simon, > >> On 2012-03-28, Florent Hivert wrote: >> >> For parameter-less categories like Fields, I don't have a feeling for >> >> whether one should teach new users to use the idiom ``X in Fields`` or >> >> ``X in Fields()``. I tend to use the later mysefl. >> > >> > Speed could be a (not so important) argument. >> >> Not so important??? I take speed very seriously. And by the way, testing >> containment is even faster if you assign Fields() to a >> constant, e.g. > > I'm not saying that speed is not important in general. We where discussing > about syntax and teaching to new commers, as opposite to hardcore > optimization. In this context I don't think speed is a major > argument. Moreover, if needed, "QQ in Fields" could certainly be way optimized > (using Cython / better mro handling, etc). So speed *currently* shouldn't be > considered as a serious argument for deciding which syntax we need. After, the > proper syntax / usage is defined we certainly will think about speed. > > Cheers, > > Florent > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org -- Die Dunkelheit... leitet die Musik. Die Musik... leitet die Seele. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Deleting depreciated is_functions
Hi Simon, > On 2012-03-28, Florent Hivert wrote: > >> For parameter-less categories like Fields, I don't have a feeling for > >> whether one should teach new users to use the idiom ``X in Fields`` or > >> ``X in Fields()``. I tend to use the later mysefl. > > > > Speed could be a (not so important) argument. > > Not so important??? I take speed very seriously. And by the way, testing > containment is even faster if you assign Fields() to a > constant, e.g. I'm not saying that speed is not important in general. We where discussing about syntax and teaching to new commers, as opposite to hardcore optimization. In this context I don't think speed is a major argument. Moreover, if needed, "QQ in Fields" could certainly be way optimized (using Cython / better mro handling, etc). So speed *currently* shouldn't be considered as a serious argument for deciding which syntax we need. After, the proper syntax / usage is defined we certainly will think about speed. Cheers, Florent -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Deleting depreciated is_functions
I think the idea was that if you cared about speed you would just use Fields(), but that it wasn't an important point in discussing whether QQ in Fields should be valid. David On Thu, Mar 29, 2012 at 09:06, Simon King wrote: > Hi Florent! > > On 2012-03-28, Florent Hivert wrote: > >> For parameter-less categories like Fields, I don't have a feeling for > >> whether one should teach new users to use the idiom ``X in Fields`` or > >> ``X in Fields()``. I tend to use the later mysefl. > > > > Speed could be a (not so important) argument. > > Not so important??? I take speed very seriously. And by the way, testing > containment is even faster if you assign Fields() to a > constant, e.g. > > sage: FieldsCat = Fields() > sage: QQ in Fields > True > sage: QQ in FieldsCat > True > sage: %timeit QQ in Fields > 625 loops, best of 3: 11.4 µs per loop > sage: %timeit QQ in Fields() > 625 loops, best of 3: 4.14 µs per loop > sage: %timeit QQ in FieldsCat > 625 loops, best of 3: 1.86 µs per loop > > Cheers, > Simon > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Deleting depreciated is_functions
Hi Florent! On 2012-03-28, Florent Hivert wrote: >> For parameter-less categories like Fields, I don't have a feeling for >> whether one should teach new users to use the idiom ``X in Fields`` or >> ``X in Fields()``. I tend to use the later mysefl. > > Speed could be a (not so important) argument. Not so important??? I take speed very seriously. And by the way, testing containment is even faster if you assign Fields() to a constant, e.g. sage: FieldsCat = Fields() sage: QQ in Fields True sage: QQ in FieldsCat True sage: %timeit QQ in Fields 625 loops, best of 3: 11.4 µs per loop sage: %timeit QQ in Fields() 625 loops, best of 3: 4.14 µs per loop sage: %timeit QQ in FieldsCat 625 loops, best of 3: 1.86 µs per loop Cheers, Simon -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Deleting depreciated is_functions
On Wed, Mar 28, 2012 at 11:27:24PM +0200, Nicolas M. Thiery wrote: > On Wed, Mar 28, 2012 at 05:39:51AM -0700, David Kohel wrote: > > Doing some magic to make 'QQ^2 in VectorSpaces' work > > might just do injustice to first-time users, since it defers > > the realization that they just made a typo -- unless > > VectorSpaces is no longer a Python class: > > > > sage: VectorSpaces > > > > > > rather an instance of the category of vector spaces. > > The rationale for that magic is that ``V in VectorSpaces`` is a short, > readable, and unambiguous idiom for asking whether V is a vector space > (over some field). > > For parameter-less categories like Fields, I don't have a feeling for > whether one should teach new users to use the idiom ``X in Fields`` or > ``X in Fields()``. I tend to use the later mysefl. Speed could be a (not so important) argument. Isn't ``X in Fields()`` faster than ``X in Fields`` ? sage: %timeit QQ in Fields 625 loops, best of 3: 4.58 盜 per loop sage: %timeit QQ in Fields() 625 loops, best of 3: 1.67 盜 per loop sage: %timeit ZZ in Fields 625 loops, best of 3: 12.9 盜 per loop sage: %timeit ZZ in Fields() 625 loops, best of 3: 2.25 盜 per loop Cheers, Florent -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Deleting depreciated is_functions
On Wed, Mar 28, 2012 at 05:39:51AM -0700, David Kohel wrote: > Doing some magic to make 'QQ^2 in VectorSpaces' work > might just do injustice to first-time users, since it defers > the realization that they just made a typo -- unless > VectorSpaces is no longer a Python class: > > sage: VectorSpaces > > > rather an instance of the category of vector spaces. The rationale for that magic is that ``V in VectorSpaces`` is a short, readable, and unambiguous idiom for asking whether V is a vector space (over some field). For parameter-less categories like Fields, I don't have a feeling for whether one should teach new users to use the idiom ``X in Fields`` or ``X in Fields()``. I tend to use the later mysefl. Cheers, Nicolas -- Nicolas M. Thiéry "Isil" http://Nicolas.Thiery.name/ -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Deleting depreciated is_functions
Hi, 1. (On Sage syntax): For the record, there are some reasons why ZZ in Fields doesn't (and perhaps shouldn't) make sense: Fields is a function not the category it returns: sage: Fields sage: Fields() Category of fields I think a student learning Sage should have a first session in which they learn that every function takes parentheses, and that there are some pre-defined objects at their disposal. The ring ZZ and field QQ are pre-defined for the ease of the user, and are not the same beasts. Is is true that ZZ(n) is valid, but is meant to create an integer, e.g. ZZ(1). For empty argument it defaults to ZZ(0), which allows '5/1 in ZZ()' to give an error in a confusing place. This should not be confused with the category constructors VectorSpaces, Fields, etc. In the same vane as pre-defining ZZ and QQ, one could pre-define some defaults Flds = Fields() and Vect = VectorSpaces() globally, but unlike ZZ, QQ, RR, and CC, I think the naive or first-time user does not usually need to have these categories at hand or need to know anything about categories to use Sage. Doing some magic to make 'QQ^2 in VectorSpaces' work might just do injustice to first-time users, since it defers the realization that they just made a typo -- unless VectorSpaces is no longer a Python class: sage: VectorSpaces rather an instance of the category of vector spaces. 2. (On is_Name): Regarding is_PrimeField(F) and ilk -- remove them: instead the syntax F.is_prime_field() is (or should be) implemented: sage: F = FiniteField(2) sage: F.is_prime_field() True sage: F. = FiniteField(8) sage: F.is_prime_field() False for all fields. Where is is not, or incorrect (!): sage: K. = NumberField(x-2/3) sage: K.is_prime_field() False this should be fixed. And someone should certainly create a trac item to for this bug. --David On Mar 28, 11:00 am, Keshav Kini wrote: > Florent Hivert writes: > >> sage: ZZ in Fields > >> False > >> sage: ZZ in Fields() > >> False > >> sage: QQ in Fields > >> True > >> sage: QQ in Fields() > >> True > > >> I don't pretend to understand why this is the case :) But maybe it's > >> better if we tell new users to use `ZZ in Fields` instead of `ZZ in > >> Fields()`, to minimize confusion...? Or maybe doing so would be > >> misleading in ways I haven't realized? > > > It works because Nicolas did the work (Ticket #9469 Category membership, > > without arguments, Merged in: sage-5.0.beta6). > > Awesome! :D Thanks, Nicolas! > > > > > > > > > > > I think you are right > > saying that we should teach "QQ in Fields" to beginner rather than > > "QQ in Fields()", except that if I remember correctly, there is a > > performance > > issue for the short notation. Also they don't have the exact same meaning. > > The > > difference is apparent in > > > sage: QQ^2 in VectorSpaces(QQ) > > True > > sage: QQ^2 in VectorSpaces > > True > > sage: QQ^2 in VectorSpaces(CC) > > False > > > Note that they are still some mathematically surprising answers: > > > sage: QQ in VectorSpaces(QQ) # bootstrap problem > > False > > sage: QQbar in VectorSpaces(QQ) > > False > > Interesting... > > > So the answer is: thinks are going better in each new Sage release. > > That is all one can hope for :) > > -Keshav > > > Join us in #sagemath on irc.freenode.net ! -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Deleting depreciated is_functions
Florent Hivert writes: >> sage: ZZ in Fields >> False >> sage: ZZ in Fields() >> False >> sage: QQ in Fields >> True >> sage: QQ in Fields() >> True >> >> I don't pretend to understand why this is the case :) But maybe it's >> better if we tell new users to use `ZZ in Fields` instead of `ZZ in >> Fields()`, to minimize confusion...? Or maybe doing so would be >> misleading in ways I haven't realized? > > It works because Nicolas did the work (Ticket #9469 Category membership, > without arguments, Merged in: sage-5.0.beta6). Awesome! :D Thanks, Nicolas! > I think you are right > saying that we should teach "QQ in Fields" to beginner rather than > "QQ in Fields()", except that if I remember correctly, there is a performance > issue for the short notation. Also they don't have the exact same meaning. The > difference is apparent in > > sage: QQ^2 in VectorSpaces(QQ) > True > sage: QQ^2 in VectorSpaces > True > sage: QQ^2 in VectorSpaces(CC) > False > > Note that they are still some mathematically surprising answers: > > sage: QQ in VectorSpaces(QQ) # bootstrap problem > False > sage: QQbar in VectorSpaces(QQ) > False Interesting... > So the answer is: thinks are going better in each new Sage release. That is all one can hope for :) -Keshav Join us in #sagemath on irc.freenode.net ! -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Deleting depreciated is_functions
Hi Keshav, > Incidentally, `ZZ in Fields` works just fine:: > > sage: 5/1 in ZZ > True > sage: 5/1 in ZZ() > > --- > TypeError Traceback (most recent call > last) > > /home/fs/src/workflow/ in () > > TypeError: argument of type 'sage.rings.integer.Integer' is not iterable > sage: ZZ in Fields > False > sage: ZZ in Fields() > False > sage: QQ in Fields > True > sage: QQ in Fields() > True > > I don't pretend to understand why this is the case :) But maybe it's > better if we tell new users to use `ZZ in Fields` instead of `ZZ in > Fields()`, to minimize confusion...? Or maybe doing so would be > misleading in ways I haven't realized? It works because Nicolas did the work (Ticket #9469 Category membership, without arguments, Merged in: sage-5.0.beta6). I think you are right saying that we should teach "QQ in Fields" to beginner rather than "QQ in Fields()", except that if I remember correctly, there is a performance issue for the short notation. Also they don't have the exact same meaning. The difference is apparent in sage: QQ^2 in VectorSpaces(QQ) True sage: QQ^2 in VectorSpaces True sage: QQ^2 in VectorSpaces(CC) False Note that they are still some mathematically surprising answers: sage: QQ in VectorSpaces(QQ) # bootstrap problem False sage: QQbar in VectorSpaces(QQ) False So the answer is: thinks are going better in each new Sage release. Cheers, Florent -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Deleting depreciated is_functions
To respond to the OP: I'm all for getting rid of these functions. "Nicolas M. Thiery" writes: > Also, the idiom ``is_Field(P)`` would be best replaced by ``P in Fields()``. As a beginner I might wonder, "Why is it `5/1 in ZZ` but `ZZ in Fields()`? Why not `5/1 in ZZ()` or `ZZ in Fields`?" These seeming inconsistencies definitely make learning Sage a bit rockier of a road than it could be, I think. Incidentally, `ZZ in Fields` works just fine:: sage: 5/1 in ZZ True sage: 5/1 in ZZ() --- TypeError Traceback (most recent call last) /home/fs/src/workflow/ in () TypeError: argument of type 'sage.rings.integer.Integer' is not iterable sage: ZZ in Fields False sage: ZZ in Fields() False sage: QQ in Fields True sage: QQ in Fields() True I don't pretend to understand why this is the case :) But maybe it's better if we tell new users to use `ZZ in Fields` instead of `ZZ in Fields()`, to minimize confusion...? Or maybe doing so would be misleading in ways I haven't realized? -Keshav Join us in #sagemath on irc.freenode.net ! -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
