On Mon, Jul 11, 2016 at 9:38 PM, Steven D'Aprano <st...@pearwood.info> wrote:
> For integers, printf and % interpret the so-called "precision" field of the
> format string not as a measurement precision (number of decimal places),
> but as the number of digits to use (which is different from the total field
> width). For example:
>
>
> py> "%10.8x" % 123
> ' 0000007b'
>
> How anyone can possibly claim this makes no sense is beyond me! Is the
> difference between "number of digits" and "number of decimal places" really
> so hard to grok? I think not.
I never claimed it's not useful. I don't really have a problem with
format supporting it, either. But if it does, then don't call it
"precision". That's like writing a function that calculates a mean and
calling it "mean", except that if passed a bunch of complex numbers,
it just returns the sum instead. I don't know of anybody who would
consider that good design, and the "precision" field in printf-style
formatting isn't good design either. But it has history behind it, so
does that put it in the right?
> And it's clearly useful: with integers, particular if they represent
> fixed-size byte quantities, it is very common to use leading zeroes. To a
> programmer the hex values 7b, 007b and 0000007b have very different
> meanings: the first is a byte, the second may be a short int, and the third
> may be a long int.
And what about 0007b? After all, the very example that started this
thread wanted 5 hex digits, not a nice, even power of 2.
> Why shouldn't we use the "precision" field for this?
For the same reason that we shouldn't use the "mean" function to calculate sums.
>>>> If you truly wanted to format the number with a precision
>>>> of 5 digits, it would look like this:
>>>>
>>>> 0x123.00
>>>
>>> Er, no, because its an integer.
>>
>> Which is why if you actually want to do this, you should convert it to
>> a decimal or a float first (of course, those don't support hexadecimal
>> output, so if you actually want hexadecimal output *and* digits after
>> the (hexa)decimal point, then I think you would just have to roll your
>> own formatting at that point).
>
> What? No no no. Didn't you even look at Lawrence's example? He doesn't want
> to format the number with decimal places at all.
I was referring to the example above. I'm completely aware that it's
not the same as what Lawrence wanted.
> Converting an integer to a float just to use the precision field is just
> wrong.
What if I've been doing my math with fixed-point integers (because I
don't know about or just don't like decimals), and now I want to
format them for output? Is this just wrong?
'{:.2f}'.format(int_value / 100)
> Now lets go the other way. How to you distinguish between a distance
> measured using an unmarked metre stick, giving us an answer of 123 metres,
> versus something measured with a 10km ruler(!) with one metre markings?
> Obviously with *leading* zeroes rather than trailing zeroes.
Fair enough, but I still wouldn't call that "precision".
> It *does* matter for measuring curves, but paradoxically the bigger the
> measuring stick (the more leading zeroes) the worse your measurement is
> likely to be. This is the problem of measuring coastlines and is related to
> fractal dimension. Suppose I lay my 10km long measuring stick along some
> piece of coastline, and measure it as 00123 metres. (It's a *thought
> experiment*, don't hassle me about the unfeasibly large stick. Divide
> everything by a thousand and call it a 10m stick marked in millimetres if
> you like.) Chances are that if I used a 1 metre measuring stick, and
> followed the contour of the coast more closely, I'd get a different number.
> So the more leading zeroes, the less accurate your measurement is likely to
> be. But interesting as this is, for most purposes either we're not
> measuring a curve, or we are but pretend we're not and ignore the fractal
> dimension.
If you use a 1 meter stick to measure the coastline, you'll go mad as
the tide keeps ruining your careful measurements. Best to just use the
10 km stick and get it over with.
--
https://mail.python.org/mailman/listinfo/python-list
