> Very good. I have seen 2D vectors implemented something like ten times in D > code, so I think it's time to stop this. They need to go in the standard > library: > http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/vec2.d > http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/vec3.d > http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/vec4.d > http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/vectorop.d > Those are pretty useful to me but the use a template mixin (sheduled for deprecation ?)
> Useful math, fast too: > http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/common.d A lot of functions here do not behave well (especially the pow/exp variants) > http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/rounding.d > This is plain ugly stuff, the rounding affect the FPU control word and do not restore it. A good conversion rounding routines should be based on > Half floats, I don't know if they are better than user defined floats of > Phobos2: > http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/half.d half float are useful for 3D because it saves bandwidth with the graphic cards. Less for other purposes. I think common2 allow to use vec3!(half) but lack of implicit conversion makes it less useful than the same design in C++. > Quaternions: > http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/quat.d Those are mostly untested. > > A color module is useful: > http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/misc/colors.d > Python std lib has colorsys: > http://docs.python.org/library/colorsys.html No this one is not good. > > More useful general matrix code: > http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/mat4.d > this stuff is well tested now. > Some very basic geometry code fit for a std.geometry module: > http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/math2d.d > not really usable. > I think all those things (maybe with a little more docs, improvements, > unittests, contracts) are fit to be added to Phobos, because: > - they are basic things that are commonly useful; > - they aren't a lot of code; > - they will be useful ten years from now too, they will not become obsolete; > - I have seen them implemented in user D code several times; > - Some of them are present in my dlibs1 and I have used them several times. > The obvious problem is that all of this is currently - for D1 - not elegant "D-style" - too much assembly - not very reliable (I figured out my 4x4 matrix inversion was false 1 month ago, after using the code for two years) - written for ease of use and conciseness rather than correctness The only part that could be saved is half-floats and perhaps quaternions but this is specific to 3D graphics. There was a discussion a while ago on adding small vectors to D2 and I think it's a good idea. A good small vector type should use the new D2 capabilities like opDispatch for swizzling, be parameterized by size and type, and not be much slower in debug mode. I plan to convert the good stuff to D2 (in fact it already begun) but I'm on a lot of projects right now.
