>>>
>>> 1. sage -coverage asks for a doctest of the form s == loads(dumps(s)).
>>> As far as I can tell however, it is happy if there is one such test
>>> in a file, even if the file happens to define 20 different classes. I
>>> would assume that we want a doctest of this form for each class
>>>
On Sat, Apr 18, 2009 at 6:55 PM, William Stein wrote:
>>> First problem with QQbar: it seems that resultant() doesn't like it,
>>> because it is not able to convert it to a Singular ring (this is the
>>> error, I'm not attaching all the output, tell me if you need it)
>>>
>>> TypeError: no conver
On Sat, Apr 18, 2009 at 5:24 PM, mabshoff wrote:
>
>
>
> On Apr 18, 5:20 pm, William Stein wrote:
>> On Sat, Apr 18, 2009 at 5:05 PM, Carl Witty wrote:
>>
>> > On Sat, Apr 18, 2009 at 2:46 PM, William Stein wrote:
>> >> I posted a patch so that
>>
>> >> (1) doctests are ran in the same order a
On Sat, Apr 18, 2009 at 5:27 PM, Carl Witty wrote:
>
> On Sat, Apr 18, 2009 at 2:46 PM, Maurizio wrote:
>> Could you be clearer? As I told, I'm not familiar with rings. I don't
>> even know the meaning of the argument of GF (I took the number 5 from
>> an example I see in sage-support group, I t
On Sat, Apr 18, 2009 at 6:04 PM, Maurizio wrote:
>> QQ is the rational numbers (fractions). QQbar is the algebraic
>> closure of QQ; this means it includes every complex number which is
>> the root of a polynomial with rational coefficients. So it includes
>> things like sqrt(2) (which is a roo
On Sat, Apr 18, 2009 at 6:34 PM, mabshoff wrote:
>
>
>
> On Apr 18, 6:06 pm, Alex Ghitza wrote:
>> Hi sage-devel,
>
> Hi Alex,
>
>> I'm slowly and painfully making my way through
>> schemes/generic/morphism.py and have run into some trouble that
>> persisted even after looking at rings/morphism.
On Apr 18, 6:06 pm, Alex Ghitza wrote:
> Hi sage-devel,
Hi Alex,
> I'm slowly and painfully making my way through
> schemes/generic/morphism.py and have run into some trouble that
> persisted even after looking at rings/morphism.pyx which was recently
> doctested by William.
>
> So here are s
Hi sage-devel,
I'm slowly and painfully making my way through
schemes/generic/morphism.py and have run into some trouble that
persisted even after looking at rings/morphism.pyx which was recently
doctested by William.
So here are some questions:
1. sage -coverage asks for a doctest of the form
Thanks for the answer.
As the time goes, I get more understanding of the complexity of the
problem (much more than I expected at first).
On 19 Apr, 02:27, Carl Witty wrote:
> On Sat, Apr 18, 2009 at 2:46 PM, Maurizio wrote:
> > Could you be clearer? As I told, I'm not familiar with rings. I do
On Apr 18, 5:24 pm, mabshoff wrote:
> One thing that would be nice to see is that one should be able to
run
> the doctest N times with N something like 100 or even 1,000 for
> example and each time a random seed would be picked. Then if any
> failure occurred the doctesting framework should also
On Sat, Apr 18, 2009 at 2:46 PM, Maurizio wrote:
> Could you be clearer? As I told, I'm not familiar with rings. I don't
> even know the meaning of the argument of GF (I took the number 5 from
> an example I see in sage-support group, I think). Do you think that QQ
> [] could fit in this case? Mo
On Apr 18, 5:20 pm, William Stein wrote:
> On Sat, Apr 18, 2009 at 5:05 PM, Carl Witty wrote:
>
> > On Sat, Apr 18, 2009 at 2:46 PM, William Stein wrote:
> >> I posted a patch so that
>
> >> (1) doctests are ran in the same order as the file
> >> (2) doctests can be run in random order
> >> (
On Sat, Apr 18, 2009 at 5:19 PM, Rob Beezer wrote:
>
> On Apr 18, 5:05 pm, Carl Witty wrote:
>> OK, what should happen now? I like the patch (except for the name of
>> the command-line argument); but it can't be applied because it makes
>> doctests fail.
>
> I'd suggest the randomized order sho
On Sat, Apr 18, 2009 at 5:05 PM, Carl Witty wrote:
>
> On Sat, Apr 18, 2009 at 2:46 PM, William Stein wrote:
>> I posted a patch so that
>>
>> (1) doctests are ran in the same order as the file
>> (2) doctests can be run in random order
>> (3) doctests can be run in random order specified by a s
On Apr 18, 5:05 pm, Carl Witty wrote:
> OK, what should happen now? I like the patch (except for the name of
> the command-line argument); but it can't be applied because it makes
> doctests fail.
I'd suggest the randomized order should be made available as soon as
possible. It requires a posi
On Apr 18, 5:05 pm, Carl Witty wrote:
> On Sat, Apr 18, 2009 at 2:46 PM, William Stein wrote:
> > I posted a patch so that
>
> > (1) doctests are ran in the same order as the file
> > (2) doctests can be run in random order
> > (3) doctests can be run in random order specified by a seed
>
> >
On Sat, Apr 18, 2009 at 2:46 PM, William Stein wrote:
> I posted a patch so that
>
> (1) doctests are ran in the same order as the file
> (2) doctests can be run in random order
> (3) doctests can be run in random order specified by a seed
>
> Carl, maybe you can referee it:
>
> http://trac.sage
>>
>> Where's the patch?
>>
>> John
>>
>
> Oops. I've posted it now.
>
> William
>
It's very interesting to run on the full rc3 tree with a fixed random
seed. I think this
reveals *numerous* errors and subtle problems:
./sage -tp 20 -long -rand=1 devel/sage/sage/ > testlong-rand1.log&
This
On Sat, Apr 18, 2009 at 3:27 PM, John H Palmieri wrote:
>
> On Apr 18, 2:46 pm, William Stein wrote:
>> On Sat, Apr 18, 2009 at 2:00 PM, Rob Beezer wrote:
>>
>> > Hi Carl,
>>
>> > Thanks for the explanation - good to know just why this was
>> > happening. I'd noticed the tests being run in a d
On Apr 18, 2:46 pm, William Stein wrote:
> On Sat, Apr 18, 2009 at 2:00 PM, Rob Beezer wrote:
>
> > Hi Carl,
>
> > Thanks for the explanation - good to know just why this was
> > happening. I'd noticed the tests being run in a different order as I
> > tried to debug this, but hadn't dug deep en
On Sat, Apr 18, 2009 at 2:00 PM, Rob Beezer wrote:
>
> Hi Carl,
>
> Thanks for the explanation - good to know just why this was
> happening. I'd noticed the tests being run in a different order as I
> tried to debug this, but hadn't dug deep enough to discover the cause.
>
> In misc/latex.py how
Carl, Burcin,
thank you very much for your support.
Burcin, I'm sorry for the trivial mistake. Thank you for pointing it
out.
Unfortunately, I don't understand this:
"
The theory only works over characteristic 0, i.e., your fields should
contain QQ. Also note that,
sage: P. = GF(5)[]
sage: (x+x
Hi Carl,
Thanks for the explanation - good to know just why this was
happening. I'd noticed the tests being run in a different order as I
tried to debug this, but hadn't dug deep enough to discover the cause.
In misc/latex.py how the latex is created often depends on the value
of the boolean EM
On Tue, Apr 14, 2009 at 11:57 AM, John H Palmieri
wrote:
> I figured out how to fix the problem, although I still don't know why
> adding a docstring should cause it.
>
> To fix it: the docstring for "print_or_typeset" contains the lines
...
Well, I can tell you why adding a docstring will cause
On Thu, Apr 16, 2009 at 3:43 PM, Maurizio wrote:
> Finally, even assuming that I can get the right answer from this,
> which is the recommended way to get the roots of an equation given by
> a "univariate polynomials == 0"? This is supposed to be the next step
> of the algorithm.
Taking a quick
25 matches
Mail list logo
