Adds epsilon to Bezier range calculations.

Adds epsilon to Bezier range calculations.

[MikeSol, 2011-07-27 08:37:06]

This passes regtests and adds a regtest to show it in action.

As I know nothing about rounding error in C++, I'd like others who are more
familiar with this to comment on the way I handle it.

Cheers,
MS

[pkx166h, 2011-07-27 20:01:29]

On 2011/07/27 08:37:06, MikeSol wrote:
> This passes regtests 

It does indeed :)

James

[pkx166h, 2011-07-27 20:04:52]

Added as

http://code.google.com/p/lilypond/issues/detail?id=1784

Just in case (some people use tracker more than Rietveld or their inbox so this
may get more eyes).

[hanwenn, 2011-07-27 20:59:42]

this just moves the rounding error an epsilon away. 

can you post an image of the problem you're solvnig ?

[mike_apollinemike.com, 2011-07-27 21:09:35]

On Jul 27, 2011, at 10:59 PM, hanwenn@gmail.com wrote:

> this just moves the rounding error an epsilon away.
> 
> can you post an image of the problem you're solvnig ?
> 
> http://codereview.appspot.com/4820048/

With my new patch, the tuplet collision right at the end of the slur is avoided
(lily finds a Bezier intersection).  Without the patch, there is a
slur/tuplet-number collision.


Cheers,
MS

[hanwenn, 2011-07-27 21:42:29]

That's weird - the overlap looks way more than 1e-10. Are you sure it is
taking the correct extent of the number into account?

(I am surprised that we do tuplet number/slur collisions at all.)


2011/7/27 mike@apollinemike.com <mike@apollinemike.com>

> On Jul 27, 2011, at 10:59 PM, hanwenn@gmail.com wrote:
>
> this just moves the rounding error an epsilon away.
>
> can you post an image of the problem you're solvnig ?
>
> http://codereview.appspot.com/4820048/
>
>
> With my new patch, the tuplet collision right at the end of the slur is
> avoided (lily finds a Bezier intersection).  Without the patch, there is a
> slur/tuplet-number collision.
>
>
> Cheers,
> MS
>
>


-- 
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

[Keith, 2011-10-01 06:02:54]

Mike, this could make sense *if* it is normal to ask where the Bezier curve
touches the left or right side of its bounding box.

I considered doing exactly this for the rounding problem in Bezier::minmax() but
I chose instead to put the corner-case handling in the caller.

Your proposed reg-test causes Slur_configuration::score_extra_encompass() to
calling get_other_coordinate() to find the height of the slur at the right end
of the slur.

Do you have time to look into why score_extra_encompass() is looking at
precisely the right-hand end of the slur?  I would have thought the
collision-avoidance code should be looking at the left bounding box corners of
the tuplet number, which are inside the ends of the slur, or something like
that.

[dak, 2012-03-12 23:13:39]

On 2011/10/01 06:02:54, Keith wrote:
> Mike, this could make sense *if* it is normal to ask where the Bezier curve
> touches the left or right side of its bounding box.

A Bezier curve stays within the convex hull formed by the end points and the
control points.  If the x (or y) coordinates of the control points are within
the interval of the end points, the end points determine the x (or y) coordinate
of the bounding box.  No need to calculate anything else in that case.