This is one of those messages that tries to 'raise Awareness'.
To run all of the optional doctests, regardless of their modifiers, we
can use
sage -t -only-optional
Most machines do not have all of the optional packages installed, so
it may be more useful to target a particular package:
sage -t
BTW: I am perfectly willing to accept a complete replacement of the
current units module (if the new one is better) although others might
disagree...
Would you want to include a metrology module if this replacement is
not accepted?
Oscar
--
To post to this group, send an email to sage-devel@goo
I will check this as soon as I can. I too was not very satisfied with
the units module. In particular, I did not like the way SI prefixes
are handled. Also, this:
sage: m=units.length.m
sage: sqrt(m^2)
sqrt(meter^2)
When I'd expect to get "meter". Some features I'd like to see in a
units module:
I've finally cracked the SYMPOW issue.
I've these this now on
* OpenSolaris
* Linux
* OS X
* Solaris 10 (SPARC)
Mike tested almost identical code on Cygwin, and reported all tests passed. I've
pasted all the doc test results in the ticket, so you can see it is not just
compiling, but worki
I found the "sage.symbolic.units" module very promising, but there
were some features it was missing, such as an easy way to enter units
(something like "units('kg*m/s^2')"), handling of SI prefixes (you can
do "units.si_prefixes.kilo*units.length.meter", but this is very
impractical), unit represe
On 08/12/2010 05:01 PM, Mitesh Patel wrote:
> On 08/11/2010 07:19 PM, Robert Bradshaw wrote:
>> Thanks for looking into this, another data point is really helpful. I
>> put a vanilla Sage in hudson and for a while it was passing all of its
>> tests every time, then all of the sudden it started fail
On 08/21/10 11:42 PM, Mike Hansen wrote:
On Sat, Aug 21, 2010 at 1:49 PM, Dr. David Kirkby
wrote:
I've created a new version of the sympow which builds and passes all the
relevant doc tests on Solaris x86 (Xeon processor).
http://boxen.math.washington.edu/home/kirkby/patches/sympow-1.018.1.p8
On Sat, Aug 21, 2010 at 1:49 PM, Dr. David Kirkby
wrote:
> I've created a new version of the sympow which builds and passes all the
> relevant doc tests on Solaris x86 (Xeon processor).
>
> http://boxen.math.washington.edu/home/kirkby/patches/sympow-1.018.1.p8.spkg
>
> It might work on Cygwin too,
On 08/21/10 09:56 PM, Jeroen Demeyer wrote:
On 2010-08-21 22:49, Dr. David Kirkby wrote:
http://boxen.math.washington.edu/home/kirkby/patches/sympow-1.018.1.p8/patches/fpu.c
Let me just mention that very new versions of gcc support setting the
FPU precision on the gcc command line with the opt
On 2010-08-21 22:49, Dr. David Kirkby wrote:
> http://boxen.math.washington.edu/home/kirkby/patches/sympow-1.018.1.p8/patches/fpu.c
Let me just mention that very new versions of gcc support setting the
FPU precision on the gcc command line with the options -mpc32, -mpc64,
-mpc80. This might be us
I've created a new version of the sympow which builds and passes all the
relevant doc tests on Solaris x86 (Xeon processor).
http://boxen.math.washington.edu/home/kirkby/patches/sympow-1.018.1.p8.spkg
It might work on Cygwin too, though I don't guarantee that. I've written it with
the intensio
On 08/21/10 08:29 PM, Dima Pasechnik wrote:
On Aug 21, 2:41 pm, "Dr. David Kirkby"
wrote:
On 08/21/10 12:00 PM, Jeroen Demeyer wrote:
On 2010-08-21 07:55, Carl Witty wrote:
On Fri, Aug 20, 2010 at 9:26 PM, Dr. David Kirkby
wrote:
Unless OS X rounds by default to 64-bits, I can't un
On Aug 21, 2:41 pm, "Dr. David Kirkby"
wrote:
> On 08/21/10 12:00 PM, Jeroen Demeyer wrote:
>
>
>
>
>
> > On 2010-08-21 07:55, Carl Witty wrote:
> >> On Fri, Aug 20, 2010 at 9:26 PM, Dr. David Kirkby
> >> wrote:
> >>> Unless OS X rounds by default to 64-bits, I can't understand how this
> >>>
Setting SAGE_CHECK=yes forces the test suites of some packages to run. Clearly
that slows the build time - in some cases very significantly. I think with Pari,
it takes about 10x as long to run the test suite as it does to just build the code.
But for some programs, the time need to run the tes
On 21 August 2010 13:27, Jeroen Demeyer wrote:
> I created the following page which will hopefully make reviewing easier:
> http://wiki.sagemath.org/NewPARI
Excellent. Perhaps you could add the suggestion that setting
SAGE_CHECK to yes when compiling the new pari spkg will run all its
tests. Pe
On 08/21/10 12:00 PM, Jeroen Demeyer wrote:
On 2010-08-21 07:55, Carl Witty wrote:
On Fri, Aug 20, 2010 at 9:26 PM, Dr. David Kirkby
wrote:
Unless OS X rounds by default to 64-bits, I can't understand how this would
have ever worked. Why was it not necessary to change the rounding behavior
of
I created the following page which will hopefully make reviewing easier:
http://wiki.sagemath.org/NewPARI
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this g
On 2010-Aug-21 05:26:36 +0100, "Dr. David Kirkby"
wrote:
>it is clear that the quad double algorithm assumes that the floating point
>processor rounds to 64-bits, which things like PowerPC and SPARC do.
>
>But Intel and AMD CPUs round to 80 bits by default. As such, on Intel/AMD
>CPUs,
>the qu
On 2010-08-21 07:55, Carl Witty wrote:
> On Fri, Aug 20, 2010 at 9:26 PM, Dr. David Kirkby
> wrote:
>> Unless OS X rounds by default to 64-bits, I can't understand how this would
>> have ever worked. Why was it not necessary to change the rounding behavior
>> of an Intel based OS X system?
>
> Mo
We're currently planning to merge the big PARI upgrade tickets
http://trac.sagemath.org/sage_trac/ticket/9343
http://trac.sagemath.org/sage_trac/ticket/9591
http://trac.sagemath.org/sage_trac/ticket/9592
into 4.6.alpha0.
I'm planning to release Sage 4.5.3.rc0 by Monday, 23 August, and, if all
go
On 08/21/2010 02:12 AM, Jason Grout wrote:
> On 8/20/10 2:44 PM, Ryan Hinton wrote:
>> I have a build of Sage at school that I occasionally update when a bug
>> or upgrade affects me. I'm the only one who uses it, but it's
>> installed in a public location (i.e. not writable by me) in case
>> some
On 8/20/10 2:44 PM, Ryan Hinton wrote:
I have a build of Sage at school that I occasionally update when a bug
or upgrade affects me. I'm the only one who uses it, but it's
installed in a public location (i.e. not writable by me) in case
someone else *might* use it. And because I don't have enou
22 matches
Mail list logo
