On 2013-01-18 08:31, Jeroen Demeyer wrote:
> After further investigating, I found the culprit to be ATLAS. Which
> means that either:
> * ATLAS returns quite bad results for some tuning parameters.
> * or riemann.pyx misuses ATLAS in a way which causes small errors to
> become very big.
Also not
After further investigating, I found the culprit to be ATLAS. Which
means that either:
* ATLAS returns quite bad results for some tuning parameters.
* or riemann.pyx misuses ATLAS in a way which causes small errors to
become very big.
--
You received this message because you are subscribed to t
Hi Jason,
No, I don't have an account. Yes, that would be reasonable from my side.
Regards,
Jan
On 18 January 2013 07:49, Jason Grout wrote:
> On 1/17/13 12:17 PM, Jan Groenewald wrote:
>
>>
>> No, I would rather privately transfer it to someone who can host this
>> kind of bandwidth. In Afri
On 1/17/13 12:17 PM, Jan Groenewald wrote:
No, I would rather privately transfer it to someone who can host this
kind of bandwidth. In Africa bandwidth is scarce, and multiple downloads
will be detrimental to our institutional bandwidth. Our better bandwidth
on Cape Town virtual servers cost per
The three major non-graphical components are fast_eval, numpy, and cython.
Cython seems an unlikely culprit--though who knows. More likely it's either
fast_eval or numpy. I know that different builds get minorly different
answers due to differences in the numpy/lapack matrix computation routines
If the functions are independent I would split it up into different files.
It might actually improve the readability ;-)
With link time optimization (gcc -flto) this should end up the same but lto
currently defaults to off.
--
You received this message because you are subscribed to the Google
On 2013-01-17 20:48, Martin Albrecht wrote:
> Any other options?
Just live with it.
It still takes way more RAM to build the documentation than to build M4RIE.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To post to this group, send email to s
On 2013-01-17 20:48, Martin Albrecht wrote:
> = Split up the file =
>
> This can easily be done, its functions all handle different cases and do not
> interact. Volker suggested it might not make much of a difference because GCC
> optimises beyond file boundaries but if we actually produce diffe
Hi,
so it seems a lot of stories of people trying to build Sage on constrained
devices include something like: "the most time was spent building libm4rie all
of which pretty much is waiting for swap".
So let's take a harder look at M4RIE. The file in questions is - as far as I
can tell - conv
After many trials and tribulations, I've finished a build of Sage-5.5 for
the Raspberry Pi. I'm still running the doctests; I've only seen timeouts
so far, which is quite positive. I'm unsure how long the full (long)
testsuite will take to run, but will post an update when it finishes. If
an
Hi Emil,
No, I would rather privately transfer it to someone who can host this kind
of bandwidth. In Africa bandwidth is scarce, and multiple downloads will be
detrimental to our institutional bandwidth. Our better bandwidth on Cape
Town virtual servers cost per MB.
I was hoping to get it on a Sa
On 2013-01-17, Volker Braun wrote:
> --=_Part_173_26006841.1358428542611
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Thursday, January 17, 2013 2:13:02 AM UTC, Dima Pasechnik wrote:
>
>> Mind you, when I worked on the latest Maxima update (#13364), I had to do
>> git
>> bisect on *
Am Donnerstag, 17. Januar 2013 16:56:41 UTC+1 schrieb Jan Groenewald:
>
> Hi
>
> On 15 January 2013 23:47, Jason Grout
> > wrote:
>
>> I'm really interested in a USB image that I can hand to students that
>> want to do development with me that:
>>
>> * I can modify (to include the Sage cell ser
On Thursday, January 17, 2013 10:57:14 AM UTC-5, Jeroen Demeyer wrote:
>
> On 2013-01-17 15:59, kcrisman wrote:
> > These are weird. This code is (documented to be) only accurate up to a
> > point, because of the inherent craziness of computing such things, but
> > it's good for what it does.
On 2013-01-17 15:59, kcrisman wrote:
> These are weird. This code is (documented to be) only accurate up to a
> point, because of the inherent craziness of computing such things, but
> it's good for what it does. But these errors are very different. I'm
> cc:ing the author in case he can think o
Hi
On 15 January 2013 23:47, Jason Grout wrote:
> I'm really interested in a USB image that I can hand to students that want
> to do development with me that:
>
> * I can modify (to include the Sage cell server, git, etc., for example)
>
> * have all the development tools installed, so that Sage
On Thursday, January 17, 2013 9:26:00 AM UTC-5, Jeroen Demeyer wrote:
>
> I sometimes get these (or similar) failures which seem to be due to some
> build-time problem. For any given build of Sage, if there are failures,
> then re-running the tests will reproduce the failures. But rebuild Sag
I sometimes get these (or similar) failures which seem to be due to some
build-time problem. For any given build of Sage, if there are failures,
then re-running the tests will reproduce the failures. But rebuild Sage
from scratch and the failures are gone. I haven't tracked this down
further. T
On Thursday, January 17, 2013 2:13:02 AM UTC, Dima Pasechnik wrote:
> Mind you, when I worked on the latest Maxima update (#13364), I had to do
> git
> bisect on *Maxima* repo to debug *Sage*, and then apply the results of
> this
> investigation to stripped of .git/ Maxima source tree, for whi
Op donderdag 17 januari 2013 13:30:45 UTC+1 schreef Dima Pasechnik het
volgende:
>
> No, not really. The bug fixes produced included
>
> * unmerging a particular commit in Maxima master,
> (by providing a corresponding patch in spkg),
> and this was purely Sage-specific.
> And for this
On 2013-01-17, Burcin Erocal wrote:
> On Thu, 17 Jan 2013 11:31:41 + (UTC)
> Dima Pasechnik wrote:
>
>> On 2013-01-17, Burcin Erocal wrote:
>> > On Thu, 17 Jan 2013 07:17:43 + (UTC)
>> > Dima Pasechnik wrote:
>> [...]
>> >> This still looks like an ugly hack. Shouldn't we rather use
>
On Thu, 17 Jan 2013 11:31:41 + (UTC)
Dima Pasechnik wrote:
> On 2013-01-17, Burcin Erocal wrote:
> > On Thu, 17 Jan 2013 07:17:43 + (UTC)
> > Dima Pasechnik wrote:
> [...]
> >> This still looks like an ugly hack. Shouldn't we rather use
> >> something like [git-subtree]
> >> (https://
On 2013-01-17, Burcin Erocal wrote:
> On Thu, 17 Jan 2013 07:17:43 + (UTC)
> Dima Pasechnik wrote:
[...]
>> This still looks like an ugly hack. Shouldn't we rather use
>> something like [git-subtree]
>> (https://github.com/apenwarr/git-subtree/) to deal with upstream
>> source?
>
> git-sub{
On Thursday, January 17, 2013 9:46:30 AM UTC, Nathann Cohen wrote:
> echo "==> Je recupere Sage : $url"
> echo "==> Nom du fichier : $fname"
> echo "Let's roll ?"
>
Ca roule!
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To post to this group
Here's the one I use :-)
#!/bin/bash
wget -q http://www.sagemath.org/download-latest.html -O /tmp/a
fname="sage-$(grep "The latest development version is" /tmp/a | perl -ape
"s/^.*\ is\ //g")"
url="http://boxen.math.washington.edu/home/release/$fname/$fname.tar";
echo "==> Je recupere Sage : $ur
On Thu, 17 Jan 2013 07:17:43 + (UTC)
Dima Pasechnik wrote:
> On 2013-01-17, Robert Bradshaw wrote:
> > On Wed, Jan 16, 2013 at 6:13 PM, Dima Pasechnik
> > wrote:
> >> On 2013-01-16, Volker Braun wrote:
> >>> --=_Part_588_6290856.1358340327889
> >>> Content-Type: text/plain; charset=ISO
On 2013-01-16 23:36, François Bissey wrote:
> On Wed, 16 Jan 2013 14:12:57 Maarten Derickx wrote:
>> Dear all,
>>
>> I want to create a script that when I run it automatically downloads the
>> latest sage developement version. I was wondering what would be the best
>> way to do so?
>>
> downloading
On 2013-01-17, Keshav Kini wrote:
> Dima Pasechnik writes:
>>> Expanding on http://wiki.sagemath.org/WorkflowSEP one would have
>>>
>>> sage_root/
>>> sage # the binary
>>> Makefile # top level Makefile
>>> (configure) # perhaps, eventually
>>> ... # othe
On 2013-01-17, Keshav Kini wrote:
> Dima Pasechnik writes:
>
>> On 2013-01-17, Robert Bradshaw wrote:
>>> On Wed, Jan 16, 2013 at 11:17 PM, Dima Pasechnik wrote:
On 2013-01-17, Robert Bradshaw wrote:
> On Wed, Jan 16, 2013 at 6:13 PM, Dima Pasechnik wrote:
>> On 2013-01-16, Volke
Dima Pasechnik writes:
> On 2013-01-17, Robert Bradshaw wrote:
>> On Wed, Jan 16, 2013 at 11:17 PM, Dima Pasechnik wrote:
>>> On 2013-01-17, Robert Bradshaw wrote:
On Wed, Jan 16, 2013 at 6:13 PM, Dima Pasechnik wrote:
> On 2013-01-16, Volker Braun wrote:
>> --=_Part_588_629
Dima Pasechnik writes:
>> Expanding on http://wiki.sagemath.org/WorkflowSEP one would have
>>
>> sage_root/
>> sage # the binary
>> Makefile # top level Makefile
>> (configure) # perhaps, eventually
>> ... # other standard top level files (README, etc.)
>>
On 2013-01-17, Robert Bradshaw wrote:
> On Wed, Jan 16, 2013 at 11:17 PM, Dima Pasechnik wrote:
>> On 2013-01-17, Robert Bradshaw wrote:
>>> On Wed, Jan 16, 2013 at 6:13 PM, Dima Pasechnik wrote:
On 2013-01-16, Volker Braun wrote:
> --=_Part_588_6290856.1358340327889
> Content
32 matches
Mail list logo
