Re: [Tex-music] musixflx in Lua
Bob Tennent wrote: |Possibly, but if two scripts were being maintained then I'd maintain |that identical output is the more critical thing to have (and, yes, in |the 16th decimal place - no optimising compiler re-orders floating point |instructions without being told that unsafe optimisations are allowed |precisely because the results can differ, the same algorithm over the |same precision of floating point representation should produce *exactly* |the same output regardless of language) David: I'm pleased to report that after replacing Nikhil's own formatting function (which truncated decimal parts rather than rounding!) by string.format(%.., ...) I'm getting exact matches with musixflx.c output. It seems Nikhil didn't find the string.format( ) function in the manual :+) Marvellous - and as per the subsequent emails, it looks like longer-term we'll be heading towards retiring musixflx.c completely. David --- TeX-music@tug.org mailing list If you want to unsubscribe or look at the archives, go to http://tug.org/mailman/listinfo/tex-music
Re: [Tex-music] musixflx in Lua
| I'm getting exact matches with musixflx.c output.
|
|Marvellous - and as per the subsequent emails, it looks like longer-term
|we'll be heading towards retiring musixflx.c completely.
I have a question to musixtex-ers about how to do this. It's possible
to add a few lines to musixtex.tex so that *if* processed by luatex
*and* musixflx.lua is accessible, the latter will be called directly
by luatex. Check out
http://icking-music-archive.org/software/musixtex/musixflx-lua.zip
if you want to try this yourself. It's a nice party trick but I've
come to the realization that this approach is mistaken.
Firstly, there are disadvantages to requiring luatex. PDF output is
the default and so an ugly option is needed to force DVI output when
Postscript slurs are used. Also UTF-8 input and OTF fonts are expected,
which will be problematical unless the traditional representations
like \'{e} are used for accents.
Secondly, although it's likely that musixflx.lua can re-invove luatex,
and musixtex.tex can be further extended to call dvips and then ps2pdf
after the second pass, this approach seems clumsy and inflexible.
I now think a better approach is to use a lua wrapper script to
successively call etex, musixflx[.lua], etex, dvips and ps2pdf. I'm sure
most of you use a similar such script now: a bat script in Windows or
a shell script on other platforms. A platform-independent *lua* script
could replace these. Pmx and M-Tx packages could provide extended
versions to incorporate pre-processing.
Is this a good idea?
Bob Tennent
---
TeX-music@tug.org mailing list
If you want to unsubscribe or look at the archives, go to
http://tug.org/mailman/listinfo/tex-music
Re: [Tex-music] musixflx in Lua
Bob Tennent wrote: | It should be functionally identical to musixflx.c (up to round-off |error). | |Is this just a throw-away line or are there actual systemic differences |in the precision of the floating point variables used? Floating point |calculations are a CPU function - it would be beneficial if the results |strived to be *identical* on the same architecture (a guarantee which TeX |provides). That's because TeX doesn't do floating-point! One of the reasons (the other being the lack of arrays) that a separate musiflx program was introduced. Internally TeX does (at least the paragraphing algorithm uses floating point) - that's why the TRIP test can have rounding errors in some of the calculations and so numbers in logs are allowed to differ but still pass the TRIP test. The differences are in the last digit and since there are no significant numerical calculations involved, I'm guessing the differences arise from differences in the output formatting. |I'm not terribly familiar with Lua, but I would anticipate |that C will be more flexible here - both scripts should use the same |floating point representation for calculations which will eliminate all |sources of non-algorithmic rounding error (if necessary, the C script |could be changed). I think that's called moving the goalposts :+) Possibly, but if two scripts were being maintained then I'd maintain that identical output is the more critical thing to have (and, yes, in the 16th decimal place - no optimising compiler re-orders floating point instructions without being told that unsafe optimisations are allowed precisely because the results can differ, the same algorithm over the same precision of floating point representation should produce *exactly* the same output regardless of language) But that said... snip I think it would be much better to incorporate the musixflx calculations into musixtex.tex and make LuaTeX a requirement for MusiXTeX. I was thinking that binding musixtex to a specific TeX driver was too radical but if that's the plan then it seems like a very good idea - anyone who wishes to use an alternate TeX driver with musixtex can then be expected to install a lua interpreter themselves. And of course if luatex is the required driver (and musixflx.lua is still available in the distribution) then there'd be no need to maintain musixflx.c any more. David --- TeX-music@tug.org mailing list If you want to unsubscribe or look at the archives, go to http://tug.org/mailman/listinfo/tex-music
Re: [Tex-music] musixflx in Lua
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.4999 and on musixflx.lua 0.5000, 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 --- TeX-music@tug.org mailing list If you want to unsubscribe or look at the archives, go to http://tug.org/mailman/listinfo/tex-music
Re: [Tex-music] musixflx in Lua
|Possibly, but if two scripts were being maintained then I'd maintain |that identical output is the more critical thing to have (and, yes, in |the 16th decimal place - no optimising compiler re-orders floating point |instructions without being told that unsafe optimisations are allowed |precisely because the results can differ, the same algorithm over the |same precision of floating point representation should produce *exactly* |the same output regardless of language) David: I'm pleased to report that after replacing Nikhil's own formatting function (which truncated decimal parts rather than rounding!) by string.format(%.., ...) I'm getting exact matches with musixflx.c output. It seems Nikhil didn't find the string.format( ) function in the manual :+) Bob --- TeX-music@tug.org mailing list If you want to unsubscribe or look at the archives, go to http://tug.org/mailman/listinfo/tex-music
Re: [Tex-music] musixflx in Lua
Bob Tennent wrote: Last November, Dirk Laurie suggested that we should be porting the M- Tx/PMX/musixtex/musixflx toolchain to LuaTeX. I won't review his arguments here, but I'm pleased to report that Nikhil Helferty, a student here, has successfully converted musixflx.c (version 0.83.3) to musixflx.lua (version 0.83.3.luaN, currently N=1). This is indeed excellent news! It should be functionally identical to musixflx.c (up to round-off error). Is this just a throw-away line or are there actual systemic differences in the precision of the floating point variables used? Floating point calculations are a CPU function - it would be beneficial if the results strived to be *identical* on the same architecture (a guarantee which TeX provides). I'm not terribly familiar with Lua, but I would anticipate that C will be more flexible here - both scripts should use the same floating point representation for calculations which will eliminate all sources of non-algorithmic rounding error (if necessary, the C script could be changed). Most of the work I do involves a lot of regression tests against reference copies of known output so I'm always particularly sensitive to statements about rounding errors ;o) It's been tested on hundreds of examples but there may be bugs lurking in rarely-exercised parts of the code so please test it on your most complex and unusual scores, and report problems to me (attach problematic .mx1 files). Usage: musixflx.lua is a lua script and so is used essentially as follows: lua musixflx.lua basename This requires a lua interpreter; for example, from here: Are there options available for producing native executables from Lua scripts on at least the major three platforms? If there are, then it would seem an excellent time to look towards dumping the C script entirely - the ability to produce a native executable would mean that anyone using MusiXTeX on a system which doesn't have LuaTeX instead would not have to install a Lua interpreter so it wouldn't make the installation of LuaTeX any harder. David --- TeX-music@tug.org mailing list If you want to unsubscribe or look at the archives, go to http://tug.org/mailman/listinfo/tex-music
Re: [Tex-music] musixflx in Lua
|i had, in fact, vaguely thought of making musixflx into a separate ctan |package (it's already separate from musixtex in the distributions, |brought in by their requirement directives[*]). | |doing that would involve breaking your structure, but i think it would |add clarity to the distribution, and would also allow mirrored |distribution of this excellent script. I combined musixflx and musixtex into a single package because the former is *essential* to the proper use of the latter; also there is a version compatibilty issue. Ultimately, the musixflx code should be incorporated into musixtex, so it seems premature to separate them now. Bob --- TeX-music@tug.org mailing list If you want to unsubscribe or look at the archives, go to http://tug.org/mailman/listinfo/tex-music
Re: [Tex-music] musixflx in Lua
| It should be functionally identical to musixflx.c (up to round-off |error). | |Is this just a throw-away line or are there actual systemic differences |in the precision of the floating point variables used? Floating point |calculations are a CPU function - it would be beneficial if the results |strived to be *identical* on the same architecture (a guarantee which TeX |provides). That's because TeX doesn't do floating-point! One of the reasons (the other being the lack of arrays) that a separate musiflx program was introduced. The differences are in the last digit and since there are no significant numerical calculations involved, I'm guessing the differences arise from differences in the output formatting. |I'm not terribly familiar with Lua, but I would anticipate |that C will be more flexible here - both scripts should use the same |floating point representation for calculations which will eliminate all |sources of non-algorithmic rounding error (if necessary, the C script |could be changed). I think that's called moving the goalposts :+) The differences are of no practical significance. What I'm looking for are significant differences, such as the lua script crashing because of a typo. |Most of the work I do involves a lot of regression tests against |reference copies of known output so I'm always particularly sensitive |to statements about rounding errors ;o) The script was produced by a line-by-line translation of the C code. It doesn't use different calculational algorithms. |Are there options available for producing native executables from Lua |scripts on at least the major three platforms? If there are, then it |would seem an excellent time to look towards dumping the C script |entirely - the ability to produce a native executable would mean that |anyone using MusiXTeX on a system which doesn't have LuaTeX instead |would not have to install a Lua interpreter so it wouldn't make the |installation of LuaTeX any harder. ^^ I'm guessing you meant to write MusiXTeX there. That would simply perpetuate the maintainance problems of requiring platform-dependent executables. I think it would be much better to incorporate the musixflx calculations into musixtex.tex and make LuaTeX a requirement for MusiXTeX. Bob --- TeX-music@tug.org mailing list If you want to unsubscribe or look at the archives, go to http://tug.org/mailman/listinfo/tex-music
Re: [Tex-music] musixflx in Lua
On Sun, Apr 10, 2011 at 12:55:58PM +0200, David Allsopp wrote: Bob Tennent wrote: It should be functionally identical to musixflx.c (up to round-off error). Is this just a throw-away line or are there actual systemic differences in the precision of the floating point variables used? Floating point calculations are a CPU function - it would be beneficial if the results strived to be *identical* on the same architecture (a guarantee which TeX provides). See Remark 1 below. I'm not terribly familiar with Lua, but I would anticipate that C will be more flexible here - both scripts should use the same floating point representation for calculations which will eliminate all sources of non-algorithmic rounding error (if necessary, the C script could be changed). See Remark 2 below. Are there options available for producing native executables from Lua scripts on at least the major three platforms? If there are, then it would seem an excellent time to look towards dumping the C script entirely - the ability to produce a native executable would mean that anyone using MusiXTeX on a system which doesn't have LuaTeX instead would not have to install a Lua interpreter so it wouldn't make the installation of LuaTeX any harder. See Remark 3 below. 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. 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. 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. 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.4999 and on musixflx.lua 0.5000, 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. Dirk --- TeX-music@tug.org mailing list If you want to unsubscribe or look at the archives, go to http://tug.org/mailman/listinfo/tex-music
