On 25 Apr., 08:10, Robert Bradshaw <rober...@math.washington.edu>
wrote:
> On Apr 23, 2010, at 7:07 PM, Nathan O'Treally wrote:
> > Though e.g. C and C++ do have automatic (or implicit) conversion, it
> > is usually referred to as (different kinds of) type *casts*.
> > C++ does have additional explicitly stated kinds of conversions
> > ("real" casts): <static_cast>, <dynamic_cast> and <reinterpret_cast>,
> > of which <dynamic_cast> though does some kind of automatic conversion.
>
> I would say that the Sage <-> C analogy is:
>
> conversion <-> type cast
> coercion <-> type promotion
Unfortunately the notion of casts (in the context of C/C++) includes
both type demotion *and* promotion (plus reinterpretation of values
without changing the "range" or representation).
And there's actually a third type of conversion people often seem to
"forget" (or not realize) perhaps because it can cause trouble: ;-)
Conversion between integers and floating-point numbers (with limited
mantissa and exponent) can result in a promotion or a demotion (i.e.
losing precision, in *both* directions), depending on the actual
values, not the types in principle.
(A similar problem occurs when converting strings or literals with
*decimal* digits to base-2 floating-point numbers or vice versa; this
led to the introduction of hexadecimal notation for floating-point
constants, too.)
> C++ is of course a bit messier, as there are so many ways to convert
> from one type to another.
C++ isn't messy. ;-)
> > (I wonder why < etc. is defined on CC at all.)
>
> The fact that we put an ordering on CC is orthogonal to coercion, and
> has been discussed elsewhere (and may very well go away). If/when we
> do away with an order on complex numbers, the ordering on real/complex
> comparisons will go away as well.
Amen. Good to hear that.
> > sage: a==b , b==c , c==a
> > (False, True, True)
> > sage: b==a , c==b , a==c
> > (False, True, True)
> > # HELL! 8/
> > (The tutorial warns in contrast to Sage it *is* consistently defined
> > in Magma.)
>
> > a := GF(5)!1;
> > b := GF(7)!1;
> > c := 1;
>
> > a eq c;
> true
> > b eq c;
> true
> > a eq b;
>
> >> a eq b;
> ^
> Runtime error in 'eq': Arguments are not compatible
> Argument types given: FldFinElt, FldFinElt
I only cited the Sage reference manual. Is it symmetric in Magma?
> In Python, the convention is that == and != never raise an error, so
> False is returned if coercion fails (the two domains are incompatible).
That's *very* poor and IMHO unacceptable in a mathematical
environment.
Tertium tamen datur, and if we don't extend all domains with a
"bottom" element (or at least change Boolean->Logical/TruthValue),
such operations should raise an exception.
A compromise would be to make it optional by some global constant/
parameter (cf. signaling NaN/signaling comparisons).
I've lost the reference, but the Sage manual somewhere states "The
results can be somewhat random.".
(I'd say this is the opposite of "obvious and natural".)
>
> > "[...] A coercion from one parent to another must be defined on the
> > whole domain, and always succeeds. As it may be invoked implicitly, it
> > should be obvious and natural (in both the mathematically rigorous and
> > colloquial sense of the word). [...]"
> > There are situations where I would relax that and raise an exception
> > e.g. if a specific value can't be implicitly converted because it has
> > no representation in the target domain.
>
> This was decided on because it made arithmetic easier to reason with,
> but if there's consensus it could be relaxed (though if it were,
> preferably the values without images would be very rare).
*Preferably*. :) See integer<->real above. Same for conversion of QQ-
>floating-point.
> I view strongly/weakly typed is more of a continuum than binary
> categories,
I wouldn't say continuum, rather different shades of white and black,
perhaps on multiple axes.
> but it's clear they're not very well defined. Of course
> most words in the English (or any other) language are quite fuzzy, but
> that doesn't mean they're not useful :).
Yes, everybody has its own interpretation. :)
(That's the way politicians [not only] in the European Union come to
"agreements".)
And that's why we (try to) use formal languages.
> here we're talking about
> the "type system" of the Sage system as a whole, which is very
> different than that of Python.
Agree.
-Leif
--
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
