http://codereview.appspot.com/4517136/diff/1001/lily/simple-spacer.cc File lily/simple-spacer.cc (right):
http://codereview.appspot.com/4517136/diff/1001/lily/simple-spacer.cc#newcode230 lily/simple-spacer.cc:230: for (++i; i < sorted_springs.size (); i++) On 2011/06/04 10:48:09, Keith wrote:
On 2011/06/04 07:09:05, joeneeman wrote: > It seems like this loop will never see i=0, even if it is active.
If springs[0] is active, the i-- above leaves i at UINT_MAX on loop
exit, so ++i
would be zero.
I don't know a good loop idiom for a down-loop using an unsigned type
(vsize)
for the index. I'll re-write as two up-loops starting with
"first_active" or
something.
(In the old code, some inactive springs were added to inv_hooke and
never
removed, but other functions made sure these had zero flexibility so
it didn't
matter. That seems too tricky to maintain, now keeping track of
compressibility
distinct from stretchability. So my reason for change here was an
attempt to
make the code /easier/ to figure out.)
Sorry, my mistake. I wouldn't bother rewriting this if I were you. Perhaps it's worth a comment, though, just to point out the corner case. http://codereview.appspot.com/4517136/diff/1001/lily/spring.cc File lily/spring.cc (left): http://codereview.appspot.com/4517136/diff/1001/lily/spring.cc#oldcode55 lily/spring.cc:55: // -infinity_f works fine for now. On 2011/06/04 10:48:09, Keith wrote:
On 2011/06/04 07:09:05, joeneeman wrote: > fixed springs have a blocking_force_ of zero instead > of -infinity_f. Does that work properly in simple-spacer?
My comment tries to state the contitions ^H^H conditions that I can
see as
required for simple-spacer to work properly.
With blocking_force 0, the unstretchable springs are on the "active"
list when
stretching the layout, but with zero stretchability they do nothing.
When
compressing, unstretchable springs never get put on the active list,
since their
blocking_force is 0.
It seems, though, that unstretchable but compressible springs should be on the active list when compressing.
With the former blocking force -inf, infinite compression, such
springs sorted
to be the very last ones removed from the active list. I could see no
reason to
keep them active until the end.
What about +inf? I'm not vehemently opposed to 0.0, but it seems strange to me that springs with are always blocking (or never blocking, depending on how you see it) should be sorted in the middle instead of at one end. http://codereview.appspot.com/4517136/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
