Re: [Bimi] [rfc-i] SVG P/S Feedback

[Brian E Carpenter <[e-mail]>]

On 31-Aug-20 13:52, Martin J. Dürst wrote:
> Hello Brian, others,
> 
> On 31/08/2020 08:36, Brian E Carpenter wrote:
>> On 31-Aug-20 10:09, Leonard Rosenthol wrote:
>>> Brian - not sure what you are looking at, but in SVG 1.1 (https://www.w3.org/TR/SVG11/single-page.html#types-DataTypeNumber), I see the following definition for a `<number>`
> 
> [snip]
> 
>> Yes, and that's all fine. But when you start converting formats, and the round trip converts
>> 32.459999 into 32.424, there's clearly a problem of how real numbers work in a particular hardware and floating point library, and/or a difference in how real numbers are handled in the two formats. So specifying how real numbers are represented in various SGML dialects is only part of the problem.
>>
>> I'm no expert on this, but https://en.wikipedia.org/wiki/IEEE_754 tells me that it's very complex and there are many cans of worms.
> 
> Floating point numbers are what they are, even if many people, including 
> engineers, tend to ignore or suppress the details.
> 
> The programming language Ruby has some pointers to information about 
> floating point numbers on the otherwise quite small top page of their 
> bug tracker (https://bugs.ruby-lang.org/). The reason for this is the 
> frequency with which we get bug reports about floating point number 
> calculations that turn out not to be bugs.
> 
> For people interested in details, I suggest reading "What Every Computer 
> Scientist Should Know About Floating-Point Arithmetic"
> (https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html).
> 
> Btw, if a conversion changes 32.459999 into 32.424, then we indeed have 
> a serious problem. Floating point arithmetic isn't that inaccurate, even 
> on the worst hardware. If the conversion is from 32.459999 to 32.46, on 
> the other hand, then that's entirely possible, and shouldn't create any 
> problems in patent litigation.

The case in point involves two particular converters from SVG to PDF and
back, so it's presumably a complex interaction between those two formats
and how the converters work, rather than a gross error in the floating point
implementations. I don't think we need to debug it, but simply to note
that if we stick to the current doctrine that the xml2rfcv3 file *is*
the canonical form of an RFC, we will be OK. If we try to define a
reversible translation to another format, I think we would come to deeply
regret it.

   Brian
 
> 
>> Regards
>>      Brian
>