<div class="gmail_quote">On 23 November 2011 21:35, 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">On Wed, 23 Nov 2011 18:20:35 +0100, Manu <<a href="mailto:turkeyman@gmail.com" target="_blank">turkeyman@gmail.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Oh wow, awesome! :)<br>
I'm always surprised by the state of the D libraries.. There's already lots<br>
of awesome obscure things are in there, but also completely obvious major<br>
features blatantly missing :)<br>
</blockquote></div>
There are some real gems, e.g. findRoot.<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
So how about a DCT? Image/video processing... Perhaps a simple adaptation<br>
of FFT?<br>
<br>
</blockquote></div>
Too many different DCTs, too many different needs I'd say.</blockquote><div><br></div><div>Well... hardware accelerated video decoders have boiled it down to a standard set of functions, so it's obviously not an endless amount, and I'd suggest someone else (who wrote those apis) has already done the work of identifying the ones that allow you to process most modern formats.</div>
<div> </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">
And it's not clear to me at all whether that class will work with fixed<br>
point data... That's extremely important for a class like this (but<br>
granted, not really in line with D's take on numeric precision).<br>
Almost all audio and video data is in fixed point. Int->float conversion is<br>
very expensive on many platforms.<br>
<br>
</blockquote></div>
Too specialized. Given the obscurity of doing a fixed point FFT, the actual<br>
implementation will be very tough, the log2N gain of calculating intermediate<br>
results is directly opposed to precision.<br></blockquote><div><br></div><div>Obscurity? MP3 isn't obscure. I'm sure there are bunches of reference implementations to draw from.</div><div>But again, I couldn't use the standard library on a PSP or iPhone for instance if there is no fixed point version. And I'm left in a world where I have to roll my own, just like I always do in C with respect to the the CRT, because the standard library just isn't thorough >_<</div>
<div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
It would be interesting to offer vectorized 'Integral <-> Float' conversions.<br></blockquote><div><br></div><div>No reason not to. If D ever gets a hardware vector type, I'll start writing that library the same day...</div>
<div>That doesn't address this issue though, I'm concerned with a lot of architectures that either don't have float units, or extremely slow float processing. Hand held gaming systems and phones.</div><div>I do think fixed point versions of these data shovelling DSP functions is quite important to many people, but I'm sure 3rd party libs will come.</div>
</div>