[sage-devel] Re: Infix mod operator?

On Tuesday, May 31, 2016 at 3:11:00 PM UTC-7, Volker Braun wrote: > > PS: This would still leave room for a preparser hack for the > easy-to-implement paren-mod infix operator: > > X (mod Y) -->X * mod(Y) > > Thoughts? > Sneaky. If we generalize that preparser rule and suppress the * gene

[sage-devel] Re: Infix mod operator?

PS: This would still leave room for a preparser hack for the easy-to-implement paren-mod infix operator: X (mod Y) -->X * mod(Y) Thoughts? -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving

[sage-devel] Re: Infix mod operator?

On Tuesday, May 31, 2016 at 7:07:14 PM UTC+2, Nils Bruin wrote: > > - you're introducing a new reserved word in sage, which will break > previous code. > Well "mod 3" can't occur inside a valid Python expression so at most it'll unbreak currently-broken code ;-) Though, especially for polynomi

[sage-devel] Re: Infix mod operator?

On Tuesday, May 31, 2016 at 9:37:48 AM UTC-7, Volker Braun wrote: > > This was a request at sd74: > > sage: 42 mod 8 > 2 > sage: type(42 mod 8) > > > Thoughts? Ticket is at http://trac.sagemath.org/ticket/20735 >

[sage-devel] Infix mod operator?

This was a request at sd74: sage: 42 mod 8 2 sage: type(42 mod 8) Thoughts? Ticket is at http://trac.sagemath.org/ticket/20735 -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving ema

[sage-devel] Re: Faulty comparison between elements of quotient of multivariate polynomial ring

Hi Simon, On Tuesday, May 31, 2016 at 9:18:15 AM UTC+1, Simon King wrote: > > Hi Alec, > > On 2016-05-30, Alec Edgington > > wrote: > > Thanks, that seems to be the problem. I also note the code comment "The > > whole quotient stuff relies in I.reduce(x) returning a normal form of x > > with

Re: [sage-devel] Users can permanently modify GF(5).list()

On Tue, 31 May 2016, Johan S. R. Nielsen wrote: This touches a very fundamental class in Sage: Parent. I'm sure Parent.list() is used for all sorts of stuff everywhere in Sage. I'm seriously surprised this bug hasn't shown up before... At least http://trac.sagemath.org/ticket/9155 is (was) sim

Re: [sage-devel] Users can permanently modify GF(5).list()

>> >> No. Better use a immutable data structure instead of a list. Thinking more about it, what should that be? A tuple? That suddenly makes the name of the function pretty strange. And does a tuple behave exactly like a list in all regards? This touches a very fundamental class in Sage: Parent.

Re: [sage-devel] Users can permanently modify GF(5).list()

I've said it before: list() should always return a tuple. Yes I know its called list, but its just an English thing that verb and noun can't be distinguished. Certainly no excuse to cache mutable data structures. On Tuesday, May 31, 2016 at 2:35:46 PM UTC+2, Jeroen Demeyer wrote: > > On 2016-05-

Re: [sage-devel] Users can permanently modify GF(5).list()

On Tuesday, May 31, 2016 at 2:35:46 PM UTC+2, Jeroen Demeyer wrote: > > No. Better use a immutable data structure instead of a list. > Oh yeah, that's much better. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group a

Re: [sage-devel] Users can permanently modify GF(5).list()

On 2016-05-31 14:06, Johan S. R. Nielsen wrote: And that the small penalty in returning a *copy* of the list in each call to list() is a small price to pay for mitigating user errors? No. Better use a immutable data structure instead of a list. -- You received this message because you are subsc

[sage-devel] Users can permanently modify GF(5).list()

Hi sage-devel We just came across the following bizarre behaviour: sage: F = GF(5) sage: F.list() [0, 1, 2, 3, 4] sage: F.list().remove(0) sage: F.list() [1, 2, 3, 4] sage: GF(5).list() [1, 2, 3, 4] Which means that the user has just forever destroyed GF(5) in this Sage session! This currently c

[sage-devel] Re: Faulty comparison between elements of quotient of multivariate polynomial ring

Hi Nils, On 2016-05-30, Nils Bruin wrote: > On Monday, May 30, 2016 at 9:55:16 AM UTC-7, Alec Edgington wrote: >> >> On Monday, 30 May 2016 17:19:54 UTC+1, Nils Bruin wrote: >>> >>> Currently, u.__cmp__ uses the former to test equality, and it should >>> probably use the latter. The reasoning is

[sage-devel] Re: Faulty comparison between elements of quotient of multivariate polynomial ring

Hi Alec, On 2016-05-30, Alec Edgington wrote: > Thanks, that seems to be the problem. I also note the code comment "The > whole quotient stuff relies in I.reduce(x) returning a normal form of x > with respect to I.". Evidently this is not a good assumption! It is a very good assumption! Unfort

Re: [sage-devel] Renaming generic curve classes

Thanks everyone for the help and suggestions. For now I just want to organize the class structure for curves so that they inherit from the projective/affine subscheme classes, but I'll definitely investigate other structures to aid with upcoming functionality goals (such as resolution of singul

[sage-devel] Re: Weird ImportError with six

great minds think alike ;-) On Tuesday, May 31, 2016 at 8:26:54 AM UTC+2, Frédéric Chapoton wrote: > > It's because these is a "six" module in sage/misc. > > I met this problem in #20694 > > Solution: use from __future__ import absolute import > > Frederic > > Le mardi 31 mai 2016 07:55:14 UTC+2,