the python name

[Avi Gross]

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.net at python.org> On
Behalf Of Chris Angelico
Sent: Saturday, January 5, 2019 5:43 PM
To: Python <python-list at python.org>
Subject: Re: the python name

On Sun, Jan 6, 2019 at 9:34 AM Avi Gross <avigross at 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