[sage-devel] Translation of "coercion"

[Simon King]

Hi!

I am trying to translate "coercion" to German. In dictionaries and
Wikipedia, I only found the legal notion of a coercion, but I doubt
that "kanonische Nötigung" and "Nötigungsmodell" are good translations
for "canonical coercion" and "coercion model".

Does someone have a better creative idea? Is there any established
notion for it in German?

Best regards,
Simon

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

[Nils Bruin]

On Apr 21, 12:37 pm, Simon King <simon.k...@nuigalway.ie> wrote:
> Hi!
>
> I am trying to translate "coercion" to German. In dictionaries and
> Wikipedia, I only found the legal notion of a coercion, but I doubt
> that "kanonische Nötigung" and "Nötigungsmodell" are good translations
> for "canonical coercion" and "coercion model".
>
> Does someone have a better creative idea? Is there any established
> notion for it in German?

I'd go with erzwingung. This use of the word "coercion" is really as
in "I force the key into the lock"

[Nathan O'Treally]

On 21 Apr., 21:37, Simon King <simon.k...@nuigalway.ie> wrote:
> I am trying to translate "coercion" to German. In dictionaries and
> Wikipedia, I only found the legal notion of a coercion, but I doubt
> that "kanonische Nötigung" and "Nötigungsmodell" are good translations
> for "canonical coercion" and "coercion model".
>
> Does someone have a better creative idea? Is there any established
> notion for it in German?

Context? (just) Type theory?

In German, it's usually "(erzwungene) Typumwandlung", "kanonische
Typumwandlung", "Typumwandlungsmodell".
(If it is clear from the context, you can of course omit "Typ-".)

-Leif

[Simon King]

Hi!

On 22 Apr., 22:35, "Nathan O'Treally" <not.rea...@online.de> wrote:
> Context? (just) Type theory?

More than type, I think, but it certainly goes in that direction.
E.g., you want to compare an element x of QQ with an element y of
ZZ['t'] -- then Sage finds that there are both canonical coercions
from QQ to QQ['t'] and ZZ['t'] to QQ['t'], so, x and y can both be
coerced to QQ['t'] and compared there.

> In German, it's usually "(erzwungene) Typumwandlung", "kanonische
> Typumwandlung", "Typumwandlungsmodell".

I like Umwandlung! It sounds rather natural to say "Es gibt eine
kanonische Umwandlung von ZZ nach GF(5)". If it is an established
notion in a related field, and if there is no other established
translation of Sage's coercion model, it should be the way to go.

Thanks a lot!
Simon

[Simon King]

PS:

On 22 Apr., 23:13, Simon King <simon.k...@nuigalway.ie> wrote:
>
> I like Umwandlung! It sounds rather natural to say "Es gibt eine
> kanonische Umwandlung von ZZ nach GF(5)".

That said: How would one express the difference between "conversion"
and "canonical coercion"?
Example:
sage: R1.<a,b> = ZZ[]
sage: R2 = ZZ['d','e']

This is conversion from an element of R1 to R2:
sage: R2(a)
d
But there is no canonical coercion between R1 and R2, and actually no
parent structure R3 with both canonical coercions from R1 to R3 and R2
to R3. Consequently:
sage: R1(1) == R2(1)
False

Do you think the distinction between "Umwandlung" (=conversion) and
"kanonische Umwandlung" (=coercion) is strong enough?

Best regards

[Georg S. Weber]

On 22 Apr., 23:31, Simon King <simon.k...@nuigalway.ie> wrote:
> PS:
>
> On 22 Apr., 23:13, Simon King <simon.k...@nuigalway.ie> wrote:
>
>
>
> > I like Umwandlung! It sounds rather natural to say "Es gibt eine
> > kanonische Umwandlung von ZZ nach GF(5)".
>
> That said: How would one express the difference between "conversion"
> and "canonical coercion"?
> Example:
>   sage: R1.<a,b> = ZZ[]
>   sage: R2 = ZZ['d','e']
>
> This is conversion from an element of R1 to R2:
>   sage: R2(a)
>   d
> But there is no canonical coercion between R1 and R2, and actually no
> parent structure R3 with both canonical coercions from R1 to R3 and R2
> to R3. Consequently:
>   sage: R1(1) == R2(1)
>   False
>
> Do you think the distinction between "Umwandlung" (=conversion) and
> "kanonische Umwandlung" (=coercion) is strong enough?
>

Hi Simon,

I don't think "coercion" should be "kanonische Umwandlung", since
there might be canonical coercions as well as non-canonical ones. 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).


Cheers,
Georg

[Simon King]

Hi Georg,

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.

Thank you for all the input!

Cheers,

Simon

--
To post to this group, send an email to sage-...@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+...@googlegroups.com

[bb]

Simon King schrieb:

> Hi Georg,
>
> 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.
>
> Thank you for all the input!
>
> Cheers,
> Simon
>
>

I argue that you are working on the tutorial text?
I screened the text and found to passages in the text that use coercion:


http://www.sagemath.org/doc/tutorial/tour_rings.html

sage: i = CC(i) # floating point complex number
sage: i == CC.0
True
sage: a, b = 4/3, 2/3
sage: z = a + b*i
sage: z
1.33333333333333 + 0.666666666666667*I
sage: z.imag() # imaginary part
0.666666666666667
sage: z.real() == a # automatic coercion before comparison
True
sage: a + b


at this place in the document coercion in the comment is used just as a
comment, I think you do not plan to translate, but is is used in the
sense of type conversion, in German "Typkonvertierung" oder
"Typumwandlung".

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. If successful, the comparison is performed between the coerced
objects; if not successful the objects are considered not equal. For
testing whether two variables reference the same object use is. For example:

sage: 1 is 2/2
False
sage: 1 is 1
False
sage: 1 == 2/2
True


There also is the problem of comparison of (eventually) different data
types, so you have to find a "caninical coercion that allows a
comparison compliant to rules", say a "eine regelkonforme Typumwandlung,
die eine Vergleichsoperation erlaubt".

In the given example of the tutorial == only checks equality of the
value, that is why 1 ==2/2 gives True. The is-operator of Sage (and
Python) not only checks the equality of the numeric value but checks if
the two objects refer to the same object. Some examples:

sage: a= "something"
sage: b = None
sage: a is not None
True
sage: b is None
True
sage: a is b
False
sage: None
sage: type(b)
<type 'NoneType'>
sage: type(a)
<type 'str'>
sage: c=1
sage: d=1.0
sage: c==d
True
sage: c is d
False
sage: type(c)
<type 'sage.rings.integer.Integer'>
sage: type(d)
<type 'sage.rings.real_mpfr.RealLiteral'>
sage:

If (("I do not work on this"== True) or ("I do not find it usefull"==
True)) then "sorry for noise!"

It would be agood idea to give the source of the term you are asking
for. Most often a translation depends on the context!

Tnx & Regards

[Simon King]

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

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

[bb]

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

[William Stein]

Actually, Python *is* strongly typed.   Instead of trying to explain the meaning of terms such as "strongly typed", "dynamically typed", etc. I refer the reader to Wikipedia [1].

 -- William 

[1] http://en.wikipedia.org/wiki/Python_(programming_language)

[bb]

William Stein schrieb:

>
>
> On Fri, Apr 23, 2010 at 10:15 AM, bb <bbl...@arcor.de
> <mailto:bbl...@arcor.de>> wrote:
>
> Simon King schrieb:
>
> Hi!
>
> On Apr 23, 2:05 pm, bb <bblo...@arcor.de

> <http://en.wikipedia.org/wiki/Python_%28programming_language%29>

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

You might find everthing you want in Wikipedia and just the opposite as
well! Never ever use Wikipedia as a proof for anything! If you would
have read carefully that nonsense, you would have found that
Citation: "Python uses duck typing
<http://en.wikipedia.org/wiki/Duck_typing> and has typed objects but
untyped variable names."
Citation: "Python is strongly typed
<http://en.wikipedia.org/wiki/Strongly_typed_programming_language>,
forbidding operations that are not well-defined (for example, adding a
number to a string) rather than silently attempting to make sense of
them." That is a tautologie, because every language is forbidding
operations that are not well-defined! The reason is, that if an
operation is not implemented (= not well defined) it cannot be parsed
correectly and cannot be performed! Simple logik - isn it?

But the main question that arises, is Python duck typed or strongly
typed or eventually both, or may be Python users dont know it even
themselfes?
May be another citation will hold: Benjamin C. Pierce
<http://w3.hidemyass.com/index.php?q=aHR0cDovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9CZW5qYW1pbl9DLl9QaWVyY2U%3D>,
author of /Types and Programming Languages/ and /Advanced Types and
Programming Languages/, says, "I spent a few weeks... trying to sort out
the terminology of "strongly typed," "statically typed," "safe," etc.,
and found it amazingly difficult.... The usage of these terms is so
various as to render them almost useless."

May be that is as intelligent as to make no difference between a cough
and a pneumonia.

If you follow the link to "strongly typed
<http://en.wikipedia.org/wiki/Strongly_typed_programming_language>", you
find for instance a sentence out of many:
Citation: "Most generally, "strong typing" implies that the programming
language places severe restrictions on the intermixing that is permitted
to occur, preventing the compiling
<http://en.wikipedia.org/wiki/Compiler> or running of source code
<http://en.wikipedia.org/wiki/Source_code> which uses data in what is
considered to be an invalid way."
In Sage/Python try
sage: a=3
sage: a=a+4.3
sage: a
7.30000000000000
sage:
You are intermixing integer and float - forbidden in programming
languages usually called "strongly typed
<http://en.wikipedia.org/wiki/Strongly_typed_programming_language>".
Try for instance in Java or C (no one I know ever was claiming C not to
be "strongly typed
<http://en.wikipedia.org/wiki/Strongly_typed_programming_language>"):
sage: type(a)
<type 'sage.rings.integer.Integer'>
sage: a+=4.3
sage: type(a)
<type 'sage.rings.real_mpfr.RealNumber'>
sage:

Is that really the concept of strongly typing? If you like one might
bring the concept of statically typing and dynamically typing into
discussion and something more. Well the, Python is dynamically typed.
Many people see dynamically typing and strongly typing as antipodes.

Anyway, I do not want to discuss that basic computer science every day
over and over again and again - I did this for more than 20 years now.
And if one likes to believe that Python is strongly typed I cannot help,
because the one just has another definition of teh term. USA and Germany
as well have religious liberty as a constitutional right. But without
understanding that concepts you will have some problems in technical
writing and to distinguish between cast and coercion. The main point is,
that Python as a rule is coercing (say automatically converting)
following some rules.

http://docs.python.org/library/stdtypes.html:
"Python fully supports mixed arithmetic: when a binary arithmetic
operator has operands of different numeric types, the operand with the
“narrower” type is widened to that of the other, where plain integer is
narrower than long integer is narrower than floating point is narrower
than complex. Comparisons between numbers of mixed type use the same
rule.
<http://w3.hidemyass.com/index.php?q=aHR0cDovL2RvY3MucHl0aG9uLm9yZy9saWJyYXJ5L3N0ZHR5cGVzLmh0bWw%3D#id10>"

I would call that "coercion" ("implizite Typumwandlung").

"The constructors int()
<http://w3.hidemyass.com/index.php?q=aHR0cDovL2RvY3MucHl0aG9uLm9yZy9saWJyYXJ5L2Z1bmN0aW9ucy5odG1sI2ludA%3D%3D##int>,
long()
<http://w3.hidemyass.com/index.php?q=aHR0cDovL2RvY3MucHl0aG9uLm9yZy9saWJyYXJ5L2Z1bmN0aW9ucy5odG1sI2xvbmc%3D##long>,
float()
<http://w3.hidemyass.com/index.php?q=aHR0cDovL2RvY3MucHl0aG9uLm9yZy9saWJyYXJ5L2Z1bmN0aW9ucy5odG1sI2Zsb2F0##float>,
and complex()
<http://w3.hidemyass.com/index.php?q=aHR0cDovL2RvY3MucHl0aG9uLm9yZy9saWJyYXJ5L2Z1bmN0aW9ucy5odG1sI2NvbXBsZXg%3D##complex>
can be used to produce numbers of a specific type."

I would call that "casting" ("explizite Typumwandlung").

Python knows both - where is the problem?

Regards BB

PS: If you are still in doubt, please, please do not use Wikipedia for
any proof! Wikipedia is only good for to make a religion. Please better
ask a computer scientist, best working in the field of computation, not
hardware! On your university there should be a collection of that species!

[kcrisman]

> PS: If you are still in doubt, please, please do not use Wikipedia for
> any proof! Wikipedia is only good for to make a religion. Please better
> ask a computer scientist, best working in the field of computation, not
> hardware! On your university there should be a collection of that species!
>

On the other hand, I think it is recognized that the mathematics sites
on Wikipedia are often of a much higher grade than other pieces of
this (note my using 'often' and 'higher', not absolute terms). See
for instance a number of references to Wikipedia in the Notices and
Bulletin of the AMS in the last few years - several using it
implicitly as a standard reference. That doesn't mean it's perfect,
but at least in mathematics many articles are as correct, as useful,
and *much* more accessible, than the standard references. Just some
thoughts, not necessarily relevant to CS of course.

- kcrisman

[Nathan O'Treally]

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

[bb]

kcrisman schrieb:

>> PS: If you are still in doubt, please, please do not use Wikipedia for
>> any proof! Wikipedia is only good for to make a religion. Please better
>> ask a computer scientist, best working in the field of computation, not
>> hardware! On your university there should be a collection of that species!
>>
>>
>
> On the other hand, I think it is recognized that the mathematics sites
> on Wikipedia are often of a much higher grade than other pieces of
> this (note my using 'often' and 'higher', not absolute terms). See
> for instance a number of references to Wikipedia in the Notices and
> Bulletin of the AMS in the last few years - several using it
> implicitly as a standard reference. That doesn't mean it's perfect,
> but at least in mathematics many articles are as correct, as useful,
> and *much* more accessible, than the standard references. Just some
> thoughts, not necessarily relevant to CS of course.
>
> - kcrisman
>
>

It makes me happy, that I am not the only wicked man to assess Wikipedia
critical, see:
http://www.artima.com/forums/flat.jsp?forum=106&thread=121406

Even if the definitions of terms of computer science would be clear you
have a tremendous number of possible combinations. There is no clear cut
between the features of programming languages, but there are overlapping
features and it is said, that there are about 200 Programming languages
actively developed. . See the citation Benjamin C. Pierce, (Advanced
Types and Programming Languages): "I spent a few weeks... trying to sort

out the terminology of "strongly typed," "statically typed," "safe," etc.

I had such boring discussions very often and for instance the one and
only argument for Python to be termed "strongly typed" is, that it is
not possible to add String and Numbers! (If you have any extended
straight proof, why Python is strongly typed, I thank you very, very
much for it!! But please not ones that refer to Wikipedia, or the
authority "xyz" has said ... I mean hard proofs or arguments in a
scientific sense.)

That is mostly the only difference to JavaScript concerning type system,
a so called "typeless" prototyped language. Python is not prototype
based but class based - would be interesting to convert some code to
JavaScript to test the limit. ( I like JavaScript and admire the
brilliant code of the tracking analysers.) There is a browser operating
system residing in the webborser available as well
(http://www.lively-kernel.org/ or try it:
http://www.lively-kernel.org/repository/lively-wiki/example.xhtml .
needs some time to load!) But that is abit off topic - I know.

Regards BB

[Robert Bradshaw]

I would say that the Sage <-> C analogy is:

conversion <-> type cast
coercion <-> type promotion

C++ is of course a bit messier, as there are so many ways to convert
from one type to another.

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.

> 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 := 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

In Python, the convention is that == and != never raise an error, so
False is returned if coercion fails (the two domains are incompatible).

> "[...] 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).

> 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.

The goal *is* to reject nonsense in all cases. I'm not claiming it's
bug-free.

> (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.

I view strongly/weakly typed is more of a continuum than binary
categories, 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 :).

You bring up a very interesting point here--all the coercion happens
due to operator overloading. I've usually thought of type systems as
an inflexible part of a given language, but here we're talking about
the "type system" of the Sage system as a whole, which is very
different than that of Python.

- Robert

[Nathan O'Treally]

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

[Nathan O'Treally]

On 25 Apr., 08:10, Robert Bradshaw <rober...@math.washington.edu>
wrote:

sage: a==b
False
sage: a!=b # This then should return False because the coercion
failed
True # Ouch!

Otherwise one could test with (a==b or a!=b)==False if the coercion
failed (like NaN==NaN is always false).

-Leif

[Gonzalo Tornaria]

On Fri, Apr 23, 2010 at 11:07 PM, Nathan O'Treally <not.r...@online.de> wrote:
> "[...] 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).

I think one of the cases, we argued about it a lot (SD4 and later), is
whether the canonical partial map QQ --> GF(p) should be an
(automatic) coercion or not. This is for the "defined on the whole
domain" part.

Also, the "== doesn't fail" part seems to force this, since it would
be even more awkward to hide the coercion failure.

I'd rather have

sage: 1/3 == GF(3)(1)

raise a ZeroDivisionError, and

sage: 1/4 == GF(3)(1)
True
sage: 1/5 == GF(3)(1)
False

but others didn't agree with me.

You may have a point with the "exact domain" --> "inexact domain"
coercions being partial. I think the reasoning is that as long as you
only coerce from the exact domain into the inexact domain, there
shouldn't be problems. Also, inexact domains are NOT rings, so you
don't require the coercions to be ring homomorphisms.

With respect to NaN, it seems to me sage gets it wrong...

sage: 0.0/0.0 == 0.0/0.0
True


Gonzalo

[Nathan O'Treally]

On 25 Apr., 17:11, Gonzalo Tornaria <torna...@math.utexas.edu> wrote:
> Also, the "== doesn't fail" part seems to force this, since it would
> be even more awkward to hide the coercion failure.

See my last two posts. In addition, Sage behaves different to Python
in many other cases.
(I'd say it is *necessary* to break Python's convention here, i.e.
*don't* hide it, following the Principle of Least Astonishment -- to
mathematicians, not Python programmers -- and staying or getting ;-)
mathematically sound.)

> I'd rather have
>
>     sage: 1/3 == GF(3)(1)
>
> raise a ZeroDivisionError, and

I'd prefer TypeError (or coercion error, "incompatible types", not yet
existent I guess)

>
>     sage: 1/4 == GF(3)(1)
>     True
>     sage: 1/5 == GF(3)(1)
>     False
>
> but others didn't agree with me.

I think I won't either. ;-)

> You may have a point with the "exact domain" --> "inexact domain"
> coercions being partial. I think the reasoning is that as long as you
> only coerce from the exact domain into the inexact domain, there
> shouldn't be problems.

Why? Or did you mean coercing from the *in*exact domain to the exact
one?

-Leif

[Gonzalo Tornaria]

On Sun, Apr 25, 2010 at 1:26 PM, Nathan O'Treally <not.r...@online.de> wrote:
> On 25 Apr., 17:11, Gonzalo Tornaria <torna...@math.utexas.edu> wrote:
>> I'd rather have
>>
>>     sage: 1/3 == GF(3)(1)
>>
>> raise a ZeroDivisionError, and
>
> I'd prefer TypeError (or coercion error, "incompatible types", not yet
> existent I guess)

I think you may be missing my point. I'm not arguing about
incompatible types raising an error instead of returning false. I'm
arguing that there should (IMO) be a canonical coercion

QQ ---> GF(3)

defined in the natural way:

a / b |---> GF(3)(a / b)

and since GF(3)(1 / 3) raises a ZeroDivisionError, it makes more sense IMO.

>>     sage: 1/4 == GF(3)(1)
>>     True
>>     sage: 1/5 == GF(3)(1)
>>     False
>>
>> but others didn't agree with me.
>
> I think I won't either. ;-)

Well, indeed 1/4 == 1 and 1/5 != 1 in GF(3). In fact, I don't think
anybody disagrees with that, and

sage: GF(3)(1/4) == GF(3)(1)
True
sage: GF(3)(1/5) == GF(3)(1)
False

actually works. The point in question is whether this "explicit
conversion" from QQ to GF(3) as above should also be an "implicit
coercion".

>> You may have a point with the "exact domain" --> "inexact domain"
>> coercions being partial. I think the reasoning is that as long as you
>> only coerce from the exact domain into the inexact domain, there
>> shouldn't be problems.
>
> Why? Or did you mean coercing from the *in*exact domain to the exact
> one?

I mean the reasoning in the coercion model of sage is: when you
operate between an exact domain and an inexact domain, it only makes
sense to work in the inexact domain.

Coercing from an inexact domain to an exact domain makes nosense at
all, don't you think?.

Gonzalo

[Robert Bradshaw]

Both have reflexive, symmetric, not-completely-transitive comparison
operators.

>
>> 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".)

I believe this is referring to the orderings, not coercion.

>>
>>> "[...] 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.

Coercion only goes from exact to inexact. The *only* time coercion
goes both ways is when there is a canonical isomorphism.

- Robert

[Robert Bradshaw]

On Apr 25, 2010, at 9:26 AM, Nathan O'Treally wrote:

> On 25 Apr., 17:11, Gonzalo Tornaria <torna...@math.utexas.edu> wrote:
>> Also, the "== doesn't fail" part seems to force this, since it would
>> be even more awkward to hide the coercion failure.
>
> See my last two posts. In addition, Sage behaves different to Python
> in many other cases.
> (I'd say it is *necessary* to break Python's convention here, i.e.
> *don't* hide it, following the Principle of Least Astonishment -- to
> mathematicians, not Python programmers -- and staying or getting ;-)
> mathematically sound.)

Certainly Sage doesn't blindly follow Python conventions for
everything (otherwise we wouldn't have a preparser) but there should
always be good reason to do things differently, at least for
consistencies sake. One reason raising an exception on [in]equality
testing is that it would break hetrogenious lists and dictionaries. In
fact, dictionaries could be broken in a nondeterministic manner.

It may be a good idea to return special values that evaluate to True
and False, but are not actually True and False in this case.

- Robert

[Nathan O'Treally]

On 26 Apr., 19:23, Robert Bradshaw <rober...@math.washington.edu>
wrote:

> On Apr 25, 2010, at 9:26 AM, Nathan O'Treally wrote:
>
> > On 25 Apr., 17:11, Gonzalo Tornaria <torna...@math.utexas.edu> wrote:
> >> Also, the "== doesn't fail" part seems to force this, since it would
> >> be even more awkward to hide the coercion failure.
>
> > See my last two posts. In addition, Sage behaves different to Python
> > in many other cases.
> > (I'd say it is *necessary* to break Python's convention here, i.e.
> > *don't* hide it, following the Principle of Least Astonishment -- to
> > mathematicians, not Python programmers -- and staying or getting ;-)
> > mathematically sound.)
>
> Certainly Sage doesn't blindly follow Python conventions for  
> everything (otherwise we wouldn't have a preparser) but there should  
> always be good reason to do things differently, at least for  
> consistencies sake. One reason raising an exception on [in]equality  
> testing is that it would break hetrogenious lists and dictionaries. In  
> fact, dictionaries could be broken in a nondeterministic manner.

Ouch! :D

But one should never use objects of probably incompatible types as
keys within dictionaries, and a query should cast a "critical type"
*prior* invocation (same for testing membership in lists).
I think it *is* already non-deterministic if you put "equal but
incompatible" keys in a dict and query with a value [of a type] that
*is* "equal and compatible" to *both* stored types/values.

Class inheritence and templates/parametric polymorphism rock...
Perhaps Sage should divorce Python. :-)


Btw, never heard of "not-*fully*-transitive" equivalence relation. ;-)
Horrible!

Cheers,
Leif

[Jason Grout]

On 04/25/2010 10:11 AM, Gonzalo Tornaria wrote:

> With respect to NaN, it seems to me sage gets it wrong...
>
> sage: 0.0/0.0 == 0.0/0.0
> True

See http://trac.sagemath.org/sage_trac/ticket/8074 for a ticket
addressing this and other corner cases in RealField.

(the ticket needs a patch, so if anyone is interested, go for it!)

Thanks,

Jason

[William Stein]

Let's switch to C++! Well, perhaps I should first finish my
Lisp-rewrite of Sage [1].

[1] http://www.mail-archive.com/sage-...@googlegroups.com/msg21687.html

-- William