On 2 May 2012 10:36, David Kirkby <david.kir...@onetel.net> wrote:
> On 2 May 2012 09:43, John Cremona <john.crem...@gmail.com> wrote:
>> This one example (#12893) is a good illustration of how non-trivial a
>> task it is to add doctests, and also how important it is to do so:
>> not ony was a (small) bug found in one the the newly tested functions,
>> but another bug was revealed somewhere else in Sage. So adding
>> doctests is extremely likely to end up in identifying and (hopefully)
>> fixing bugs, which can be hard and time-consuming,
>
> Yes, I agree.
>
> I wish I could convince William a bit more of the importance of this.
I'm sure that William agrees entirely with what I said.
>
>> and certainly
>> involves some knowledge of what the functions are really doing.
>
> That's where I can't really help. My background is not mathematics,
> though I'm not totally mathematically retarded. Number theory used to
> be a hobby of mine, but not any more.
>
>> That said, there is also a use for the testing which (I think) David K
>> did a while back which was to fire random input at random functions to
>> see what happens, with somewhat embarrassing results for some function
>> I wrote which have not all been fixed yet. (e.g. mwrank('0 0 0 0')
>> hangs forever because -- as everyone is supposed to know -- mwrank
>> wants 5 integers input, and it is waiting for a 5th, but will never
>> get it.
>
> Yes, it was me who fired random data into Sage.
>
> 19 months ago I found:
>
> sage: seed(1,2)
>
> will crash Sage, on every platform I checked (Linux, OS X and OpenSolaris).
>
> http://trac.sagemath.org/sage_trac/ticket/10113
>
> I've just checked the latest beta (only on Linux) and again it crashes
> Sage. I guess it will crash on Solaris and OS X too, though I don't
> have time to check.
>
> It's possible that indicates an underlying problem, that is not
> specific to calling "seed" incorrectly, but I just happened to find it
> using "seed".
>
> If anyone else has some spare CPU cycles, they could try writing code
> to crash Sage. It would be best if they did not use mine, but
> developed their own, as I suspect each person would approach it a
> different way, and be more likely to find bugs.
>
>> In this example I did write a patch which I thought solved
>> the problem 19 months ago, but it was not approved and nothing has
>> been done on that since....)
>> John
>
> I thought there was an issue with the patch John. Perhaps it did not
> fully solve the problem, but at least partially solved it. Can you
> give me the number, and I'll take a look again. I guess if it
> partially solves a problem, but not fully solves it, the patch is
> better than no patch. I don't have time to look now - I am at work.
It's #10108.
If the best solution is an upstream change to mwrank's input parsing,
then I am willing to do what is needed. We are going to upgrade the
version of eclib (which includes mwrank) in sage in the next release
anyway, as in ticket #10993. Currently, using the default way to
input integers into C++, all whitespace including newlines is ignored,
so whenever the input is incomplete mwrank just waits for the rest,
and this never happens since Sage only ever sends one line of input.
John
>
>
> Dave
>
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to
> sage-devel+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
