Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #111235 > unrolled thread

Curious Omission In New-Style Formats

Back to article view | Back to comp.lang.python

Contents

  Curious Omission In New-Style Formats Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-09 22:54 -0700
    Re: Curious Omission In New-Style Formats Ian Kelly <ian.g.kelly@gmail.com> - 2016-07-10 01:21 -0600
      Re: Curious Omission In New-Style Formats Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-10 17:34 -0700
        Re: Curious Omission In New-Style Formats Ian Kelly <ian.g.kelly@gmail.com> - 2016-07-11 09:04 -0600
          Re: Curious Omission In New-Style Formats Steven D'Aprano <steve@pearwood.info> - 2016-07-12 02:28 +1000
            Re: Curious Omission In New-Style Formats Ethan Furman <ethan@stoneleaf.us> - 2016-07-11 10:24 -0700
              Re: Curious Omission In New-Style Formats Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-07-12 11:47 +1200
                Re: Curious Omission In New-Style Formats Ethan Furman <ethan@stoneleaf.us> - 2016-07-11 17:24 -0700
                Re: Curious Omission In New-Style Formats Ian Kelly <ian.g.kelly@gmail.com> - 2016-07-11 19:16 -0600
            Re: Curious Omission In New-Style Formats Ian Kelly <ian.g.kelly@gmail.com> - 2016-07-11 12:38 -0600
              Re: Curious Omission In New-Style Formats Steven D'Aprano <steve@pearwood.info> - 2016-07-12 13:38 +1000
                Re: Curious Omission In New-Style Formats Ian Kelly <ian.g.kelly@gmail.com> - 2016-07-13 00:21 -0600
                  Re: Curious Omission In New-Style Formats Marko Rauhamaa <marko@pacujo.net> - 2016-07-13 09:57 +0300
                  Re: Curious Omission In New-Style Formats Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-13 00:05 -0700
                    Re: Curious Omission In New-Style Formats Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-07-13 18:49 +1000
                      Re: Curious Omission In New-Style Formats Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-07-13 16:01 +0200
                      Re: Curious Omission In New-Style Formats Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-07-13 20:04 -0400
                  Re: Curious Omission In New-Style Formats Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-13 15:24 -0700
                    Re: Curious Omission In New-Style Formats Ian Kelly <ian.g.kelly@gmail.com> - 2016-07-13 18:45 -0600
                      Re: Curious Omission In New-Style Formats Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-13 20:39 -0700
                        Re: Curious Omission In New-Style Formats Ian Kelly <ian.g.kelly@gmail.com> - 2016-07-13 23:18 -0600
                          Re: Curious Omission In New-Style Formats Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-07-14 17:47 +1000
                            Re: Curious Omission In New-Style Formats Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-07-14 07:34 -0400
                            Re: Curious Omission In New-Style Formats Ian Kelly <ian.g.kelly@gmail.com> - 2016-07-14 08:30 -0600
                              Re: Curious Omission In New-Style Formats Marko Rauhamaa <marko@pacujo.net> - 2016-07-14 19:02 +0300
                                Re: Curious Omission In New-Style Formats Ian Kelly <ian.g.kelly@gmail.com> - 2016-07-14 11:10 -0600
                                  Re: Curious Omission In New-Style Formats Marko Rauhamaa <marko@pacujo.net> - 2016-07-14 20:30 +0300
                                    Re: Curious Omission In New-Style Formats Ian Kelly <ian.g.kelly@gmail.com> - 2016-07-14 18:17 -0600
                                      Re: Curious Omission In New-Style Formats Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-14 18:08 -0700
                                      Re: Curious Omission In New-Style Formats Marko Rauhamaa <marko@pacujo.net> - 2016-07-15 09:06 +0300
                                        Re: Curious Omission In New-Style Formats Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-07-15 09:54 +0200
                                          Re: Curious Omission In New-Style Formats Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-07-15 11:40 +0300
                                            Re: Curious Omission In New-Style Formats Steven D'Aprano <steve@pearwood.info> - 2016-07-15 20:56 +1000
                                              Re: Curious Omission In New-Style Formats Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-07-15 13:44 +0200
                                                Re: Curious Omission In New-Style Formats Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-07-15 16:38 +0300
                                                  Re: Curious Omission In New-Style Formats Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-07-15 16:47 +0200
                                              Re: Curious Omission In New-Style Formats Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-07-15 16:13 +0300
                                                Re: Curious Omission In New-Style Formats Steven D'Aprano <steve@pearwood.info> - 2016-07-16 01:12 +1000
                                              Re: Curious Omission In New-Style Formats Random832 <random832@fastmail.com> - 2016-07-15 09:39 -0400
                                              Re: Curious Omission In New-Style Formats Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-07-15 16:32 +0200
                                            Re: Curious Omission In New-Style Formats Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-07-15 13:05 +0200
                                              Re: Curious Omission In New-Style Formats Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-07-15 16:28 +0300
                                                Re: Curious Omission In New-Style Formats Steven D'Aprano <steve@pearwood.info> - 2016-07-16 01:13 +1000
                                                  Re: Curious Omission In New-Style Formats Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-07-15 18:27 +0300
                                          Re: Curious Omission In New-Style Formats Marko Rauhamaa <marko@pacujo.net> - 2016-07-15 12:20 +0300
                                            Re: Curious Omission In New-Style Formats Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-07-15 12:44 +0200
                                  Re: Curious Omission In New-Style Formats Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-14 16:26 -0700
                            Re: Curious Omission In New-Style Formats Robert Kern <robert.kern@gmail.com> - 2016-07-14 16:17 +0100
                      Re: Curious Omission In New-Style Formats Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-15 16:35 -0700
                        Re: Curious Omission In New-Style Formats Chris Angelico <rosuav@gmail.com> - 2016-07-16 10:57 +1000
                    Re: Curious Omission In New-Style Formats MRAB <python@mrabarnett.plus.com> - 2016-07-14 01:59 +0100
                Re: Curious Omission In New-Style Formats Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-07-13 07:46 -0400
                  Re: Curious Omission In New-Style Formats Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-07-13 16:04 +0300
                Re: Curious Omission In New-Style Formats Chris Angelico <rosuav@gmail.com> - 2016-07-13 23:00 +1000
                  Re: Curious Omission In New-Style Formats Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-07-13 16:16 +0300
                    Re: Curious Omission In New-Style Formats Chris Angelico <rosuav@gmail.com> - 2016-07-13 23:49 +1000
                      Re: Curious Omission In New-Style Formats Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-07-13 17:23 +0300
                        Re: Curious Omission In New-Style Formats Chris Angelico <rosuav@gmail.com> - 2016-07-14 00:28 +1000
            Re: Curious Omission In New-Style Formats Terry Reedy <tjreedy@udel.edu> - 2016-07-11 14:54 -0400
            Re: Curious Omission In New-Style Formats Ian Kelly <ian.g.kelly@gmail.com> - 2016-07-11 13:27 -0600
            Re: Curious Omission In New-Style Formats Michael Torrie <torriem@gmail.com> - 2016-07-11 14:06 -0600
            Re: Curious Omission In New-Style Formats Random832 <random832@fastmail.com> - 2016-07-11 16:34 -0400
            Re: Curious Omission In New-Style Formats Terry Reedy <tjreedy@udel.edu> - 2016-07-11 16:52 -0400
            What is precision of a number representation? (was: Curious Omission In New-Style Formats) Ben Finney <ben+python@benfinney.id.au> - 2016-07-12 06:56 +1000
              Re: What is precision of a number representation? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-11 23:28 +0100
            Re: What is precision of a number representation? Ethan Furman <ethan@stoneleaf.us> - 2016-07-11 14:22 -0700
            Re: What is precision of a number representation? (was: Curious Omission In New-Style Formats) Chris Angelico <rosuav@gmail.com> - 2016-07-12 07:51 +1000
              Re: What is precision of a number representation? (was: Curious Omission In New-Style Formats) Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-07-12 00:14 +0100
                Re: What is precision of a number representation? (was: Curious Omission In New-Style Formats) Chris Angelico <rosuav@gmail.com> - 2016-07-12 09:57 +1000
              Re: What is precision of a number representation? (was: Curious Omission In New-Style Formats) Steven D'Aprano <steve@pearwood.info> - 2016-07-12 14:19 +1000
                Re: What is precision of a number representation? (was: Curious Omission In New-Style Formats) Chris Angelico <rosuav@gmail.com> - 2016-07-12 14:36 +1000
                Re: What is precision of a number representation? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-07-12 11:50 +0200
                  Re: What is precision of a number representation? Marko Rauhamaa <marko@pacujo.net> - 2016-07-12 13:27 +0300
                    Re: What is precision of a number representation? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-07-12 13:02 +0200
                  Re: What is precision of a number representation? Steven D'Aprano <steve@pearwood.info> - 2016-07-12 23:16 +1000
            Re: What is precision of a number representation? Ethan Furman <ethan@stoneleaf.us> - 2016-07-11 15:17 -0700
              Re: What is precision of a number representation? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-07-12 16:21 +1000
                Re: What is precision of a number representation? Random832 <random832@fastmail.com> - 2016-07-12 09:36 -0400
            Re: What is precision of a number representation? Ethan Furman <ethan@stoneleaf.us> - 2016-07-11 15:29 -0700
            Re: Curious Omission In New-Style Formats Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-07-12 11:26 +1200
            Re: What is precision of a number representation? Chris Angelico <rosuav@gmail.com> - 2016-07-12 11:57 +1000
            Re: What is precision of a number representation? Ben Finney <ben+python@benfinney.id.au> - 2016-07-12 13:41 +1000
            Re: What is precision of a number representation? Terry Reedy <tjreedy@udel.edu> - 2016-07-12 00:14 -0400
            Re: What is precision of a number representation? Terry Reedy <tjreedy@udel.edu> - 2016-07-12 00:17 -0400

Page 1 of 5  [1] 2 3 4 5  Next page →

#111235 — Curious Omission In New-Style Formats

In printf-style formats, you can specify the number of digits for an integer separately from the field width. E.g.

    >>> "%#0.5x" % 0x123
    '0x00123'

but not in new-style formats:

    >>> "{:#0.5x}".format(0x123)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    ValueError: Precision not allowed in integer format specifier

The field width itself doesn’t give the right number of digits in this case:

    >>> "{:#05x}".format(0x123)
    '0x123'

because you lose 2 characters for the “0x” prefix.

[toc] | [next] | [standalone]

#111237

On Sat, Jul 9, 2016 at 11:54 PM, Lawrence D’Oliveiro
<lawrencedo99@gmail.com> wrote:
> In printf-style formats, you can specify the number of digits for an integer separately from the field width. E.g.
>
>     >>> "%#0.5x" % 0x123
>     '0x00123'
>
> but not in new-style formats:
>
>     >>> "{:#0.5x}".format(0x123)
>     Traceback (most recent call last):
>       File "<stdin>", line 1, in <module>
>     ValueError: Precision not allowed in integer format specifier
>
> The field width itself doesn’t give the right number of digits in this case:
>
>     >>> "{:#05x}".format(0x123)
>     '0x123'
>
> because you lose 2 characters for the “0x” prefix.

So add 2 to the field width to account for the fixed-size prefix.

>>> '{:#07x}'.format(0x123)
'0x00123'

It's specified in PEP 3101 that the precision is ignored for integer
conversions. Apparently that changed from "ignored" to "not allowed"
in 3.1, as per the documentation. I'm not sure what the reasoning was,
except perhaps that precision doesn't really make sense for integers
in the first place.

[toc] | [prev] | [next] | [standalone]

#111259

On Sunday, July 10, 2016 at 7:22:42 PM UTC+12, Ian wrote:
> On Sat, Jul 9, 2016 at 11:54 PM, Lawrence D’Oliveiro wrote:
>> In printf-style formats, you can specify the number of digits for an
>> integer separately from the field width. E.g.
>>
>>     >>> "%#0.5x" % 0x123
>>     '0x00123'
>>
> except perhaps that precision doesn't really make sense for integers
> in the first place.

Except that it does make sense, as I showed in my example.

<http://man7.org/linux/man-pages/man3/printf.3.html>

[toc] | [prev] | [next] | [standalone]

#111272

On Sun, Jul 10, 2016 at 6:34 PM, Lawrence D’Oliveiro
<lawrencedo99@gmail.com> wrote:
> On Sunday, July 10, 2016 at 7:22:42 PM UTC+12, Ian wrote:
>> On Sat, Jul 9, 2016 at 11:54 PM, Lawrence D’Oliveiro wrote:
>>> In printf-style formats, you can specify the number of digits for an
>>> integer separately from the field width. E.g.
>>>
>>>     >>> "%#0.5x" % 0x123
>>>     '0x00123'
>>>
>> except perhaps that precision doesn't really make sense for integers
>> in the first place.
>
> Except that it does make sense, as I showed in my example.

Your example showed a 3-digit number being formatted with a requested
precision of 5 digits. The way this was done was by left-padding the
number with 0s until there were 5 digits, but still only 3 digits of
precision. If you truly wanted to format the number with a precision
of 5 digits, it would look like this:

    0x123.00

It may happen to do what you want in the printf-style format, but
calling the field "precision" is at best misleading, and there are
other ways to accomplish the same result.

> <http://man7.org/linux/man-pages/man3/printf.3.html>

Well, str.format does not use the same syntax as printf.

[toc] | [prev] | [next] | [standalone]

#111273

On Tue, 12 Jul 2016 01:04 am, Ian Kelly wrote:

> On Sun, Jul 10, 2016 at 6:34 PM, Lawrence D’Oliveiro
> <lawrencedo99@gmail.com> wrote:
>> On Sunday, July 10, 2016 at 7:22:42 PM UTC+12, Ian wrote:
>>> On Sat, Jul 9, 2016 at 11:54 PM, Lawrence D’Oliveiro wrote:
>>>> In printf-style formats, you can specify the number of digits for an
>>>> integer separately from the field width. E.g.
>>>>
>>>>     >>> "%#0.5x" % 0x123
>>>>     '0x00123'
>>>>
>>> except perhaps that precision doesn't really make sense for integers
>>> in the first place.
>>
>> Except that it does make sense, as I showed in my example.
> 
> Your example showed a 3-digit number being formatted with a requested
> precision of 5 digits. The way this was done was by left-padding the
> number with 0s until there were 5 digits, 

Right.

> but still only 3 digits of precision.

Er, what? I count *five* digits in "00123", not three.

You seem to be assuming that "precision" can only refer to digits after the
decimal place, but that's a dubious proposition. That might be the way
printf interprets the precision for *floats*, but its not the way it
interprets the precision for *ints*, and who is to say that one way is
right and the other is wrong?


> 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.

Now, if I remember what I was told in my physics class circa 1985 correctly:

12345678 written with a precision of five digits is 12346000;

12345678 written with a precision of five decimal places is 12345678.00000.

How should we extrapolate to the case where the precision *in digits* is
greater than the number of digits available? Well, for the "decimal places"
case, we add zeroes to the right. So for the digits case, we ought to add
zeroes to the left, which brings us back to the printf usage:

123 with five digits of precision is "00123".


And we can combine that with the overall length to pad the result with
spaces as well.

It seems to me that it would be reasonable to support this for format() too.


> It may happen to do what you want in the printf-style format, but
> calling the field "precision" is at best misleading, and there are
> other ways to accomplish the same result.

Naturally. So why bother to have .format() or % in the first place? There's
always other ways to accomplish the same result.





-- 
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

[toc] | [prev] | [next] | [standalone]

#111274

On 07/11/2016 09:28 AM, Steven D'Aprano wrote:
> On Tue, 12 Jul 2016 01:04 am, Ian Kelly wrote:

> Er, what? I count *five* digits in "00123", not three.
>
> You seem to be assuming that "precision" can only refer to digits after the
> decimal place, but that's a dubious proposition.

I will readily admit to not having a maths degree, and so of course to 
me saying the integer 123 has a precision of 5, 10, or 99 digits seems 
like hogwash to me.

But I'm always willing to learn.  So please explain what 123 with a 
precision of five integer digits means, and what to do we gain by saying 
such a thing?

--
~Ethan~

[toc] | [prev] | [next] | [standalone]

#111303

Ethan Furman wrote:
> I will readily admit to not having a maths degree, and so of course to 
> me saying the integer 123 has a precision of 5, 10, or 99 digits seems 
> like hogwash to me.

Seems to me insisting that the number after the dot be
called "precision" in all cases is imposing a foolish
consistency.

There's a third thing that %-formats use it for as well:
for a string it means the maximum number of characters
to include.

To my way of thinking, the format string just lets you
specify uop to two numbers, the interpratation or wnich
is up to toe format concerned.

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#111305

On 07/11/2016 04:47 PM, Gregory Ewing wrote:
> Ethan Furman wrote:

>> I will readily admit to not having a maths degree, and so of course to
>> me saying the integer 123 has a precision of 5, 10, or 99 digits seems
>> like hogwash to me.
>
> Seems to me insisting that the number after the dot be
> called "precision" in all cases is imposing a foolish
> consistency.

That isn't what I said.

> To my way of thinking, the format string just lets you
> specify up to two numbers, the interpretation or which
> is up to to format concerned.

Agreed.

--
~Ethan~

[toc] | [prev] | [next] | [standalone]

#111307

On Mon, Jul 11, 2016 at 5:47 PM, Gregory Ewing
<greg.ewing@canterbury.ac.nz> wrote:
> Ethan Furman wrote:
>>
>> I will readily admit to not having a maths degree, and so of course to me
>> saying the integer 123 has a precision of 5, 10, or 99 digits seems like
>> hogwash to me.
>
>
> Seems to me insisting that the number after the dot be
> called "precision" in all cases is imposing a foolish
> consistency.
>
> There's a third thing that %-formats use it for as well:
> for a string it means the maximum number of characters
> to include.
>
> To my way of thinking, the format string just lets you
> specify uop to two numbers, the interpratation or wnich
> is up to toe format concerned.

The builtin types strive for consistency with each other and with
printf-style formats, but ultimately the parsing of the format spec is
entirely at the whim of the __format__ method of the type being
formatted. You could make it a Turing-complete mini-language if you
liked.

py> class Foo:
...     def __format__(self, spec):
...         return str(eval(spec)(self))
...
py> '{:id}'.format(Foo())
'139869336090384'
py> '{:repr}'.format(Foo())
'<__main__.Foo object at 0x7f35de17b7b8>'
py> '{:lambda x: x == 42}'.format(Foo())
'False'

[toc] | [prev] | [next] | [standalone]

#111283

On Mon, Jul 11, 2016 at 10:28 AM, Steven D'Aprano <steve@pearwood.info> wrote:
> On Tue, 12 Jul 2016 01:04 am, Ian Kelly wrote:
>> Your example showed a 3-digit number being formatted with a requested
>> precision of 5 digits. The way this was done was by left-padding the
>> number with 0s until there were 5 digits,
>
> Right.
>
>> but still only 3 digits of precision.
>
> Er, what? I count *five* digits in "00123", not three.
>
> You seem to be assuming that "precision" can only refer to digits after the
> decimal place, but that's a dubious proposition. That might be the way
> printf interprets the precision for *floats*, but its not the way it
> interprets the precision for *ints*, and who is to say that one way is
> right and the other is wrong?

In what way do the leading zeroes in "00123" add to the precision of
the number? 00123 is the same quantity as 123 and represents no more
precise a measurement. Neither does 0000000123 for "ten" digits of
precision. We could just keep adding zeroes ad nauseam and then claim
that 123 has infinite precision.

Clearly, that's wrong.

>> 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).

>> It may happen to do what you want in the printf-style format, but
>> calling the field "precision" is at best misleading, and there are
>> other ways to accomplish the same result.
>
> Naturally. So why bother to have .format() or % in the first place? There's
> always other ways to accomplish the same result.

I think it's just a case of purity winning out over practicality. As I
said before, I don't really know why the decision was made to not
support or allow it. What I've written above was my best guess.

[toc] | [prev] | [next] | [standalone]

#111311

On Tue, 12 Jul 2016 04:38 am, Ian Kelly wrote:

> In what way do the leading zeroes in "00123" add to the precision of
> the number? 00123 is the same quantity as 123 and represents no more
> precise a measurement. 

You guys... next you're going to tell me that 1.23 and 1.2300 are the same
quantity and represent no more precise a measurement :-) And keep adding
zeroes 1.230000000... and claim infinite precision.

That's not now "precision" works. Its true that *mathematically* leading
zeroes don't change the number, but neither do trailing zeroes.
Nevertheless, we *interpret* them as having meaning, as indicators of the
precision of measurement in the mathematical sense.

In a moment, I'm going to attempt to justify a reasonable meaning for
leading zeroes. But that's actually not relevant. printf (and Python's %
string operator) interprets the precision field in the mathematical sense
for floats, but that's not the only sense possible. The word "precise" has
a number of meanings, including:

- exactness
- accurate
- strict conformity to a rule
- politeness and nicety
- the quality of being reproducible


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.

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.

Why shouldn't we use the "precision" field for this? It doesn't mean what
scientists mean by precision, but so what? That's not important. Scientists
don't usually have to worry about leading zeroes, but programmers do, and
its useful to distinguish between the *total* width (padded with spaces)
and the *number* width (padded with zeroes).

I think that printf and % get this right, and format() gets it wrong.


[...]
>>> 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.

Converting an integer to a float just to use the precision field is just
wrong. That's like saying that "1234".upper() doesn't make sense because
digits don't have uppercase forms, and if you really want to convert "1234"
to uppercase you should spell it out in words first:

"onetwothreefour".upper()



Earlier, I said that I would attempt to give a justification for leading
zeroes in terms of measurement too. As I said, this is strictly irrelevant,
but I thought it was interesting and so I'm going to share. You can stop
reading now if you prefer.

If you measure something with a metre ruler marked in centimetres, getting
1.23 metres, that's quite different from measuring it with a ruler marked
in tenths of a millimetres and getting 1.2300. That's basic usage for
precision in terms of number of decimal places and I'm sure we all agree
about that.

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. If I lay out
the one metre stick 123 times, then I write the measurement as 123. If I
lay out my 10km ruler and note the position, I measure:

zero tens of kilometres;
zero kilometres;
three hundreds-of-metres;
two tens-of-metres;
three metres;

giving 00123 metres of course. Simple!

Of course, it's rare that we do that. Why would we bother to distinguish the
two situations? And who the hell has a 10km long measuring stick?

If I'm a scientist, I'll probably write them both as 123m and not care about
the size of the measuring stick, only about the smallest marking on it. At
least for measuring straight-line distances, the size of the measuring
stick generally doesn't matter.

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.

But as I said, none of this is strictly relevant to the question of
interpreting the "precision" field of format strings as leading zeroes for
integers. That has a common, standard interpretation as "number of digits"
(as opposed to "number of decimal places") and is very useful. I maintain
that format() has made a mistake by forbidding it.



-- 
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

[toc] | [prev] | [next] | [standalone]

#111376

On Mon, Jul 11, 2016 at 9:38 PM, Steven D'Aprano <steve@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.

[toc] | [prev] | [next] | [standalone]

#111378

Ian Kelly <ian.g.kelly@gmail.com>:

> 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?

Apparently, the original intent for the field was for precision only,
and the syntax of placing the precision after a dot reinforces the
notion. Later, the field found other neat uses and people didn't think
of going back and renaming the field in source code and all of the
documentation.

For Unix hackers, this was a neat trick, a laudable hack.

A somewhat similar example is the "execute" permission flag on Unix
files. On regular files, it expresses whether the file can be executed.
On directory files, it expresses whether it can be "entered".

Just as you can enter into philosophical discussions about whether
integers or strings can have a precision, you can debate whether a
directory can be executed.


Marko

[toc] | [prev] | [next] | [standalone]

#111380

On Wednesday, July 13, 2016 at 6:22:31 PM UTC+12, Ian wrote:

> 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".

Like it or not, that is the accepted term, as used in the printf(3) man page.

Feel free not to use common accepted terms if you don’t want. You can use words to mean whatever you avocado, but don’t expect other people to carrot.

[toc] | [prev] | [next] | [standalone]

#111382

On Wednesday 13 July 2016 17:05, Lawrence D’Oliveiro wrote:

> On Wednesday, July 13, 2016 at 6:22:31 PM UTC+12, Ian wrote:
> 
>> 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".
> 
> Like it or not, that is the accepted term, as used in the printf(3) man page.
> 
> Feel free not to use common accepted terms if you don’t want. You can use
> words to mean whatever you avocado, but don’t expect other people to carrot.

+1 QOTW


-- 
Steve

[toc] | [prev] | [next] | [standalone]

#111400

Op 13-07-16 om 10:49 schreef Steven D'Aprano:
> On Wednesday 13 July 2016 17:05, Lawrence D’Oliveiro wrote:
>
>> On Wednesday, July 13, 2016 at 6:22:31 PM UTC+12, Ian wrote:
>>
>>> 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".
>> Like it or not, that is the accepted term, as used in the printf(3) man page.
>>
>> Feel free not to use common accepted terms if you don’t want. You can use
>> words to mean whatever you avocado, but don’t expect other people to carrot.
> +1 QOTW

But as far as I know, "significant digits" is not the accepted term for the
width of the representation when you print a number with added zeroes in front of it.

So when we start we a term like "precision" and people jump from that to "significant
digits", maybe we should consider how confusing the common accepted term can be.

-- 
Antoon

[toc] | [prev] | [next] | [standalone]

#111420

On Wed, 13 Jul 2016 16:01:09 +0200, Antoon Pardon
<antoon.pardon@rece.vub.ac.be> declaimed the following:

>
>But as far as I know, "significant digits" is not the accepted term for the
>width of the representation when you print a number with added zeroes in front of it.
>
	From my 70s COBOL class -- that would likely be described as a
"zero-filled" PIC clause.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#111414

On Wednesday, July 13, 2016 at 6:22:31 PM UTC+12, Ian wrote:

> ... don't call it "precision".

How about “mantissa length”, then. That sufficiently neutral for you?

[toc] | [prev] | [next] | [standalone]

#111424

On Wed, Jul 13, 2016 at 4:24 PM, Lawrence D’Oliveiro
<lawrencedo99@gmail.com> wrote:
> On Wednesday, July 13, 2016 at 6:22:31 PM UTC+12, Ian wrote:
>
>> ... don't call it "precision".
>
> How about “mantissa length”, then. That sufficiently neutral for you?

That makes even less sense for integers.

[toc] | [prev] | [next] | [standalone]

#111426

On Thursday, July 14, 2016 at 12:46:26 PM UTC+12, Ian wrote:
> On Wed, Jul 13, 2016 at 4:24 PM, Lawrence D’Oliveiro wrote:
>> On Wednesday, July 13, 2016 at 6:22:31 PM UTC+12, Ian wrote:
>>
>>> ... don't call it "precision".
>>
>> How about “mantissa length”, then. That sufficiently neutral for you?
> 
> That makes even less sense for integers.

Why?

[toc] | [prev] | [next] | [standalone]

Page 1 of 5  [1] 2 3 4 5  Next page →

Back to top | Article view | comp.lang.python

csiph-web