Re: [codec] Format for the codec specification

[Cullen Jennings <[e-mail]>]

These are all valid concerns, but I think people have often found that the providing code path is the "least bad way" of specifying codecs.  I did want to point out that bugs are found in specs all the time regardless if they are C code, english text, or something else. We have an errata process for updating RFCs as well as a ways to publish new versions of RFCs. I think that is about the best we can do. It's also easy to accidentally write ambiguous text like your C example below. Again, this happens in both english and C - we just need to do our best to keep an eye open for those and fix them. That's one of the advantages of having "running code" - it helps discover the corner cases that are under specified. The code tends to be "Reference" in that it is written to help illustrate the algorithm and is often not the most optimal way to implement the algorithm, may not be thread safe, may need changes to be ported to some platforms and so on.  C may not be the best for this but it has the advantage of behind widely understood - particularly in DSP codec circles. We could have a huge argument about what language for a long time. I have seen that argument before and it's not fun. In the end, the odds we would choose C are extremely high. 

Cullen


On Sep 25, 2010, at 2:55 AM, Riccardo Bernardini wrote:

> 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
> 
> _______________________________________________
> codec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/codec