That's an interesting idea Steve, thanks. - David
On Wed, 2013-06-12 at 10:30 -0600, Steve Strobel wrote: > On Mon, Jun 10, 2013 at 11:07 AM, <[email protected]> wrote: > > > Small differences in the bit-exactness of floating point > calculation are > not errors. That's the problem... > > > One potential solution would be to use a software floating point > library while doing bit-exact verification of build system changes, > algorithm changes (such as trying a different FFT library), etc. Once > those changes were shown to be equivalent, the software floating point > library could be swapped out for whatever floating point method runs > best on the hardware, and it would seem reasonable (to me) to assume > that the remaining small differences in the floating point > calculations would not be considered errors. In other words, the > codec2 "standard" would be defined using a reference implementation > with software floating point, and the optimized implementations would > be expected to vary slightly. For the sake of verification, we might > want to use a software floating point library that is very high > precision. It would not need to run real time on any platform. It > would need to return consistent results regardless of compile-time > options, and ideally on different hardware platforms. > > > I tried to take a step in that direction back in December. I hoped to > use a typedef for the floating point data type, with the intention of > being able to easily swap it out. The most simple case would be > selecting between "float" and "double". (I realize that calls to > sin() and similar would also need changed to sinf()... since they > aren't overloaded). I also wanted to compile the codec2 source as C++ > so I could use a class with overloaded operators for the floating > point data type. I got stuck trying to build the codec2 source as C++ > when I couldn't find the source for the autotools-generated files; > maybe it would be easier now that cmake is an option. > > > In my case, I wanted to use a C++ floating point library > <http://www.openexr.com/about.html> that represents floating point > numbers using only 16 bits, hoping it would run real time on a > Blackfin DSP (which doesn't have a FPU). Those using ARM targets > without FPU could get the same results using GCC's half-precision > (16-bit) floating point __fp16 type (currently supported only on > ARM). I would expect that if the 16-bit floats could handle the range > needed for codec2 that they would work, but that the audio quality > would suffer somewhat from the limited resolution (which might be > acceptable or might not... I sure would like to try it). > > > Steve > > > > > -- > Steve Strobel > Link Communications, Inc. > 1035 Cerise Rd > Billings, MT 59101-7378 > (406) 245-5002 ext 102 > (406) 245-4889 (fax) > WWW: http://www.link-comm.com > MailTo:[email protected] > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ Freetel-codec2 mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/freetel-codec2 ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
