The Ucamco "decimal" type is defined on page 40 of [1]. They define it as fitting into an IEEE double.
I think keeping user-specified data would be desired and not truncate the value unless requested.
Seth
[1] http://www.ucamco.com/files/downloads/file/81/the_gerber_file_format_specification.pdf
On Dec 24, 2019 12:06 PM, Jeff Young <j...@rokeby.ie> wrote:
Safer because we’ve been writing them out like that for some time. Maybe someone has some huge hack that uses fixed-length regular expressions to parse them or something.In the absence of a spec, the examples are what people use.I’m not convinced this is the best plan either — but I am convinced it’s the safest.Cheers,Jeff.On 24 Dec 2019, at 19:29, Jon Evans <jon@craftyjon.com> wrote:Why is B safer? To me, B sounds riskier as there is a chance we are throwing away data. I'm not in favor of implementing B without a clear spec (and I guess Ucamco would need to be involved) on what guarantees can be made.Right now, we implement B based on some apparently arbitrary assumptions about what data can be thrown away. Re-implementing the current behavior in the new library would certainly be possible, I'm just not convinced that it's the best plan.-JonOn Tue, Dec 24, 2019, 13:54 Jeff Young <jeff@rokeby.ie> wrote:Safest would be (b).We could probably do something pretty dumb (ie: set a single value in the JSON printer which it uses for precision).On 24 Dec 2019, at 15:22, Jon Evans <jon@craftyjon.com> wrote:_______________________________________________Hi all,The Gerber job file specification[1] says that the format follows the JSON standard, and doesn't say much else about numeric value storage.But, in the examples in that spec, decimal (floating-point) values are all truncated with only a few digits after the decimal point.The manual JSON generation code that exists today follows along these examples, truncating floating-point numbers using formatting like %.3f and so on. Now I'm working on switching us over to using a library for this JSON generation, but it will output floating-point values as doubles without any such truncation.For computer software reading these job files, I would guess this has no impact. But for humans opening up the file, they may find that the numbers stored don't match their expectations.What should we do about this?(a) nothing, storing doubles in the file is fine(b) find some way to manually truncate/round values to some precision, but still write them to the file as "decimals" -- if so, what should the spec be for this rounding / truncation?(c) something else?Best,Jon
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
_______________________________________________ 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
