Hello,
Adding that much restrictions to code, just in order to tell "the code
is the spec" removes a lot of the interest of this code. I think it's a
bad idea, the code would be inefficient and so, useless.
it is more interesting to have a design doc / spec, AND a reference
implementation.
For an example, look at how the SHA-1 RFC does it: you get a formal
description, and then a usable reference code:
https://www.rfc-editor.org/rfc/rfc3174
I generally believe that being able to write a complete natural language
specification of an algorithm gives everyone confidence that you are
able to explain it and you have a complete mental image of its
behaviour. Also, it is good industry practice, and I dont think any
reliable company would avoid writing a specification before writing code.
So in my opinion, no, it does not depends on the code being readable or not.
Efficient AND Readable code is another development skill, which is as
important as being able to properly specify the behaviour of the
underlying algorithm, but separate.
Sebastien
Le 14/12/2023 à 11:07, glen english LIST a écrit :
Hi Sebastien
I agree with your spirit and comment. I agree the current codebase can
be a little difficult to follow !
I think the requirement and definition of "reference C code" requires
that there is no optimisation, and no machine specific instructions ,
no unrelated or unused code etc. Is this your driving point ?
regards
glen english
On 14/12/2023 8:41 pm, Sebastien F4GRX wrote:
Hello,
I agree reference code is important as a known-good base to help test
the compliance of third party implementations, but code NEVER has
been equivalent to a specification.
Code is usually complex, and specific to a particular kind of
machines. it uses shortcuts, optimizations, and is linked to its
implementation language. it's almost art. It is unusable to build a
hardware version of the codec. So, it's not a spec.
A formal spec is more important, as it describes the pure algorithmic
structure of the codec in a concise, synthetic, yet practical way.
Writing a spec is a also a way to make sure we know what the code is
doing, without having to know how to code. And to make sure no detail
is left out.
For example, there is a difference between writing "energy is
quantified linearly by selecting codes in this lookup tables for
these values of energies" and having to browse dozens of files to
find which encoding table and routine are used for a specific mode.
I know because was there before, I tried as a third party developer,
to document codec2 algorithms from code, without previous intimate
knowledge of the algorithms (I have already shared my doc).
I found it very difficult to do, not because codec2 is complex, but
because the current codec2 code base is quite large, comes with lots
of unused and/or unrelated routines, and as such is very hard to
follow. This is normal.
I am very glad that a specification is finally available. I have not
yet been able to read it yet as github told me the pdf was corrupted,
but I hope to get it soon, read it, help improve it, and use it to
finally build a fixed point version.
Thank you very much for this document,
Sebastien
Le 13/12/2023 à 23:35, glen english LIST a écrit :
I support reference C code
For a developer who needs to implement an algorthm on their
platform, the reference C code (RCC) provides ability to
numerically test bench their platform code (essential) , and
provides a well broken down algorithm method in the form of C code
(essential) .
In my opinion, an implementation developer does not need to
understand how and why , just what has to be done.
I'm starting to implement Codec2 on a RISC-V soft micro on an FPGA
with custom instructions. I started with the RCC, and identify
regions that I can generate FPGA acceleration in the fabric , and I
test bench it against vectors produced by the RCC.
(While I have a general interest in the inner workings) - I don't
need understand David's excellent Codec2 math inclusive
documentation, I just need to implement my numerically accurate
version of the RCC
-glen VK1XX
On 14/12/2023 9:24 am, david wrote:
Hi Greg,
Thanks for your comments, good to get a perspective from a non DSP
person. Some thoughts:
1/ The modes are not interoperable.
2/ The "stable" question is a good one. I consider codec2
unstable, as
I am dissatisfied with performance and enjoy experimenting. Having
said that, the youngest mode is now 7 years old, and some haven't
changed in a decade. I don't think we'd remove any existing modes
that
had a user base > 1.
_______________________________________________
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
_______________________________________________
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
_______________________________________________
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
_______________________________________________
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
