Hello, I'm returning to here sonn.
I regard Emre's work is aiming to refactor (not improve its
functionality of) the code, on the other hand thins one is a
separate bug fix which also should be backpatched.
But, honestrly I'm not sure such small fix would improve the
current situnation of the
Emre Hasegeli writes:
>> Possibly this objection is pointless, because I'm not at all sure that
>> the existing code is careful about how it uses FPeq/FPzero; perhaps
>> we're applying EPSILON to all manner of numbers that don't have units
>> of the coordinate space. But this
> However, for either patch, I'm a bit concerned about using FPzero()
> on the inner product result. To the extent that the EPSILON bound
> has any useful meaning at all, it needs to mean a maximum difference
> between two coordinate values. The inner product has units of coordinates
> squared,
Kyotaro HORIGUCHI writes:
> I happend to see a strange geometric calcualtion on master/HEAD.
> ...
> Instead, calculating inner product of the two direction vectors
> works as expected.
> (l1->A * l2->A) + (l1->B * l2->B) == 0
This seems to be a strict subset