Floats are not accurate beyond 6-7 digits and worse, floating point behavior is actually not fully well defined. You can actually get different quirks depending on platform, compiler and arch. Though generally the risk isn't in the arithmetic but supporting functions that are part of libc.
>And why did Kicad choose integer as internal measurement resolution? Using integers is standard programming behavior for applications that want well defined and bounded mathematical behavior. When you do floating point math, even if we ignore the inaccurate power part of the number, that error still sits in the number. When you carry out sufficient and numerous operations using numbers that carry these not used digits, they can actually creep in and start affecting the digits you do care about and cause errors. >Last, so that means there is no way to handle this issue? We have come to the conclusion that if somebody needs PCB designs larger than 4 meters, which is already an ridiculous size. They need to discuss with us the use case which is already going to be ridiculously niche for that one person because there is no standard PCB manufacturing equipment for a board of that size. On Mon, Nov 25, 2024, 8:01 AM Liang Jia <[email protected]> wrote: > Hi Mark, > > Thanks for your email. > > Could you please explain more about the relation between "Change the > measurement store from 32-bit to *64-bit*" and "128-bit integer math > support in processors"? > And why did Kicad choose integer as internal measurement resolution? > > >mm is not adequate to express the resolution of position data required > for a board design. > How about this? use mm for internal measurement resolution, but use > nanometer or *double(instead of integer)* for board design. > > > Last, so that means there is no way to handle this issue? > > On Mon, 25 Nov 2024 at 19:21, Mark Roszko <[email protected]> wrote: > >> >This means it is possible to create boards up to approximately 4 meters >> by 4 meters >> >> Yes, KiCad is limited to 4x4 meter boards currently. >> >> > Change the measurement store from 32-bit to 64-bit, so Kicad can >> support a larger board. >> >> This is not an easy task in the slightest. Specifically because we can't >> get 128-bit integer math support in processors, and many compilers do not >> support 128-bit integers. I think gcc has some experimental support. >> >> > Change the resolution of all objects to mm >> >> mm is not adequate to express the resolution of position data required >> for a board design. >> >> >> >> Basically the bug here is we simply do not tell the users the DXF is >> beyond our board support limit. >> >> >> On Mon, Nov 25, 2024 at 5:07 AM Liang Jia <[email protected]> >> wrote: >> >>> Hi All, >>> >>> I am writing to inquire about the challenges we are facing when >>> importing DXF files which contain large numbers into our system. >>> >>> I have noticed that when the number exceeds a certain threshold(such as >>> 4437 mm), the import process results in an int overflow error. >>> >>> I did the search below: >>> 1. Found that there was a ticket to track it, but it seems *it still >>> opens*. >>> https://gitlab.com/kicad/code/kicad/-/issues/12392 >>> >>> 2. From the Kicad document: >>> The internal measurement resolution of all objects in KiCad is *1 >>> nanometer*, and measurements are stored as *32-bit integers*. This >>> means it is possible to create boards up to approximately 4 meters by 4 >>> meters >>> I think the *root cause* is here: Kicad tried to convert the DXF number >>> into nanometer, but those numbers exceeded the limit of integer. >>> >>> Questions: >>> 1. Is there any workaround for this case, and let Kicad import those >>> files successfully? >>> 2. If I want to fix ticket 12392, what should I do? >>> Change the measurement store from 32-bit to 64-bit, so Kicad can >>> support a larger board. >>> Change the resolution of all objects to mm >>> >>> Looking forward to any comment or workaround. >>> >>> Sincerely >>> Liang >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "KiCad Developers" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion visit >>> https://groups.google.com/a/kicad.org/d/msgid/devlist/CAE0Ak8bd%3DgDwW%3DDWVXH-TKj%3Dr4nsgW370aNqB6PbP7T8b2QU6A%40mail.gmail.com >>> <https://groups.google.com/a/kicad.org/d/msgid/devlist/CAE0Ak8bd%3DgDwW%3DDWVXH-TKj%3Dr4nsgW370aNqB6PbP7T8b2QU6A%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "KiCad Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion visit >> https://groups.google.com/a/kicad.org/d/msgid/devlist/CAJjB1qKoN689BoyB1uWpWYmDCpbaCRKCyW2qmnBOoG5Au_Nnfg%40mail.gmail.com >> <https://groups.google.com/a/kicad.org/d/msgid/devlist/CAJjB1qKoN689BoyB1uWpWYmDCpbaCRKCyW2qmnBOoG5Au_Nnfg%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to the Google Groups > "KiCad Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/a/kicad.org/d/msgid/devlist/CAE0Ak8bmAyB7ciCe6nrps8gw0meXgaj25r5Zq-o2Z9x_-8CFDA%40mail.gmail.com > <https://groups.google.com/a/kicad.org/d/msgid/devlist/CAE0Ak8bmAyB7ciCe6nrps8gw0meXgaj25r5Zq-o2Z9x_-8CFDA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "KiCad Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/kicad.org/d/msgid/devlist/CAJjB1qLDDND2JZpaBCOHZpoz9HvsVF%2Brn%3D5nSGAQVDzyrFFRBA%40mail.gmail.com.
