On 2013-01-26 00:54, Ethan Van Andel wrote:
> I do not have any easy way to run that build. It certainly doesn't run
> on my machine (12.10 x86).
What do you mean with "x86"? Is that 32-bit or 64-bit? The tarball was
made on an x86_64 machine.
> Also, can you clarify for me: does this build-rela
But we currently use ATLAS-3.8.4 for which I'm not aware of any precision
bug. ATLAS-3.10 also fixed the iml bug. I don't know of any numerical
errors larger than the expected floating point precision.
On Saturday, January 26, 2013 2:09:48 AM UTC, François wrote:
>
> Well my personal take on
Well my personal take on it is that the ATLAS build had a small issue. In the
context of
sage-on-gentoo i have seen particular version of Atlas or other cblas break
only one doctest
as an indication that there was a fault or a difference with the atlas sage
usually ship.
Early version of atlas 3
I do not have any easy way to run that build. It certainly doesn't run on
my machine (12.10 x86). Is there a straightforward way to run it that I'm
unaware of?
Also, can you clarify for me: does this build-related error appear on lots
of machines (i.e. have other people encountered it), or onl
On 2013-01-22 20:13, Ethan Van Andel wrote:
> Has anyone else encountered the numerical errors? I'm happy to dig in
> and try to figure out what's happening, but if the failed build errors
> can't be duplicated (or even if I don't have a way to duplicate them),
> there's not much I can do.
Here
Has anyone else encountered the numerical errors? I'm happy to dig in and
try to figure out what's happening, but if the failed build errors can't
be duplicated (or even if I don't have a way to duplicate them), there's
not much I can do.
Ethan
On Friday, January 18, 2013 5:17:56 PM UTC-8, k
>
>
> It's also worth noting that there's a ticket (#11273) that has been in
> review for roughly two years (most of the delay is my fault) that adds a
> lot of new functionality to this package. It doesn't change any code in
> this section, although it does add more documentation saying roughl
Hi, I'm the primary author of that file.
There are two things being discussed here, the divide-by-zero warnings and
the numerical errors. The same section of code is related to both:
olderr = np.geterr()['invalid'] # checks the current error handling
> np.seterr(invalid='ignore')
> K = np.array
On 18/01/13 23:25, Volker Braun wrote:
> On Friday, January 18, 2013 9:47:53 AM UTC, François wrote:
>
> doctest:1: RuntimeWarning: divide by zero encountered in divide
> It doesn't correlate to any of the error you reported but it adds to
> the feeling that something needs fixing in t
On Friday, January 18, 2013 9:47:53 AM UTC, François wrote:
> doctest:1: RuntimeWarning: divide by zero encountered in divide
> It doesn't correlate to any of the error you reported but it adds to
> the feeling that something needs fixing in that file.
I would say it is precisely the kind of m
On 18/01/13 22:40, Jeroen Demeyer wrote:
> 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 caus
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.
Third po
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
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
15 matches
Mail list logo
