Re: Vertical spacing, distinguish stretchability/compressibility (issue4517136)

[joeneeman]

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/