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 p
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 d
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 fa
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 in
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
>
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 ot
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
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 i
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 defaul
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: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 w
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 wou
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 *
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. C
-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
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 everybod
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 envir
"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.
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,
> the
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 th
> 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
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 li
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
this I think is good. What I think is bad is that something like
1.0*sin(1) is not numerica
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 w
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 def
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
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 no
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
28 matches
Mail list logo
