On Friday, October 24, 2014 9:45:46 AM UTC-7, Nils Bruin wrote:
> There may be a good reason why Sage chooses to call __radd__ manually
> rather than let python do the work by returning NotImplemented, but if
> there's not perhaps it would be better to stay closer to python's standard?
>
The re
Understood. Thank you!
On Friday, October 24, 2014 2:45:46 PM UTC-2, Nils Bruin wrote:
>
> On Thursday, October 23, 2014 11:46:02 AM UTC-7, João Alberto Ferreira
> wrote:
>>
>> I am running the following Python example from the book "Learning
>> Python", from Mark Lutz and David Ascher, but Sage
On Thursday, October 23, 2014 11:46:02 AM UTC-7, João Alberto Ferreira
wrote:
>
> I am running the following Python example from the book "Learning
> Python", from Mark Lutz and David Ascher, but Sage is returning a
> TypeError after presenting the correct response. Can anyone explain me
> why?
Ok, thank you all!
I was curious just because, due to the error, I did not expect a result.
On Thursday, October 23, 2014 5:28:46 PM UTC-2, kcrisman wrote:
>
> Or, in the notebook/cell server/cloud, choose "python" from the drop-down
> menu for system and just do this example in Python! Lots of
Or, in the notebook/cell server/cloud, choose "python" from the drop-down
menu for system and just do this example in Python! Lots of options.
> Or type
>
> Integer = int
>
> to make Sage integers the usual Python integers in that session.
>
> On Thu, Oct 23, 2014 at 11:54 AM, Volker Braun
Or type
Integer = int
to make Sage integers the usual Python integers in that session.
On Thu, Oct 23, 2014 at 11:54 AM, Volker Braun wrote:
> The short answer is that mathematical objects in Sage don't define addition
> by implementing __add__ and __radd__ by hand. If you want to learn about
>
The short answer is that mathematical objects in Sage don't define addition
by implementing __add__ and __radd__ by hand. If you want to learn about
them make sure to not add Sage objects (like Sage integers). E.g. int(1) +
y would work.
On Thursday, October 23, 2014 7:46:02 PM UTC+1, João Al
This is now http://trac.sagemath.org/sage_trac/ticket/11436.
--
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to
sage-support+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sage-su
> > > I don't know why, but maybe that can help you track it down.
>
> > Thanks - that definitely helps, since pexpect is actually passing
> > strings.
>
> Well, searching for "1024" in r.py results in two hits, and I think the
I don't know why that didn't occur to me.
> relevant one is
The oth
On Monday, June 6, 2011 12:55:49 PM UTC-7, kcrisman wrote:
>
>
> >
> > > So I feel like pexpect must be doing something naughty. Does anyone
> > > have any ideas what might be going on so I can use more data?
> >
> > I tried this experiment: I added spaces to the first string to be
> > evalua
>
> > So I feel like pexpect must be doing something naughty. Does anyone
> > have any ideas what might be going on so I can use more data?
>
> I tried this experiment: I added spaces to the first string to be
> evaluated. When the string has length <= 1024, it seems to work, and when
> the stri
On Monday, June 6, 2011 10:54:57 AM UTC-7, kcrisman wrote:
>
> I'm using R matrices to use an R program and then do things with it in
> Sage. For some reason Sage doesn't get the "right" answer for
> matrices above a certain size.
>
> The first one is right (it gives the space that is in the
Thanx!
On Oct 1, 9:16 am, Martin Albrecht <[EMAIL PROTECTED]>
wrote:
> > I just wanted to know what is the difference between case 2^15 and
> > 2^16.
>
> > Thanx in advance!
>
> > Bests,
> > Ahmad
>
> These are different implementations. GF(2^15) uses Givaro under the hood and
> GF(2^16) is using
> I just wanted to know what is the difference between case 2^15 and
> 2^16.
>
> Thanx in advance!
>
> Bests,
> Ahmad
These are different implementations. GF(2^15) uses Givaro under the hood and
GF(2^16) is using Pari/GP. I'll open a trac ticket about that bug.
Martin
PS: GF(p^n) for p^n >= 2^
Anyway the to_V function introduced by William is wokring fine:
def to_V(w):
return V(w.polynomial().padded_list(V.dimension()))
On Oct 1, 5:35 am, Ahmad <[EMAIL PROTECTED]> wrote:
> I just tried this and when the field is bigger or equal to 2^16 I got
> following error:
>
> 2^15: Fine!
>
>
15 matches
Mail list logo