[sage-support] Re: pth roots in fields of characteristic p
On Tue, Nov 18, 2008 at 7:43 PM, John H Palmieri <[EMAIL PROTECTED]> wrote: > > Thanks for the answers. By the way: > >> Infinite fields of characteristic p aren't perfect, > > Isn't the algebraic closure of F_p perfect? For fields of > characteristic p, perfect should mean that every element has a pth > root. (I agree that some infinite fields of characteristic p aren't > perfect, but this is not true for all of them.) Sorry, Fpbar is indeed an exception. I was thinking of "global fields", which are fields that are finitely generated over their prime subfield (in this case, F_p).Any algebraically closed field is perfect, since there are no nontrivial finite extensions. If a field F is infinite and finitely generated over its prime subfield, it has to have transcendence degree at least 1, hence contain k(t), where k is a finite field and t is an indeterminate. If F were perfect, it would contain all p-power roots of t, hence it wouldn't be finitely generated over F_p. -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: pth roots in fields of characteristic p
Thanks for the answers. By the way: > Infinite fields of characteristic p aren't perfect, Isn't the algebraic closure of F_p perfect? For fields of characteristic p, perfect should mean that every element has a pth root. (I agree that some infinite fields of characteristic p aren't perfect, but this is not true for all of them.) John > because the definition > of perfect is that "every finite extension is separable". > In any case, Sage is I think very limited regarding non-finite characteristic > p fields, unfortunately (e.g., function fields of curves over finite fields). > This is one of those things that Magma is unusually good at. > > William --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: pth roots in fields of characteristic p
On Tue, Nov 18, 2008 at 4:30 PM, John H Palmieri <[EMAIL PROTECTED]> wrote: > > Does Sage know how to compute pth roots in any finite field of > characteristic p? There exists a finite field of char p such that Sage can compute the p-th roots of a number: sage: a = GF(7)(2) sage: a.nth_root(7) 2 Same for a non-prime field: sage: a = GF(49,'b').0 sage: a.nth_root(7) 6*b + 1 So I guess the answer to your question is probably "yes". Incidentally, on a finite field p-th powering is an automorphism, so there is always exactly one p-th root. The nth_root command works by finding the roots of the poly x^n - a. > That is, if I have a prime number p, a finite field > F of characteristic p, and an element b of F, will > > sage: b.nth_root(p) > > always return a value, or will it sometimes return a ValueError? It should *always* return a value. If it doesn't, that's a bug. > Does > it depend on the field, and if so, is there a way to test whether any > given field has an algorithm for computing pth roots? (If I want to > implement something which depends on such an algorithm, I want to be > able to ignore the bad fields from the start.) All fields should have such an algorithm. However, one could write a better algorithm than what is in Sage now. E.g., if your field F has cardinality p^n, than an algorithm to compute the unique p-th root b of a is to just to use that for all x in the field x^(p^n) = x, so since b^p = a we have b = (b^p)^(p^(n-1)) = a^(p^(n-1)) I.e., compute p-th roots by raising to the power of p^(n-1). sage: a = GF(49,'b').0 sage: a.nth_root(7) 6*b + 1 sage: a^7 6*b + 1 > I don't know what infinite fields of characteristic p Sage knows > about, but one could ask similar questions for those: is there > something like an 'is_perfect' method, and for which perfect fields > does Sage know how to compute pth roots? Infinite fields of characteristic p aren't perfect, because the definition of perfect is that "every finite extension is separable". In any case, Sage is I think very limited regarding non-finite characteristic p fields, unfortunately (e.g., function fields of curves over finite fields). This is one of those things that Magma is unusually good at. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] pth roots in fields of characteristic p
Does Sage know how to compute pth roots in any finite field of characteristic p? That is, if I have a prime number p, a finite field F of characteristic p, and an element b of F, will sage: b.nth_root(p) always return a value, or will it sometimes return a ValueError? Does it depend on the field, and if so, is there a way to test whether any given field has an algorithm for computing pth roots? (If I want to implement something which depends on such an algorithm, I want to be able to ignore the bad fields from the start.) I don't know what infinite fields of characteristic p Sage knows about, but one could ask similar questions for those: is there something like an 'is_perfect' method, and for which perfect fields does Sage know how to compute pth roots? John --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: latex output for real numbers without zeros at the end
On Nov 18, 2008, at 5:57 AM, Stan Schymanski wrote:
>
> Ah, I see:
>
> dummy1 = RealField(8)(0.1);dummy1
> 0.10
>
> dummy2 = RealField(16)(0.1);dummy2
> 0.1000
>
> latex(x*dummy1)
> {0.1001 x}
>
> latex(x*dummy2)
> {0.1 x}
>
> This is not quite what one would expect. However, the behaviour before
> the fix was not much better in my opinion, as the precision was not
> obvious from the latex output, either:
>
> sage: dummy1 = RealField(8)(0.1);dummy1
> 0.10
> sage: dummy2 = RealField(16)(0.1);dummy2
> 0.1000
> sage: latex(x*dummy1)
> {0.1001000 x}
> sage: latex(x*dummy2)
> {0.100 x}
>
> Obviously, the fix does not fix all the problems, but it does make
> latex output much more useful. Would you agree?
That depends on your definition of useful. Personally, I think it's
useful to see how many digits of precision a given number has, and
for most things it works fine.
The issue here is the interaction with Maxima, which is being fixed.
Making it so any latexification of all real numbers is truncated is
(IMHO) not the right fix because one component abuses precisions.
- Robert
>
>
>
>
> On Nov 18, 12:44 pm, Robert Bradshaw <[EMAIL PROTECTED]>
> wrote:
>> The side effect is that now real numbers of different precisions all
>> print the same, so I'm not sure that this would be considered a "fix"
>> as the trailing zeros are intentional. There should be print modes
>> that one can set (globally, on the ring, or with contexts).
>>
>> - Robert
>>
>> On Nov 17, 2008, at 11:29 PM, Stan Schymanski wrote:
>>
>>
>>
>>> Hi Mike,
>>
>>> This is great, it does exactly what I wanted. Thanks a lot! Are
>>> there
>>> any potentially undesired side-effects of the changes in
>>> real_mpfr.pyx
>>> or could this fix be included in future versions of sage?
>>
>>> Stan
>>
>>> On Nov 18, 8:14 am, "Mike Hansen" <[EMAIL PROTECTED]> wrote:
Hello,
>>
On Mon, Nov 17, 2008 at 11:11 PM, Stan Schymanski
<[EMAIL PROTECTED]> wrote:
>>
> Dear Mike,
>>
> Thanks a lot for that, this looks very promising. However, after
> making the suggested change, the behaviour of latex() did not
> change.
> Do I need to restart sage for the changes to take effect?
>>
You need to run "sage -br" to compile the new changes.
>>
--Mike
>>
>>
> >
--~--~-~--~~~---~--~~
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sage-support
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-support] Re: Question about doc tests
On Tue, Nov 18, 2008 at 8:23 AM, Simon King <[EMAIL PROTECTED]> wrote: > > Dear William, > > On Nov 18, 5:12 pm, "William Stein" <[EMAIL PROTECTED]> wrote: >> And no, Michael, this isn't a bug. It's a feature that I implemented >> long ago. > > I agree it is a feature. > > In fact, I've put these words in with the intention to make it > optional, but then I forgot it... Which is one more reason to consider it a mis-feature. I had no clue when I wrote that code whether # optional or putting those three words in would turn out to be the way to go. In retrospect, # optional is, since generally speaking, "explicit is better than implicit". William --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: Question about doc tests
On Tue, Nov 18, 2008 at 9:05 AM, mabshoff <[EMAIL PROTECTED]> wrote: > > > > On Nov 18, 9:01 am, Simon King <[EMAIL PROTECTED]> wrote: >> Dear William, >> >> On Nov 18, 5:26 pm, "William Stein" <[EMAIL PROTECTED]> wrote: >> >> > Which is one more reason to consider it a mis-feature. I had no >> > clue when I wrote that code whether # optional or putting those three >> > words in would turn out to be the way to go. In retrospect, # optional is, >> > since generally speaking, "explicit is better than implicit". >> >> Here I disagree, for the following reason. Well of course it is a feature. I really thought it was clever when I thought it up and implemented it. But it is a bad design, because it isn't explicit, and it is way too easy for somebody -- both the original author or a user -- to simply not know about. With # optional on each line, that *never* happens. I like your idea of something like sage: # begin optional ... sage: # end optional That's explicit and clear, and doesn't require # optional for every line. > There has been talk about making "#optional" more clever, i.e. one > would feed it a list of optional components and then -optional would > only test for those components that are installed. One could still > have a global switch to do what you want, but let it be less random > than some words in the text. I think that (1) will definitely happen since I need it for testing the Sage/Magma interface, and (2) is orthogonal to this discussion. > >> I have many examples for a class that depends on SmallGroups library >> being installed. >> With the "requires optional package" feature, I can turn off all >> examples at once. >> >> Am I right that it'd be needed to put "# optional" after each input >> line? Then, I think the "requires optional package" really is a >> feature, not a misfeature. >> >> Similar things hold with the "# long time" feature: It switches off >> one input line (unless -long is used), but it does not switch off the >> lines that depend on it. >> How painful if you have many lines of code that only take short time >> but have to be commented # long time since they depend on one long >> command from the very beginning of the example! >> >> I think it would be nice to have a way to define a whole block of code >> as "being long". E.g. >> sage: One_long_command # starting long example >> sage: many >> sage: short >> sage: commands # ending long example >> sage: continuing >> sage: independent >> sage: computations >> >> so that the first four lines (but not the last three) require sage -t - >> long >> >> Yours >> Simon > > Cheers, > > Michael > > > -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: Question about doc tests
On Nov 18, 9:01 am, Simon King <[EMAIL PROTECTED]> wrote: > Dear William, > > On Nov 18, 5:26 pm, "William Stein" <[EMAIL PROTECTED]> wrote: > > > Which is one more reason to consider it a mis-feature. I had no > > clue when I wrote that code whether # optional or putting those three > > words in would turn out to be the way to go. In retrospect, # optional is, > > since generally speaking, "explicit is better than implicit". > > Here I disagree, for the following reason. There has been talk about making "#optional" more clever, i.e. one would feed it a list of optional components and then -optional would only test for those components that are installed. One could still have a global switch to do what you want, but let it be less random than some words in the text. > I have many examples for a class that depends on SmallGroups library > being installed. > With the "requires optional package" feature, I can turn off all > examples at once. > > Am I right that it'd be needed to put "# optional" after each input > line? Then, I think the "requires optional package" really is a > feature, not a misfeature. > > Similar things hold with the "# long time" feature: It switches off > one input line (unless -long is used), but it does not switch off the > lines that depend on it. > How painful if you have many lines of code that only take short time > but have to be commented # long time since they depend on one long > command from the very beginning of the example! > > I think it would be nice to have a way to define a whole block of code > as "being long". E.g. > sage: One_long_command # starting long example > sage: many > sage: short > sage: commands # ending long example > sage: continuing > sage: independent > sage: computations > > so that the first four lines (but not the last three) require sage -t - > long > > Yours > Simon Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: Question about doc tests
Dear William, On Nov 18, 5:26 pm, "William Stein" <[EMAIL PROTECTED]> wrote: > Which is one more reason to consider it a mis-feature. I had no > clue when I wrote that code whether # optional or putting those three > words in would turn out to be the way to go. In retrospect, # optional is, > since generally speaking, "explicit is better than implicit". Here I disagree, for the following reason. I have many examples for a class that depends on SmallGroups library being installed. With the "requires optional package" feature, I can turn off all examples at once. Am I right that it'd be needed to put "# optional" after each input line? Then, I think the "requires optional package" really is a feature, not a misfeature. Similar things hold with the "# long time" feature: It switches off one input line (unless -long is used), but it does not switch off the lines that depend on it. How painful if you have many lines of code that only take short time but have to be commented # long time since they depend on one long command from the very beginning of the example! I think it would be nice to have a way to define a whole block of code as "being long". E.g. sage: One_long_command # starting long example sage: many sage: short sage: commands # ending long example sage: continuing sage: independent sage: computations so that the first four lines (but not the last three) require sage -t - long Yours Simon --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: notebook does not compute any more
On Tue, Nov 18, 2008 at 2:43 AM, Stan Schymanski <[EMAIL PROTECTED]> wrote: > > Dear all, > After shutting down a notebook server that has been running for weeks > on a MacBook Pro and installing some Mac updates, I can't get the > notebook to perform any calculations any more. Whenever I press Shift- > Enter, the green bar appears, but the notebook never produces an > output. I restarted sage and the notebook server several times, and > tried out different notebooks and worksheets on both Firefox and > Safari, but it is the same everywhere. Does anyone have an idea what I > could do to get it to run again? Funnily enough, if I use the notebook > from a remote computer, it works fine. Go figure! It sounds like you're starting the notebook configured to not listen on localhost, but you're connecting to it on localhost. Try using the outside ip address on your computer, which you use to connect to it from elsewhere? -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: Question about doc tests
On Tue, Nov 18, 2008 at 8:05 AM, Simon King <[EMAIL PROTECTED]> wrote: > > Sorry for the noise. > > On Nov 18, 4:16 pm, Simon King <[EMAIL PROTECTED]> wrote: >> Now, I have a very long doc string for an extension class and just >> observe that the examples from that doc string are not tested. > > The doc string contains the words "package", "requires" and > "installed". So, I had to do I'm ok with getting rid of that behavior, where docstrings that contain all those words are automatically considered optional. It seemed like a good idea when I made it up in 2005, but as it turns out people are fine with putting #optional's in front of all optional doctests, and I think having the #optional's on the doctests is also just better from a user perspective. And no, Michael, this isn't a bug. It's a feature that I implemented long ago. > sage -t -optional > and then it worked. > > Cheers > Simon > > > > -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: Question about doc tests
Dear William, On Nov 18, 5:12 pm, "William Stein" <[EMAIL PROTECTED]> wrote: > And no, Michael, this isn't a bug. It's a feature that I implemented > long ago. I agree it is a feature. In fact, I've put these words in with the intention to make it optional, but then I forgot it... Yours, Simon --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: Transformation to Jordan form for tame 6x6 integer matrix
On Tue, Nov 18, 2008 at 8:00 AM, Marshall Hampton <[EMAIL PROTECTED]> wrote: > > Jason Grout has now fixed this, you can get the patch at > > http://trac.sagemath.org/sage_trac/ticket/4273 > > It probably won't get into Sage until sage-3.2.1, which has a target > release date of 11/22 but since 3.2 is turning into a pretty big > release I think it will be more like the end of the month. 3.2 should be released in <= 2 days. > > Cheers, > Marshall Hampton > > On Oct 13, 4:08 pm, Rob Beezer <[EMAIL PROTECTED]> wrote: >> Thanks for the response and for submitting this as a bug. I should >> have thought to try a simpler test case. >> >> Rob >> >> On Oct 13, 4:58 am, Marshall Hampton <[EMAIL PROTECTED]> wrote: >> >> > This is now Ticket #4273 on trac (http://trac.sagemath.org/sage_trac/ >> > ticket/4273). >> >> > I will try to fix this if no one else does. Many Sage developers are >> > busy at Sage Days 10 in Nancy, France, so they might be a little more >> > distracted than usual, but I think this is a major bug so it should >> > get attention soon. >> >> > -M. Hampton >> >> > On Oct 12, 10:39 pm, Marshall Hampton <[EMAIL PROTECTED]> wrote: >> >> > > The transformation=True fails even for matrix(QQ,[[0,1,0],[0,0,0], >> > > [0,0,0]]). It looks like the algorithm to construct it is flawed, and >> > > will not work if there are blocks with the same eigenvalue. Anyone >> > > want to re-write this? >> >> > > -M. Hampton >> >> > > On Oct 12, 9:34 pm, Rob Beezer <[EMAIL PROTECTED]> wrote: >> >> > > > I have a 6x6 matrix with integer entries, whose eigenvalues are also >> > > > integers. I wanted theJordancanonical form, and the associated >> > > > matrix to make the similarity transformation. TheJordanform comes >> > > > out nicely, but I can't get the transformation matrix. I've included >> > > > the error output below - the error seems more severe without setting >> > > > base_ring=QQ. I've also include a legitimate transformation matrix I >> > > > worked up by hand (with some help from SAGE!). >> >> > > > Is this expected behavior? Any usage hints or workarounds? Thanks. >> >> > > > Rob >> >> > > > m=matrix(QQ, [[2,0,1,1,0,0],[0,2,1,1,0,0],[2,0,1,0,0,1],[2,0,0,1,1,0], >> > > > [0,2,1,0,0,1],[0,2,0,1,1,0]]) >> > > > m.jordan_form() >> >> > > > [4|0|0 0|0 0] >> > > > [-+-+---+---] >> > > > [0|2|0 0|0 0] >> > > > [-+-+---+---] >> > > > [0|0|0 1|0 0] >> > > > [0|0|0 0|0 0] >> > > > [-+-+---+---] >> > > > [0|0|0 0|0 1] >> > > > [0|0|0 0|0 0] >> >> > > > p=m.jordan_form(base_ring=QQ, transformation=True) >> >> > > > Traceback (click to the left for traceback) >> > > > ... >> > > > ValueError: cannot compute the basis of theJordanblock of size 2 >> > > > with >> > > > eigenvalue 0 >> >> > > > Traceback (most recent call last): >> > > > File "", line 1, in >> > > > File "/home/rob/.sage/sage_notebook/worksheets/admin/46/code/98.py", >> > > > line 6, in >> > > > p=m.jordan_form(base_ring=QQ, transformation=True) >> > > > File "/opt/sage-3.1.2/local/lib/python2.5/site-packages/ >> > > > SQLAlchemy-0.4.6-py2.5.egg/", line 1, in >> > > > File "matrix2.pyx", line 4125, in >> > > > sage.matrix.matrix2.Matrix.jordan_form (sage/matrix/matrix2.c:23429) >> > > > ValueError: cannot compute the basis of theJordanblock of size 2 >> > > > with eigenvalue 0 >> >> > > > p=matrix(QQ,[[1,1,0,1,3,1],[1,-1,0,1,3,1],[1,0,1,1,0,1], >> > > > [1,0,-1,-3,-6,0],[1,-2,1,0,0,-8],[1,-2,-1,-2,-6,-3]]) >> > > > p.inverse()*m*p == m.jordan_form() >> >> > > > True > > > -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: Question about doc tests
On Nov 18, 8:05 am, Simon King <[EMAIL PROTECTED]> wrote: > Sorry for the noise. > > On Nov 18, 4:16 pm, Simon King <[EMAIL PROTECTED]> wrote: > > > Now, I have a very long doc string for an extension class and just > > observe that the examples from that doc string are not tested. > > The doc string contains the words "package", "requires" and > "installed". So, I had to do > sage -t -optional > and then it worked. Mhh, is this a bug in our doctesting code? It sounds like it, but I am not 100% sure. > Cheers > Simon Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: Question about doc tests
Sorry for the noise. On Nov 18, 4:16 pm, Simon King <[EMAIL PROTECTED]> wrote: > Now, I have a very long doc string for an extension class and just > observe that the examples from that doc string are not tested. The doc string contains the words "package", "requires" and "installed". So, I had to do sage -t -optional and then it worked. Cheers Simon --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] numerical_integral
hello, I'm using sage 3.1.4 on a core duo with debian, I guess numerical_integral is not supposed to integrate complex valued functions, the following line outputs some blank lines and then the (wrong) result (0.0, 0.0): sage: numerical_integral(lambda x:e^(-x)*e^(-I*0.05*x), 0, Infinity) (0.0, 0.0) I guess this is not a desired behaviour ..., Georg --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: Transformation to Jordan form for tame 6x6 integer matrix
Jason Grout has now fixed this, you can get the patch at http://trac.sagemath.org/sage_trac/ticket/4273 It probably won't get into Sage until sage-3.2.1, which has a target release date of 11/22 but since 3.2 is turning into a pretty big release I think it will be more like the end of the month. Cheers, Marshall Hampton On Oct 13, 4:08 pm, Rob Beezer <[EMAIL PROTECTED]> wrote: > Thanks for the response and for submitting this as a bug. I should > have thought to try a simpler test case. > > Rob > > On Oct 13, 4:58 am, Marshall Hampton <[EMAIL PROTECTED]> wrote: > > > This is now Ticket #4273 on trac (http://trac.sagemath.org/sage_trac/ > > ticket/4273). > > > I will try to fix this if no one else does. Many Sage developers are > > busy at Sage Days 10 in Nancy, France, so they might be a little more > > distracted than usual, but I think this is a major bug so it should > > get attention soon. > > > -M. Hampton > > > On Oct 12, 10:39 pm, Marshall Hampton <[EMAIL PROTECTED]> wrote: > > > > The transformation=True fails even for matrix(QQ,[[0,1,0],[0,0,0], > > > [0,0,0]]). It looks like the algorithm to construct it is flawed, and > > > will not work if there are blocks with the same eigenvalue. Anyone > > > want to re-write this? > > > > -M. Hampton > > > > On Oct 12, 9:34 pm, Rob Beezer <[EMAIL PROTECTED]> wrote: > > > > > I have a 6x6 matrix with integer entries, whose eigenvalues are also > > > > integers. I wanted theJordancanonical form, and the associated > > > > matrix to make the similarity transformation. TheJordanform comes > > > > out nicely, but I can't get the transformation matrix. I've included > > > > the error output below - the error seems more severe without setting > > > > base_ring=QQ. I've also include a legitimate transformation matrix I > > > > worked up by hand (with some help from SAGE!). > > > > > Is this expected behavior? Any usage hints or workarounds? Thanks. > > > > > Rob > > > > > m=matrix(QQ, [[2,0,1,1,0,0],[0,2,1,1,0,0],[2,0,1,0,0,1],[2,0,0,1,1,0], > > > > [0,2,1,0,0,1],[0,2,0,1,1,0]]) > > > > m.jordan_form() > > > > > [4|0|0 0|0 0] > > > > [-+-+---+---] > > > > [0|2|0 0|0 0] > > > > [-+-+---+---] > > > > [0|0|0 1|0 0] > > > > [0|0|0 0|0 0] > > > > [-+-+---+---] > > > > [0|0|0 0|0 1] > > > > [0|0|0 0|0 0] > > > > > p=m.jordan_form(base_ring=QQ, transformation=True) > > > > > Traceback (click to the left for traceback) > > > > ... > > > > ValueError: cannot compute the basis of theJordanblock of size 2 > > > > with > > > > eigenvalue 0 > > > > > Traceback (most recent call last): > > > > File "", line 1, in > > > > File "/home/rob/.sage/sage_notebook/worksheets/admin/46/code/98.py", > > > > line 6, in > > > > p=m.jordan_form(base_ring=QQ, transformation=True) > > > > File "/opt/sage-3.1.2/local/lib/python2.5/site-packages/ > > > > SQLAlchemy-0.4.6-py2.5.egg/", line 1, in > > > > File "matrix2.pyx", line 4125, in > > > > sage.matrix.matrix2.Matrix.jordan_form (sage/matrix/matrix2.c:23429) > > > > ValueError: cannot compute the basis of theJordanblock of size 2 > > > > with eigenvalue 0 > > > > > p=matrix(QQ,[[1,1,0,1,3,1],[1,-1,0,1,3,1],[1,0,1,1,0,1], > > > > [1,0,-1,-3,-6,0],[1,-2,1,0,0,-8],[1,-2,-1,-2,-6,-3]]) > > > > p.inverse()*m*p == m.jordan_form() > > > > > True --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: Question about doc tests
Dear Team, a follow-up question: In the documentation (http:// modular.math.washington.edu/sage/doc/prog/node9.html), it says "Every function must have a docstring". It does not say "Every class must have a docstring". Now, I have a very long doc string for an extension class and just observe that the examples from that doc string are not tested. Is this to be expected? Is this desired? If the doc string of a class really does not count, where else should I move it? Yours Simon --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: Question about doc tests
Dear Burcin, On Nov 18, 1:33 pm, Burcin Erocal <[EMAIL PROTECTED]> wrote: > It seems that this should be working since Sage-3.1.3. First do > > export SAGE_PATH=/path/to/your/foo.so/ > > Then include the "from foo import bar" line in your doctests, and run > > /path/to/sage -t your_file.pyx Great, it works! Thank you very much! Simon --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: latex output for real numbers without zeros at the end
Ah, I see:
dummy1 = RealField(8)(0.1);dummy1
0.10
dummy2 = RealField(16)(0.1);dummy2
0.1000
latex(x*dummy1)
{0.1001 x}
latex(x*dummy2)
{0.1 x}
This is not quite what one would expect. However, the behaviour before
the fix was not much better in my opinion, as the precision was not
obvious from the latex output, either:
sage: dummy1 = RealField(8)(0.1);dummy1
0.10
sage: dummy2 = RealField(16)(0.1);dummy2
0.1000
sage: latex(x*dummy1)
{0.1001000 x}
sage: latex(x*dummy2)
{0.100 x}
Obviously, the fix does not fix all the problems, but it does make
latex output much more useful. Would you agree?
Stan
On Nov 18, 12:44 pm, Robert Bradshaw <[EMAIL PROTECTED]>
wrote:
> The side effect is that now real numbers of different precisions all
> print the same, so I'm not sure that this would be considered a "fix"
> as the trailing zeros are intentional. There should be print modes
> that one can set (globally, on the ring, or with contexts).
>
> - Robert
>
> On Nov 17, 2008, at 11:29 PM, Stan Schymanski wrote:
>
>
>
> > Hi Mike,
>
> > This is great, it does exactly what I wanted. Thanks a lot! Are there
> > any potentially undesired side-effects of the changes in real_mpfr.pyx
> > or could this fix be included in future versions of sage?
>
> > Stan
>
> > On Nov 18, 8:14 am, "Mike Hansen" <[EMAIL PROTECTED]> wrote:
> >> Hello,
>
> >> On Mon, Nov 17, 2008 at 11:11 PM, Stan Schymanski
> >> <[EMAIL PROTECTED]> wrote:
>
> >>> Dear Mike,
>
> >>> Thanks a lot for that, this looks very promising. However, after
> >>> making the suggested change, the behaviour of latex() did not
> >>> change.
> >>> Do I need to restart sage for the changes to take effect?
>
> >> You need to run "sage -br" to compile the new changes.
>
> >> --Mike
>
>
--~--~-~--~~~---~--~~
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sage-support
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-support] Re: latex output for real numbers without zeros at the end
Hi Robert, In my understanding the changes only affect the latex display, not for example the print command: dummy = 0.60001;dummy 0.6000100 latex(dummy) 0.60001 print(dummy) 0.6000100 What do you mean by real numbers of different precisions being printed the same? dummy = RealField(8)(sqrt(2));dummy 1.4 dummy2 = RealField(16)(sqrt(2));dummy2 1.414 latex(dummy) 1.4 latex(dummy2) 1.414 This did not work before the fix. Could you give an example for something that you expect not to work after the fix? Cheers Stan On Nov 18, 12:44 pm, Robert Bradshaw <[EMAIL PROTECTED]> wrote: > The side effect is that now real numbers of different precisions all > print the same, so I'm not sure that this would be considered a "fix" > as the trailing zeros are intentional. There should be print modes > that one can set (globally, on the ring, or with contexts). > > - Robert > > On Nov 17, 2008, at 11:29 PM, Stan Schymanski wrote: > > > > > Hi Mike, > > > This is great, it does exactly what I wanted. Thanks a lot! Are there > > any potentially undesired side-effects of the changes in real_mpfr.pyx > > or could this fix be included in future versions of sage? > > > Stan > > > On Nov 18, 8:14 am, "Mike Hansen" <[EMAIL PROTECTED]> wrote: > >> Hello, > > >> On Mon, Nov 17, 2008 at 11:11 PM, Stan Schymanski > >> <[EMAIL PROTECTED]> wrote: > > >>> Dear Mike, > > >>> Thanks a lot for that, this looks very promising. However, after > >>> making the suggested change, the behaviour of latex() did not > >>> change. > >>> Do I need to restart sage for the changes to take effect? > > >> You need to run "sage -br" to compile the new changes. > > >> --Mike > > --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: Question about doc tests
Dear Simon, On Tue, 18 Nov 2008 02:27:24 -0800 (PST) Simon King <[EMAIL PROTECTED]> wrote: > I still don't get it. The problem is the PYTHONPATH, in the Sage environment. Putting foo.so in $SAGE_LOCAL/lib doesn't work, since that is not in the PYTHONPATH. Try sage: sys.path to see the locations searched for modules you try to import. The Sage sources pass the tests, because the Sage library is installed in the default PYTHONPATH, i.e., SAGE_LOCAL/lib/python2.5/site-packages. For the doctesting to work, you need to add the path of your modules to the PYTHONPATH in the Sage environment. It seems that this should be working since Sage-3.1.3. First do export SAGE_PATH=/path/to/your/foo.so/ Then include the "from foo import bar" line in your doctests, and run /path/to/sage -t your_file.pyx I only tried this on python files, so I don't know if there is a problem with cython modules. If your module is already compiled, and in the given directory, I don't see what can go wrong though. Cheers, Burcin --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: Question about doc tests
Simon King wrote:
> Dear Burcin,
>
> On Nov 18, 11:46 am, Burcin Erocal <[EMAIL PROTECTED]> wrote:
>>> Do I understand correctly that this will be fixed in Sage 3.2?
>> Yes, it will be fixed in 3.2.
>
> Good!
>
>>> Do you mean "better approach for Sage" or "better approach for my
>>> writing doc-tests"? By the way, what is SAGE_PATH? It isn't defined,
>>> and even search_src('SAGE_PATH') fails.
>> SAGE_PATH is one of the many undocumented environment variables Sage
>> uses [1], which I found in the list archives when I was trying to solve
>> this problem.
>
> It still seems to me that it is *less* than undocumented:
> It is not defined in Sage (commandline), search_src fails, and also it
> is not defined when I run "sage -sh".
At the sage prompt, you can type "%env" to get the environment variables
as a dictionary, or "!env" to actually run the env command to get the
environment variables. For the SAGE variables, I get:
SAGE_TESTDIR
SAGE_LOCAL
SAGE_ORIG_LD_LIBRARY_PATH_SET
SAGE_STARTUP_FILE
SAGE_ROOT
SAGE_ORIG_LD_LIBRARY_PATH
SAGE_DATA
SAGE64
SAGE_SERVER
SAGE_PACKAGES
Huh, no SAGE_PATH.
Jason
--~--~-~--~~~---~--~~
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sage-support
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-support] Re: latex output for real numbers without zeros at the end
The side effect is that now real numbers of different precisions all print the same, so I'm not sure that this would be considered a "fix" as the trailing zeros are intentional. There should be print modes that one can set (globally, on the ring, or with contexts). - Robert On Nov 17, 2008, at 11:29 PM, Stan Schymanski wrote: > > Hi Mike, > > This is great, it does exactly what I wanted. Thanks a lot! Are there > any potentially undesired side-effects of the changes in real_mpfr.pyx > or could this fix be included in future versions of sage? > > Stan > > On Nov 18, 8:14 am, "Mike Hansen" <[EMAIL PROTECTED]> wrote: >> Hello, >> >> On Mon, Nov 17, 2008 at 11:11 PM, Stan Schymanski >> <[EMAIL PROTECTED]> wrote: >> >>> Dear Mike, >> >>> Thanks a lot for that, this looks very promising. However, after >>> making the suggested change, the behaviour of latex() did not >>> change. >>> Do I need to restart sage for the changes to take effect? >> >> You need to run "sage -br" to compile the new changes. >> >> --Mike > > --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: Question about doc tests
Hi Simon, On Tue, Nov 18, 2008 at 3:09 AM, Simon King <[EMAIL PROTECTED]> wrote: > It still seems to me that it is *less* than undocumented: > It is not defined in Sage (commandline), search_src fails, and also it > is not defined when I run "sage -sh". It is used in sage-doctest and sage-env in $SAGE_ROOT/local/bin/. --Mike --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: Question about doc tests
Dear Burcin,
On Nov 18, 11:46 am, Burcin Erocal <[EMAIL PROTECTED]> wrote:
> > Do I understand correctly that this will be fixed in Sage 3.2?
>
> Yes, it will be fixed in 3.2.
Good!
> > Do you mean "better approach for Sage" or "better approach for my
> > writing doc-tests"? By the way, what is SAGE_PATH? It isn't defined,
> > and even search_src('SAGE_PATH') fails.
>
> SAGE_PATH is one of the many undocumented environment variables Sage
> uses [1], which I found in the list archives when I was trying to solve
> this problem.
It still seems to me that it is *less* than undocumented:
It is not defined in Sage (commandline), search_src fails, and also it
is not defined when I run "sage -sh".
Cheers,
Simon
--~--~-~--~~~---~--~~
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sage-support
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-support] Re: Question about doc tests
On Tue, 18 Nov 2008 01:11:35 -0800 (PST)
Simon King <[EMAIL PROTECTED]> wrote:
>
> Dear Burcin,
>
> On Nov 18, 9:51 am, Burcin Erocal <[EMAIL PROTECTED]> wrote:
> > I do this with the code I develop out of the tree too. You need to
> > import your module explicitly for each doctest, i.e., include a
> > "from foo import func_name" at the beginning of your EXAMPLES:
> > section.
>
> OK, I'll change it accordingly!
>
> > A patch fixing this is in 3.2.rc1, but I don't recall if it was in a
> > previous stable release or not. Which version are you using?
>
> Still version 3.1.4
>
> In other words, if the next release appears (couple of days?) it would
> work. I guess I can wait a few days.
>
> > Sage seems to include the current directory in the module search
> > path (sys.path). This is not the case for doctesting.
>
> Do I understand correctly that this will be fixed in Sage 3.2?
Yes, it will be fixed in 3.2.
> > I think using the SAGE_PATH variable in general is a better
> > approach.
>
> Do you mean "better approach for Sage" or "better approach for my
> writing doc-tests"? By the way, what is SAGE_PATH? It isn't defined,
> and even search_src('SAGE_PATH') fails.
SAGE_PATH is one of the many undocumented environment variables Sage
uses [1], which I found in the list archives when I was trying to solve
this problem.
After complaints about Sage clearing the PYTHONPATH environment, it was
suggested that we use a different variable for this. SAGE_PATH was
chosen. It works for the command line, and the notebook, but it
was ignored for doctesting.
BTW, there are a few bugs in trac which ask for functionality provided
by SAGE_PATH, it would be good to see if they can be closed.
[1] Do we at least have a wiki page about these environment variables?
Cheers,
Burcin
--~--~-~--~~~---~--~~
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sage-support
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-support] notebook does not compute any more
Dear all, After shutting down a notebook server that has been running for weeks on a MacBook Pro and installing some Mac updates, I can't get the notebook to perform any calculations any more. Whenever I press Shift- Enter, the green bar appears, but the notebook never produces an output. I restarted sage and the notebook server several times, and tried out different notebooks and worksheets on both Firefox and Safari, but it is the same everywhere. Does anyone have an idea what I could do to get it to run again? Funnily enough, if I use the notebook from a remote computer, it works fine. Go figure! Thanks for your help. Regards, Stan --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: Question about doc tests
Dear Burcin, I still don't get it. On Nov 18, 9:51 am, Burcin Erocal <[EMAIL PROTECTED]> wrote: > > Second attempt: > > Import 'foo' in all examples (there is 'foo.so' in the directory) > > Result: ImportError: No module named foo > > But this should. First setting: foo.so is in the current directory, and I do "from foo import bar". Result: no module named foo Second setting: foo.so is in SAGE_LOCAL/lib/. Result: no module named foo Hence: > Sage seems to include the current directory in the module search path > (sys.path). This is not the case for doctesting. I think using the > SAGE_PATH variable in general is a better approach. But shouldn't SAGE_LOCAL/lib/ belong to the Sage path? Why do (almost) all doc tests from the Sage sources pass? What is the difference to the second setting? Cheers Simon --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: Question about doc tests
Dear Burcin,
On Nov 18, 9:51 am, Burcin Erocal <[EMAIL PROTECTED]> wrote:
> I do this with the code I develop out of the tree too. You need to
> import your module explicitly for each doctest, i.e., include a "from
> foo import func_name" at the beginning of your EXAMPLES: section.
OK, I'll change it accordingly!
> A patch fixing this is in 3.2.rc1, but I don't recall if it was in a
> previous stable release or not. Which version are you using?
Still version 3.1.4
In other words, if the next release appears (couple of days?) it would
work. I guess I can wait a few days.
> Sage seems to include the current directory in the module search path
> (sys.path). This is not the case for doctesting.
Do I understand correctly that this will be fixed in Sage 3.2?
> I think using the SAGE_PATH variable in general is a better approach.
Do you mean "better approach for Sage" or "better approach for my
writing doc-tests"? By the way, what is SAGE_PATH? It isn't defined,
and even search_src('SAGE_PATH') fails.
Thank you very much
Simon
--~--~-~--~~~---~--~~
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sage-support
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-support] Re: Question about doc tests
Hi Simon, On Mon, 17 Nov 2008 11:26:16 -0800 (PST) Simon King <[EMAIL PROTECTED]> wrote: > > Dear Team, > > I have a couple of .pyx files and (sometimes trying to be a good boy) > I provided long doc strings with lots of doc tests. I do this with the code I develop out of the tree too. You need to import your module explicitly for each doctest, i.e., include a "from foo import func_name" at the beginning of your EXAMPLES: section. However, this didn't work properly until recently, since the sage-doctest script didn't add the contents of the SAGE_PATH variable to sys.path. A patch fixing this is in 3.2.rc1, but I don't recall if it was in a previous stable release or not. Which version are you using? > However, >sage -t foo.pyx > fails by raising errors on *all* tests that involve any function from > 'foo.pyx'. > First attempt: > Plainly use the function 'bar' from 'foo.pyx' > Result: NameError: name 'bar' is not defined This is not expected to work. > Second attempt: > Import 'foo' in all examples (there is 'foo.so' in the directory) > Result: ImportError: No module named foo But this should. > Third attempt: > Explicitly name the function 'foo.bar'. > Result: NameError: name 'foo' is not defined > > The puzzling fact is: The test examples work if I try them directly in > Sage after doing > from foo import * Sage seems to include the current directory in the module search path (sys.path). This is not the case for doctesting. I think using the SAGE_PATH variable in general is a better approach. Cheers, Burcin --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
