kicad-developers team mailing list archive
Mailing list archive
Re: Rationale for rounding BIUs
On Mon, Jun 25, 2012 at 12:11:16PM +0200, jp.charras wrote:
> It is.
> However in debug mode, KiROUND print a warning if the rounding cannot be made.
Something escaped then, the doubt was because I've seen that
construction in the legacy_plugin code... should have user KiROUND,
right? *look at the code* ok, now it does XD
> 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)
Ok got it. The famous '0.1 is periodic in binary' so division by 10 is
not exact. Also the format string...
> 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
Well, just use the external file in nm, then :P:P or also use
a format/scan which doesn't suffer from this kind of issues (mainframes
have *as opcodes* routines for bcd arithmetics... well, even the x87,
even if I didn't see them uses). The new C specification also adds the
'decimal' types (like in SQL), so we should see a resurgence of these...
> 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...
There is a whole class of algorithms dedicated to these (two examples:
the CORDIC and the Bresenham classes of routines); also most DSP are
fixed point so there is a strong request for that (btw I have no idea of
the difference in precision for a trig calculated using CORDIC or the
'conventional' Taylor expansion...)
> Fortunately rounding errors are not always an issue, but sometimes they are.
I don't know in other fields but in control and DSP we always need to
check: 1) overflows 2) roundings and 3) stability. Hardware tends to
explode otherwise, so is not only a good idea! Also financial uses
almost exclusively fixed point bcd...
Fortunately the limitation of both fixed and floating point are well
studied, so there is a lot of literature to save our ass (i.e. numerical
recipes in whatever language you're using at the moment)
> And remember using ints *does not* avoid truncation errors in calculations.
It gives remainders :D (which can be taken into account, usually)
Just to give good news: the board is finished and passed the external
DRC. I've reloaded it with a temporarily hacked version of the biuParse
(which rounds everything to 1/20 of mm) so it's our first fully metric
board. Let's see how much the fabricator will break it:P