Le 28/12/2019 à 14:37, Mark Roszko a écrit : > But that 1.600 is not a double/floating number, it truncated from the > double of 1.600000000000000088817841970012523233890533447265625 > > The entire complaint I believe is when it comes to serializing to JSON > in 99% of software of all languages, you do not apply custom > formatting to convert doubles to having less digits, you literally > store the data type as is for what's considered a JSON "number". > Otherwise we should be storing the float as string and applying the > custom formatting in the conversion to string.
OK. I am thinking we have to use a reasonable and readable notation (like in all our kicad files). To encode a board thickness, 1.600 is readable. 1.600000000000000088817841970012523233890533447265625 is just ridiculous (for any value in a config file). > > On Sat, Dec 28, 2019 at 8:01 AM jp charras <jp.char...@wanadoo.fr> wrote: >> >> Le 24/12/2019 à 21:43, Jon Evans a écrit : >>> OK, so both the JSON format itself and the Ucamco gerber format (which >>> is not necessarily the same as the job file format, but hey) specify >>> storing doubles. >>> But, the examples in the Ucamco doc, and KiCad itself, do not store doubles. >>> >>> I have to imagine that the gerber job file format is so new that it >>> isn't entrenched in anyone's workflow yet, and if it is, they are not >>> relying on this quirk of KiCad's implementation (but anything is possible). >>> The only way to get KiCad's behavior is through manual formatting of >>> JSON, so anyone who writes software that parses job files through a JSON >>> parsing library is going to have those values "upcasted" anyway. >>> >>> My personal opinion is that we should bite the bullet and change the >>> behavior to comply with the standard (i.e. store doubles), and also >>> suggest to Ucamco that they revise the job file spec to be more explicit >>> about this. >>> >>> Perhaps JP should weigh in on this as well. >>> >>> -Jon >> >> Sorry for the delay. >> >> I am unsure to understand the meaning of >> "KiCad itself do not store doubles" >> (in gerber job files) >> >> A line like: >> "BoardThickness": 1.600, >> >> stores a double: >> AFAIK, "1.600" is of course a floating number, and also a double, not >> an integer. >> >> In job files, most of values (board sizes, layers thickness, clearances) >> are "mechanical" values. >> >> A reasonable precision is the micron for this kind of parameters. >> >> No need to use nanometers. >> So values are written using 3 digits for the mantissa. >> >> Using the notation: >> "BoardThickness": 1600e-3, >> is perfectly valid, but useless and less readable. >> >> FYI, using 6 digits (1 nanometer) in other Gerber files is needed to >> avoid coordinates truncation. >> >> 3 digits is certainly enough to fabricate a board. >> Unfortunately, truncation slightly modify polygon coordinates, and this >> truncation can (and frequently does) create self intersecting polygons. >> (self intersecting polygons are illegal). >> >> -- >> Jean-Pierre CHARRAS >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp > > > -- Jean-Pierre CHARRAS _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
