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
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
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
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
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?
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
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,
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,
Dear Simon,
On Tue, 18 Nov 2008 02:27:24 -0800 (PST)
Simon King [EMAIL PROTECTED] wrote:
snip
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
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 =
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
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
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
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)
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
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
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
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,
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
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-
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
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
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
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
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,
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
26 matches
Mail list logo
