Re: [sage-devel] Sage 4.3.3.alpha1 released

6 views
Skip to first unread message
Message has been deleted

John Cremona

unread,
Feb 19, 2010, 12:11:50 PM2/19/10
to sage-...@googlegroups.com
On 19 February 2010 06:32, Minh Nguyen <nguye...@gmail.com> wrote:
> Hi folks,
>
> This is the final alpha release of Sage 4.3.3. The next release would
> be an rc0. The development version of Sage is now in feature freeze.
>

On 32-bit Suse I get this fuzz:


File "/local/jec/sage-4.3.3.alpha1/devel/sage/sage/misc/functional.py",
line 705:
sage: h.n()
Expected:
0.33944794097891573
Got:
0.33944794097891567

John

John Cremona

unread,
Feb 19, 2010, 12:42:34 PM2/19/10
to sage-...@googlegroups.com
and on 64-bit ubuntu I get a different error:

sage -t -long "devel/sage/sage/interfaces/r.py"
**********************************************************************
File "/home/jec/sage-4.3.3.alpha1/devel/sage/sage/interfaces/r.py", line 667:
sage: r.help('print.anova')
Expected:
anova package:stats R Documentation
...
Chambers, J. M. and Hastie, T. J. (1992) _Statistical Models in
S_, Wadsworth & Brooks/Cole.
...
Got:
No documentation for 'print.anova' in specified packages and libraries:
you could try '??print.anova'
**********************************************************************

John

ma...@mendelu.cz

unread,
Feb 19, 2010, 1:44:06 PM2/19/10
to sage-devel
32 bit debian:

sage -t -long "devel/sage/sage/interfaces/r.py"
[9.6 s]

----------------------------------------------------------------------
All tests passed!
Total time for all tests: 9.7 seconds

ma...@mendelu.cz

unread,
Feb 19, 2010, 1:50:45 PM2/19/10
to sage-devel
The same problem on 32 bit debian as reported above

sage -t "devel/sage/sage/misc/functional.py"
**********************************************************************
File "/opt/sage-4.3.3.alpha1/devel/sage/sage/misc/functional.py", line


705:
sage: h.n()
Expected:
0.33944794097891573
Got:
0.33944794097891567

**********************************************************************
1 items had failures:
1 of 14 in __main__.example_28

Robert Marik

mhampton

unread,
Feb 19, 2010, 2:08:08 PM2/19/10
to sage-devel
All tests passed on an upgrade from the alpha0, on a 10.6.2 mac.
-Marshall

ma...@mendelu.cz

unread,
Feb 19, 2010, 3:57:06 PM2/19/10
to sage-devel
And the other tests passed (fresh install)

Linux um-bc107 2.6.26-2-686 #1 SMP Wed Aug 19 06:06:52 UTC 2009 i686
GNU/Linux

Robert

David Joyner

unread,
Feb 19, 2010, 4:57:56 PM2/19/10
to sage-...@googlegroups.com
Also, build from source went fine and all tests passed on a 10.6.2 mac.


On Fri, Feb 19, 2010 at 2:08 PM, mhampton <hamp...@gmail.com> wrote:
> All tests passed on an upgrade from the alpha0, on a 10.6.2 mac.
> -Marshall
>

> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>

mhampton

unread,
Feb 19, 2010, 9:55:55 PM2/19/10
to sage-devel
Another upgrade passed all tests on Ubuntu 9.10 64-bit, on a core i7
860 quad-core machine.

slabbe

unread,
Feb 20, 2010, 7:58:39 AM2/20/10
to sage-devel
> This is the final alpha release of Sage 4.3.3. The next release would
> be an rc0. The development version of Sage is now in feature freeze.

Does that mean only ticket solving a defect will be merged into sage
until sage-4.4.1?

The Sage days 20 are beginning on Monday. I think there will be a big
loads of tickets being created/reviewed/solved in the next 10 days.
Moreover, I will explain how to contribute to sage to at least three
persons. It would be nice if their first ticket could be reviewed and
merged in sage-4.3.3....especially since sage-4.4 is planned to be a
stabiliser release. If it is fine with release managers, I would
propose a sage-4.3.3.alpha2 version that would contain the first quick
results of Sage Days 20.

Cordially,

Sébastien

Message has been deleted

John H Palmieri

unread,
Feb 20, 2010, 11:45:09 AM2/20/10
to sage-devel
On Feb 19, 11:08 am, mhampton <hampto...@gmail.com> wrote:
> All tests passed on an upgrade from the alpha0, on a 10.6.2 mac.
> -Marshall

On two separate 10.6.2 machines, I was unable to upgrade successfully:
after upgrading, any attempt to run Sage would give me a segfault.

With a build from scratch, all tests passed on one machine, while on
another I see

--------------

The following tests failed:

sage -t -long "devel/sage/sage/plot/plot3d/base.pyx"

The failures all end with the message

ImportError: The _imaging C module is not installed

--
John

John Cremona

unread,
Feb 20, 2010, 12:16:36 PM2/20/10
to sage-...@googlegroups.com
On 20 February 2010 16:29, Minh Nguyen <nguye...@gmail.com> wrote:
> Hi John,
>
> On Sat, Feb 20, 2010 at 4:11 AM, John Cremona <john.c...@gmail.com> wrote:
>
> <SNIP>

>
>> On 32-bit Suse I get this fuzz:
>>
>>
>> File "/local/jec/sage-4.3.3.alpha1/devel/sage/sage/misc/functional.py",
>> line 705:
>>    sage: h.n()
>> Expected:
>>    0.33944794097891573
>> Got:
>>    0.33944794097891567
>
> I get the same numerical noise on two Itanium machines: iras and cleo
> on Skynet. A patch is up at ticket #8314:
>
> http://trac.sagemath.org/sage_trac/ticket/8314
>

Now positively reviewed.

John

> --
> Regards
> Minh Van Nguyen

ma...@mendelu.cz

unread,
Feb 20, 2010, 1:18:59 PM2/20/10
to sage-devel
On 20 ún, 18:16, John Cremona <john.crem...@gmail.com> wrote:
> >http://trac.sagemath.org/sage_trac/ticket/8314
>
> Now positively reviewed.
>
> John

This solves the problem with dostests, but I see another problem: we
have two different answers. One of them is wrong. Which one? And why?

And is it O.K. to change doctest instead of fix a bug?

Robert Marik

Message has been deleted

John Cremona

unread,
Feb 20, 2010, 1:37:34 PM2/20/10
to sage-...@googlegroups.com
On 20 February 2010 18:26, Minh Nguyen <nguye...@gmail.com> wrote:
> Hi Robert,
>
> On Sun, Feb 21, 2010 at 5:18 AM, ma...@mendelu.cz <ma...@mendelu.cz> wrote:
>
> <SNIP>

>
>> This solves the problem with dostests, but I see another problem: we
>> have two different answers. One of them is wrong. Which one? And why?
>>
>> And is it O.K. to change doctest instead of fix a bug?
>
> The function call h.n() results in a numerical appoximation, which is
> I think machine dependent. One gets different answers on different
> machines, as the doctest reports on the 32-bit Suse and 64-bit Itanium
> machines show. So I think it's not even a 32- vs. 64-bit issue. So I
> think it's architecture dependent.

Would it be more arch. independent if we used RR(h) instead?

ma...@mendelu.cz

unread,
Feb 20, 2010, 1:52:20 PM2/20/10
to sage-devel
Hi Minh

thank you very much for explanation. Looks strange for me, but I
cannot understand details - I have no education in computer science.

I wonder, if Maple, Mathematica or Maxima exihibit similar behavior on
various architectures. Does anybody know?

Robert

On 20 ún, 19:26, Minh Nguyen <nguyenmi...@gmail.com> wrote:

> The function call h.n() results in a numerical appoximation, which is
> I think machine dependent. One gets different answers on different
> machines, as the doctest reports on the 32-bit Suse and 64-bit Itanium
> machines show. So I think it's not even a 32- vs. 64-bit issue. So I
> think it's architecture dependent.
>

Dr. David Kirkby

unread,
Feb 20, 2010, 2:23:43 PM2/20/10
to sage-...@googlegroups.com
Minh Nguyen wrote:
> Hi Robert,
>
> On Sun, Feb 21, 2010 at 5:18 AM, ma...@mendelu.cz <ma...@mendelu.cz> wrote:
>
> <SNIP>
>
>> This solves the problem with dostests, but I see another problem: we
>> have two different answers. One of them is wrong. Which one? And why?
>>
>> And is it O.K. to change doctest instead of fix a bug?
>
> The function call h.n() results in a numerical appoximation, which is
> I think machine dependent. One gets different answers on different
> machines, as the doctest reports on the 32-bit Suse and 64-bit Itanium
> machines show. So I think it's not even a 32- vs. 64-bit issue. So I
> think it's architecture dependent.


That's almost certainly true. In fact, the result printed by the "failure" is
more accurate than the expected value! I tried this in Mathematica:


In[1]:= Integrate[ Sin[x]/x^2,{x,1,Pi/2}]

-2 Pi
Out[1]= -- - CosIntegral[1] + CosIntegral[--] + Sin[1]
Pi 2

In[2]:= N[%,100]

Out[2]= 0.3394479409789156796919271718652186179944769882691752577491475103140\

> 509215988087842006743201412102786

One just has to live with these numerical issues. There was a discussion on
gcc-help the other day by someone who got different answers from two different
Intel chips. So you can't even assume it's an Intel/AMD/SPARC/Itanium issue.


Dave


Erik Lane

unread,
Feb 20, 2010, 3:13:27 PM2/20/10
to sage-...@googlegroups.com
>
> That's almost certainly true. In fact, the result printed by the "failure"
> is more accurate than the expected value! I tried this in Mathematica:
>

This might be a trivial question, but how do you know which number is
more accurate than the other, if those results are machine-dependent?
Or is the Mathematica answer your gold standard? If that is the case I
find it troubling. One of the reasons for Sage, in my mind, is to
avoid Mathematica and its 'black-box' approach. Therefore to trust its
answers over your own program's as the arbiter of accuracy is not a
promising sign.

I really am not meaning to troll, but that raised a huge red flag in my mind.

Thanks,
Erik

Robert Bradshaw

unread,
Feb 20, 2010, 3:32:29 PM2/20/10
to sage-...@googlegroups.com
On Feb 20, 2010, at 12:13 PM, Erik Lane wrote:

>> That's almost certainly true. In fact, the result printed by the
>> "failure"
>> is more accurate than the expected value! I tried this in
>> Mathematica:
>
> This might be a trivial question, but how do you know which number is
> more accurate than the other, if those results are machine-dependent?

It's pretty standard in numerical integration (and any other numerical
algorithms) for the last couple of bits to be wrong due to (the
accumulation of) rounding, which can be platform dependent. This is
why, for example, numerical_integral provides an answer and an error
bound:

sage: numerical_integral(sin(x)/x^2, 1, 1/2*pi)
(0.33944794097891573, 3.7686291973639345e-15)

> Or is the Mathematica answer your gold standard? If that is the case I
> find it troubling.

Sometimes Mathematica is wrong, but it can still provide a useful check.

> One of the reasons for Sage, in my mind, is to
> avoid Mathematica and its 'black-box' approach. Therefore to trust its
> answers over your own program's as the arbiter of accuracy is not a
> promising sign.
>
> I really am not meaning to troll, but that raised a huge red flag in
> my mind.

I think the reason Mathematica was invoked is because it can do
arbitrary precision numerical integration, and a good test to see if
the last couple of digits are right is to compute the result to much
higher precision. (We do have arbitrary precision for lots of other
stuff, but much of the numerical stuff is to double precision only,
which is the most useful and lots faster.)

- Robert


John H Palmieri

unread,
Feb 20, 2010, 3:40:39 PM2/20/10
to sage-devel
On Feb 19, 9:11 am, John Cremona <john.crem...@gmail.com> wrote:

> On 19 February 2010 06:32, Minh Nguyen <nguyenmi...@gmail.com> wrote:
>
> > Hi folks,
>
> > This is the final alpha release of Sage 4.3.3. The next release would
> > be an rc0. The development version of Sage is now in feature freeze.
>
> On 32-bit Suse I get this fuzz:
>
> File "/local/jec/sage-4.3.3.alpha1/devel/sage/sage/misc/functional.py",
> line 705:
>     sage: h.n()
> Expected:
>     0.33944794097891573
> Got:
>     0.33944794097891567

I was curious about this, so I tried specifying the number of digits:

sage: h = integral(sin(x)/x^2, (x, 1, pi/2)); h
integrate(sin(x)/x^2, x, 1, 1/2*pi)
sage: h.n()
0.33944794097891573
sage: h.n(digits=14)
0.33944794097891573
sage: h.n(digits=600)
0.33944794097891573
sage: h.n(digits=600) == h.n(digits=14)
True
sage: h.n(prec=50) == h.n(prec=1000)
True

Is there an inherit limit in Sage on the accuracy of numerical
integrals?

--
John

Robert Bradshaw

unread,
Feb 20, 2010, 4:13:09 PM2/20/10
to sage-...@googlegroups.com


I don't know if this above uses ginac, maxima, or gsl, but it seems
limited to double precision (which wouldn't surprise me for any of
those three systems). It's also very new. It should probably be
raising a NotImplemented error, but at least it's not casting the
result to a higher precision ring.

- Robert


Fredrik Johansson

unread,
Feb 20, 2010, 4:30:40 PM2/20/10
to sage-...@googlegroups.com

You can use mpmath for arbitrary precision integration:

sage: import mpmath
sage: mpmath.mp.dps = 50
sage: mpmath.quad(lambda x: mpmath.sin(x)/x**2, [1, mpmath.pi/2])
mpf('0.33944794097891567969192717186521861799447698826917531')
 
Fredrik

Harald Schilly

unread,
Feb 20, 2010, 4:36:53 PM2/20/10
to sage-devel
On Feb 20, 10:30 pm, Fredrik Johansson <fredrik.johans...@gmail.com>
wrote:

> You can use mpmath ...

Btw. is mpmath-0.14 now in 4.3.3 or not? -> http://trac.sagemath.org/sage_trac/ticket/8159

h

Message has been deleted

Erik Lane

unread,
Feb 20, 2010, 4:48:45 PM2/20/10
to sage-...@googlegroups.com
> I think the reason Mathematica was invoked is because it can do arbitrary
> precision numerical integration, and a good test to see if the last couple
> of digits are right is to compute the result to much higher precision. (We
> do have arbitrary precision for lots of other stuff, but much of the
> numerical stuff is to double precision only, which is the most useful and
> lots faster.)
>
> - Robert

Thank you for that very clear answer!

Georg S. Weber

unread,
Feb 20, 2010, 5:09:37 PM2/20/10
to sage-devel

Hi John,

AFAIK, the "_import" module is built by the PIL spkg. Try reinstalling
it, eventually you have to issue "export SAGE_BINARY_BUILD=yes"
before, in order to make PIL build sanely (I have to do that every
time on my production machine). I have no idea whether this is related
to the segfaults you see after updating, however. Were these installs
older than the MACOSX_DEPLOYMENT_TARGET patch (I don't remember the
ticket number)? That would explain it, and then you should do clean
full installs anyway.


Cheers,
Georg

Dr. David Kirkby

unread,
Feb 20, 2010, 5:38:01 PM2/20/10
to sage-...@googlegroups.com
Erik Lane wrote:
>> That's almost certainly true. In fact, the result printed by the "failure"
>> is more accurate than the expected value! I tried this in Mathematica:
>>
>
> This might be a trivial question, but how do you know which number is
> more accurate than the other, if those results are machine-dependent?

The result I showed, the answer was not computed using a floating point
processor, but by arbitrary precision arithmetic. As such, it should not have
been machine defendant.

> Or is the Mathematica answer your gold standard?

I'm not suggesting it is a gold standard, but given the results agreed
reasonably closely with Sage, and were computed to arbitrary precision, then I
had a reasonable degree of confidence in believing the "failure" was not really
a failure at all.

> If that is the case I
> find it troubling. One of the reasons for Sage, in my mind, is to
> avoid Mathematica and its 'black-box' approach. Therefore to trust its
> answers over your own program's as the arbiter of accuracy is not a
> promising sign.

From a practical point of view, despite the open source nature of Sage and the
closed-source nature of Mathematica, I am *personally* in a no better position
to evaluate Sage's answer than I am to check Mathematica's answer. Since Sage is
not anyone's program really.

If my life depended on that integral, I'd look at other ways of verifying the
result.

> I really am not meaning to troll, but that raised a huge red flag in my mind.

It was not meant to.

> Thanks,
> Erik
>

John H Palmieri

unread,
Feb 20, 2010, 10:53:24 PM2/20/10
to sage-devel
On Feb 20, 2:09 pm, "Georg S. Weber" <georgswe...@googlemail.com>
wrote:

> Hi John,
>
> AFAIK, the "_import" module is built by the PIL spkg. Try reinstalling
> it, eventually you have to issue "export SAGE_BINARY_BUILD=yes"
> before, in order to make PIL build sanely (I have to do that every
> time on my production machine).

I tried reinstalling it, running this export command first, and that
seems to have worked. I noticed one difference on the two machines:
on the one where I don't have the failure, it says

--- using frameworks at /System/Library/Frameworks

and on the other one, it says

--- using frameworks at /Library/Frameworks

I think there may be some bad things in the second directory, from
when I tried to build python or tcl or tk, and maybe those are
interfering somehow. Our spkg should try to guard against this,
somehow.

> I have no idea whether this is related
> to the segfaults you see after updating, however. Were these installs
> older than the MACOSX_DEPLOYMENT_TARGET patch (I don't remember the
> ticket number)?

No, this was upgraded from 4.3.3.alpha0, which itself was built from
scratch.

--
John

Erik Lane

unread,
Feb 21, 2010, 3:57:10 AM2/21/10
to sage-...@googlegroups.com
> I'm not suggesting it is a gold standard, but given the results agreed
> reasonably closely with Sage, and were computed to arbitrary precision, then
> I had a reasonable degree of confidence in believing the "failure" was not
> really a failure at all.
>


Thank you for your very clear explanation!
Erik

Georg S. Weber

unread,
Feb 21, 2010, 11:02:14 AM2/21/10
to sage-devel
> > AFAIK, the "_import" module is built by the PIL spkg. Try reinstalling
> > it, eventually you have to issue "export SAGE_BINARY_BUILD=yes"
> > before, in order to make PIL build sanely (I have to do that every
> > time on my production machine).
>
> I tried reinstalling it, running this export command first, and that
> seems to have worked.  I noticed one difference on the two machines:
> on the one where I don't have the failure, it says
>
> --- using frameworks at /System/Library/Frameworks
>
> and on the other one, it says
>
> --- using frameworks at /Library/Frameworks
>
> I think there may be some bad things in the second directory, from
> when I tried to build python or tcl or tk, and maybe those are
> interfering somehow.  Our spkg should try to guard against this,
> somehow.
>

Maybe yes, maybe no,

the PIL setup.py intentionally probes for external libraries that do
not come with Sage. These may be installed in different locations on
different computers, so what you see might be just OK. The only "good"
solution would be to officially incorporate some libjpeg.spkg and
libtiff.spkg in Sage, or to cripple PIL to never probe for those
(which is necessary if you build binary distribitions, that's what the
env var from my former message is for). The current situation is
somewhat a compromise. Not that the PIL setup.py couldn't be
streamlined a bit further, but there's more important work to do.


Cheers,
Georg

Burcin Erocal

unread,
Feb 21, 2010, 4:27:47 PM2/21/10
to sage-...@googlegroups.com

This is now #8321:

http://trac.sagemath.org/sage_trac/ticket/8321

Thanks.

Burcin

Reply all
Reply to author
Forward
0 new messages