kicad-developers team mailing list archive
Mailing list archive
Re: Preliminary angle and distances sweep
On 4/30/2013 1:01 PM, Lorenzo Marcantonio wrote:
> On Tue, Apr 30, 2013 at 11:13:19AM -0500, Dick Hollenbeck wrote:
>>> - When going from double to int (geometrically) a KiROUND should be used
>>> instead of a int cast
>> Yes, as soon as you enable arbitrary degrees. (We've not done that to this point.)
> Not only for degrees, but especially for coordinates, like when
> computing point on a circle. For angle I reckon it would be the opposite
> (i.e. now they could be rounded, after the switch they would not).
> However this should be for 'user visible' angles only... it is not
> desiderable to round angles used for internal processing (for example
> the angles computed during DRC). If I didn't miss anything the only
> "user level" angles are: the arc angles, text orientation, pad
> orientation and module orientation.
> Since these are only passed around and summed/subtracted between them
> I think that if there are no fractional angle incoming (from a file for
> example) there shouldn't be fractional angles coming out. And since
> I didn't touch the dialog (except for ensuring that they were used as
> int) the user should only 'see' integer values (integer decidegrees).
This user would rather UI angles be in degrees not deci-degrees. I've
been bit by this several times recently because I don't use arcs
frequently and forget (insert old guy joke here) that I have to multiply
angles by 10 when I enter them into arc edit dialog. It is always
frustrating when you enter 45 into the dialog thinking you will get a 45
degree arc and you end up with a 4.5 degree arc and I know that KiCad
uses deci-degrees externally and internally. I wonder what the poor
first time user must think. My guess is that most users think in degrees.
>> That is a context specific issue, I am reluctant to say yes to that in a general sense.
>> Actually fvar is really a double, so adding an integer to it will be fine. The integer
>> gets promoted to double (at least conceptually) with no loss of information yet.
> Exactly. That's why I said 'theorically should be the same'; a double
> should fit all the digits (plus one decimal digit used for rounding plus
> one guard digit) of an int without loss of precision. However
> summing two doubles should be evaluated case by case (to avoid biasing).
> And even if fvar would be something like a float, promotion rules would
> kick in and everything would be done in double precision anyway.
> In short:
> i1 + KiROUND(d1) -> int + int (d1 is rounded)
> KiROUND(i1 + d1) -> double + double, the result is rounded *but* since
> i1 was integer anywhat it shouldn't change how the
> rounding happen (i.e. 0.7 rounds to 1, 0.7 + i would
> round anyway to 1 + i, whatever integer i we chose)
> KiROUND(d1 + d2) -> Need to be evaluated, but usually this should be the
> right thing to do (very context dependant)
> AFAIK most of the cases are of the kind center + trigvalue, and there is
> no double+double sum around being put in an int. Since I like to think
> that an int+int is cheaper than a double+double (not necessarily
> true these days...) I prefer the first form.
>> Yes, if the strangeness is worth the speed. For something relative, i.e. a rough ranking,
>> Thomas Spindler used another technique that I wrapped into close_ness() in spectra_export.
>> It could have been called "ball_park".
> I only did one time, in HitTestPoints. The strangeness is something very
> relative since is something like the second thing you learn in CG after
> matrix operations:P the close_ness thing seems interesting, I'll look
> into that
> There is a way bigger performance loss in computing unasked distances
> during clipping for display (on the queue)
>> I have found it better to return the most information possible, the double, and let the
>> caller establish usage (rounding) policy on a case by case basis. Dumbing down a function
>> reduces its applicability.
> Then it's already fine that way. I think that in fact sometimes is used for full
>> Possibly MSVC++, which is now excluded.
> MSVC likes to warn a lot (implicit double to int for sure), probably that was the reason.
>> Yes I do, but the function name tells me nothing. DECI_DEGRESS is better clarity
>> somewhere in the name if that's what you are using.
> It's difficult to make mnemonics useful for everyone, I think that
> RAD2DECIDEG and DECIDEG2RAD would be good names (DECIDEGREES2RAD seem
> a little too verbose)
>> If you want further clean up work. I no longer think we need the BOARD_ITEM::Show() debug
>> functions. It is very easy now to use
> Put in queue for later.