[Unlurk] FWIW I would really like to see this implemented as I write scientific code every day and would love to use Vala/Genie instead of C++ :-)
Cheers, Conrad On Tue, 2009-03-24 at 22:06 -0400, Yu Feng wrote: > Would it be reasonable to write some Vala compiler modules that > implements these types internally? > > The implementations can then be shared across the entire vala user base. > Yet these modules can be release under different packages, eg, > vala-ccode-currency, vala-ccode-vector, vala-ccode-complex ... > > Also with these backend modules, one can have far more > optimizations(assembly, sse, implicit parallism..) than those achievable > within vala itself. > > > Yu > > > On Tue, 2009-03-24 at 16:22 -0700, William Swanson wrote: > > It seems useful to catalog the use-cases for operator overloading at > > this point, since folks are missing the big picture by focusing on > > only one or two: > > > > --- Non-standard number representations --- > > * Arbitrary-sized large integers > > * Fractional (int/int) number represtations > > * Base-10 floats for rounding issues > > * Arbitrary-precision floating-point numbers > > * 16-bit floats for OpenGL textures > > These types would implement the four basic operators (+ - * /) as well > > as modulo (%) for the integer types. Xavier Bestel says, "Math > > operators should be limited to > > purely math operations, on integers and reals." Well, Xavier, these > > *are* integers and reals, and they want operator overloading. > > > > --- Complex numbers --- > > Like the real numbers, these numbers have well-defined versions of the > > four basic operators (+ - * /). There is no ambiguity or lack of > > clarity when someone says "complex1 + complex2" or "complex1 / > > complex2". Many programming languages even have complex numbers as a > > built-in type, including C99. > > > > --- Quaternions --- > > Quaternions are complex numbers generalized into four dimensions. As > > with complex numbers, all four basic operators (+ - * /) are > > well-defined. Quaternions are used to represent rotations in 3D, among > > other things. > > > > --- Vectors --- > > Vectors can come in fixed sizes like <x, y> to <x, y, z, z>, or they > > may be arbitrarily sized. Depending on the application, vectors can be > > represented with integers, floats, or doubles. In every case, the + > > and - operators perform member-wise addition, and the * and / > > operators perform scaling. Vectors also support other operations like > > the dot product and cross product, but those should be implemented as > > named functions as Frederik says earlier. > > > > --- Matrices --- > > Like vectors, matrices come in all sizes and types. Like vectors, the > > + and - operators operate member-wise, while the * and / operators > > perform scalar multiplication. In addition, matrices define a * > > operator that works on any two properly-sized matrices. The other > > matrix operations like transpose and inverse would be named functions. > > --- > > > > These are the applications I can think of, and I am sure there are > > others. Each of these use-cases is a mathematical object, and the > > operators that apply to these objects are well-established by > > mathematical convention. Any programmer using these entities already > > has the mathematical background to know how the operators should > > behave. If not, they can always read the documentation. Named > > functions, on the other hand, make reading documentation mandatory. Is > > the member-wise addition function called "plus," "add," "add_to," or > > what? Which of these functions modifies the original object, and which > > does not? With operator overloading, the answer is simply "+" or "+=". > > Isn't saving a trip to the documentation the nature of clear, > > self-explanatory code? > > > > I hear a lot of strong terms like "nightmarish" and "horror story" in > > relation to operator overloading, but not a lot of concrete examples > > to back them up. I agree that using << for IO is ugly, but that is > > hardly justification for eliminating the entire feature. I suspect the > > problem isn't operator overloading itself, but C++'s excessively > > flexible nature. A locked-down implementation that supports only the > > basic math operators (+ - * / %), forces those operators to be > > "const" to eliminate side effects, and forces the assignment operators > > (+= -= *= /= %=) to behave predictably would fully support the use > > cases above and would not leave much room for "nightmarish horror > > stories". This isn't C++, where you can overload the [] or -> > > operators to shoot yourself in the foot. > > > > -William Swanson > > _______________________________________________ > > Vala-list mailing list > > Vala-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/vala-list -- ----------------------------------------------------------------------------- Conrad D. Steenberg Ph.D. conrad.steenb...@caltech.edu Scientific Software Engineer http://clarens.caltech.edu Pierce Bio-Engineering Lab Mail Code 114-96 California Institute of Technology Pasadena, CA, 91125 _______________________________________________ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
