Simon King schrieb:
Hi!
On Apr 23, 2:05 pm, bb <bblo...@arcor.de> wrote:
...
The second passage I found was at
http://www.sagemath.org/doc/tutorial/programming.html
... When comparing objects of different types in Sage, in most cases
Sage tries to find a canonical coercion of both objects to a common
parent.
I am translating the whole tutorial, so, you are right with both
passages you mention. IIRC there was a number of questions on sage-
support about coercion (understandably, I think). But the tutorial and
the "Sage constructions" don't seem to address it. Therefore I
consider to add a new section on conversion vs. coercion in tutorial/
programming (in English as well), apart from just translating.
The notions of type conversion (in C), conversion (in Sage) and
coercion (in Sage) are distinct, but have a big semantic overlap.
"Being distinct and having a semantic overlap" means: One has to be
particularly careful in choosing sound notions in translation, or
confusion will rise.
Examples:
1) In C:
int i = 10;
char j;
j = (char)i; // type conversion
cast:
Sorry, I only see that from a perspective of computer
science/programming. The conversion in the example above is called
"explicit type conversion". That is done by "casting". In your example
you used a C-like casting: (char)i;. In C++ there is also a functional
casting possible: char (i) - may be its possible in newer C versions
as well? And you assign that to a proper variable j. That is the way in
strong-typed languages. If you try i=(char) i; you should get an error
message. Very often people do not understand, that in the cast process
the original type of the casted variable will be preserved! i is integer
before and after casting!
I know a lot of C literature and do not know any one calling any form of
type conversion coercion! Because there is no implicit conversion in
strong-typed languages possible. (Well, there are exceptions, i. e.
short a=2000;
int b;
b=a;
and in printing with printf() by format code. That only holds, because
you can always fit a short in an int, but the opposite is not true, and
it is also not true for many other data types (see a C reference!).)
sage: i=2000
sage: float(i)
2000.0
sage: i
2000
sage: f=23.34
sage: f
23.3400000000000
sage: int (f)
23
sage: f
23.3400000000000
sage:
coercion:
is an implicit type conversion. Python/Sage are not strong-typed
languages! So you usually can use an implicit type conversion, usually
called coercion.
Some german computer science books call that implicit type conversion
"(automatische) oder erzwungene Typumwandlung". **
sage: a=2
sage: a=34.45
sage: a=3/2
sage: a.n()
1.50000000000000
sage:
Yoe see, that Sage has nothing against the change of type.
The data type model of Sage is described on
http://docs.python.org/reference/datamodel.html. There is also given the
rule:
"Arguments to rich comparison methods are never coerced."
"is" and "is not" is one of the "rich comparison" methods (whereas ==,
and so on is not!):
"The operators is
<http://w3.hidemyass.com/index.php?q=aHR0cDovL2RvY3MucHl0aG9uLm9yZy9yZWZlcmVuY2UvZXhwcmVzc2lvbnMuaHRtbA%3D%3D#is>
and is not
<http://w3.hidemyass.com/index.php?q=aHR0cDovL2RvY3MucHl0aG9uLm9yZy9yZWZlcmVuY2UvZXhwcmVzc2lvbnMuaHRtbA%3D%3D#isnot>
test for object identity: x is y is true if and only if /x/ and /y/ are
the same object. x is not y yields the inverse truth value."
So I argue that you put more meaning into that simple facets of type
conversion (explicit or inplicit) as ist is really worth.
May be there is some content in it for any mathematical application or a
proof? But that is not my business!
Regards BB
2) Sage conversion is (in general) no *type* conversion.
sage: a = GF(2)(1)
sage: type(a)
<type 'sage.rings.integer_mod.IntegerMod_int'>
sage: b = GF(5)(a) # conversion
sage: type(b)
<type 'sage.rings.integer_mod.IntegerMod_int'>
So, the type happens to be the same (no type conversion), but ``a`` is
in GF(2) while ``b`` is in GF(5).
3a) Conversion is not the same as coercion:
sage: a = GF(2)(1)
sage: b = GF(5)(a)
sage: a == b # there is no canonical coercion, so, they don't
compare equal
False
sage: a == GF(2)(b) # i.e., conversion != coercion
True
sage: b == GF(5)(a)
True
sage: 1 == a # there is a canonical coercion from ZZ to GF(2)!
True
sage: 1 == b # there is a canonical coercion from ZZ to GF(5)!
True
3b)
sage: R.<x> = ZZ[]
sage: p = x^2 + 2*x + 1
sage: p.parent()
Univariate Polynomial Ring in x over Integer Ring
sage: q = p + GF(2)(1) # both summands are converted to GF(2)['x']
sage: q # since q has coefficients in GF(2), 2*x and 1+1 vanish!
x^2
sage: q.parent()
Univariate Polynomial Ring in x over Finite Field of size 2 (using
NTL)
Cheers,
Simon
--
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
