Re: 3d vector struct
On Friday, 7 February 2014 at 04:03:58 UTC, Marco Leise wrote: Am Mon, 03 Feb 2014 22:01:14 + schrieb Stanislav Blinov stanislav.bli...@gmail.com: Return-by-value being optimized as a move might be one more reason why you would like to use slices... 3 doubles is only one machine word more than an array slice and there are no indirections, allocations and length attribute to deal with (which is always 3 here). I know. I also know that people making games are obsessed with performance :) And, where there's 3d vector, there would also be 4d vector and matrices...
Re: 3d vector struct
On Friday, 7 February 2014 at 10:50:49 UTC, Stanislav Blinov wrote: I know. I also know that people making games are obsessed with performance :) And, where there's 3d vector, there would also be 4d vector and matrices... Wouldn't it make more sense to aim for a float SIMD implementation instead then? :P
Re: 3d vector struct
On Friday, 7 February 2014 at 21:37:26 UTC, Casper Færgemand wrote: On Friday, 7 February 2014 at 10:50:49 UTC, Stanislav Blinov wrote: I know. I also know that people making games are obsessed with performance :) And, where there's 3d vector, there would also be 4d vector and matrices... Wouldn't it make more sense to aim for a float SIMD implementation instead then? :P It may well be :D
Re: 3d vector struct
Am Mon, 03 Feb 2014 22:01:14 + schrieb Stanislav Blinov stanislav.bli...@gmail.com: Return-by-value being optimized as a move might be one more reason why you would like to use slices instead of variables to store coordinates (since that would mean just moving a pointer and a size_t), but that might have to wait until custom allocators finally arrive. 3 doubles is only one machine word more than an array slice and there are no indirections, allocations and length attribute to deal with (which is always 3 here). -- Marco
Re: 3d vector struct
On Monday, 3 February 2014 at 20:10:59 UTC, Brenton wrote: 6) Any other comments or suggestions? I know that the I'm learning the language factor plays a huge role, but after you are done studying your vector implementation, I think you could forget about it and use the ones provided by other libraries :P If you didn't knew about it, DUB is a marvelous software that gives you quick access to lots of nice libraries. EG: one you might be interested in is http://code.dlang.org/packages/gl3n Another one *might* be gfm: http://code.dlang.org/packages/gfm I'm also wondering where the hell did I put my raytracer code I did ages ago...
3d vector struct
Hi, I'm just getting to know D and so am hoping that someone more
experienced with the language could review this 3d vector struct
and my comments below. I'm planning on building a little ray
tracer in the next week or so :)
struct Vector3d {
double x = 0, y = 0, z = 0;
void normalize() {
double scale = 1.0 / (x * x + y * y + z * z);
x *= scale; y *= scale; z *= scale;
}
double dot(in Vector3d other) inout {
return x * other.x + y * other.y + z * other.z;
}
Vector3d cross(in Vector3d other) inout {
const Vector3d result = {
y * other.z - z * other.y,
z * other.x - x * other.z,
x * other.y - y * other.x
};
return result;
}
}
1) I initialize the vector to a null vector, not nans
2) The dot and cross are inout methods, i.e. available for
mutable, const, and immutable objects. There is no reason to
declare inout methods as being const.
3) The dot and cross methods take an input in argument. This
allows the compiler to choose between passing the parameter by
const value or const reference. I read somewhere that in and
scope have not yet been implemented yet and that I should use
const ref instead?
4) Is it advisable for the cross method to return by value? In
C++, I would declare this method as inline and in a header file.
Can I trust D to inline away this inefficiency? Perhaps I should
pass in the result as a ref or out parameter (although I
don't require the vector to be initialized here)? Is there a
more efficient way to do this?
5) I notice that a lot of other people online prefer using fixed
arrays not structs for Vectors in D, why?
6) Any other comments or suggestions?
Re: 3d vector struct
Brenton: 1) I initialize the vector to a null vector, not nans Why? 2) The dot and cross are inout methods, i.e. available for mutable, const, and immutable objects. There is no reason to declare inout methods as being const. But I suggest to add pure/nothrow. 3) The dot and cross methods take an input in argument. This allows the compiler to choose between passing the parameter by const value or const reference. This is not true. In means const scope, so it's always passed by value. Bye, bearophile
Re: 3d vector struct
5) I notice that a lot of other people online prefer using
fixed arrays not structs for Vectors in D, why?
It does make some calculations more straightforward. For example
I have code that calculates distance between points as follows:
double euclideanDistance( double[] pt1, double[] pt2 ) in {
assert( pt1.length == pt2.length );
} body {
return sqrt(
0.0.reduce!( (sum,pair) = sum +
(pair[0]-pair[1])^^2)(zip(pt1, pt2))
);
}
Now a point is not a vector, but they are similar in many
respects. That fact that I use an array for my points makes such
calculations possible. Furthermore you can always add methods to
your struct that let users access the appropriate indices as x, y
and z. If you use UFCS (I haven't yet) you could make these
appear to user code just as if you had named your variables x, y,
and z.
Finally, maybe as some point you want to support vectors of
varied dimension ... it then becomes easier to port your struct.
6) Any other comments or suggestions?
Once you have your design more or less settled you should make it
generic (if not for practical reasons just for fun and
experience). You likely want your type to support only
floating-point values, so you can see here how types can be
restricted to FP (see line 50).
https://github.com/craig-dillabaugh/phobos/blob/master/std/complex.d
Thats my fork of the Phobos libraries, likely a bit out of date,
but I was too lazy to look up the prope URL.
Re: 3d vector struct
On Monday, 3 February 2014 at 20:10:59 UTC, Brenton wrote:
double dot(in Vector3d other) inout {
return x * other.x + y * other.y + z * other.z;
}
Vector3d cross(in Vector3d other) inout {
const Vector3d result = {
y * other.z - z * other.y,
z * other.x - x * other.z,
x * other.y - y * other.x
};
return result;
}
}
Shouldn't these functions be non-member:
double dot(in Vector3d one, in Vector3d other) {}
Vector3d cross(in Vector3d one, in Vector3d other) {}
No one Vector3d is more special in these functions, so treat them
equal.
Re: 3d vector struct
On Monday, 3 February 2014 at 20:10:59 UTC, Brenton wrote: 4) Is it advisable for the cross method to return by value? In C++, I would declare this method as inline and in a header file. Can I trust D to inline away this inefficiency? Perhaps I should pass in the result as a ref or out parameter (although I don't require the vector to be initialized here)? Is there a more efficient way to do this? Seeing as previous responses skipped over this point: Yes, return by value. The compiler will optimize that for you by moving (not copying) the result. Return-by-value (and optimizations involved) is one of the stronger things in D that IIRC was there even before e.g. C++11 with its move semantics. Performing a move means that it is absolutely possible for clever compiler to even construct the value in-place, but I'm not sure if any of existing D compilers do that as of yet. Return-by-value being optimized as a move might be one more reason why you would like to use slices instead of variables to store coordinates (since that would mean just moving a pointer and a size_t), but that might have to wait until custom allocators finally arrive.
