"Jonas Hahnfeld" <[email protected]> writes:
> I've tried to approach this systematically and made the observation
> that the moving dots might be related to what other regression tests
> are built for `check` (and maybe in what order? not sure if that is
> stable across invocations). Based on that, I've created a small set of
> input files (see attached archive) that really changes at random on
> subsequent invocations of `lilypond -dread-file-list names.ly`, at
> least on my system.
>
> I went on to understand what is causing the non-determinism. From what
> I found so far, it looks like some functions might be called in a
> different order in subsequent invocations of lilypond. I've also put a
> small diff into above archive which adds a few `printf`s: Sometimes
> `Dot_column::calc_positioning_done` is called before
> `Rest_collision::force_shift_callback_rest`, on another invocation it
> might be the other way around. The problem is that
> `Rest_collision::force_shift_callback_rest` calls
> `Grob::translate_axis` which updates a cache and changes the Y
> position.
>
> At least that's what it looks like to me right now, without knowing
> which ordering of above functions would be correct. But a changing
> order at random seems odd, doesn't it?
Turn off address space randomization and chances are that things become
more deterministic. As it is, certain data structures like Scheme
hashes are traversed in orders that depend on address allocation orders.
The current situation of random results for successive runs on identical
input is probably not significantly worse than pseudorandom results that
are only deterministic if you change absolutely nothing. Whether
minimal unrelated changes (including compilation with different
compiler/libraries) lead to considerable changes in results or no
changes at all: in practice that does not likely make a lot of
difference. It's only a bit baffling for people used to the consistency
of computers.
> Posting here in case somebody with more experience goes like "hey,
> that can be easily fixed like this". Otherwise I'll try to understand
> what's causing the different orders and how it can be turned off.
--
David Kastrup
---
** [issues:#5217] random results for the merge-rests-engraver regression test**
**Status:** New
**Created:** Fri Oct 20, 2017 07:28 AM UTC by Knut Petersen
**Last Updated:** Sun Nov 03, 2019 06:48 PM UTC
**Owner:** Knut Petersen
**Attachments:**
-
[out-test-baseline-merge-rests-engraver.png](https://sourceforge.net/p/testlilyissues/issues/5217/attachment/out-test-baseline-merge-rests-engraver.png)
(23.8 kB; image/png)
-
[out-test-merge-rests-engraver.png](https://sourceforge.net/p/testlilyissues/issues/5217/attachment/out-test-merge-rests-engraver.png)
(23.7 kB; image/png)
There is some randomness in the placement of dots. The merge-rests-engraver.ly
regtest (git-version557dc7) exposes the problem as the output might be one of
the two attached pngs. The probability for both results is identical on my
system.
---
Sent from sourceforge.net because [email protected] is
subscribed to https://sourceforge.net/p/testlilyissues/issues/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/testlilyissues/admin/issues/options. Or, if this is
a mailing list, you can unsubscribe from the mailing list.
_______________________________________________
Testlilyissues-auto mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/testlilyissues-auto
