lilypond-auto
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: #5217 rand


From: Auto mailings of changes to Lily Issues via Testlilyissues-auto
Subject: [Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] Re: #5217 random results for the merge-rests-engraver regression test
Date: Sun, 03 Nov 2019 20:26:19 -0000

"Jonas Hahnfeld" address@hidden 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 printfs: 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:

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 address@hidden 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
address@hidden
https://lists.sourceforge.net/lists/listinfo/testlilyissues-auto

reply via email to

[Prev in Thread] Current Thread [Next in Thread]