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

2016-06-01 Thread Kiran Kedlaya
Eh? Shouldn't foo.list() return the same as list(foo) (a list) and 
foo.tuple() the same as tuple(foo) (a tuple)?

On Tuesday, May 31, 2016 at 6:08:51 AM UTC-7, Volker Braun wrote:
>
> 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.


[sage-devel] Bugs in solve

2016-06-01 Thread Bruno Grenet

Hi all,

I've reported two bugs in solve on trac, seemingly due to bugs in our 
interface with Maxima.


1. Ticket #20755 : the bug
   implies wrong answers when invoking roots on symbolic expressions:

   sage: w = x^4  -  (1+3*i)*x^3  -  (2-4*i)*x^2  +  (6-2*i)*x-  4  -  4*i
   sage: len(w.roots()) # incorrect
   2
   sage: len(w.roots(ring=QQbar)) # correct
   4

2. Ticket #20346 : the bug
   implies a TypeErrorwhen invoking solve with option "to_poly_solve":

   sage:  p=  x^10  -  10*x^8  +  35*x^6  +  x^5  -  50*x^4  -  5*x^3  +  
25*x^2  +  5*x-  1
   sage:  p.solve(x,  to_poly_solve=True)
   Traceback(most recent call last):
   ...
   TypeError:  'sage.symbolic.expression.Expression'  object  doesnot  support 
indexing

In the tickets, I described as precisely as I can the origin of the 
bugs. Yet I do not understand the interface well enough to fix them. If 
somebody with a better understanding than me can have a look, it would 
be great!


Thanks,
Bruno

--
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] Kudos to tmonteil

2016-06-01 Thread kcrisman
Despite having starting answering questions just over three years ago, 
Thierry Monteil will (probably in mere moments) become the first person 
with 1 "karma" on ask.sagemath.org.  Congratulations - and thanks to 
ALL who patrol that site, which has brought so much help to so many.  (And 
still has plenty of opportunity to do so - see 
http://ask.sagemath.org/questions/scope:unanswered/sort:answers-asc/page:1/ 
)

-- 
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] Re: Infix mod operator?

2016-06-01 Thread Bruno Grenet

I've already commented on trac, but a very quick answer:

Le 01/06/2016 00:07, Volker Braun a écrit :
Well "mod 3" can't occur inside a valid Python expression so at most 
it'll unbreak currently-broken code ;-)


It can be valid in Sage:

sage: implicit_multiplication(True)
sage: mod = 5
sage: mod 3
15

Cheers,
Bruno

--
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] Re: Infix mod operator?

2016-06-01 Thread Daniel Krenn
On 2016-06-01 00:31, Nils Bruin wrote:
> 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?

> The problem with introducing a new reserved keyword is that people are
> presently free to use "mod" as a variable 

...and, of course, there is the function "mod" already defined.


-- 
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] Re: Infix mod operator?

2016-06-01 Thread Erik Bray
On Tue, May 31, 2016 at 7:07 PM, Nils Bruin  wrote:
>
> 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).

All the more reason Sage's preparser should be replaced with an actual
parser, modified from the Python grammar (this was already suggested
in one of the Python 3 threads, in the context of using lib2to3).  An
AST could first be generated using Sage's modified grammar, than
transformed into a standard Python AST for passing through lib2to3 :)

Best,
Erik

-- 
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: make giac/giacpy a standard package

2016-06-01 Thread Dima Pasechnik


On Wednesday, June 1, 2016 at 9:00:34 AM UTC+1, Ralf Stephan wrote:
>
> The giac and giacpy packages are now one year optional (#12375). Since
> pynac-0.6.6 (#20742) has optional support for giac, and uses it to fix a 
> bug,
> as well as a much faster GCD, I'm proposing to make the giac/giacpy 
> packages
> a standard part of Sage. In a recent thread we could also read about the
> speed of its Gröbner basis implementation.
>
> It is planned to do all of Pynac's multivariate polynomial calculations 
> with the
> help of libgiac. Alternatively, the 4.x versions of Singular are still not 
> integrated,
> and if they were they would still be inferior, so I see no alternative for 
> Pynac.
>

An alternative would be a proper Macaulay2 backend - actually, something 
that I plan to 
implement.

Anyway, it would be great to have giac/giacpy as standard packages!



> Please give your opinion.
>
> Regards,
>
>

-- 
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] make giac/giacpy a standard package

2016-06-01 Thread Ralf Stephan
The giac and giacpy packages are now one year optional (#12375). Since
pynac-0.6.6 (#20742) has optional support for giac, and uses it to fix a 
bug,
as well as a much faster GCD, I'm proposing to make the giac/giacpy packages
a standard part of Sage. In a recent thread we could also read about the
speed of its Gröbner basis implementation.

It is planned to do all of Pynac's multivariate polynomial calculations 
with the
help of libgiac. Alternatively, the 4.x versions of Singular are still not 
integrated,
and if they were they would still be inferior, so I see no alternative for 
Pynac.

Please give your opinion.

Regards,

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

2016-06-01 Thread Johan S . R . Nielsen
Volker Braun writes:
> 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.

This is now #20743. Since I am currently unable to compile Sage (see the
Brial thread), I unfortunately can't fix this myself.

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.