I hope we agree that evaluation (meaning evaluation of all variables
by some elements in a ring) should yield an element of the ring. I
don't mind if subs should give back a polynomial in all cases.
[Aside: Strangely this is not the case for symbolic expressions. I am
sure there must have been a
On Fri, Mar 11, 2011 at 8:42 AM, Simon King wrote:
> On 11 Mrz., 17:24, Volker Braun wrote:
>> Substitution should always try to return the same type (i.e. same parent) if
>> possible. Anything else will just be a constant source of bugs where your
>> code works with generic polynomial input, but
I hope we agree that evaluation (meaning evaluation of all variables
by some elements in a ring) should yield an element of the ring. I
don't mind if subs should give back a polynomial in all cases.
[Aside: Strangely this is not the case for symbolic expressions. I am
sure there must have been a
I hope we agree that evaluation (meaning evaluation of all variables
by some elements in a ring) should yield an element of the ring. I
don't mind if subs should give back a polynomial in all cases.
[Aside: Strangely this is not the case for symbolic expressions. I am
sure there must have been a
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, 14 Mar 2011 17:40:41 +0100
Julien PUYDT wrote:
> Le 14/03/2011 14:12, David Kirkby a écrit :
> >
> > On 14 March 2011 13:04, David Kirkby
> > wrote:
> >> On 13 March 2011 15:34, Julien PUYDT
> >> wrote:
> >>> Hi,
> >>>
> >>> among the few failing tests with my ARM built, two are because o
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:40, Julien PUYDT wrote:
> > Le 14/03/2011 14:12, David Kirkby a écrit :
> >
> > The solution of finding a "good" integer is fragile : it will break
> > anytime wind will change direction.
>
> I tend to agree.
>
> > Actually, the best solution is the one I gave : handle fuz
Le 14/03/2011 14:48, David Kirkby a écrit :
Have you run the Python test suite?
$ SAGE_CHECK=yes
$ export SAGE_CHECK
$ ./sage -f python-2.6.x (or whatever version we have)
That will run the Python test suite. ~Just about everyone gets some
failures, but if you get pickling failure, then report
On 14 March 2011 16:40, Julien PUYDT wrote:
> Le 14/03/2011 14:12, David Kirkby a écrit :
> The solution of finding a "good" integer is fragile : it will break anytime
> wind will change direction.
I tend to agree.
> Actually, the best solution is the one I gave : handle fuzzy results! You
> ha
On Monday, March 14, 2011 9:40:41 AM UTC-7, Snark wrote:
>
> Le 14/03/2011 14:12, David Kirkby a �crit :
>
> Are doctests pure string checks? Can't they allow things like "(result -
> expected) < 0.001" ?
>
Yes and yes. You can certainly have a test like
sage: abs(x-y) < 0.0001
True
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.
Le 14/03/2011 14:12, David Kirkby a écrit :
On 14 March 2011 13:04, David Kirkby wrote:
On 13 March 2011 15:34, 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", li
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)
On Mar 14, 10:58 am, Volker Braun wrote:
> On Monday, March 14, 2011 6:13:54 AM UTC, Dr. David Kirkby wrote:
>
> > 1) A doctest should have a comment by it, referencing the trac ticket where
> > the
> > test was added. In other words, just simply "Trac #1234" if the test was
> > added
> > on ticke
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 13 March 2011 15:34, Julien PUYDT wrote:
> Hi,
>
> the most serious problem I see in my ARM port is the following :
>
> File "/home/jpuydt/sage-4.6.2/devel/sage/sage/structure/sage_object.pyx",
> line 1053:
> sage: print "x"; sage.structure.sage_object.unpickle_all() # long time
> (4s on sa
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
On 14 March 2011 13:04, David Kirkby wrote:
> On 13 March 2011 15:34, 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(floa
On 13 March 2011 15:34, 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.9
On Monday, March 14, 2011 6:13:54 AM UTC, Dr. David Kirkby wrote:
>
> 1) A doctest should have a comment by it, referencing the trac ticket where
> the
> test was added. In other words, just simply "Trac #1234" if the test was
> added
> on ticket 1234.
>
In the few cases where the doctest was
Le 14/03/2011 07:39, Dr. David Kirkby a écrit :
On 03/13/11 03:34 PM, Julien PUYDT wrote:
running "make ptestlong" gave (in part -- the rest is in other mails) :
sage -t -long -force_lib devel/sage/sage/tests/cmdline.py # 2 doctests
failed
sage -t -long -force_lib devel/sage/sage/calculus/riem
26 matches
Mail list logo
