Dear Michael
On Jan 23, 1:30 am, mabshoff [EMAIL PROTECTED]
dortmund.de wrote:
On Jan 22, 11:34 pm, Simon King [EMAIL PROTECTED] wrote:
snip
I mean: saying ./sage -notebook, i got a lot of error messages and
eventually an Unhandled SIGSEGV.
I can reproduce it.
Slightly relieving for me
On Jan 22, 2:17 pm, Carl Witty [EMAIL PROTECTED] wrote:
'Integer' is a Sage type. This means it has lots of useful
mathematical convenience methods (like .is_square()), it participates
in the coercion model, etc. Also, 'Integer' is implemented with GMP,
and 'long' is not, so 'Integer' is
On Jan 22, 2008 11:48 PM, Paul Zimmermann [EMAIL PROTECTED] wrote:
thank you for your explanations.
The 'int' (and its bignum counterpart, 'long') are native Python
types. As far as I know, we don't modify Python at all; removing
'int' would be major surgery, and we're not going to do
On Jan 23, 2008 4:24 AM, Gorka Merino [EMAIL PROTECTED] wrote:
Good morning Dr. Stein, I'm not sure if this is the appropriate place to ask
for but i had some problems t get into the forums,
I'm trying to install SAGE for Windows from the
http://sagemath.org/SAGEbin/microsoft_windows/
On Jan 23, 2008 5:33 AM, mabshoff
[EMAIL PROTECTED] wrote:
On Jan 23, 2:29 pm, William Stein [EMAIL PROTECTED] wrote:
On Jan 22, 2008 11:48 PM, Paul Zimmermann [EMAIL PROTECTED] wrote:
SNIP
I guess 'long' is based on GMP too, does it make sense to have two
concurrent
interfaces
I'm probably trying to do something stupid here, but I'm interested
in the expression sin(a)+sin(b)+sin(c) where a,b,c are the angles of
a triangle, i.e. c=pi-a-b. This of course can be simplified to
sin(a)+sin(b)+sin(a+b).
I thought it might be interesting to plot this and so I entered:
Thanks, William, that's great!
--~--~-~--~~~---~--~~
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
On Jan 23, 7:49 pm, Yi Qiang [EMAIL PROTECTED] wrote:
I can comment on the python-gnutls issue. The problem is that the API
for gnutls has changed and is NOT backwards compatible with the
previous releases. Hence, python-gnutls will not work since it is
simply a package that wraps the
kcrisman,
The best possible world might be something like
show(graphs(n,size==3))
If you look at
http://trac.sagemath.org/sage_trac/ticket/1869
again, you'll see that as of sage 2.10.1 (as long as the patch gets a
review before 2.10.1 comes out...), you'll be able to do things like
sage:
It is due to the fact that ^ has a higher precedence than - in Python.
n(-1^(1/3)) is the same as n((-1^(1/3))).
--Mike
On Jan 23, 2008 5:04 PM, Ted Kosan [EMAIL PROTECTED] wrote:
Does anyone have any thoughts on why the following 2 code samples give
different results?:
#SAGE Version 2.10,
Mike wrote:
It is due to the fact that ^ has a higher precedence than - in Python.
n(-1^(1/3)) is the same as n((-1^(1/3))).
Okay, here is how I ran into this:
https://sage.ssu.portsmouth.oh.us:9000/home/pub/21/
What I expected to get was -1.44224957030741. Which result should it
I'm sorry, I didn't read the ticket on this.
This is pretty great - thanks for the work! Amazing what is possible
to do. I assume by the fact that you gave the variable that name that
it would be possible at some later point to amend the code to allow
checking for other extra_property
On Jan 23, 8:26 pm, Ted Kosan [EMAIL PROTECTED] wrote:
Mike wrote:
It is due to the fact that ^ has a higher precedence than - in Python.
n(-1^(1/3)) is the same as n((-1^(1/3))).
Okay, here is how I ran into this:
https://sage.ssu.portsmouth.oh.us:9000/home/pub/21/
What I
On Jan 23, 2008 5:50 PM, kcrisman [EMAIL PROTECTED] wrote:
On Jan 23, 8:26 pm, Ted Kosan [EMAIL PROTECTED] wrote:
Mike wrote:
It is due to the fact that ^ has a higher precedence than - in Python.
n(-1^(1/3)) is the same as n((-1^(1/3))).
Okay, here is how I ran into this:
kcrisman wrote:
But what Ted really wanted was just the real cube root of -1.
What I wanted was where the graph crossed the x axis as shown in the plot :-)
Ted
--~--~-~--~~~---~--~~
To post to this group, send email to sage-support@googlegroups.com
To
kcrisman wrote:
I'm sorry, I didn't read the ticket on this.
This is pretty great - thanks for the work! Amazing what is possible
to do. I assume by the fact that you gave the variable that name that
it would be possible at some later point to amend the code to allow
checking for other
William wrote:
Until a month ago (-1)^(1/3) would have given -1. This is the default
behavior dictated by Maxima. Then Paul Zimmerman complained
(with a great argument) that this was stupid, and Mike Hansen changed
the default Maxima behavior to what we currently have. He did
this by
Hi, all,
In 2.10 (on 10.4.11), I notice that readline is behaving badly:
If I ^R and search for a string, and find it, and then either use
^A or E to move to the beginning or end of the found line, I end
up with the cursor at the right margin of my Terminal window, and on
the line above
Jason Grout wrote:
kcrisman wrote:
I'm sorry, I didn't read the ticket on this.
This is pretty great - thanks for the work! Amazing what is possible
to do. I assume by the fact that you gave the variable that name that
it would be possible at some later point to amend the code to allow
So why is solve placing parentheses around the 3rd root it returns if
it evaluates into an imaginary value?
[...,..,x == (-1)^(1/3)*3^(1/3)]
around the 3rd root should be around the -1 in the 3rd root
Ted
--~--~-~--~~~---~--~~
To post to this group, send
[...,..,x == (-1)^(1/3)*3^(1/3)]
I ran into this issue while demonstrating the usefulness of the solve
function in front of a class of students. That was quite 'fun' :-)
Ted
It does seem strange that the answer that looked like it should be real is
actually not. If you have
21 matches
Mail list logo
