Log in

No account? Create an account

Previous Entry | Next Entry

Today's Lesson

It doesn't pay not to use the right mathematical operator, just because it's slow. Or rather, if you've fudged the math for speed, and your results are crap, maybe you should try using the right math, rather than bemoaning how your algorithm sucks. :-P

Or maybe I should just fall back on the old standard, get it working, *then* optimize.


( 9 comments — Leave a comment )
Aug. 29th, 2005 07:36 pm (UTC)
At least you're not running into problems where the correct operator still gives you wrong results because you're exceeding the resolution of a double float. Or causing the system to panic because you tried using floating point math in an interrupt handler on a system that only supports floats in userspace.
Aug. 29th, 2005 07:39 pm (UTC)
I've certainly run out of precision before, but I don't generally write code in interrupt handlers. :-)
Aug. 30th, 2005 01:25 am (UTC)
Premature optimization is the root of all programming evil.

(Well, except for Windows, that's evil without any optimization ;)
Aug. 30th, 2005 05:31 am (UTC)
That and denormals.
Aug. 30th, 2005 04:37 pm (UTC)
Facinating. How did I not know this?
Aug. 31st, 2005 06:48 am (UTC)
Do you write IIR filters much? That the only place they've ever bitten me.
Aug. 31st, 2005 06:59 pm (UTC)
Actually I do. But usually only in the whitening context, and my data is usually so noisy that I don't have to deal with small number problems. At least I don't think I do. ;-/

I guess I did know about denormals, but I'd completely forgotten about them.
Aug. 31st, 2005 07:09 pm (UTC)
Yeah, I guess for it to bite you hard requires
1) input data includes stretches of exact zero, no noise.
2) processing is in real time, with a penalty for just one block of processing taking extra-long.
which sounds pretty much like audio synthesis.
Aug. 31st, 2005 07:09 pm (UTC)
that would be me
( 9 comments — Leave a comment )