On Sep 14, 3:02 pm, Andrey Novoseltsev wrote:
> sage: list(m)
> [(0, 0), (0, 0)]
This is just a consequence of iter(m) yielding an iterator over the
rows of m. Changing that would break code.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To p
On 9/14/12 5:02 PM, Andrey Novoseltsev wrote:
Hello,
I find the following confusing:
sage: m = matrix(2)
sage: m
[0 0]
[0 0]
sage: m.list()
[0, 0, 0, 0]
sage: list(m)
[(0, 0), (0, 0)]
There can be arguments on what is a list of a matrix, but I think that
two outputs above should be the same. A
Christopher Swenson writes:
> Raspberry Pi?
No, a Trim-Slice H250:
http://thread.gmane.org/gmane.comp.mathematics.sage.devel/58670/focus=58749
-Keshav
Join us in #sagemath on irc.freenode.net !
--
You received this message because you are subscribed to the Google Groups
"sage-devel" g
Hello,
I find the following confusing:
sage: m = matrix(2)
sage: m
[0 0]
[0 0]
sage: m.list()
[0, 0, 0, 0]
sage: list(m)
[(0, 0), (0, 0)]
There can be arguments on what is a list of a matrix, but I think that
two outputs above should be the same. Are there any reasons to not
make it happen? Sinc
Le 14/09/2012 19:33, Julien Puydt a écrit :
PS: almost five hours now for that file ;-)
It went through after at most height hours.
Snark on #sagemath
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To post to this group, send email to sage-d
Hi folks,
you may have already seen this, but in case you haven't, I'm thrilled
to share that the Python Software Foundation has just created its
newest and highest distinction, the Distinguished Service Award, and
has chosen John as its first recipient:
http://pyfound.blogspot.com/2012/09/announ
I was surprised to learn that Sage has a notion of equal that is not
transitive. While you are of course free to make up rules and define new
relations that fall in the gap between mathematics and computer
representation, it might help to look at what other computer algebra
systems do. In par
On Friday, September 14, 2012 6:34:01 PM UTC+1, Snark wrote:
> Here is a good question: if it's possible to split for a more efficient
> compilation, why doesn't the compiler just do that automatically?
The optimization is eating your box alive, the rest is peanuts compared to
that.
At leas
Raspberry Pi?
Though I think running qemu would be faster...
On Fri, Sep 14, 2012 at 11:52 AM, Jeroen Demeyer wrote:
> William, you once or twice mentioned that you were going to order an ARM
> box for Sage development. Did anything happen already?
>
> --
> You received this message because you
Le 14/09/2012 18:40, Philipp Jovanovic a écrit :
On Sep 14, 2012, at 6:33 PM, Jeroen Demeyer wrote:
On 2012-09-14 18:30, Julien Puydt wrote:
If you can split it to alleviate the above, then I'll gladly test the
resulting spkg :-)
Alternatively, compile that file with less optimization
On Sep 14, 2012, at 6:33 PM, Jeroen Demeyer wrote:
> On 2012-09-14 18:30, Julien Puydt wrote:
>> Le 14/09/2012 18:21, Martin Albrecht a écrit :
>>> conversion.c also takes a long time to compile on my machine, I am
>>> considering
>>> splitting it up into smaller units. It's a bunch of bitflippi
Le 14/09/2012 18:33, Jeroen Demeyer a écrit :
On 2012-09-14 18:30, Julien Puydt wrote:
If you can split it to alleviate the above, then I'll gladly test the
resulting spkg :-)
Alternatively, compile that file with less optimization
Yes, but it looks more like a workaround than a solution :
On 2012-09-14 18:30, Julien Puydt wrote:
> Le 14/09/2012 18:21, Martin Albrecht a écrit :
>> conversion.c also takes a long time to compile on my machine, I am
>> considering
>> splitting it up into smaller units. It's a bunch of bitflipping
>> functions that
>> are huge because hardcoded shifts ar
Le 14/09/2012 18:21, Martin Albrecht a écrit :
conversion.c also takes a long time to compile on my machine, I am considering
splitting it up into smaller units. It's a bunch of bitflipping functions that
are huge because hardcoded shifts are a lot faster than variable shifts.
Indeed, if it's s
Hi,
conversion.c also takes a long time to compile on my machine, I am considering
splitting it up into smaller units. It's a bunch of bitflipping functions that
are huge because hardcoded shifts are a lot faster than variable shifts.
On Friday 14 Sep 2012, Julien Puydt wrote:
> Hi,
>
> the co
Le 14/09/2012 17:51, Jeroen Demeyer a écrit :
On 2012-09-14 17:25, Julien Puydt wrote:
Hi,
the compilation of sage 5.3 on ARM doesn't seem to work as well as for
the previous version ; specifically, the compilation of libm4rie is
problematic in the file conversion.c : it started three hours ago
William, you once or twice mentioned that you were going to order an ARM
box for Sage development. Did anything happen already?
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To post to this group, send email to sage-devel@googlegroups.com.
To u
On 2012-09-14 17:25, Julien Puydt wrote:
> Hi,
>
> the compilation of sage 5.3 on ARM doesn't seem to work as well as for
> the previous version ; specifically, the compilation of libm4rie is
> problematic in the file conversion.c : it started three hours ago and
> it's still on that file. The box
Hi,
the compilation of sage 5.3 on ARM doesn't seem to work as well as for
the previous version ; specifically, the compilation of libm4rie is
problematic in the file conversion.c : it started three hours ago and
it's still on that file. The box isn't dead, just taxed...
I must admit that I
Hi,
The math department is installing their UPS's in the server room. My
understanding is that this would not entail any downtime for the sage
cluster, but evidently it will. I don't know if this is indirect --
maybe just the network switches or something are down.
William
On Fri, Sep 14, 2012
for me, pinging to math.washington.edu doesn't succeed either (only
washington.edu works). so, my guess is, this is (once again) a UW network
specific router outage. the cluster itself is probably just fine, only lost
connection to the outside world :-)
h
--
You received this message because
Is the sage cluster down right now? I can't ping or ssh into mod, geom,
boxen, or sage.
Thanks,
Jason
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To post to this group, send email to sage-devel@googlegroups.com.
To unsubscribe from this gro
As indicated in Debian bug opened by Snark (#687496), the problem is
already known and fixed upstream
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54559), so this is just a
matter of waiting for 4.7.1-9 in Debian (or using 4.7.1-7)...
Thanks for the answers.
Damien
--
You received this messa
On 2012-09-14 11:08, Damien Wyart wrote:
> Should I get in touch with the gcc
> team through a bug report myself? Or open a bug on the Debian side?
I guess this depends on whether you get this bug only with Debian's GCC
or also with vanilla GCC. If unsure, I would open a bug for Debian's GCC.
--
Thanks Jason! I'm not surprised that there's lots of room for speed up --
and I agree it could be a lot of fun for the right kind of person :)
I've been out of the loop for a little while, and I guess I missed
interact.sagemath.org . . . I have a few things I'd like to add!
On Thursday, Septe
Le 14/09/2012 11:08, Damien Wyart a écrit :
I have a copy of the end of the compilation log file and also of the
temporary file refered to by gcc. Should I get in touch with the gcc
team through a bug report myself? Or open a bug on the Debian side? Or
transmit the files to sage dev team who woul
On Friday, September 14, 2012 11:51:03 AM UTC+1, Simon King wrote:
> But hang on. Do you suggest that the cached method fed with unhashable
> arguments
> does return a result, but won't cache it? That might be very reasonable.
> Then, it would only remain to make power series and friends unhash
Hi Volker,
On 2012-09-14, Volker Braun wrote:
> --=_Part_466_20242037.1347617685588
> Content-Type: text/plain; charset=ISO-8859-1
>
> We don't have to break any existing @cached_method code, we just have to
> change @cached_... to skip the cache lookup if the argument doesn't have a
> __ha
We don't have to break any existing @cached_method code, we just have to
change @cached_... to skip the cache lookup if the argument doesn't have a
__hash__.
And is_identical() would of course have to work recursively, so for two
polynomials you'd have to compare the coefficients with is_ident
Hi,
I can't compile sage with an up-to-date Debian unstable, and this seems
related to gcc 4.7.1-8 (reverting to 4.7.1-7 does the trick).
I am not sure how to proceed right now, because I have no knowledge of the
sage source code, nor of gcc internals...
Here are a few relevant lines from the
Hi,
the patchbot site shows a traceback suggesting the mongodb server is
down.
http://patchbot.sagemath.org/
Am I looking at the right page? Can somebody bring the database up?
Thanks.
Burcin
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
31 matches
Mail list logo
