Dirk Laurie wrote: > 1. Identical results on the same architecture requires switching off *all* > optimization in the C compiler. Not even a widely disseminated > software package such as BLAS (Basic Linear Algebra Subroutines) > promises identical runs nowadays, even for two runs on the same > machine. One should not write software that behaves qualitatively > differently depending on what happens in the sixteenth decimal place.
This is not relevant to my point - when regressing output of scripts, it is exceedingly useful if the output can be strived to be identical (and in this case, all that means is the translation from .mx1 to .mx2). And no optimisations in the compiler should by default be re-ordering floating point instructions because that is unsafe. > 2. Lua is written in C; in fact, the C code for a customized version of > the Lua interpreter is compiled and linked into the LuaTeX > executable. Lua's "number" and C's "double" is one and the same. Then this should eliminate the errors assuming the algorithms have been implemented using the same sequenced floating point operations. > 3. There is a strong possibility that LuaTeX will become the default > TeX engine in most distributions. I.e. when you type latex, > or etex, or pdftex, or luatex, in all cases the actual executable > will be luatex, although what it actually does will depend on which > of the four names you used. (If you type tex, you should still get > an executable generated from Knuth's cweb source, by the terms of > his licence.) I.e. if you have TeX, you will have luatex without > lifting a finger. I hadn't reckoned that this step was actually being taken - but it eliminates virtually all my concerns if musixflx.lua becomes the only version of the script anyway! > 4. I can find only one place where musixflx may possibly, even though > he probability is remote, be roundoff-sensitive: > If the overhang is less than half the barlength, include the > latest bar in the line, and shrink the line accordingly. > It is possible (though the probability is less than that of my winning > the lottery if I buy only one ticket) that the overhang on musixflx.c > could be 0.4999999999999999 and on musixflx.lua 0.5000000000000000, > or vice versa. > I suspect that on PMX-generated scores no decision on line breaking > is left to musixflx, so this conditional should not be encountered > in that case. I was only talking about musixflx (i.e. musixtex itself) - I don't use PMX. Incidentally, while I appreciate your exaggeration to make a point, the resulting output in the .mx2 file is only to 5 decimal places as the result is a TeX pt... David ------------------------------- [email protected] mailing list If you want to unsubscribe or look at the archives, go to http://tug.org/mailman/listinfo/tex-music
