An OOP view of the "number" concept
Forwarding from Math Forum: more on how I think it pays students nowadays to look at numbers differently, now that they're consistently implemented as instances of a type which includes methods and attributes per OOP. Context: http://mathforum.org/kb/message.jspa?messageID=5657989&tstart=0 Kirby ==== Re: Operations: binary vs unary Posted: Apr 19, 2007 12:38 PM In my math courses we consider a number's operational capabilities to be a part of its "type" or "class". Whereas we have the standard +, -, /, * operators to play with, it's also possible to invoke these operations using a consistent "dot notation" -- which I consider a part of contemporary mathematics (characteristic of several self-executing MNs [1]). Using Python... IDLE 1.2
3 .__neg__() # unary op takes no argument -3 -------3 -3 3 .__add__(5) 8 3 .__sub__(5) # binary op expects an argument -2
Of course this still looks strange to people who grew up in the 1900s (as I did) and think in a different paradigm. In the old way of thinking, operations were not included in our type definitions. The idea of "adding" was somehow independent of the set theory definitions (since dispensed with) of integers for example. Nowadays, a number such as the integer 1 has "guts", just as a string does.[2] Kirby Urner Saturday Academy Silicon Forest, Oregon [1] MNs = math notations, per Kenneth Iverson's treatise thereon: http://www.cacs.louisiana.edu/~mgr/404/burks/language/apl/camnweb/camn.htm [2] 'OOP Meets Algebra, Suggesting New "Ways of Looking" ' by Kirby Urner First posted: Feb 24, 1999 http://www.4dsolutions.net/ocn/oopalgebra.html
Hi Kirby,
3 .__add__(5)
3 .__add__(5)
8
Of course this still looks strange to people who grew up in the 1900s (as I did) and think in a different paradigm.
In the old way of thinking, operations were not included in our type definitions. The idea of "adding" was somehow independent of the set theory definitions (since dispensed with) of integers for example.
I still recall the moment, when - while learning some smalltalk (after I knew Python) - one expression really impressed me: <smalltalk> 2 sin </smalltalk> Because in smalltalk nearly all expressions are message sends of the syntax receiver message this would mean the same as 2.sin() in a python-like-syntax. So 2 is an object, which you can ask to give you its sine-value. This is classical smalltalk-80. "Everything is an object" means more to me since that moment. It is interesting how they do this in smalltalk, for instance, you can easily put different kinds of number types on the left side- like "2.0 sin" gives you the same value for a float type. Actually in Python, dot-notation breaks down with this case: 2.0.sin() ??? I just noticed that. Perhaps one of the reasons smalltalk doesn't use the dot. Greetings Christian
Actually in Python, dot-notation breaks down with this case: 2.0.sin() ??? I just noticed that. Perhaps one of the reasons smalltalk doesn't use the dot.
Greetings
Christian
The way I look at it, Python ints and floats "out of the box" have a more limited repertoire than in Smalltalk apparently.
dir(2.0) ['__abs__', '__add__', '__class__', '__coerce__', '__delattr__', '__div__', '__divmod__', '__doc__', '__eq__', '__float__', '__floordiv__', '__ge__', '__getattribute__', '__getformat__', '__getnewargs__', '__gt__', '__hash__', '__init__', '__int__', '__le__', '__long__', '__lt__', '__mod__', '__mul__', '__ne__', '__neg__', '__new__', '__nonzero__', '__pos__', '__pow__', '__radd__', '__rdiv__', '__rdivmod__', '__reduce__', '__reduce_ex__', '__repr__', '__rfloordiv__', '__rmod__', '__rmul__', '__rpow__', '__rsub__', '__rtruediv__', '__setattr__', '__setformat__', '__str__', '__sub__', '__truediv__']
2.0 .__add__(3.0) # normally 2.0 + 3.0 5.0
2.0 .__neg__() # normally -2.0 -2.0
Once we import math, then we get these external functions, which don't actually reach into the guts of the number type for an answer. The native types are knowledgeable, but not omniscient (likewise with user-defined). Kirby
Hi,
The way I look at it, Python ints and floats "out of the box" have a more limited repertoire than in Smalltalk apparently.
Limited for a reason, see below.
Once we import math, then we get these external functions, which don't actually reach into the guts of the number type for an answer. The native types are knowledgeable, but not omniscient (likewise with user-defined).
Right, so there is also a virtue in Pythons way of number-objects _not_ knowing about sin(): smalltalk's smart numbers only work, because everything (every method/function) is contained in one image; mathematical functions are methods defined somewhere in the Number class hierarchy of the smalltalk system. And you always have everything around, if you use it or not. Contrast this with Python, where you start with a limited set of builtin functions and object types and import other stuff only when needed. You save your work with little files (modules) and use rather less ressources than a full smalltalk image. Much more lightweight approach. Certainly one of the most important reasons I prefer Python, even when I admire the uniformity of smalltalk objects: the granularity of module files and a small efficient runtime environment running fast enough everywhere. Christian
participants (2)
-
Christian Mascher -
kirby urner