Hi, > Why are the two logs added as integers (+) rather than > as polynumials (^)? Why do you do % 255 rather than 256?
Interesting point. The justification must be hidden in James S. Plank's statement: "This implementation makes use of the fact that the inverse log of an integer is equal to the inverse log of (i mod (2^w - 1))." I'll try to find out why this is a fact and why this causes the + in the multiplication algorithm. (Any hint appreciated. It is half a life ago that i did sincere algebra.) Nevertheless i think this open question does not infringe the claim that ecma130ab.c implements ECMA-130 Annex A by help of well known mathematical methods. > If you double the gfpow table's size you could > elminate the % 255. This is well worth a try. I simplified the constant division by 3 but that happens not often enough to have much effect. One could also apply the division to the matrix H which currently is an alter ego of the power table. The index computation of burn_rspc_q0q1() can be done in part before the loop. Maybe one would have to explore the route via Fourier again for a really smart reformulation. > Does ECMA provide any "test vectors" for you to test your code with? > Unit tests might be very useful! I test against the old implementation which was once introduced by the founders of libburn. Nevertheless i am not sure whether that one really complies to ECMA-130. A test would be to blow up some data sectors and to burn them in raw mode. Then one would try to read them as data blocks. The drive's decoder would then deliver the original data if all went right. But for burning data sectors in raw mode there are more things to learn. Some i find in the MMC specs. Some are still obscure to me. By the code replacement i just want to keep up eventual old capabilities of libburn which i had to remove after Joerg's intervention a few weeks ago. ------------------------------------------------- libburn does not stem from cdrtools. It rather appears to have originated as academic project which stalled when the semester was over. When i began to beef it up, it became obvious that its architecture was significantly more elaborate than the implementation code in its functions. See also "Project history as far as known to me" beginning in line 171 of http://libburnia-project.org/browser/libburn/trunk/README ------------------------------------------------- Have a nice day :) Thomas -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org