kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

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
> precision.
> 
>> 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.
>