Choosing a programming language as a competitive tool

[Alex Martelli]

"Andrew Dalke" <dalke at acm.org> wrote in message
news:9d6k29$p5e$1 at slb4.atl.mindspring.net...
    ...
> Alex:
> > Presumably by projecting it onto a space of lower dimensionality, or
> > embedding it into a space of higher dimensionality.
    ...
> That doesn't work because in Python (2, 4) is not equivalent to
> (2, 4, 0).

Neither is it "equivalent" in geometry -- you need to define what
2D plane (or other surface) in 3-space that (2, 4) lies on, before
you can define what 3-vector the 2-vector (2,4) is equivalent to.

> If you want to talk about its embedding in some sort
> of vector space you'll need another, perhaps boolean space to
> define which axes of the infinite space are used to define this
> finite subspace.

"Boolean"?  "finite"?  Seems we're talking at cross-purposes,
because I don't see where booleans or finiteness enter the
picture.


> Also, if (x, y) really is a vector in a vector space then

...then depending on what definition of "vector space" you
like, the algebraic structure x and y come from must be a
ring (or some other kind of abstract algebraic structure), just
to start with.  But, as you know, Python does not constrain
the types or classes of either x or y.  So, a _subset_ of the
set of (x,y)s that Python lets you express will be your vector
space -- those where x and y come from the right underlying
'scalar' ring (or field, or whatever).  (Other subsets will be
2D vector spaces over all other 'scalar' rings/fields/etc that
you can represent in Python).

> '+' must be defined so (x1, y1) + (x2, y2) is also a vector
> in the vector space and is commutable, so it equals

It need not be _notated_ '+', nor need it be infix, of course,
so "lambda x, y: map(operator.add, x, y)" is an acceptable
'+' for these purposes -- for all those underlying rings where
operator.add is the ring's addition operator.  More generally,
you need to parameterize the ring on its addition operator,
and that parameter will enter the definition of the vector
space's consequent addition operator.

> (x2, y2) + (x1, y1).  This doesn't work if x1 and x2 are strings,

Strings are not a ring under '+', are they?  Give me an operator
under which the members of the underlying set _are_ a ring,
and you'll get the addition operator for the vector space by a
simple application of the above (suitably parameterized).


> so Python lists/tuples really have nothing to do with vectors
> in the math sense.

Wrong: they're just more general because Python does not
statically constrain types.  If you think "vectors in the math
sense", or any other abstract-algebra concept, is defined by
the syntax sugar of the operators on it, then you may be
missing the 'abstract' part:-).  Of course, the things we do
with computers generally only _approximate_ the real maths
abstractions we're trying to handle -- since we _are_ using
finite and discrete mappings of infinite and often continuous
abstractions.  I don't think the lack of static type constraints
makes Python any farther from "vectors in the math sense"
than, say, C++, any more that does one's ability in C++ to
overload ::operator+ on std::vector<double> arguments so
that you can use the infix-'+' with the semantics of the
addition operator for the vector space.


> Also, addition of two lists/two tuples doesn't correspond to
> any addition of vectors in a vector space.

The Python operator notated with infix '+' between sequences
doesn't, I agree.  But concrete notation has little to do with
the applicability of abstract algebra concepts here, either.


Alex