Re: [codec] Format for the codec specification

[Stephen Botzko <[e-mail]>]

I agree.  Also, as a practical matter it is quite difficult to write the
mathematical description in an RFC, since you are restricted to plain ASCII
text.

Stephen Botzko

On Fri, Oct 1, 2010 at 1:37 PM, Cullen Jennings <[e-mail]> wrote:

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