On 2014-10-16 22:55, kcrisman wrote:
See http://stackoverflow.com/questions/26409854/ My sense is that NaN
isn't real, but maybe it is in an IEEE framework?
NaN is Not A Number, so surely Not A RealNumber either.
The fact that the Sage parent happens to be RR is not really relevant.
--
You
In #16747, Karen Kohl and Laura Peskin proposed to include Fredrik Johansson's
arb library as an optional package. I cleaned that up a little bit and set this
to needs_review as I did not get any answers from the original authors.
As it is, #16747 simply adds the library and does not do anything
On 16.10.2014 23:09, Volker Braun wrote:
sage: RR('nan')
NaN
Its one of the possible elements of RR, but not ZZ.
sage: RR(NaN)*RR(infinity)
NaN
sage: RR(NaN)*infinity
-Infinity
Huh?
Regards
Jonas
--
You received this message because you are subscribed to the Google Groups
sage-devel
On 2014-10-16, Volker Braun vbraun.n...@gmail.com wrote:
Ok, the ctypedef is the wrong thing. Declaring a fake function that is a
cast on the C side is the way to go:
cdef extern from foo.h:
int* vla_cast (int (*)[]) (int*)
int foo(int n, int* a)
cpdef pyfoo():
cdef int
On Friday, October 17, 2014 11:02:53 AM UTC+1, Dima Pasechnik wrote:
cdef extern from foo.h:
int* vla_cast (int (*)[]) (int*)
int foo(int n, int* a)
Hmm, and what should be in foo.h ?
The header of your external C99 code that you want to call. I.e. only the
foo function
Thats because the infinity ring has no NaN. RR has its own implementation
of infinities, but if you want to consistently compare infinity with any
other Sage element then everything in Sage has to coerce into the Sage
infinity ring.
There are various improvements that one could make to the
RR is not the real numbers, its just a pretty useful approximation for a
variety of tasks.
On Friday, October 17, 2014 8:28:51 AM UTC+1, Jeroen Demeyer wrote:
On 2014-10-16 22:55, kcrisman wrote:
See http://stackoverflow.com/questions/26409854/ My sense is that NaN
isn't real, but maybe
RR is not the real numbers, its just a pretty useful approximation for a
variety of tasks.
Sure! But that doesn't necessarily answer the question either way.
See http://stackoverflow.com/questions/26409854/ My sense is that NaN
isn't real, but maybe it is in an IEEE framework?
On 2014-10-17 13:30, Volker Braun wrote:
RR is not the real numbers, its just a pretty useful approximation for a
variety of tasks.
Sure, and now we have to decide if that approximation works best if
NaN is considered to be an element of it or not.
--
You received this message because you are
On Friday, October 17, 2014 4:00:39 PM UTC+1, Jeroen Demeyer wrote:
Sure, and now we have to decide if that approximation works best if
NaN is considered to be an element of it or not.
Fair enough, but I can tell you already that I'm going to side with the
IEEE in general and Paul
I upgraded my OSX buildbot, now it doesn't compile Sage any more ;-)
Checking multilib configuration for libgcc...
Configuring stage 1 in x86_64-apple-darwin14.0.0/libgcc
configure: creating cache ./config.cache
checking build system type... x86_64-apple-darwin14.0.0
checking host system type...
Relevant bit from config.log:
xgcc (GCC) 4.7.3
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
configure:3355: $? = 0
configure:3344:
Relevant?
https://groups.google.com/d/msg/sage-devel/-sm2ejzcjY8/x27G0nMRdY4J
On Friday, October 17, 2014 6:58:16 PM UTC+2, Volker Braun wrote:
I upgraded my OSX buildbot, now it doesn't compile Sage any more ;-)
Checking multilib configuration for libgcc...
Configuring stage 1 in
Oh that's fun. I usually get that message when xvcc cannot find its own
libraries
in stage 1. Something that is usually solved by setting LD_LIBRARY_PATH (or here
its mac equivalent) or using static libraries for gmp/mpfr/mpc. But this is new,
someone hasn't been thinking forward about new
Sure, and now we have to decide if that approximation works best if
NaN is considered to be an element of it or not.
Fair enough, but I can tell you already that I'm going to side with the
IEEE in general and Paul Zimmermann in particular here.
So you can confirm that this would be an
MPFR itself is not an IEEE standard, but the existence of the NaN special
value is modeled after the IEEE 754 floating point arithmetic.
On Friday, October 17, 2014 7:10:03 PM UTC+1, kcrisman wrote:
Sure, and now we have to decide if that approximation works best if
NaN is considered to be
I tried gcc 4.8.3 with the OSX 10.10 patch but that dies with Bootstrap
comparison failure!
More info: http://trac.sagemath.org/ticket/17169
On Friday, October 17, 2014 6:14:07 PM UTC+1, Jean-Pierre Flori wrote:
Relevant?
https://groups.google.com/d/msg/sage-devel/-sm2ejzcjY8/x27G0nMRdY4J
17 matches
Mail list logo
