+1 for little endian-ness. As well as consistency, I think big endian
only makes sense for fixed size words. Otherwise you have to know how
large the number is to know what each digit represents, and it seems
odd to me to, say, subtract and have the result of the 5th and 7th
digits be plac
Wait I have to get the permission of each speaker to put his/her talk
on Google Video? I wish that had been dealt with at SAGE Days 4.
On 6/29/07, William Stein <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I've posted most of the video for SAGE Days 4 here:
> http://sage.math.washington.edu/sd4video/
Hi,
I've posted most of the video for SAGE Days 4 here:
http://sage.math.washington.edu/sd4video/
--
William Stein
Associate Professor of Mathematics
University of Washington
http://www.williamstein.org
--~--~-~--~~~---~--~~
To post to this group, send email
After all, Intel has taken over Powerpc even in macs.. ;-)
With that as a precedent, if SAGE goes little-endian, while
Mathematica is big-endian, it could only mean that...
Gonzalo
On 6/29/07, David Roe <[EMAIL PROTECTED]> wrote:
> I would agree on the little endian-ness. The lists of digits c
I would agree on the little endian-ness. The lists of digits coming from
p-adics (and printing in series mode) is little-endian. It would be nice to
be consistent with this. I also agree with David Harvey's arguments.
David
On 6/29/07, David Harvey <[EMAIL PROTECTED]> wrote:
>
>
>
> On Jun 29,
On Jun 29, 2007, at 5:51 AM, Martin Albrecht wrote:
>
> On Friday 29 June 2007 02:48, Nick Alexander wrote:
>> Martin Albrecht <[EMAIL PROTECTED]> writes:
>>> Hi there,
>>>
>>> I often come across the situation where I have to construct an
>>> integer
>>> from its binary representation and vic
On Friday 29 June 2007 02:48, Nick Alexander wrote:
> Martin Albrecht <[EMAIL PROTECTED]> writes:
> > Hi there,
> >
> > I often come across the situation where I have to construct an integer
> > from its binary representation and vice versa. So far you do it in SAGE
> > using strings. I have attac
As other people have mentioned, there's a factor of 2 overhead in the
first loop. I'm not sure why you're indexing from 1 either.
As for writing fast pyrex matrix code, M[i,j] is really slow. Here's
what happens:
- A new (len 2) tuple is allocated
- i and j are converted into Python ints (in
