Chris, As you noticed, I wanted to focus on a point and simplified the code. The point was of an example that struck me as both mathematically beautiful and completely impractical when it comes to decent programming given the languages and tools available today.
What follows is really off topic so anyone not interested may wish to abort here. It helps explain my chosen example. The reality I am behind that function definition was quite a bit weirder. It was part of an exercise in a world where arithmetic as we know it did not exist and had to be bootstrapped into existence. Numbers had to be crafted from nothing starting with the special number zero and a vague function called successor() that created sort of an ordering on what became a set of integers. So ONE (1) was DEFINED as successor(0) and TWO (2) was successor(1) and so on. Of course, they then had to create a function called predecessor() with the abstract and vague concept that it was a sort of inverse of successor() so that for all elements x of the set created from 0 onward, there existed a function called predecessor() such that: predecessor(successor(x)) == x and of course: successor(predecessor(x)) == x So, at this point, negative integers are not quite in existence as nothing defines predecessor(0), at least not yet. The progression was first to create functions comparing any two entities (i.e. integers) sort of like the one I mention above and calling it something like greater_than(a,b) and so on till you built up a logical structure that included set theory and eventually all of arithmetic and beyond. As a philosophical or logical exercise, it indeed is true to suggest that the lesser of a trillion and a quadrillion is whichever is in a sense closer to zero. Closer here is defined as fewer calls to predecessor() before hitting the one known number in this scheme. At that point in the book, expressions like "5 - 3" are not yet defined. Now such attempts to do a step by step building of a mathematical structure from some minimal number of postulates is frequent in mathematics. Think Euclidean Geometry where if don't take the fifth, you may end up in other geometries like Riemannian and Lobachevskian. But in programming, we have other definitions of number and the meaning of "+" uses such definitions. We do not require multiple steps to add things. (Well, we sort of do by adding columns and carrying, but relatively few and often hidden.) We not only do not need multiple additions to do a multiplication, but have extended arithmetic so you can multiple by real numbers instead of just by integers as well as by negative ones or even by complex numbers and other extensions. Ditto for raising numbers to powers not being restricted to an integral number of multiplications. My point is that the Turing tape with a head that can maintain states is a fantasy that can be set up to very laboriously do the simplest things. Just adding two numbers can require something tedious where two areas of the tape contain N and M squares in a row that represent each of the two numbers. The head must march back and forth and copy one square at a time, perhaps to a new place, while marking the old one in a way that guides it to take the next one when it returns, or something equally silly and if you count how many times the head moves one square to the left or right in trying to add a million to a million by making a third region containing 2 million identical squares, good luck. Back to python. One feature I like in python is how flexible some things are. Specifically as an example, an integer can grow as large as you want without special arrangements being made. A dictionary similarly can grow or a list or many things that normally start with a smaller amount of space reserved for it. A dictionary may be created with space for a hundred entries but as it fills, magically, a larger amount of space is created and things are migrated over but everything already pointing to entries does not notice or care. When I used to write programs in languages like C or PASCAL some things that work fine in PYTHON would simply fail. Or, my code would be full of places where I had to check if space was used up, allocate new contiguous space and migrate things and try to sew up any loose ends. Do I want to go backward on many similar aspects where modern computing does a better job? How much time need I waste using a limited language that can, with tons of work, potentially do everything possible if I have to consciously allocate space, mange my own tables keeping track of what is in use, returning resources when no longer using them and so on. Languages with strong typing sometimes got so restrictive and hard to write realistic programs in that they had to be amended with gimmicks allowing you to go around them. Languages where nothing was mutable wasted resources by constantly copying things. It works, but there can be ways to make a different tradeoff. Python is a mixture of new and old. Some argue a few decades is not old given hold FORTRAN is. True. But people considering building a completely new language today might make different choices. But it might take decades before that language had a chance to be as widely used as python and clearly python periodically adjusts to new ideas and evolves. But as we see in the way version 2.x is being gradually let go, not all change can be done without some sacrifice of the old way which was not designed in ways that are quite easy to keep alongside the new. Python is not alone. PERL also has a schism and clearly C has many offspring that are in some ways above C-level. END OF DIGRESSION. -----Original Message----- From: Python-list <python-list-bounces+avigross=verizon....@python.org> On Behalf Of Chris Angelico Sent: Saturday, January 5, 2019 5:43 PM To: Python <python-list@python.org> Subject: Re: the python name On Sun, Jan 6, 2019 at 9:34 AM Avi Gross <avigr...@verizon.net> wrote: > I recall an example from a version of mathematical LISP that I will > rewrite in python for illustration: > > def is_greater(left, right): > if left <= 0 : return False > if right <= 0 : return True > return is_greater(left - 1, right - 1) Possibly: if left <= 0: return is_greater(-right, -left) Otherwise it will give incorrect results for, eg, is_greater(-10, -11) But your point is taken. ChrisA -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
