Re: [codec] Format for the codec specification

[Riccardo Bernardini <[e-mail]>]

Quoting Jean-Marc Valin <[e-mail]>:

> Hi Roni,
>
> Thanks for the correction on the case of G.719. Despite that, my  
> point still stands: there *are* codecs for which the decoder is  
> standardized without a bit-exact definition. As long as we define  
> the amount of deviation permitted, then there is no problem.
>
> Oh, and I do agree that the C code should take precedence over the  
> mathematical description.

A question just came to my mind: what about bugs in the C code?   
Suppose, for example, that the algorithm requires the computation of a  
DCT of a block of samples and that there is some typo in the constants  
used in the C code, so that what the C code computes is not the DCT,  
but something similar and the difference is such that it really does  
not matter in most cases, but causes very bad performances (when  
compared with theoretical description) in others.  In this case, the  
precedence would go to the "wrong" description.

I agree that the example above is somehow  weak (I just invented it  
"on the spot"), but I hope that spirit is clear: it could happen that  
despite of all attention we could pay, some subtle but important bugs  
could find their way to the C code.  Also I agree that we can always  
publish an errata or an RFC that obsolete the old one.

Another doubt about having a C code as a normative reference: could  
portability issues make the code "ambiguous"?  For example, a code  
could use the assumption that int is _exactly_ 32 bits long and short  
is _exactly_ 16 bits.  If the same code is run on a processor that  
uses, say, 64 bits for int and 32 for shorts, maybe the results could  
be different.  Of course, you can solve this _specific_ issue by  
including stdint.h (not available everywhere, though) and using types  
like int16_t, but what I want to point out is that we must pay  
attention to this type of portability issues, if we want the meaning  
of the C code being non-ambiguous.  Another example, much more subtle,  
could be

   int foo[3];
   int goo, foo=3;
   int *pt;

   pt  = (int*) foo;
   goo = (int) pt;  /* Is really pt==foo? */

As far as I know (but I am not a C language-lawyer), the standard  
grants that conversion pointer-to-integer-to-pointer will give the  
original pointer back, but nothing is said about the case above  
(imagine an architecture where addresses can be only even).  Although  
the code above would work on a typical x86 architecture, I would not  
use it in a code that should play the role of a reference.

By the way, I agree that the code above is quite silly, but I seen  
things like this used, for example, in multi-thread applications where  
the programmer wanted to pass an integer by using a function that  
expected a pointer.

What about using some other language with less portability issues,  
such as Ada or Java?  Better yet, some language with a semantic  
formally defined? (I do not know any, but maybe someone does)

[Oh, by the way, I *do not want* to start a flame war about which  
language to use.  Rather than fighting over it, I would go with C.  I  
just wanted to share with you some doubts of mine.]

Although I agree that errors and ambiguities could creep in the  
mathematical description, maybe it is easier to write a correct and  
unambiguous mathematical description rather than a program code (in  
whatever language is written).



> Cheers,
>
> 	Jean-Marc
>
> On 10-09-24 06:06 PM, Roni Even wrote:
>> 6.5 Description of the codec
>> The description of the coding algorithm of this Recommendation is made in
>> terms of bit-exact
>> fixed-point mathematical operations. The ANSI-C code indicated in clause 10,
>> which constitutes an
>> integral part of this Recommendation, reflects this bit-exact, fixed-point
>> descriptive approach. The
>> mathematical descriptions of the encoder and decoder can be implemented in
>> other fashions,
>> possibly leading to a codec implementation which does not comply with this
>> Recommendation.
>> Therefore, the algorithm description of the ANSI-C code of clause 10 shall
>> take precedence over the
>> mathematical descriptions whenever discrepancies are found. A set of test
>> signals, which can be
>> used together with the ANSI-C code in order to verify bit-exactness, is
>> available as an electronic
>> attachment to this Recommendation.
>>
>>
>> Roni Even
>>
>>
>>
> _______________________________________________
> codec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/codec
>



-- 
Riccardo Bernardini
DIEGM -- University of Udine
via delle Scienze 208
33100 Udine
Tel: [phone]
Fax: [phone]

----------------------------------------------------------------------
SEMEL (SErvizio di Messaging ELettronico) - CSIT -Universita' di Udine