<div class="gmail_quote">On 5 February 2012 02:17, Martin Nowak <span dir="ltr"><<a href="mailto:dawg@dawgfoto.de">dawg@dawgfoto.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
First criticism I expect is for many to insist on a class-style vector<br>
library, which I personally think has no place as a low level, portable API.<br>
Everyone has a different idea of what the perfect vector lib should look<br>
like, and it tends to change significantly with respect to its application.<br>
<br>
</blockquote>
<br></div>
- Thing like toDouble, toFloat don't map to vectors if they change the number of elements.<br></blockquote><div><br></div><div>You'll notice my comment above those functions, I refer that this is a perfect opportunity for multiple return values, and short of that, maybe I'll remove the functions, or change them in some way.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> - What's getX(byte16), swizzling makes sense for float4/double2, not sure about the rest.<br></blockquote>
<div><br></div><div>I agree that's not clear, I had intended to add some asserts limiting those to 2-4d vectors, or actually change the names of those functions completely.</div><div>They really just call through to a broadcast swizzle!().</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> - Using named free functions for operands (or, complement, neg) is overly verbose.<br></blockquote><div>
<br></div><div>Is it possible to implement global operators like this? I think it's important to keep the functions there for those anyway... it offers explicit versioning, and some architectures may have non trivial implementations for those functions (for instance, neg requires 0-x on some hardware)</div>
<div><br></div><div>The operators are still supported if you prefer to use them, obviously.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So indeed my proposal is to prefer GLSL-like syntax.<br>
<br>
// construction conversion<br>
auto f = float4(1.0, 2.0f, 3, 4);<br>
auto f2 = v.yxzw; // using opDispatch<br></blockquote><div><br></div><div>I planed to do this, but so far I've spent a lot of time with swizzle!(). Getting that right is tricky, and that's the meat of all permutation operations. Everything else will be layers of prettiness over that.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">auto d = double2(v.wy);<br>
auto d = double2(v.get!(0), v.get!(1)); // probably someone knows a trick for compile time indexing (v[0])<br></blockquote><div><br></div><div>swizzle!() already does this work (compile time), I'll be wrapping more handy helpers around that when it's complete.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
auto f3 = float4(1.0, d, 2);<br>
double d = f3.z;<br></blockquote><div><br></div><div>This API will never offer this operation. It is the single worst violation of the API, and the fastest way to make the whole implementation pointless.</div><div>Swapping register types is often the worst hazard a CPU is capable of.</div>
<div><br></div><div>Casting to scalar will only be implemented with explicit functions, and performance hazards detailed in the documentation, which hopefully people will read, since they'll need to look up the function to use it ;)</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">// a lot of operands can be mapped and are already<br>
f |= f2;<br>
f = f & ~f2;<br></blockquote><div><br></div><div>Sure, what's your point? You'll see I use them all over the place.</div><div>That said, encouraging usage of functions like andn() in this case will result in an optimisation on some hardware which the compiler is probably not capable of without specific tweaking by someone who knows what they're doing.</div>
<div>It's really bad form to depend on an optimiser to fix my code, when you could have just given it the appropriate instruction right up front. Especially true for an open source project like D where contributions of that sort are unreliable, and the number of people qualified to improve the optimiser in that way are very low.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I feel this flat API is easier to implement, maintain, and understand, and<br>
I expect the most common use of this lib will be in the back end of peoples<br>
own vector/matrix/linear algebra libs that suit their apps.<br>
<br>
</blockquote></div>
Phobos should provide at least basic vector and matrix implementations.<br>
</blockquote></div><br><div>It will, but that's a separate (higher level) module, although this provides most foundational vector operations.</div><div>I want to keep this level primitive and simple. If there's any dispute over the implementation of this layer, just imagine the dispute when trying to implement matrix and quaternion libs... they can be so context specific. Consider the differences between realtime and scientific uses... This library can't really go wrong at that level, but there's a LOT more to consider when working on that layer.</div>