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
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp