On Thu, Jun 17, 2010 at 12:14 PM, Nils Bruin <nbr...@sfu.ca> wrote:
> On Jun 17, 10:32 am, Robert Dodier <robert.dod...@gmail.com> wrote:
>> On Jun 16, 11:24 am, Tom Coates <t.coa...@imperial.ac.uk> wrote:
>>
>> > A)  factorial(x) should raise an error;
>>
>> > B)  factorial(x) should return gamma(x+1).
>>
>> More generally, the question is what to do with something
>> which doesn't make sense according to whatever rules have
>> been established so far. I claim the "mathematical" attitude
>> is to let it stand; then someone who has greater imagination
>> can figure out what to do with it. Barfing out an error makes
>> it pretty much impossible to reinterpret the expression in
>> an interesting way.
>
> This is an option if  you are working in a symbolic domain, where
> "gamma(x+1)" can be represented as such. The original question was
> what should happen if a numerical argument gets passed in, for
> instance
>
> factorial(ZZ(-3))
>
> It would be rather bad form if the return value were to lie in what is
> referred to as the "symbolic ring" for this input, whereas
> factorial(ZZ(3)) would return the integer 6. In general, the *parent*
> of the return value should not depend on the *value* of the argument;
> only on the *parent* of the argument.

In Sage, the behavior of sqrt(2) versus sqrt(4) is considered very reasonable
to most users.  And it does exactly what you claim is "rather bad form".

sage: sqrt(2)
sqrt(2)
sage: sqrt(4)
2
sage: type(sqrt(2))
<type 'sage.symbolic.expression.Expression'>
sage: type(sqrt(4))
<type 'sage.rings.integer.Integer'>

Matlab, Magma, and PARI all just treat sqrt(n) as purely numerical,
without a second thought.
Mathematica and Maple act just like Sage.

> This kind of issue points at a fundamental difference between symbolic
> algebra systems where everything is an "expression tree", such as
> maple and maxima, and systems more fundamentally based on categories,
> where objects have a parent.

Sage is *both*.

  Mathematica, Maple, Maxima -- these are all symbolic

  Magma, Matlab, GP -- more based on "categories", but where of course
in Matlab it's all floating point.

But the goal of the Sage project is to be a viable alternative to both
of these.  Please don't try to make Sage be all categories or all
symbolic.

> In fact, William Stein's vote for "B" in favor of backwards
> compatibility is only partly based on reality:

My suggestion was merely that making errors be raised when they aren't
now would break backwards compatibility.   This is true irregardless
of the fact that errors were raised in some cases before.

> sage: factorial(-1)
> ValueError: factorial -- self = (-1) must be nonnegative
> sage: factorial(-1.1)
> ValueError: factorial -- must be nonnegative
> sage: gamma(-1.1+1)
> -10.6862870211932
>
> but:
>
> sage: factorial(1.1)
> 1.04648584685356
> sage: gamma(1.1+1)
> 1.04648584685356
>
> I'd say factorial( <integer> ) should return an integer (or an error
> if it can't).
>  factorial( <float> ) would be expected to return a float
> and hence can safely use gamma. This probably violates Python's duck
> typing, though. Perhaps return integer output on anything that can be
> canonically coerced into the integers?

This reminds me of the argument that resulted in Guido making 1/3 be 0
in Python long ago, namely that a binary operation on objects x,y in a
set R should result in an element in R.

 -- William



-- 
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Reply via email to