• ponce (6/6) Sep 04 2010 Hi,
• ponce (2/2) Sep 20 2010 Vibrant has been open source'd (again):
• bearophile (38/40) Sep 20 2010 Very good. I have seen 2D vectors implemented something like ten times i...
• Johan Granberg (5/65) Sep 21 2010 I second that, if we should learn something from looking at 3D libs writ...
• Don (7/44) Sep 21 2010 Actually, I don't see any functions which are faster than std.math.
• #ponce (3/9) Sep 21 2010 I wrote that years ago because Pascal didn't have those ;)
• so (20/33) Oct 09 2010 You know vectors are one of the hardest things to implement if you want ...
• #ponce (20/53) Sep 21 2010 This is plain ugly stuff, the rounding affect the FPU control word and d...
• #ponce (1/1) Sep 21 2010 Errata: A good rounding routine should be based on FISTTP which avoid me...
• Don (4/9) Sep 21 2010 My guess is that what you really want, is pack-and-unpack routines for
• #ponce (7/10) Sep 21 2010 What I would like is the ability to take a custom type and make a small ...
• #ponce (4/6) Sep 21 2010 In C++ I can make the half type and create vec3h with
• Don (4/16) Sep 21 2010 My friend Google found some SSE2 code which does float->half in 3.5

ponce <contact gamesfromILOVESPAMmars.fr> writes:

Hi,

Do you remember Vibrant, the abstract arena shooter I wrote last year?
The game has been updated several times since, bringing many enhancements.

http://www.gamesfrommars.fr/vibrant

Cheers,
ponce

ponce <contact gamBOOMesfrommars.fr> writes:

Vibrant has been open source'd (again):
http://bitbucket.org/ponce/vibrant

bearophile <bearophileHUGS lycos.com> writes:

ponce:

 Vibrant has been open source'd (again):
 http://bitbucket.org/ponce/vibrant

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

Useful math, fast too:
http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/common.d
http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/rounding.d

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

Quaternions:
http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/quat.d

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

More useful general matrix code:
http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/mat4.d

Some very basic geometry code fit for a std.geometry module:
http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/math2d.d

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.

Advanced modules for computational geometry, colorimetry, statistics, etc, are
beyond the scope of Phobos2. But short, simple to use, frequently useful
functions are fit for the standard library. So I think there are modules that
should be added to Phobos:

std.geometry
std.color
std.quaternions
std.halffloats
std.vectors
std.combinatorics (or std.comb) for permutations, combiantions, subsets, and
few more.
Plus more code for std.math and std.array (for the matrix code) and
std.numerics.

Eventually I'd like to write a basic std.combinatorics module for Phobos2.

Bye,
bearophile

Johan Granberg <lijat.meREM OVEgmail.com> writes:

bearophile wrote:

 ponce:
 
 Vibrant has been open source'd (again):
 http://bitbucket.org/ponce/vibrant

 
 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
 
 Useful math, fast too:
 http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/common.d
 http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/rounding.d
 
 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
 
 Quaternions:
 http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/quat.d
 
 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
 
 More useful general matrix code:
 http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/mat4.d
 
 Some very basic geometry code fit for a std.geometry module:
 http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/math2d.d
 
 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.

I second that, if we should learn something from looking at 3D libs written
in c++ it is that they all reimplement vectors and that this make it a pain
to move code betwean them because of incompatible vector implementations.

So adding this would be a huge step forward for phobos.

 Advanced modules for computational geometry, colorimetry, statistics, etc,
 are beyond the scope of Phobos2. But short, simple to use, frequently
 useful functions are fit for the standard library. So I think there are
 modules that should be added to Phobos:
 
 std.geometry
 std.color
 std.quaternions
 std.halffloats
 std.vectors
 std.combinatorics (or std.comb) for permutations, combiantions, subsets,
 and few more. Plus more code for std.math and std.array (for the matrix
 code) and std.numerics.
 
 Eventually I'd like to write a basic std.combinatorics module for Phobos2.
 
 Bye,
 bearophile

Don <nospam nospam.com> writes:

bearophile wrote:
 ponce:
 
 Vibrant has been open source'd (again):
 http://bitbucket.org/ponce/vibrant

 
 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

Definitely we need vectors in Phobos.

 
 Useful math, fast too:
 http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/common.d
 http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/rounding.d

Actually, I don't see any functions which are faster than std.math. 
std.math.exp2() is *much* faster than common.pow2() (one slow 
instruction, vs five!!!) And exp2 sets the flags correctly.
expi() is faster than sincos().

 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
 
 Quaternions:
 http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/quat.d
 
 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
 
 More useful general matrix code:
 http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/mat4.d
 
 Some very basic geometry code fit for a std.geometry module:
 http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/math2d.d
 
 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.

I agree. There's some useful stuff here.

#ponce <contact gamCOOKIESesfrommars.fr> writes:

 
 Actually, I don't see any functions which are faster than std.math. 
 std.math.exp2() is *much* faster than common.pow2() (one slow 
 instruction, vs five!!!) And exp2 sets the flags correctly.
 expi() is faster than sincos().
 

I wrote that years ago because Pascal didn't have those ;)
I refused to use std.math function because they were taking a real argument. is
that optimized ?

I've strong NIH syndrom. ;)

so <so so.do> writes:

On Tue, 21 Sep 2010 11:59:51 +0300, Don <nospam nospam.com> wrote:

 bearophile wrote:
 ponce:

 Vibrant has been open source'd (again):
 http://bitbucket.org/ponce/vibrant

  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

 Definitely we need vectors in Phobos.

You know vectors are one of the hardest things to implement if you want  
everything. In D2 it should possible to have it all!

My ideal vector design :

- one struct for all dimensions.
- swizzling
- after a limit (dimension) you have a choice to use either unwrapping or  
plain for.
- avoid temporaries as much as possible.
- policy to use sse. etc...

Can't think of anything more now.

First 3 is very easy to implement, 4 wasn't possible on C++ because of  
aliasing, didn't give much of a thought in D, 5 also shouldn't be that  
hard.

alias vector!(3, float) vec3;
alias vector!(4, float) vec4;
...

There we solved everything! in theory :)

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

#ponce <contact gamCOOKIESesfrommars.fr> writes:

 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.

#ponce <contact gamCOOKIESesfrommars.fr> writes:

Errata: A good rounding routine should be based on FISTTP which avoid messing
with the rounding mode entirely.

Don <nospam nospam.com> writes:

#ponce wrote:
 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++.

My guess is that what you really want, is pack-and-unpack routines for 
whole arrays.  half[0..n*2] <--> float[0..n]

It's a fascinating problem. I bet it can be done very efficiently.

#ponce <contact gamCOOKIESesfrommars.fr> writes:

 My guess is that what you really want, is pack-and-unpack routines for 
 whole arrays.  half[0..n*2] <--> float[0..n]

What I would like is the ability to take a custom type and make a small vector
out of it.

alias vec3<half> vec3h;

but as D doesn't have conversion function like C++, here is how to create such
small vectors :

vec3h a = vec3h(cast(half)1.f, cast(half)2.f, cast(half)3.f);

Granted, hardly a problem and dropping conversion functions is a gain.

 It's a fascinating problem. I bet it can be done very efficiently.

I heard stories of half-float => float conversions being the bottleneck while
filling mapped GPU buffers. 
The other one being using anything else than memcpy.

#ponce <contact gamCOOKIESesfrommars.fr> writes:

 vec3h a = vec3h(cast(half)1.f, cast(half)2.f, cast(half)3.f);

In C++ I can make the half type and create vec3h with

vec3h a = vec3h(1, 2.f, 3);

because so much thing are implicit.

 I heard stories of half-float => float conversions being the bottleneck

I meant float -> half-float

Don <nospam nospam.com> writes:

#ponce wrote:
 vec3h a = vec3h(cast(half)1.f, cast(half)2.f, cast(half)3.f);

 
 In C++ I can make the half type and create vec3h with
 
 vec3h a = vec3h(1, 2.f, 3);
 
 because so much thing are implicit.
 
 I heard stories of half-float => float conversions being the bottleneck

 
 I meant float -> half-float
 

My friend Google found some SSE2 code which does float->half in 3.5 
cycles. Not too bad.

http://www.devmaster.net/forums/showthread.php?t=10924