On 2012/06/12 13:22:10, dak wrote:
On 2012/06/12 12:54:40, MikeSol wrote: > On 2012/06/12 12:49:45, dak wrote: > > http://codereview.appspot.com/6303065/diff/10003/lily/grob.cc > > File lily/grob.cc (right): > > > >
http://codereview.appspot.com/6303065/diff/10003/lily/grob.cc#newcode472
> > lily/grob.cc:472: real_ext[d] += offset; > > On 2012/06/12 12:32:37, dak wrote: > > > I don't understand this. The only way to get a nan from adding
an offset
to > > > infinity is by adding another nan or an infinite offset with
different
sign. > > > > > > What case is this supposed to catch? > > > > So what you actually meant to say was > > if (!real_ext.is_empty ()) > > real_ext.translate (offset); > > > > If that's what you mean, why don't you write it instead of some
puzzle?
> > This is not what I mean. An empty interval is, in LilyPond, an
interval whose
> left is greater than it's right.
I disagree. An empty interval is an interval not containing any
point. The
details are not important.
I see that you chose to push this unchanged instead of using my suggestion. The result is that both interval ends are translated _independently_. Treating them _independently_ in this obfuscate manner only makes sense when you expect them to be set independently, namely one interval end being infinite, the other finite. For one thing, you have not explained how you expect such a configuration to come about. For another it means that (inf,3) which is an empty interval, gets transformed under an infinite shift to (inf,inf) an interval that will likely blow the emptiness check. Your example, (3,2) is transformed with an infinite shift into (inf,inf) again blowing the emptiness check since inf<inf can't be determined. Could you please explain the cases where you expect to get sensible results with that approach? http://codereview.appspot.com/6303065/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
