sagetolerance * DBL_EPSILON <= abs(f(x)-expected_result)
would be one general method to test for epsilon equivalency at double
precision.
On Mar 17, 7:06 am, Jason Grout wrote:
> On3/17/11 12:35 AM, Robert Bradshaw wrote:
>
>
>
>
>
> > On Wed, Mar 16, 2011 at 6:15 PM, Jason Grout
> > wrote:
>
On 3/17/11 12:35 AM, Robert Bradshaw wrote:
On Wed, Mar 16, 2011 at 6:15 PM, Jason Grout
wrote:
On 3/16/11 3:04 PM, Peter Jeremy wrote:
Overall, I believe the abs(actual-expected)
Crazy idea: What if we introduce a "# numeric 1e-10" doctest flag (like
#optional, etc.) that does just that---
On Thu, Mar 17, 2011 at 01:35, Robert Bradshaw wrote:
> On Wed, Mar 16, 2011 at 6:15 PM, Jason Grout
> wrote:
> > On 3/16/11 3:04 PM, Peter Jeremy wrote:
> >
> >> Overall, I believe the abs(actual-expected) >> the only practical way to handle doctests. The expected numeric
> >> result is still
Hello,
What if we introduce a "# numeric 1e-10" doctest flag (like
#optional, etc.) that does just that---reads in the doctest answer, gets the
output of the function, and does an abs(actual-expected)< epsilon (where
epsilon can be specified in the flag, or it has a default).
sage: some_numerica
On Wed, Mar 16, 2011 at 6:15 PM, Jason Grout
wrote:
> On 3/16/11 3:04 PM, Peter Jeremy wrote:
>
>> Overall, I believe the abs(actual-expected)> the only practical way to handle doctests. The expected numeric
>> result is still available, just not on a line by itself.
>
> Crazy idea: What if we in
On Wed, Mar 16, 2011 at 4:58 AM, Julien PUYDT wrote:
> Le 16/03/2011 08:55, Robert Bradshaw a écrit :
>>
>> We can, for example, call gsl rather than libc. Or we can special case
>> this processor and/or set of values.
>>
>> Whatever process is used to compute the value, the fact is that the
>> re
On Mar 17, 1:50 am, kcrisman wrote:
> On Mar 16, 9:15 pm, Jason Grout wrote:
>
> > On 3/16/11 3:04 PM, Peter Jeremy wrote:
>
> > > Overall, I believe the abs(actual-expected) > > the only practical way to handle doctests. The expected numeric
> > > result is still available, just not on a line b
On Mar 16, 9:15 pm, Jason Grout wrote:
> On 3/16/11 3:04 PM, Peter Jeremy wrote:
>
> > Overall, I believe the abs(actual-expected) > the only practical way to handle doctests. The expected numeric
> > result is still available, just not on a line by itself.
>
> Crazy idea: What if we introduce
On 3/16/11 3:04 PM, Peter Jeremy wrote:
Overall, I believe the abs(actual-expected)
Crazy idea: What if we introduce a "# numeric 1e-10" doctest flag (like
#optional, etc.) that does just that---reads in the doctest answer, gets
the output of the function, and does an abs(actual-expected)< ep
On 2011-Mar-15 19:55:33 +, David Kirkby wrote:
>The x86 CPU has an 80-bits, which is used for long-double on some
>systems.
This is part of the original x87 FPU. The i386 API uses this by
default (but the x86_64 API uses SSE2 by default so long doubles need
special handling). The x87 suffer
Le 16/03/2011 08:55, Robert Bradshaw a écrit :
We can, for example, call gsl rather than libc. Or we can special case
this processor and/or set of values.
Whatever process is used to compute the value, the fact is that the
result has *no* rounding error on all other platforms. This platform
prod
On 16 March 2011 07:55, Robert Bradshaw wrote:
> On Tue, Mar 15, 2011 at 12:55 PM, David Kirkby
> wrote:
>> On 15 March 2011 17:05, Julien PUYDT wrote:
>>> Well, as far as I know, the result of computing $\Gamma(n)$ for a small
>>> integral $n$ is mathematically an integer,
>>
>> It's true for
On Wed, Mar 16, 2011 at 8:55 AM, Robert Bradshaw
wrote:
> Whatever process is used to compute the value, the fact is that the
> result has *no* rounding error on all other platforms. This platform
> produces inferior results, and I'd call it a bug. Let's fix/work
> around it, not mask it.
We also
On Tue, Mar 15, 2011 at 12:55 PM, David Kirkby wrote:
> On 15 March 2011 17:05, Julien PUYDT wrote:
>> Le 14/03/2011 20:00, Robert Bradshaw a écrit :
>>>
>>> In the case of the OP's failures, that processor (or libm, libc,
>>> whatever) is giving us less accurate answers than anything else we've
On 15 March 2011 17:05, Julien PUYDT wrote:
> Le 14/03/2011 20:00, Robert Bradshaw a écrit :
>>
>> In the case of the OP's failures, that processor (or libm, libc,
>> whatever) is giving us less accurate answers than anything else we've
>> tested on, and I think it's worth looking into fixing the
Le 14/03/2011 20:00, Robert Bradshaw a écrit :
In the case of the OP's failures, that processor (or libm, libc,
whatever) is giving us less accurate answers than anything else we've
tested on, and I think it's worth looking into fixing the problem, or
even adding an # optional, or as an expected
More OT:
On Mon, Mar 14, 2011 at 12:42 PM, Willem Jan Palenstijn
wrote:
> You can use 'hg blame' or similar to get the revision in which a line/doctest
> was changed, and then 'hg log -r revision' to get the commit message of that
> revision.
And for a while now we've tried to make sure that ti
On Mon, Mar 14, 2011 at 12:42 PM, Willem Jan Palenstijn
wrote:
> On Mon, Mar 14, 2011 at 05:44:26PM +, David Kirkby wrote:
>> On 14 March 2011 16:42, Willem Jan Palenstijn wrote:
>> > You can use hg to find out which commit added it, and if that commit is
>> > recent enough it will have the
On Mon, Mar 14, 2011 at 05:44:26PM +, David Kirkby wrote:
> On 14 March 2011 16:42, Willem Jan Palenstijn wrote:
> > You can use hg to find out which commit added it, and if that commit is
> > recent enough it will have the trac ticket number in the commit message.
> > This is what version con
On Mon, Mar 14, 2011 at 8:49 AM, David Kirkby wrote:
> On 14 March 2011 14:58, rjf wrote:
>> At the risk of pointing out the obvious, there are 2 well known
>> tests for the closeness of two numbers.
>>
>> relative error and absolute error.
>>
>> abs( (a-b)/a) is relative error [assume a [or b]
On 14 March 2011 16:42, Willem Jan Palenstijn wrote:
> On Mon, Mar 14, 2011 at 03:48:00PM +, David Kirkby wrote:
>> > Why are we even testing the behaviour on floats? Isn't sage's default
>> > floating point type RDF?
>>
>> If the trac ticket number was a comment in the code, as I suggested o
On Mon, Mar 14, 2011 at 03:48:00PM +, David Kirkby wrote:
> On 14 March 2011 13:38, Nils Bruin wrote:
> > On Mar 13, 4:34?pm, Julien PUYDT wrote:
> >> Hi,
> >>
> >> among the few failing tests with my ARM built, two are because of
> >> accuracy reasons :
> >>
> >> File "/home/jpuydt/sage-4.6.
On 14 March 2011 14:58, rjf wrote:
> At the risk of pointing out the obvious, there are 2 well known
> tests for the closeness of two numbers.
>
> relative error and absolute error.
>
> abs( (a-b)/a) is relative error [assume a [or b] is not zero) and
> abs( a-b ) is absolute error.
>
> Defini
On 14 March 2011 13:38, Nils Bruin wrote:
> On Mar 13, 4:34 pm, Julien PUYDT wrote:
>> Hi,
>>
>> among the few failing tests with my ARM built, two are because of
>> accuracy reasons :
>>
>> File "/home/jpuydt/sage-4.6.2/devel/sage/sage/functions/other.py", line 497:
>> sage: gamma1(float(6)
At the risk of pointing out the obvious, there are 2 well known
tests for the closeness of two numbers.
relative error and absolute error.
abs( (a-b)/a) is relative error [assume a [or b] is not zero) and
abs( a-b ) is absolute error.
Defining another error measurement by "how many digits ar
On Mar 13, 4:34 pm, Julien PUYDT wrote:
> Hi,
>
> among the few failing tests with my ARM built, two are because of
> accuracy reasons :
>
> File "/home/jpuydt/sage-4.6.2/devel/sage/sage/functions/other.py", line 497:
> sage: gamma1(float(6))
> Expected:
> 120.0
> Got:
> 119.999
26 matches
Mail list logo
