kicad-developers team mailing list archive

["jp.charras" <jp.charras@xxxxxxxxxx>]

Le 25/06/2012 08:32, Lorenzo Marcantonio a écrit :
> On Sun, Jun 24, 2012 at 06:23:46PM +0200, jean-pierre charras wrote:
> > I am afraid I do not really understand your question.
> > In float to integer conversions, rounding creates a smaller error than truncating.
> > And truncating fval<  0 ? fval - 0.5 : fval + 0.5 is the right way to round a value that must be converted to integer BIU.
>
> Right, I was asking before in other circumstances (i.e. motion control)
> truncation or rounding is often (I can't say always, but almost)
> replaced by floor()ing, to avoid a discontinuity issue around zero
> (reason: the default rounding minimized biasing, flooring minimizes
> discontinuities, more or less; I don't know the proper math terms...)
> I generally simply avoid floating point if possible using fixed point
> instead, if dynamic range is not needed; there is also the issue of the
> rounding mode in use and so on (wikipedia treats everything in
> details...).
>
> In short I asked because I have simply never seen that construction (but
> in fact maybe it's simply equivalent to floor(x+0.5) :P). Just to know
> better the code.
It is.
However in debug mode, KiROUND print a warning if the rounding cannot be made.
> > By the way, your recent issue when reading your board file in kicad nanometer version is a truncating issue,
> > when scaling float values read in files to integer internal units.
> > When using rounding conversion instead of truncating, it happens no more.
>
> Wasn't that a precision issue caused by internal rounding of
> printf/scanf using doubles instead of long doubles? (I would have simply
> saved the nanos as integer...) If that was the case changing precision
> shouldn't have changed the result!

This is not a printf/scanf issue using doubles, this is a scaling issue.
Here is an example ( in decimal, with one digit mantissa ) that shows can happen:
If I use a scaling factor FILE2IU= 3, and I want to save the IU integer value = 1000
The saved value is 333.3 (with truncation)
after reading the file you get 333.3 * 3 = 999.9
With truncation, new IU = 999
With rounding, new IU = 1000

regardless the size of the float number, i.e. the number of digits after the decimal separator.

For this kind of issue, the fix is easy (however find the reason was tricky)
(It was just a read function where the call to the rounding conversion was forgotten)

And saving values using the internal values "as is" is a very bad idea.
Values in files *must* be independent of the internal representation,
that can be modified without breaking the file format


> Anyway, this is my view about float to int conversion: if possible,
> avoid it; otherwise just do whatever works (not very scientific,
> I know...)

If possible, yes.
However, there is a lot of case where it is not possible, or even bad,
mainly in trigonometric calculations:
rotations, moving a line and keep slope, distance between items...
Fortunately rounding errors are not always an issue, but sometimes they are.

And remember using ints *does not* avoid truncation errors in calculations.


--
Jean-Pierre CHARRAS
KiCad Developers team.
KiCad Developers <kicad-developers@xxxxxxxxxxxxxxxxxxx>