Re: [sage-devel] Sage 4.3.3.alpha1 released
John Cremona
> 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
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
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
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
-Marshall
ma...@mendelu.cz
Linux um-bc107 2.6.26-2-686 #1 SMP Wed Aug 19 06:06:52 UTC 2009 i686
GNU/Linux
Robert
David Joyner
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
860 quad-core machine.
slabbe
> 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
John H Palmieri
> 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
> 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
>
> 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
> >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
John Cremona
> 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?
>
> 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
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
> Hi Robert,
>
> On Sun, Feb 21, 2010 at 5:18 AM, ma...@mendelu.cz <ma...@mendelu.cz> wrote:
>
> <SNIP>
>
>> 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?
>
> 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
> 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
>> 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
> 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
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
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')
Harald Schilly
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
Erik Lane
> 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
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
>> 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
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
> 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
> > 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
