| Thread Previous • Date Previous • Date Next • Thread Next |
On Mon, 11 Oct 2010, Dick Hollenbeck wrote:
It is mind boggling that 2.54 and using a C++ double does not allow this to happen. I don't have time to test it, but I am wondering about it. Is this a problem with 64 IEEE float, or that we simply do not have enough resolution in our internal units?
The problem is both. That's also the reason a special arbitrary precision decimal or "money mode" is sometimes needed. For KiCad it's probably enough to settle for internal unit that is compatible enough with inches. One nm would limit our PCB width and height to about 4.3 meters or 169 inches when using 32b integer coordinates and would give us nice 25400 as conversion coefficient for mils (so hundredth of a mil smallest imperial precision). I'd guess the reason for original funny units is the time when 32b int was "expensive". Today SIMD being available everywhere and GCC autovectorization working quite well, there is nothing to worry. Maybe just consider in architecturing phase that GCC autovectorizer works better on certain structures. Vectorizer example1 is one very good test when run million times inside a loop and taking time (time test.executable). Its easy to reach ten times improvements on multiplication, addition and comparison. I have no idea how much code or algorithms is vectorizable in KiCad, but during the rewrite designing code for SIMD may be worth considering even if not implementing right away.
-Vesa The library: http://en.wikipedia.org/wiki/Computer_numbering_formats#Floating-point_numbers http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems http://en.wikipedia.org/wiki/Fixed-point_arithmetic http://gcc.gnu.org/projects/tree-ssa/vectorization.html http://ds9a.nl/gcc-simd/
| Thread Previous • Date Previous • Date Next • Thread Next |
