I have these rather unpleasant failure:
sage -t --long --warn-long 76.2 src/sage/tests/cmdline.py
**
File "src/sage/tests/cmdline.py", line 222, in
sage.tests.cmdline.test_executable
Failed example:
print out
Expected:
34
On 2014-11-04 22:31, Harald Schilly wrote:
On Tue, Nov 4, 2014 at 10:24 PM, Jeroen Demeyer wrote:
In my opinion, doctest output should be the actual output of a Sage run
somewhere and not artificially be adjusted
Well, if there are different outputs for the same input, which one to
pick?
An
On 2014-11-04 22:02, Jean-Pierre Flori wrote:
I think its the way we treat tolerance which changed
It's true that the way we treat tolerance has changed, see
http://trac.sagemath.org/ticket/16889
But that's not the reason for the failed tests, the reason is
http://trac.sagemath.org/ticket/16858
On Tue, Nov 4, 2014 at 10:24 PM, Jeroen Demeyer wrote:
> In my opinion, doctest output should be the actual output of a Sage run
> somewhere and not artificially be adjusted
Well, if there are different outputs for the same input, which one to
pick? IMHO, in this case it's actually better to cle
On 2014-11-04 21:58, Thierry wrote:
Enlagring the tolerance for catching the correct result instead of
taking this correct result as the centered expectation looks like an odd
fix !
On the other hand, don't forget that doctests serve not only as *tests*
but also as *docs*. I think it's good to h
On Tuesday, November 4, 2014 8:58:54 PM UTC, Thierry wrote:
>
> all those numerical noise appearing suddenly, couldn't that mean that
> some numerical algorithm became less stable/accurate somewhere in the
> code ?
No, it is because we print more digits now.
--
You received this message bec
It could. But in this case looking at the 1e-15 tolerance I think that
we are just hitting numerical noise because the specification for double
doesn't insure that those last decimals are exact. And even if it
was for a single computation we could be hit by rounding error if there is
a number of
On Tuesday, November 4, 2014 9:58:54 PM UTC+1, Thierry wrote:
>
> Hi,
>
> all those numerical noise appearing suddenly, couldn't that mean that
> some numerical algorithm became less stable/accurate somewhere in the
> code ?
>
> I think its the way we treat tolerance which changed, so no real
Hi,
all those numerical noise appearing suddenly, couldn't that mean that
some numerical algorithm became less stable/accurate somewhere in the
code ?
If it turns out to be the case, we should thank doctests for the
discovery, not asking them to shut up by enlarging the tolerance !
Also, in the
On Tuesday, November 4, 2014 7:02:00 PM UTC+1, Volker Braun wrote:
>
> Since they are machine-dependent numerical noise its not going to get
> fixed unless you tell us what failed.
>
> Sure, don't worry, I'll open a ticket for that.
It is #17921.
--
You received this message because you are s
Since they are machine-dependent numerical noise its not going to get fixed
unless you tell us what failed.
On Tuesday, November 4, 2014 3:54:19 PM UTC, Jean-Pierre Flori wrote:
>
> I didn't check but would say so as the failures happen in other files.
> Namely in the different translations of:
>
On 4 November 2014 15:42, Volker Braun wrote:
> Do you get any failures with #17278?
>
2 pass, 1 still fails:
File "src/sage/tests/french_book/linsolve_doctest.py", line 51, in
sage.tests.french_book.linsolve_doctest
Failed example:
x = A\b; x # rel tol 1e-15
Expected:
(-0.2
I didn't check but would say so as the failures happen in other files.
Namely in the different translations of:
src/doc/en/tutorial/tour_linalg.rst
--
You received this message because you are subscribed to the Google Groups
"sage-release" group.
To unsubscribe from this group and stop receiving
Do you get any failures with #17278?
On Tuesday, November 4, 2014 1:58:34 PM UTC, Jean-Pierre Flori wrote:
>
>
>
> On Tuesday, November 4, 2014 2:16:43 PM UTC+1, John Cremona wrote:
>>
>> It's a long time since I have done a "make ptestlong" and not had
>> several test failures. I have done "ma
On 4 November 2014 13:56, Volker Braun wrote:
> At least the ones you mention are in #17278 which will be in rc2
Good! looking forward to it.
John
>
>
> On Tuesday, November 4, 2014 1:16:43 PM UTC, John Cremona wrote:
>>
>> It's a long time since I have done a "make ptestlong" and not had
>> se
On Tuesday, November 4, 2014 2:16:43 PM UTC+1, John Cremona wrote:
>
> It's a long time since I have done a "make ptestlong" and not had
> several test failures. I have done "make distclean" first and have
> pulled the latest develop branch (commit
> 8b95db32005c62e289d6698e8233218d5fda0f60)
At least the ones you mention are in #17278 which will be in rc2
On Tuesday, November 4, 2014 1:16:43 PM UTC, John Cremona wrote:
>
> It's a long time since I have done a "make ptestlong" and not had
> several test failures. I have done "make distclean" first and have
> pulled the latest develo
It's a long time since I have done a "make ptestlong" and not had
several test failures. I have done "make distclean" first and have
pulled the latest develop branch (commit
8b95db32005c62e289d6698e8233218d5fda0f60) but see this:
sage -t --long src/sage/matrix/matrix_double_dense.pyx # 1 doctest
On Tuesday, November 4, 2014 8:49:10 AM UTC, leif wrote:
>
> Well, if a (potential) argument follows '-n'
Its not a hand-written parser, duh. Also, that is not how command line
tools work.
> > On the plus side the error that you'll get is pretty self-explanatory.
> CRITICAL:root:unknown,
>
Volker Braun wrote:
You can't really deprecate that yet make the notebook selectable, either
-n takes an option or not.
Well, if a (potential) argument follows '-n', but doesn't match any of
'ipython', 'sagenb', nor 'default', we should probably default to
'default'... ;-) (Not to mention it
20 matches
Mail list logo
