William Stein schrieb:
On Fri, Apr 23, 2010 at 10:15 AM, bb <bblo...@arcor.de
<mailto:bblo...@arcor.de>> wrote:
Simon King schrieb:
Hi!
On Apr 23, 2:05 pm, bb <bblo...@arcor.de
<mailto: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!
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)
<http://en.wikipedia.org/wiki/Python_%28programming_language%29>
--
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
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!
--
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
