Both excellent points Jean-Marc. I've found myself making similar
gyrations to support an elegant fixed point port, e.g. replacing trig
functions with look up tables.
For the fdmdv modem I used the quality testing framework idea to port
Octave simulations to C float code. There are some scripts that verify
a bunch of internal states are within 1 part in 1E4 in both
implementations.
On a lighter note I once wrote a "fixed point fairy tale" to vent my
frustration at this same problem in a corporate situation, where I've
seen it derail companies, cost jobs and millions of $:
http://www.rowetel.com/blog/?p=10
- David
On Thu, 2013-03-07 at 16:07 -0500, Jean-Marc Valin wrote:
> On 03/07/2013 11:26 AM, Steve Strobel wrote:
> > I am not sure I can completely justify it, but my tendency would be to
> > to use C++ classes to represent the numeric values. If the variables
> > were declared using typedefs, it would be easy to control whether they
> > used native float/double or the C++ classes. Naturally a C++ compiler
> > would be needed to use the classes, but I don't think it would be too
> > hard to make the source also compile as C when using the native
> > floats/doubles.
>
> You're aware that the majority of devices that would benefit from a
> fixed-point port don't actually have a C++ compiler? In general, I think
> there's one important point being missed here. What's hard isn't the
> part about "dumb float->fixed conversion". Regardless of how you write
> your fixed-point, you still have to do quality testing to make sure
> every change you make preserves quality. On top of that, there's usually
> many places where you need to write *different* code for the
> fixed-point. For example, in many places, the only way to avoid 64-bit
> arithmetic is to add renormalization steps or even use a different
> algorithm to compute the same result. Sure it'd be nice to have code
> that's more readable than what the Speex macros give you, but without
> spending more time on a framework (that may not even work) than on the
> port, the only real options are something like these macros or a
> separate codebase. BTW, for CELT I once wrote a script that would run
> the preprocessor to convert the code back to float.
>
> Jean-Marc
>
>
> ------------------------------------------------------------------------------
> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
> endpoint security space. For insight on selecting the right partner to
> tackle endpoint security challenges, access the full report.
> http://p.sf.net/sfu/symantec-dev2dev
> _______________________________________________
> Freetel-codec2 mailing list
> Freetel-codec2@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
