| Thread Previous • Date Previous • Date Next • Thread Next |
On 2019-07-10 15:02, Wayne Stambaugh wrote:
Are you planning on allowing either direct or fixing it to a single direction? I would think the latter would be preferable.
I'm not currently planning on using the center point method unless someone has a good solution to the invalid arc issue. The three-arc-point solution I proposed does not need a direction as it is implicit in the point positions.
Is there a good solution to this issue for the center point idea?That was my other concern. The mid point may not round to 1nm. It seems to me you are always bound by rounding and resolution limits.
The nomenclature is biting us here :). The center point would be in the middle of the circle along which the arc is drawn. The midpoint is on the arc itself.
Internally, I propose that the midpoint is a set value (not calculated) in integer units. All integer values up to 53 bits are exactly representable as 64-bit floating point values with no rounding. We are currently using 32-bit integers for our internal representation so we should not encounter rounding issues with the midpoint. Now, it may not be precisely at the midpoint of the arc but this doesn't matter for our calculation, which only needs the three points to lie on the same arc.
In this proposal, the center point, arc angle and radius are all calculated and may exhibit rounding issues when directly used. The rounding issues will be on the order of the current rounding issues we have with the end point but, critically, do not cause discontinuities.
Don't forget, this will impact all import from and export to 3rd party file formats so it's not going to be a trivial change.
Agreed. That is why I want to get the buy-in before coding up a proposed implementation. This will touch a lot of things.
-Seth
| Thread Previous • Date Previous • Date Next • Thread Next |
