Hi Nasos,
in fact I had a look afterwards on the operator we have, but didn't see anything very promising. Well, I think your interface is nice like that and we will put some BIG letters in the documentation for people to be careful when writing code. Anyway, it's way better than a lot of things I saw in many libraries.
As for the documentation, I am documenting everything else in ublas with doxygen, so if you want, you can write doxygen comments in your code. If you're not familiar with doxygen, let me do it, it will be a pleasure.
I will release the new "code" with doxygen commands little by little in the SVN. The code will be a little bit bigger due to that but I am documenting everything single piece of ublas.
Cheers,
David
David,
I would love to have operators acting as you propose. I am afraid though that we will not be able to overload them, since their operation on primitives supersedes other overloads. I was thinking of ways of overcoming that, or using other operators, but I am relatively pessimistic on whether this can happen in a sound way.
If you spot something in http://en.wikipedia.org/wiki/Operators_in_C_and_C%2B%2B, I will give it a shot.After work today I will post examples showing the interface for people to comment on. I suppose after this cycle there will be a final version for examples to be included in the documentation.
> I will need some examples to write the documentation to all of that too and include it with the one I'm writing right now.
Best
Nasos
Date: Mon, 29 Mar 2010 09:38:07 +0200
From: david.bellot@gmail.comHi Nasos,
the implementation looks very promising. A few quick thoughts before going to work today:
> "automatic" choice seems to be dangerous to me.)
it is kind of dangerous but this is what most of the people expect. Maybe another "marker" could help but it means overloading 2 operators, like for example mat << 1 ,2 ,3 % 12,14,16 % 33,44,55; So that the code will not be too much verbose.
If I remember the operator & is used in LateX to separate lines in array ? (don't remember exactly). But that would be a "common" sign for users. I'm always in favour of simple writings when developing numerical code.
That's all cosmetic of course: you can even think about wrting stuffs like
mat =
1 | 2 | 3 ||
6 | 5 | 4 ||
7 | 8 | 9;
> - Where do you think this should be added? As a separate header file, or included in vector_ and matrix_ expression headers?
Better to have this function attached directly to vector_ and matrix_. One thinks about its immediate availability when programming.
I will need some examples to write the documentation to all of that too and include it with the one I'm writing right now.
Anyway, that all sounds very good and nice.
Thanks.
David
--
David Bellot, PhD
david.bellot@gmail.com
http://david.bellot.free.fr
Hotmail: Trusted email with powerful SPAM protection. Sign up now.
_______________________________________________
ublas mailing list
ublas@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: david.bellot@gmail.com