HaloO,
Doug McNutt wrote:
I really want to use complex numbers, vectors, matrices, and
sometimes quarternions. I really want to be able to define or use
previously defined operators in a way that I learned in the 50's. I
want my compiler to understand when I use vectors in which the
components are complex numbers. I want dot and cross product to work.
I want to be able to multiply a matrix by a vector and get a polite
error message if I try that with impossible arguments.
This is all possible with Perl 6 and its type system, I hope. The
concept of a vector as an element of a vector space e.g. should
be instanciable with complex numbers as "coordinates". That is
the dot product has type :(Vector[::T], Vector[::T] --> ::T). The
type ::T has to do the Num role to be viable for instanciating
Vector. E.g. Vector[Str] should give a compile time type error.
What I think I learned from those two messages is that it's damnably
difficult for a parser to figure out what I'm doing. Perhaps it just
isn't worth while.
If you mean that the parser understands the semantics of your code,
building a parser is indeed in the realm of AI. But for reasonable
operator overloading only two things are needed. Firstly a definition
what exactly constitutes the type Num algebraically. And Secondly a
syntax to make that information machine readable.
The definition of Num should be as minimal as possible. E.g. it should
not contain the requirement to be totally ordered. Well, Num will
actually be ordered and there's a type that does not require it. This
could be called Field. That is it defines the presence of +, -, * and /
as binary operations and unary -. Interestingly there's no unary /.
Other functions like sqrt make use of these operators to iteratively
calculate their result. The only additional requirement for a numerical
type is thus to provide an absolute value function. So as long as a user
defined type Foo provides these five operations the sqrt function should
automatically be callable with it! Note further that a template
implementation of sqrt should automatically yield the result undef for
negative real numbers by detecting diverging absolute value or
occurrence of division by zero while iterating. And of course there can
be optimized implementations for certain types.
I really don't mind informing my compiler in advance about what I
want a variable to be treated as. Typedef {}, Dimension () and the
like are no problem at all. I don't mind. And I think that would also
apply to my scientifically oriented friends.
Yes, type annotation allows the compiler to detect errors that would
otherwise occur at runtime. Not to mention the fact that no optimization
is possible. Well, with the above algebraic approach you can generically
optimize 2*$x/3 from the cost of two multiplications to (2/3)*$x which
costs one runtime multiplication irrespective of the type of $x.
Wouldn't it make life easier for the parser to overload the *
operator into a dot product whenever both arguments have been defined
as vectors or been returned as vectors by a previous operation?
Yes, that is easy doing for the compiler. It simply creates code for
a dynamically dispatched operator. But the algebraically pleasing
approach needs tensor calculus or Clifford algebras to properly define
products of vectors.
One
could even use ** for a cross product since raising to a vector power
is unreasonable.
This is a particularly bad idea that plays in the same league as
using + for string concatenation. Powering is defined through
multiplication. So without a proper product there can hardly be
a power operator. Without that you don't have power series either
and therefore no higher functions like sine or cosine etc. One could
also overload the string replicating x operator to mean cross product
when called with two three or seven dimensional vectors. Much better
than overloading * for the inner product it might be possible to dwell
on the customs to write it as <a,b> if one can avoid the clash with
the non-interpolating string list creator. OTOH the scalar product is
just [+](@a »*« @b). A nice idea is to abbreviate that as *+ or +* akin
to Einstein's summation convention.
Regards, TSa.
--
The Angel of Geometry and the Devil of Algebra fight for the soul
of any mathematical being. -- Attributed to Hermann Weyl
