On 06/25/2012 05:11 AM, jp.charras wrote: > 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.
Maybe, but what about basic "please and thank you." Where does that fit in? Obviously nowhere for Lorenzo. _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
