[Top][All Lists]

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

Re: Vertical spacing, distinguish stretchability/compressibility (issue4

From: joeneeman
Subject: Re: Vertical spacing, distinguish stretchability/compressibility (issue4517136)
Date: Sat, 04 Jun 2011 17:32:15 +0000
File lily/ (right):
lily/ 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
for the index.  I'll re-write as two up-loops starting with
"first_active" or

(In the old code, some inactive springs were added to inv_hooke and
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
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.
File lily/ (left):
lily/ // -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.
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.

reply via email to

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