On 23 Apr., 11:10, Simon King <simon.k...@nuigalway.ie> wrote:
> On Apr 22, 10:46 pm, "Georg S. Weber" <georgswe...@googlemail.com>
> wrote:
>
> > I think I like "Wandlung" as the common umbrella term for both
> > "coercion" ("Umwandlung", I like that, too) and "conversion" (for the
> > latter I'd propose: "Verwandlung" --- but "Konversion" might do as
> > well, and would be a good memory hook for what is what).
>
> Yes, conversion<->Konversion and coercion<->Umwandlung sounds good to
> me.To get back to the topic... ;-) Sorry, Simon, you misunderstood me; my enumeration of German terms didn't mean they are synonyms, i.e. (type) conversion == (Typ-)Umwandlung, coercion == erzwungene Typumwandlung (oder implizite, automatische) canonical coercion == kanonische (erzwungene/implizite/automatische) Typumwandlung. (And coercion model == Typumwandlungsmodell) Unfortunately, conversion, casts and coercion are often used as [if they were] synonyms, and the terms aren't really absolute. Coercion is a kind of conversion, namely implicit or automatic conversion. (Other definitions state a coercion is simply a function taking the value of some type and mapping it into another type/domain, so the notion of coercion above here would be named coercion model; also the *model* defines what's implicit) http://trac.sagemath.org/sage_trac/ticket/1144#comment:2 gives another nice description of what coercions are in the context of Sage... :D 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. The same is true for constructors taking other types as arguments; though they are explicit in the defining class, there application can be implicit, i.e. automatically performed by the compiler, but this mechanism is afaik not referred to as coercion (not because it wasn't coercion). In Sage, coercions are explicitly defined in the class definitions, too; the mechanism is somewhat different though, because it uses its own "parent" model that doesn't necessarily reflect the class hierarchy. Btw, the Sage reference manual discusses Sage's coercion model (which is *not* the same as Python's): http://www.sagemath.org/doc/reference/coercion.html http://www.sagemath.org/doc/reference/sage/structure/coerce.html But I don't agree with it (I'd say it isn't sound or really consistent). ;-) E.g., for me it doesn't make sense to (allow to) compare reals to complex numbers (other than [in]equality): sage: a=3.5 sage: b=CC(5.5+I) sage: a<b True sage: type(a); type(b) <type 'sage.rings.real_mpfr.RealLiteral'> <type 'sage.rings.complex_number.ComplexNumber'> sage: a=7.5 sage: a<b False (I wonder why < etc. is defined on CC at all.) The Tutorial (http://www.sagemath.org/doc/tutorial/ programming.html#loops-functions-control-statements-and-comparisons) gives another example: sage: GF(5)(1) == QQ(1); QQ(1) == GF(5)(1) False False sage: GF(5)(1) == ZZ(1); ZZ(1) == GF(5)(1) True True sage: ZZ(1) == QQ(1) True # This means a==b is False and a==c is True though c==b *is* True: sage: a=GF(5)(1) sage: b=QQ(1) sage: c=ZZ(1) # (scroll away these definitions to surprise somebody else) 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 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. For "conversions" in Sage it is said that success might depend on the actual values (as opposed to their types). "[...] The goal of the coercion system is to facilitate this [transparently doing arithmetic, comparisons, etc. between elements of distinct sets], and at the same time being strict enough to not resolve ambiguity or accept nonsense.[...]" (http://www.sagemath.org/doc/developer/coding_in_python.html) While ambiguity could be rejected (by exceptions or a compiler error message) or resolved *in a defined way*, obvious (detectable) "nonsense" should be rejected in all cases. This is exactly what type safety means. (If the programmer *explicitly* requests nonsense, the program's behavior will be undefined [by the programming language]. There are situations where type punning, for example interpreting a C double as an unsigned int or bitfield, does make sense and does have well-defined behavoir, that's why C++ does have <reinterpret_cast>.) I hesitate to continue the discussion of what strictly or strongly typed languages are, but IMHO Python is weakly typed, because functions do not have formal signatures at all, lists can have mixed- type elements, ... (unless you consider "object" a "true" type, which doesn't help much). Reflection is another source of trouble, because it introduces mixing of object and meta level, which is hell not only in logic. -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
