On 4 Mai, 17:30, "William A. Stein" <[email protected]> wrote: > On May 4, 2010, at 8:21 AM, Jason Grout <[email protected]> wrote: > > Does anyone object to me changing float(CDF(1.0)) to behave like > > float(CC(1.0)) (i.e., a float conversion will succeed if the imaginary part > > is 0). Note that this will make CDF and the python complex type have > > different behaviors. > > I think I wrote the original code for this, and I am ok with the change you > suggest, since our policy on explicit coercions is to make them work when > they make (some) mathematical sense. > > > > > Also note that this will partially match the numpy complex type (which > > apparently just returns the real part of the number on conversion to float): > > > sage: float(numpy.complex128(1.0)) > > 1.0 > > sage: float(numpy.complex128(1.0+2j)) > > 1.0 > > That is truly evil.
This just again shows the confusion about the notion of "coercion". The usual interpretation is that the aspect of (indirect) force refers to *someone* being forced to *do* something, namely the compiler/ interpreter to *implicitly* apply type conversion rules (to facilitate the syntax of expressions), *not* to forcing *something* (a "value") into something, i.e. into some (possibly "too small") type or memory location. Since these rules are applied implicitly, they should only operate on the type or representation of some object, not its value or meaning in the semantic domain (e.g. in maths the float 1.0 normally means the same as the integer 1, as does the rational 5/5 [though Sage usually takes into account the structure of the sets the values belong to]; in physics, one might coerce eV to Joule, altering the apparent "value" or representation - hopefully - without changing the meaning). [Depending on the application domain, these coercions might though look like projections or abstractions wrt the *data* an object carries, as opposed to their *information* or meaning in a given context. Other coercion systems may not care that much about perhaps losing precision.] (So I wouldn't consider float() a coercion for *two* reasons; i.e. float() is not a coercion even if by "explicit coercion" you mean "explicit application of a coercion function", which extends the usual meaning of "coercion" to properties coercion functions should have.) Things are different when considering *explicit* conversions (or casts); these might actually be *value* conversions (in the semantic domain, i.e. actually changing the meaning of some object), e.g. type demotions from float to int (probably losing precision, probably in the opposite direction, too), or projections like taking the real part of a complex number. sage: int(1.1) # pretty valid; this is neither implicit *nor* meaning- preserving So the result of float(1+2j) *could* equally well be 1.0 (a projection, discarding information) because it is explicit, though one should perhaps better use (1+2j).real_part() since it is more "readable". (Btw, Python floats do not even form a ring.) Anyhow, the behavoir should be consistently defined and well- documented. (When there's a trade-off between consistency or "obvious meaning" and convenience, I'd always prefer the former.) Just my 2 cents, -Leif P.S.: In maths, 0.0 and 0.0000 denote the same thing; in other sciences, they usually do not (because the literals are interpreted to carry information on the precision or accuracy, e.g. of a measurement, too). We should also distinguish "Sage types" (usually Python classes that represent mathematical structures) from Python types; Sage implements its own type system through "parents", s.t. Sage objects might be incompatible though they have the same Python type. This is similar to having different number types with units; converting mass/kilograms to wave length/meters might make sense on the programming language's level (if e.g. both types are represented by reals); it obviously doesn't make sense on the application level. -- To post to this group, send an email to [email protected] To unsubscribe from this group, send an email to [email protected] For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
