Jan Groenewald wrote:
Just for fun, I started a build on the ubuntu development release.
It goes:
...
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
chec
Hi
Just for fun, I started a build on the ubuntu development release.
It goes:
...
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make se
Floating-point and numerically unstable formula just don't mix. Sure,
working with RIF makes it much harder to get something that is plainly
wrong, but you can still construct quickly-varying functions where it will
give you the wrong result. There is no magic bullet, you have to learn
about nu
vdelecroix wrote:
In particular, when
I write ((106*pi - 333) / (355 - 113*pi)).n(digits=4) I do expect the
four first digits of my real number and not a "ValueError:
power::eval(): division by zero". Even if I am a starter.
Isn't that pretty educational?
From the message you can immediately g
On 19 mai, 12:34, Volker Braun wrote:
> For starters, most of the plotting stuff will rely on quickly computing
> numerical approximations to symbolic expressions. There you certainly don't
> want to start refining the RIF precision iteratively if you hit a
> numerically unstable point.
I got it
For starters, most of the plotting stuff will rely on quickly computing
numerical approximations to symbolic expressions. There you certainly don't
want to start refining the RIF precision iteratively if you hit a
numerically unstable point.
The only bug that I see is that the documentation of
On 19 mai, 11:52, Volker Braun wrote:
> On Sunday, May 19, 2013 10:36:18 AM UTC+1, vdelecroix wrote:
> > If we want to round down the
> > expression "- expr" then we should round up "expr" and then take the
> > opposite.
>
> If you care about errors then you should be evaluating the symbolic
> exp
On Sunday, May 19, 2013 10:36:18 AM UTC+1, vdelecroix wrote:
> If we want to round down the
> expression "- expr" then we should round up "expr" and then take the
> opposite.
If you care about errors then you should be evaluating the symbolic
expressions with interval arithmetic. Your proposa
Sorry, the first block of examples should be replaced with
{{{
sage: a = (106*pi - 333) / (355 - 113*pi)
sage: a.n(digits=5)
Traceback (most recent call last)
...
ValueError: power::eval(): division by zero
sage: a.n(digits=6)
289.000
sage: a.n(digits=7)
289.
sage: a.n(digits=8)
293.65079
sage:
On 19 mai, 03:36, leif wrote:
> vdelecroix wrote:
> > In an attempt to improve #14567, I found the following thing (which
> > for me is a bug). Consider the different real fields with rounding
> > RNDD or RNDU. Then -pi is systematically wrongly approximated.
>
> AFAIK that's a (probably unexpecte
Ah, I see. Can you tell me what the intended behavior should be? I was
hoping I could help out somewhere, but I'd need to know what should be
intended in both the documentation and the function. Also, do you know
anything about the function's behavior on QQ?
On Tuesday, May 14, 2013 9:39:08 PM
On May 19, 12:15 am, Robert Bradshaw
wrote:
> Note that adding a __dict__ also massively slows down any cpdef function
> calls.
Which could be mitigated if cython would grow a pragma that allows
cpdef calls being generated with "__pyx_skip_dispatch=1" (giving them
the semantics of "cdef method t
Note that adding a __dict__ also massively slows down any cpdef function calls.
On Sat, May 18, 2013 at 10:16 AM, Nils Bruin wrote:
> I don't dare posting this on cython-users because it's a horrible
> hack, but it does make a cython class have a dictionary that gets
> recognized by python as one
13 matches
Mail list logo
