William wrote
I would be happy to introduce a short-cut alias for numerical_approx,
e.g., N() or n() or ??.
...
Something simple like a.N() might be quite reasonable as a shortcut
for a.numerical_approx(), and would be very simple to implement (just
one line of code in an appropriate
Nick wrote:
I use RR(expr) and find it at least as usable as the N[expr] notation
of Mathematica.
and William wrote:
We should learn a lot about how
Mathematica/Maple, etc., work, and why, but then make a _choice_
for SAGE that is a reasonable trade-off between various options.
Python is
On 7/10/07, Ted Kosan [EMAIL PROTECTED] wrote:
I have found myself using numerical_approx() instead of RR() because
it is also placed at the end of the line and so is relatively easy to
locate the cursor there and add it. With RR(), one has to wrap the
code in a function and then unwrap it
On Tue, Jul 10, 2007 at 02:54:31PM -0700, William Stein wrote:
On 7/10/07, David Harvey [EMAIL PROTECTED] wrote:
I don't really like the idea of modules that imitate various
environments, i.e. I don't think it's possible or desirable for us to
try to look specifically like any other
On 7/11/07, Joel B. Mohler [EMAIL PROTECTED] wrote:
I think the init file idea needs to be pushed harder. I already do this and
the
flexibility is absolutely critical to my happiness. I even have my init file
call another file in the current directory so I can have different things
I would be willing to chip in some effort on the mathematica.sage
file, although not in the very near future. I plan to begin migrating
my undergraduate courses to sage from mathematica for fall semester
2008. I hope to convince other faculty do to the same, but it won't
be easy. I am mainly
On 7/11/07, Hamptonio [EMAIL PROTECTED] wrote:
I would be willing to chip in some effort on the mathematica.sage
file, although not in the very near future. I plan to begin migrating
my undergraduate courses to sage from mathematica for fall semester
2008. I hope to convince other faculty
Well the biggest reason is just inertia: my department has been using
mathematica for years, and everyone has a full set of computer labs
and handouts and demos already done in mathematica. Why learn a new
system and have to port everything over? We don't even directly pay
for the license as a
Ted Kosan [EMAIL PROTECTED] writes:
In SAGE, I have ended up using the numerical_approx() method as an
equivalent to N[] and //N in Mathematica, but I have found it not to
be as quick and easy to use.
I use RR(expr) and find it at least as usable as the N[expr] notation
of Mathematica.
Nick
I agree that RR(expr) works well as an N(expr) replacement. It would
be nice for mathematica migrators to actually have N() defined,
although that does clutter up the namespace more.
I hadn't realized that mathematica was so unusual in its behavior in
this regard. However, there's another
Hi all,
So far I've been refraining from posting here, since I don't have
strong feelings one way or the other, but the discussion so far has
been great and I'd like to leave a few comments.
On 7/8/07, William Stein [EMAIL PROTECTED] wrote:
Hi,
Thanks for all the feedback from everybody
-1 to single-letter functions in the namespace.
Also note that RDF(expr) works too, and is marginally to extremely faster,
depending on the precision that RR is using.
On Tue, 10 Jul 2007, Hamptonio wrote:
I agree that RR(expr) works well as an N(expr) replacement. It would
be nice for
Perhaps it would help to start with a fairly clean namespace and then
have some modules which would imitate various environments. So for
example, there might be a simple command like:
set_style('mathematica')
which would define the N() function, and some other favorite
mathematica functions.
I don't really like the idea of modules that imitate various
environments, i.e. I don't think it's possible or desirable for us to
try to look specifically like any other system. Mathematica semantics
are so different from SAGE's, it would be misleading to suggest
anything like that. But I
On 7/10/07, David Harvey [EMAIL PROTECTED] wrote:
I don't really like the idea of modules that imitate various
environments, i.e. I don't think it's possible or desirable for us to
try to look specifically like any other system. Mathematica semantics
are so different from SAGE's, it would be
On Jul 10, 2007, at 2:20 PM, David Harvey wrote:
I don't really like the idea of modules that imitate various
environments, i.e. I don't think it's possible or desirable for us to
try to look specifically like any other system. Mathematica semantics
are so different from SAGE's, it would
Though I am against having all single-letter symbolic variables
defined, I want to put a comment in for having a well-populated
global namespace at startup. I like this so I can get right to work
with out having to import a bunch of stuff too (let alone remember
where things are). This is
On Jul 10, 2007, at 2:54 PM, William Stein wrote:
On 7/10/07, David Harvey [EMAIL PROTECTED] wrote:
[snip]
But I *do* like the idea of the clean initial
namespace, which gets subsequently polluted on demand when
requested by
the user.
I do not think this should be the default for
William wrote:
From an implementation point of view, given the SAGE rules,
it makes way more sense for 2.5*sin(1) to remain symbolic,
since:
(1) this is what the backend simplification system (maxima) does,
and
(2) 2.5 * sin(1) in SAGE is computed by making 2.5 symbolic,
then doing
2007/7/8, Hamptonio [EMAIL PROTECTED]:
My biases are probably based on using mathematica for 17 years, but I
like the way it handles numerical vs symbolic computations. So at
present, in sage, sin(1) is symbolic, and sin(1.0) is numerical, and
+1, I like this behavior as well. And I like
2007/7/7, William Stein [EMAIL PROTECTED]:
So I propose that the only symbolic variables that are predefined
are x (since it's so useful to have this predefined), I (=sqrt(-1)),
and e (=2.7...).
I myself prefer to import everything by hand in Python. Thus the sage
module can have many
Hi,
Thanks for all the feedback from everybody about symbolic variables,
special functions, etc. For now (i.e., the very near term), I think
the best thing to do is:
(1) remove all predefined *symbolic* variables except x,
leave in e, pi, and I:
-- everybody basically wants
On 7/7/07, William Stein [EMAIL PROTECTED] wrote:
Hi,
I just taught a very intense two week workshop on the Riemann Hypothesis
to 24 bright high school students, in which we used SAGE quite a lot
each day for 2.5 hours (http://wstein.org/simuw/). I'm now very
seriously considering some
On Jul 7, 2007, at 10:44 , William Stein wrote:
So I propose that the only symbolic variables that are predefined
are x (since it's so useful to have this predefined), I (=sqrt(-1)),
and e (=2.7...).
If users want a symbolic variable, they have to use the var command.
I prefer having
On 7/7/07, Justin C. Walker [EMAIL PROTECTED] wrote:
On Jul 7, 2007, at 10:44 , William Stein wrote:
So I propose that the only symbolic variables that are predefined
are x (since it's so useful to have this predefined), I (=sqrt(-1)),
and e (=2.7...).
If users want a symbolic variable,
On Jul 7, 2007, at 10:44 AM, William Stein wrote:
The first is *removing* having predefined symbolic variable
names. I.e., in SAGE right now the variables a..z and A..Z
are prdefined at startup to be symbolic variables (except for I
and e).
+1 for nothing but e, I, and x defined by
Strongly support having as few predefined variables as possible. The
closer to zero the better. Honestly I would even prefer the entire
startup namespace to be as empty as possible; I would rather have to
import EllipticCurve, NumberField, etc than have them pre-loaded. I
know I won't get my
27 matches
Mail list logo
