>|> 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.t
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 optimi
>|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
>|p
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 t
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 -
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?
>|> 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 t
>|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 d
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
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) t
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.
11 matches
Mail list logo
