[sage-devel] Re: Infix mod operator?

[Nils Bruin]

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 * generation, 
we can finally accept lisp syntax!

The problem with introducing a new reserved keyword is that people are 
presently free to use "mod" as a variable and with the new preparser rule 
their code would break, e.g.

mod = pi/2
sin(mod)

is now valid, but would be preparsed to

sin*mod()

which probably is invalid or at least very likely has a different result.


-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Infix mod operator?

[Volker Braun]

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 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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Infix mod operator?

[Volker Braun]

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 polynomials, I agree than requiring parens to 
disambiguate is a good idea, otherwise

x^2-1 mod x+1

will most likely not do what you want.

 

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Infix mod operator?

[Nils Bruin]

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 
> 
>

I can see a few negatives: 
 - confusion with "%" operator and with "mod" operators in other languages 
(which are generally "remainder" operators)
 - once we have it for integers, I am sure people would start to expect it 
to work in other situations too (where preparsing is harder)
 - the current implementation is a smart idea, but it's not "highest 
precedence": 3^5 mod 2
 - you're introducing a new reserved word in sage, which will break 
previous code.
 - to be an infix operator, it has to respect parentheses, so (2+3) mod 
(3*(7+8)^2-19) should work (and then we're down the drain again, because 
regex isn't powerful enough for parentheses).

I think it's an interesting experiment, but at the moment I don't think the 
advantages (a slightly more convenient way of creating elements in Z/nZ by 
having a shorthand notation for IntegerRing(n).one()) outweigh the problems 
above.

I think the observation that having extremely concise access to the 
appropriate 1 and then let coercion do the job, is a very useful one. So if 
we'd spell it

42 * mod(8)

you're almost there. The implementation could possibly by

def mod(N):
  return parent(N).quo(N).one()

You have to write the parentheses (but honestly, most math typesets (mod N) 
anyway, and usually has very low precedence because it qualifies the entire 
formula) and the multiplication sign (unless you're crazy enough to 
activate implicit multiplication), but in return there's no extra 
preparsing, no reserved keyword, and complete transparency to what it does 
and higher generality (because it will work for polynomials too). With a 
little more work we could also have it work for ideals.

So, +1 for the whole suggestion, but I think we should go with the 
convenience function instead of preparsing. There's a reason why python3 
made "print" into a function instead of a separate syntactic construct.

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Infix mod operator?

[Volker Braun]

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 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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Alec Edgington]

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 respect to I.". Evidently this is not a good assumption! 
>
> It is a very good assumption! Unfortunately, it seems that this 
> assumption doesn't hold in all cases :( 
>

You're right, the assumption should hold. Which means the real problem is 
in the reduce() method.

Alec

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Jori Mäntysalo]

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) similar.

--
Jori Mäntysalo

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

[Johan S . R . Nielsen]

>>
>> 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. 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...

Best,
Johan

Johan S. R. Nielsen writes:

> 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 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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Volker Braun]

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-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 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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Johan S. R. Nielsen]

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 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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Jeroen Demeyer]

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 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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Johan S . R . Nielsen]

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 causes a bug in a decoding algorithm in
sage.coding.linear_code.

My first thought was to simply fix this behaviour with finite fields.
But looking in sage/structure/parent.pyx:1356 it turns out that this
behaviour is not only known but also tested for! In #10470, caching of
list() was introduced and tested for exactly by modifying the returned
list.

Do people agree with me that this behaviour is crazy? 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? Or do you agree with the
authors of #10470 and that the current behaviour should be retained.

Best,
Johan

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Simon King]

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 argued in the code. It looks like 
>>> univariate polynomial ideals should just get a containment test implemented
>>>
>>
>> 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!
>>
> This is now http://trac.sagemath.org/ticket/20722 . First try is there. 
> Some unexpected consequences (the univariate problem might have been solved 
> already). An expert on quotients of "letterplace" free algebras is required.

I thought that letterplace does provide a normal form. Does it not?

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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Simon King]

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! Unfortunately, it seems that this
assumption doesn't hold in all cases :(

Cheers,
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Renaming generic curve classes

[Grayson Jorgenson]

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 
singularities). I really like Johan's suggestion for the class names and 
folder name, and have attempted implementing these changes in ticket #20697 
.

Thanks again,
Grayson

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Weird ImportError with six

[Volker Braun]

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, Andrey Novoseltsev a écrit :
>>
>> Hello,
>>
>> Can anybody explain (even better - fix ;-)) what is going on with this 
>> error with 7.2 and 7.3.beta0:
>>
>> sage: from sage.misc.remote_file import get_remote_file
>> sage: get_remote_file('
>> http://193.146.36.205:8080/GgbSageDirect/DiscoverGGB/DiscoverGGBAux/2015_11_24_fromGgbXMLString2Cons.sage
>> ')
>> Attempting to load remote file: 
>> http://193.146.36.205:8080/GgbSageDirect/DiscoverGGB/DiscoverGGBAux/2015_11_24_fromGgbXMLString2Cons.sage
>>
>> ---
>> ImportError   Traceback (most recent call 
>> last)
>>  in ()
>> > 1 get_remote_file('
>> http://193.146.36.205:8080/GgbSageDirect/DiscoverGGB/DiscoverGGBAux/2015_11_24_fromGgbXMLString2Cons.sage
>> ')
>>
>> /home/novoselt/sage/local/lib/python2.7/site-packages/sage/misc/remote_file.pyc
>>  
>> in get_remote_file(filename, verbose)
>>  34
>>  35 # import compatible with py2 and py3
>> ---> 36 from six.moves.urllib.request import urlretrieve
>>  37
>>  38 global cur
>>
>> ImportError: No module named moves.urllib.request
>>
>> Given that I can repeat this line directly without any issues:
>>
>> sage:  from six.moves.urllib.request import urlretrieve
>> 
>>
>> Thank you!
>> Andrey
>>
>>

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.