On 08/23/10 01:30 PM, Bill Hart wrote:
Surely we are not putting QD back into Sage?
Anyhow, Mark Watkins said that for computing modular degrees you can
(probably) just use ordinary doubles.
Bill.
No, I managed to get around it another way.
The patch I have:
http://trac.sagemath.org/sage_trac/ticket/9703
adds some inline assembler which sets the precision control bits (8 and 9) of
the FPU. It does not need any header files and works on Cyginw and Solaris.
There are also some changes to the Configure script, which were necessary for
this to be integrated, so it not one of those patches where I can guarantee it
will not have some subtle effect on some other system, though I think it's scope
is very limited.
It's been tested on many systems, and passes all doc tests. I'd appreciate if
you could test it on whatever you have.
http://boxen.math.washington.edu/home/kirkby/patches/sympow-1.018.1.p8.spkg
The failures I got before were
sage -t -long devel/sage/sage/modular/abvar/abvar.py # 1 doctests
failed
sage -t -long devel/sage/sage/lfunctions/sympow.py # 13 doctests failed
sage -t -long devel/sage/sage/schemes/elliptic_curves/ell_rational_field.py #
17 doctests failed
so if those pass for you, with that package, I'd be interested. Just make a note
on the trac ticket. The more successful results from it, the more it is likely
to get a positive review.
Dave
On 20 Aug, 22:10, David Kirkby<[email protected]> wrote:
On 20 August 2010 21:09, Mike Hansen<[email protected]> wrote:
This was from Michael Abshoff from awhile back when he was working on
Sage and Solaris:
"""
* sympow: Here we are using Mark Watkins own quaddouble code and the
FPU mode setting code is basically busted. There are two ways how to
handle this: (a) Fix the FPU mode setting code by using Solaris
specific headers (b) rip out the quaddouble code and replace it with
MPFR. (a) might be less work in the short term, but (b) seems to be
the better long term solution since on Mips64 or Sparc for example
IEEE does act sufficiently different to cause trouble. At least the
examples we test on Sparc with sympow seem to compute correctly, but I
would not trust it at all until we use MPFR.
"""
We had run into accuracy issues with Bailey's quaddouble in Sage on
Solaris when working on the number_of_partitions code.
--Mike
Thanks Mike.
I believe I now have a much better understanding of this, and why it
affects only Cygwin and Solaris on 86. There is nothing to worry about
with Solaris on SPARC.
If one downloads the latest quad double package qd-2.3.11.tar.gz,
there is a paper in the docs directory:
"Library for Double-Double and Quad-Double Arithmetic∗
Yozo Hida† Xiaoye S. Li‡ David H. Bailey‡
May 8, 2008"
In that it says:
"Note on Intel x86 Processors. The algorithms in this library assume
IEEE double precision
floating point arithmetic. Since Intel x86 processors have extended
(80-bit) floating point registers,
the round-to-double flag must be enabled in the control word of the
FPU for this library to function
properly under x86 processors. The function fpu fix start turns on the
round-to-double bit in
the FPU control word, while fpu fix end will restore the original state."
Both Solaris on x86 and Cygwin will *not* get this set with sympow,
because it only attempts this if
1) The OS is Linux
2) The processor is x86.
Neither Cygwin or Solaris x86 are consdiered to fall into this
category by the Configure script.
But on Solaris x86 at least, the QD package I downloaded builds and
passes all tests. It uses a bit of inline assembly code to put thex
FPU in the right mode. That should be pretty trivial I think. I should
be able to create something that will work on both Solaris x86 and
Cygwin.
Dave
--
To post to this group, send an email to [email protected]
To unsubscribe from this group, send an email to
[email protected]
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
