On May 22, 11:53 am, "David Roe" <[EMAIL PROTECTED]> wrote:
> These are all basically examples of sections of injective canonical maps
> going the other direction.
Yes I now think this seems like the best way to address this.
Non-automatic coercions that are (partially defined) inverses of
auto
Hello,
I've released sage-2.5.3. The SAGE Notebook now should feel faster,
there are a number of bug fixes, and I've updated linbox to the most
recent version.
I will post binaries later tonight. Also, you can (hopefully) upgrade
using the upgrade() command from within SAGE.
* m albre
SAGE developers,
As you may know, I have been working on building some new spkgs and
have also begun refactoring the spkg build scripts themselves. A few
ideas that I would like feedback on:
1. Creating a repository for the spkg makefiles and build scripts
As far as I know, the full spkg infr
On 5/22/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> This actually makes sense, but it would be nice if instead of throwing
> an exception, a list of imported modules would be saved when trying to
> save a session and then imported when executing load_session().
You're right, this is a bu
This actually makes sense, but it would be nice if instead of throwing
an exception, a list of imported modules would be saved when trying to
save a session and then imported when executing load_session().
I'm still a bit new to python, so I'm not sure how you would want to
handle saving objects
On May 22, 2007, at 9:17 AM, [EMAIL PROTECTED] wrote:
> On Tue, 22 May 2007, David Harvey wrote:
>
> William: I don't like the word "scalar". That may be because much
> of my experience with PHP and PERL -- where there are scalars and
> arrays. I'd like it to be called something like "unitl
# HG changeset patch
# User Bobby Moretti <[EMAIL PROTECTED]>
# Date 1179852649 25200
# Node ID 5d423d8161906a30efe1b6837524724737303db2
# Parent 82e2148257968030ef5a6d2a5ee415aaf0927f28
implemented SR.numerical_approximation()
diff -r 82e214825796 -r 5d423d816190 sage/calculus/calculus.py
--- a/
I hate significant figures. Use real error propogation and standard
deviations instead.
David
On 5/22/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
> On Tue, 22 May 2007, David Harvey wrote:
>
> >> 1*meters + 2*meters*meters : NOT OK.
> >> 1*meters + 2*feet = ... in feet or m
On Tue, 22 May 2007, David Harvey wrote:
>> 1*meters + 2*meters*meters : NOT OK.
>> 1*meters + 2*feet = ... in feet or meters? (I say meters)
>
> I say metres.
Not my fault you can't spell. ;)
William: I don't like the word "scalar". That may be because much of my
experience with
On May 22, 2007, at 3:10 AM, [EMAIL PROTECTED] wrote:
> * Are we going to throw exceptions when units of differing type
> are added?
>
> 1*meters + 2*meters*meters : NOT OK.
> 1*meters + 2*feet = ... in feet or meters? (I say meters)
I say metres.
david
--~--~-~--~~-
On 5/22/07, Michel <[EMAIL PROTECTED]> wrote:
> I do not agree with the radical statement that there should not be
> (non-canonical)
> coercions in that direction. There is a coercion from QQ to ZZ.
You misunderstand -- by "coercion" David Roe meant a canonical
coercion, which is defined by the
I do not agree with the radical statement that there should not be
(non-canonical)
coercions in that direction. There is a coercion from QQ to ZZ.
Why shouldn't there be a coercion from a polynomial ring to its
base ring? Sage should mimic the way mathematicians think.
I agree that perhaps this
On 5/22/07, Michel <[EMAIL PROTECTED]> wrote:
> > I'm concerned that your proposal, if I understand it correctly,
> > will make it difficult to avoid infinite loops. Could you flesh
> > out your proposal more, and specifically address issues
> > involving infinite loops?
>
> I guess this was more
These are all basically examples of sections of injective canonical maps
going the other direction. There clearly shouldn't be a coerce method going
that direction because the objects are not isomorphic. If we switch to a
data-driven, category theoretic coercion system, it should be possible to
r
> I'm concerned that your proposal, if I understand it correctly,
> will make it difficult to avoid infinite loops. Could you flesh
> out your proposal more, and specifically address issues
> involving infinite loops?
I guess this was more of an idea than a proposal. But given
the rethinking o
On May 22, 2007, at 12:10 AM, [EMAIL PROTECTED] wrote:
>
>> I am in favor of something more like that, though I *loathe* adding
>> anything further to the preparser. Maybe this is more pythonic:
>>
>> sage: sin(10 * degrees)
>>
>> i.e., degrees would be a Python object that represent 1 degree
On 5/22/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>
> > I am in favor of something more like that, though I *loathe* adding
> > anything further to the preparser. Maybe this is more pythonic:
> >
> > sage: sin(10 * degrees)
> >
> > i.e., degrees would be a Python object that represent 1
> I am in favor of something more like that, though I *loathe* adding
> anything further to the preparser. Maybe this is more pythonic:
>
> sage: sin(10 * degrees)
>
> i.e., degrees would be a Python object that represent 1 degree.
> The resulting object 10 * degrees would be a number with unit
On 5/21/07, Michel <[EMAIL PROTECTED]> wrote:
>
> What about my example: constant polynomials to elements of the base
> ring.
>
> In this case it seems *much more natural* to put the logic in
> PolynomialRing
> than to pollute the __call__ method of every possible ring.
>
> There are many more ex
On 5/22/07, William Stein <[EMAIL PROTECTED]> wrote:
> By the way, here is what Mathematica does:
>
> In[7]:= N[Sin[10 Degree]]
> Out[7]= 0.173648
>
> I am in favor of something more like that, though I *loathe* adding
> anything further to the preparser. Maybe this is more pythonic:
>
>sage:
20 matches
Mail list logo
