On 28/12/2019 13:37, Mark Roszko wrote:
But that 1.600 is not a double/floating number, it truncated from the
double of 1.600088817841970012523233890533447265625
The value you quote here is illusory: the ieee-754 double format is
incapable of storing more than 17 decimal (53
If the Ucamco specification calls out JSON as the file format, then we
should respect the JSON file formatting regardless of whether it's ugly
or not.
Cheers,
Wayne
On 12/28/19 9:02 AM, Jon Evans wrote:
> I understand that point of view, but how do we determine what is
> "reasonable"?
> The
I understand that point of view, but how do we determine what is
"reasonable"?
The Ucamco spec does not state anything about it, they just refer to the
JSON spec.
If we were to follow the JSON spec, we would not round or truncate.
So I guess what I am asking is, if people think it's important for
Mark is correct: The question is about whether or not we need to apply
specific rounding/truncation (which no third-party JSON library does)
On Sat, Dec 28, 2019 at 8:37 AM Mark Roszko wrote:
> But that 1.600 is not a double/floating number, it truncated from the
> double of
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.600088817841970012523233890533447265625
>
> The entire complaint I believe is when it comes to serializing to JSON
> in 99% of software of all languages,
But that 1.600 is not a double/floating number, it truncated from the
double of 1.600088817841970012523233890533447265625
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
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
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
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.pdfOn
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
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
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 wrote:
>
> Hi all,
>
> The Gerber job file specification[1] says that the format follows the JSON
> standard, and
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
13 matches
Mail list logo
