Re: [Libguestfs] [PATCH nbdkit 1/5] Add new public nbdkit_parse_probability function

On 5/16/23 21:35, Eric Blake wrote: To clarify, I didn't believe it could in any way offend you, technically speaking; I thought my opinion could perhaps be considered offensive by the author of the original QEMU feature, i.e. by the developer who had introduced floating point parsing originally to QEMU (I don't know who that developer was). You're "only" fixing bugs in an existing feature (and improving its test coverage). I'm challenging the existence of the entire feature. I do agree that *IF* the feature exists, it should be reasonably bug-free. This is actually the core mistake, in my opinion. Preferring "one and half gigabytes" rather than "one billion, six hundred ten million, six hundred twelve thousand, seven hundred thirty six bytes", is understandable. What is *not* understandable, knowing the pitfalls of floating point (!), why the former form was equated with "parsing floating point". Note: I wrote "one and half gigabytes", not "one point five tenths gigabytes". Huge difference! In everyday speech, we use super simple fractions, with both numerator and denominator being very small natural numbers. And especially with multipliers such as K, M, G, T, which are powers of 2 (10, 20, 30, 40, respectively), I would argue that no denominators other than 2, 4 and maybe (!) 8 matter! (Who has ever said, "give me two thirds of a gigabyte"? Or "five sevenths"?) I totally don't see a user entering, as disk size, "1.234567G". I don't even see them entering "1.875G" ("one point eight hundred seventy five thousandths gigabytes"). At best I can see them say "two gigs minus an eighth gig", or "one plus seven eighths gig", but even for that, I need to squint. We don't actually *think* about sizes in numbers that have many digits after the decimal point. What we do is, we think in simple fractions, and have just learned how those simple fractions *look* when written as decimal numbers. So adding a general floating point parser was overkill; it must have looked attractive only because the complications of floating point were under-estimated. So QEMU should have added the following formats instead: - a[s] - b/c[s] - a+b/c[s] where "a" is your usual integer, [s] is an (optional) suffix like K or G, c may be 2, 4 or 8 (nothing else), and b may be [0 .. c-1]. If the suffix is omitted, it is taken as "byte", and then the second and third forms are not permitted (no fractions of bytes). Of course, hindsight is 20/20. I had learned to stay away from floating point very early on; topics in university like bounding errors and non-associativity of floating point addition made me look for articles on the web, and those had permanently convinced me that floating point is *unusable* unless you are able and willing to do complete numerical analysis in your C source code. In practice, C programmers don't even remember the integer promotions and the usual arithmetic conversions. :/ [...] This was just an example (independent of actual fp precision) to illustrate the meaning of the round parens in the footnote. "long double" would work equally well for the example. I remember :) Again: yes. This was only a tangent. I meant to quote the fp->integer conversion rule, and then I thought the related footnote deserved additional (but independent) reasoning. By that point I didn't feel tied to "double" any longer, really. [...] Agreed. I think that, for using floating point, we should: - error-check any conversion from string to binary (object) representation, - bound the parsed values as early as possible, with an eye towards later use, - in each subsequent operation, show that the result will be in range, and (hopefully) will not see catastrophic loss of precision. I don't insist on this; it's just what I could explicitly ACK. *shudder*. :) I didn't read your patches in detail BTW. I went through the subjects in order, and looked at some details. I could tell it required an immense amount of thinking and work. Dealing with (unsigned!) integers is less work, IMO. Thanks! Laszlo