Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #111235 > unrolled thread
| Started by | Lawrence D’Oliveiro <lawrencedo99@gmail.com> |
|---|---|
| First post | 2016-07-09 22:54 -0700 |
| Last post | 2016-07-12 00:17 -0400 |
| Articles | 20 on this page of 84 — 19 participants |
Back to article view | Back to comp.lang.python
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 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | Michael Torrie <torriem@gmail.com> |
|---|---|
| Date | 2016-07-11 14:06 -0600 |
| Message-ID | <mailman.190.1468267596.2295.python-list@python.org> |
| In reply to | #111273 |
On 07/11/2016 01:27 PM, Ian Kelly wrote:
> On Mon, Jul 11, 2016 at 12:54 PM, Terry Reedy <tjreedy@udel.edu> wrote:
>> In any case, I think it an improvement to say that '0x00123' has a field
>> width of 7 rather than a 'precision' of 5.
>>
>>>>> '{:#07x}'.format(0x123) # specifiy field width
>> '0x00123'
>>>>> "%#0.5x" % 0x123 # specify int precision
>> '0x00123'
>
> It occurs to me now that this does create a challenge if the format is
> meant to support negative numbers as well:
>
>>>> '%#0.5x' % -0x123
> '-0x00123'
>>>> '{:#07x}'.format(-0x123)
> '-0x0123'
I'm not sure I've ever seen a negative hex number in the wild. Usually
when I view a number in hex I am wanting the raw representation. -0x123
with a width of 7 would be 0xFFEDD
[toc] | [prev] | [next] | [standalone]
| From | Random832 <random832@fastmail.com> |
|---|---|
| Date | 2016-07-11 16:34 -0400 |
| Message-ID | <mailman.192.1468269251.2295.python-list@python.org> |
| In reply to | #111273 |
On Mon, Jul 11, 2016, at 16:06, Michael Torrie wrote: > I'm not sure I've ever seen a negative hex number in the wild. Usually > when I view a number in hex I am wanting the raw representation. -0x123 > with a width of 7 would be 0xFFEDD There's nothing "raw" about python int objects. To get what you want, you need to do x & 0xfffff If you have "5" as a parameter, you can get the desired constant as (1 << x*4) - 1.
[toc] | [prev] | [next] | [standalone]
| From | Terry Reedy <tjreedy@udel.edu> |
|---|---|
| Date | 2016-07-11 16:52 -0400 |
| Message-ID | <mailman.194.1468270338.2295.python-list@python.org> |
| In reply to | #111273 |
On 7/11/2016 3:27 PM, Ian Kelly wrote:
> On Mon, Jul 11, 2016 at 12:54 PM, Terry Reedy <tjreedy@udel.edu> wrote:
>> In any case, I think it an improvement to say that '0x00123' has a field
>> width of 7 rather than a 'precision' of 5.
>>
>>>>> '{:#07x}'.format(0x123) # specifiy field width
>> '0x00123'
>>>>> "%#0.5x" % 0x123 # specify int precision
>> '0x00123'
>
> It occurs to me now that this does create a challenge if the format is
> meant to support negative numbers as well:
>
>>>> '%#0.5x' % -0x123
> '-0x00123'
This expands the field from 7 to 8 chars. In running text, this is
alright. In formatted table columns, it is not.
>>>> '{:#07x}'.format(-0x123)
> '-0x0123'
Multiple alternatives
>>> '{: #08x} {: #08x}'.format(0x123, -0x123)
' 0x00123 -0x00123'
>>> '{:+#08x} {:+#08x}'.format(0x123, -0x123)
'+0x00123 -0x00123'
>>> '{0:#0{1}x} {2:+#0{3}x}'.format(0x123, 7, -0x123, 8)
'0x00123 -0x00123'
>>> n1, n2, w = 0x123, -0x123, 7
>>> '{0:#0{1}x} {2:+#0{3}x}'.format(n1, w+(n1<0), n2, w+(n2<0))
'0x00123 -0x00123'
In running text, I ight go with '+','-' prefix.
--
Terry Jan Reedy
[toc] | [prev] | [next] | [standalone]
| From | Ben Finney <ben+python@benfinney.id.au> |
|---|---|
| Date | 2016-07-12 06:56 +1000 |
| Subject | What is precision of a number representation? (was: Curious Omission In New-Style Formats) |
| Message-ID | <mailman.195.1468270587.2295.python-list@python.org> |
| In reply to | #111273 |
Ethan Furman <ethan@stoneleaf.us> writes: > 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. Precision is not a property of the number. It is a property of the *representation* of that number. The representation “1×10²” has a precision of one digit. The representation “100” has a precision of three digits. The representation “00100” has a precision of five digits. The representation “100.00” also has a precision of five digits. Those can all represent the same number; or maybe some of them represent “one hundred” and others represent “one hundred and a millionth”. The representation is only an approximation of the actual number, and the precision tells us how fuzzy the approximation is. None of these say how *accurate* the representation is; if those are representations of the number “seven thousand” they are not very accurate, while they might be passably accurate for the number “one hundred and seventy”. > 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? We gain clarity of speech: we distinguish the different aspects (how many digits of this representation are actually claimed to represent the number?) communicated by a representation. -- \ “… no testimony can be admitted which is contrary to reason; | `\ reason is founded on the evidence of our senses.” —Percy Bysshe | _o__) Shelley, _The Necessity of Atheism_, 1811 | Ben Finney
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-11 23:28 +0100 |
| Subject | Re: What is precision of a number representation? |
| Message-ID | <87oa6324j4.fsf@bsb.me.uk> |
| In reply to | #111294 |
Ben Finney <ben+python@benfinney.id.au> writes: > Ethan Furman <ethan@stoneleaf.us> writes: > >> 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. > > Precision is not a property of the number. It is a property of the > *representation* of that number. > > The representation “1×10²” has a precision of one digit. > The representation “100” has a precision of three digits. > The representation “00100” has a precision of five digits. > The representation “100.00” also has a precision of five digits. What is your source for the third one? I've never seen the term used in this way so I'm curious about how widely it's used. (I disagree with the second one, too, but that's an old argument that does not need resurrecting.) > Those can all represent the same number; or maybe some of them represent > “one hundred” and others represent “one hundred and a millionth”. So 00100 represents the range [99.995, 100.005] just like 100.00? That's new to me. It is more than a Python thing? <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ethan Furman <ethan@stoneleaf.us> |
|---|---|
| Date | 2016-07-11 14:22 -0700 |
| Subject | Re: What is precision of a number representation? |
| Message-ID | <mailman.196.1468272113.2295.python-list@python.org> |
| In reply to | #111273 |
On 07/11/2016 01:56 PM, Ben Finney wrote: > Precision is not a property of the number. It is a property of the > *representation* of that number. > > The representation “1×10²” has a precision of one digit. > The representation “100” has a precision of three digits. > The representation “00100” has a precision of five digits. > The representation “100.00” also has a precision of five digits. Your first, second, and fourth example have zeroes to the right, and I understand them just fine. Your third example has zeroes to the left, and you haven't explained how 00100 is more precise than 100. I mean, if somebody told me that one hundred was closer to one hundred than it was to ten thousand I would have to say "D'oh!" > We gain clarity of speech: we distinguish the different aspects (how > many digits of this representation are actually claimed to represent the > number?) communicated by a representation. Nope, still not clear to me. :( -- ~Ethan~
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-07-12 07:51 +1000 |
| Subject | Re: What is precision of a number representation? (was: Curious Omission In New-Style Formats) |
| Message-ID | <mailman.197.1468273886.2295.python-list@python.org> |
| In reply to | #111273 |
On Tue, Jul 12, 2016 at 6:56 AM, Ben Finney <ben+python@benfinney.id.au> wrote: > Precision is not a property of the number. It is a property of the > *representation* of that number. > > The representation “1×10²” has a precision of one digit. > The representation “100” has a precision of three digits. > The representation “00100” has a precision of five digits. > The representation “100.00” also has a precision of five digits. > > Those can all represent the same number; or maybe some of them represent > “one hundred” and others represent “one hundred and a millionth”. > Yep. Precision is also a property of a measurement, the same way that a unit is. If I pace out the length of the main corridor in my house, I might come up with a result of thirty meters. The number is "30"; the unit is "meters", the precision is two significant digits, and the accuracy depends on how good I am at pacing distance. This is why it's important to be able to record precisions of arbitrary numbers. If I then measure the width of this corridor with a laser, I could get an extremely precise answer - say, 2,147 millimeters, with a precision of four significant digits, and excellent accuracy. But if I multiply those numbers together to establish the floor area of the corridor, the result does NOT have four significant figures. It would be 64 square meters (not 64.41), and the accuracy would be pretty low (effectively, the *in*accuracies of both measurements get combined). But on the other hand, if you want to know whether your new fridge will fit, you could measure it with the same laser and come up with a figure of 1,973 mm (four sig fig), which would mean your clearance is 174mm (four sig fig). How do you record this? Is it 174.0? 0174? "174 with four significant figures"? ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> |
|---|---|
| Date | 2016-07-12 00:14 +0100 |
| Subject | Re: What is precision of a number representation? (was: Curious Omission In New-Style Formats) |
| Message-ID | <20160712001452.4432d7d0@HP-6550b> |
| In reply to | #111297 |
On Tue, 12 Jul 2016 07:51:23 +1000 Chris Angelico <rosuav@gmail.com> wrote: [snip] > > Yep. Precision is also a property of a measurement, the same > way that a unit is. If I pace out the length of the main > corridor in my house, I might come up with a result of thirty > meters. The number is "30"; the unit is "meters", the > precision is two significant digits, and the accuracy depends > on how good I am at pacing distance. > > This is why it's important to be able to record precisions of > arbitrary numbers. If I then measure the width of this > corridor with a laser, I could get an extremely precise answer > - say, 2,147 millimeters, with a precision of four significant > digits, and excellent accuracy. But if I multiply those > numbers together to establish the floor area of the corridor, > the result does NOT have four significant figures. It would be > 64 square meters (not 64.41), and the accuracy would be pretty > low (effectively, the *in*accuracies of both measurements get > combined). But on the other hand, if you want to know whether > your new fridge will fit, you could measure it with the same > laser and come up with a figure of 1,973 mm (four sig fig), > which would mean your clearance is 174mm (four sig fig). How > do you record this? Is it 174.0? 0174? "174 with four > significant figures"? Thees all look good, but you may get into trouble if you trust a PC with them! If the language/PC uses floating point representation then it will assign a fixed number of bits for the fractional part, and this will be left aligned in all/most hardware. This fraction might be 52 bits long. Your example number has about 11 bits of precision. The floating point representation will then have ~40 bits appended which imply a precision which does not exist. Your program may still know that only 11 bits are significant, but the representation implies that 52 bits are significant, and provides no indication otherwise. Good news!: Unum is an alternate numeric representation that does indicate the precision of a number [1]. It also resolves other problems of current float representation. Bad news?:In doing so unums becomes incompatible with current hardware floating point engines. Jan Coombs -- [1] slides: http://sites.ieee.org/scv-cs/files/2013/03/Right-SizingPrecision1.pdf RichReport 54 minute interview: https://youtu.be/jN9L7TpMxeA
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-07-12 09:57 +1000 |
| Subject | Re: What is precision of a number representation? (was: Curious Omission In New-Style Formats) |
| Message-ID | <mailman.200.1468281472.2295.python-list@python.org> |
| In reply to | #111301 |
On Tue, Jul 12, 2016 at 9:14 AM, Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> wrote: > Thees all look good, but you may get into trouble if you trust a > PC with them! > > If the language/PC uses floating point representation then it > will assign a fixed number of bits for the fractional part, and > this will be left aligned in all/most hardware. PCs don't necessarily use floating point. Just check out Python's own decimal.Decimal class, or roll your own if you need to. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-07-12 14:19 +1000 |
| Subject | Re: What is precision of a number representation? (was: Curious Omission In New-Style Formats) |
| Message-ID | <57846fdb$0$1593$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #111297 |
On Tue, 12 Jul 2016 07:51 am, Chris Angelico wrote: > say, 2,147 > millimeters, with a precision of four significant digits How do you represent 1 mm to a precision of four significant digits, in such a way that it is distinguished from 1 mm to one significant digit, and 1 mm to a precision of four decimal places? 0001 1 1.0000 -- Steven “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-07-12 14:36 +1000 |
| Subject | Re: What is precision of a number representation? (was: Curious Omission In New-Style Formats) |
| Message-ID | <mailman.7.1468298208.21009.python-list@python.org> |
| In reply to | #111314 |
On Tue, Jul 12, 2016 at 2:19 PM, Steven D'Aprano <steve@pearwood.info> wrote: > On Tue, 12 Jul 2016 07:51 am, Chris Angelico wrote: > >> say, 2,147 >> millimeters, with a precision of four significant digits > > > How do you represent 1 mm to a precision of four significant digits, in such > a way that it is distinguished from 1 mm to one significant digit, and 1 mm > to a precision of four decimal places? > > 0001 > 1 > 1.0000 Exactly my point. Granted, I mucked up my example (subtraction doesn't maintain sig figs - apologies, my bad), but there are other ways to end up with numbers close to zero with more sig figs than nonzero digits. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Antoon Pardon <antoon.pardon@rece.vub.ac.be> |
|---|---|
| Date | 2016-07-12 11:50 +0200 |
| Subject | Re: What is precision of a number representation? |
| Message-ID | <mailman.11.1468317141.21009.python-list@python.org> |
| In reply to | #111314 |
Op 12-07-16 om 06:19 schreef Steven D'Aprano: > On Tue, 12 Jul 2016 07:51 am, Chris Angelico wrote: > >> say, 2,147 >> millimeters, with a precision of four significant digits > > How do you represent 1 mm to a precision of four significant digits, in such > a way that it is distinguished from 1 mm to one significant digit, and 1 mm > to a precision of four decimal places? > > 0001 > 1 > 1.0000 Your question doesn't has an answer because 1 mm doesn't have a precision of four significant digits. A precision is an indication of a fault tolerance. You don't indicate less fault tolerace by writing it as 0001. Please explain how 0001 represants a difference in precision than just 1. Writing 1.0000 instead of 1 can be understood as the actual number being between 0.99995 and 1.00005 instead of the actual number being between 0.95 and 1.05. Now between which two numbers is 0001 supposed to be? -- Antoon Pardon
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2016-07-12 13:27 +0300 |
| Subject | Re: What is precision of a number representation? |
| Message-ID | <87furfducw.fsf@elektro.pacujo.net> |
| In reply to | #111327 |
Antoon Pardon <antoon.pardon@rece.vub.ac.be>:
> Op 12-07-16 om 06:19 schreef Steven D'Aprano:
>> How do you represent 1 mm to a precision of four significant digits,
>> in such a way that it is distinguished from 1 mm to one significant
>> digit, and 1 mm to a precision of four decimal places?
>
> Your question doesn't has an answer because 1 mm doesn't have a
> precision of four significant digits.
Your statement is invalid. You presuppose some notational conventions.
1 mm is simply one millimeter; in and of itself it doesn't in any way
convey precision.
> A precision is an indication of a fault tolerance. You don't indicate
> less fault tolerace by writing it as 0001.
I doubt a "fault" is relevant here. In ordinary usage, precision refers
to a range of values, which is probably what you are getting at.
> Please explain how 0001 represants a difference in precision than just
> 1.
"Precision" here is not ordinary usage. Historically, it comes from the
printf(3) library function:
Each conversion specification is introduced by the character %,
and ends with a conversion specifier. In between there may be (in
this order) zero or more flags, an optional minimum field width,
an optional precision and an optional length modifier.
[man 3 printf]
Thus, "precision" is simply the name of a formatting field, regardless
of the semantics of that field. The name was chosen because for floating
point numbers, it actually refers to the precision of the numeric
representation. However, the field has other uses that have nothing to
do with precision:
Precision [...] gives the minimum number of digits to appear for d,
i, o, u, x, and X conversions, the number of digits to appear after
the radix character for a, A, e, E, f, and F conversions, the
maximum number of significant digits for g and G conversions, or the
maximum number of characters to be printed from a string for s and S
conversions.
[man 3 printf]
> Writing 1.0000 instead of 1 can be understood as the actual number
> being between 0.99995 and 1.00005 instead of the actual number being
> between 0.95 and 1.05.
That certainly is a very common practice.
> Now between which two numbers is 0001 supposed to be?
What is your problem? What practical trouble is Python's format method
giving you?
Do you ever "turn on" a light or "roll down" a window by pushing a
button? Do you "turn up" the volume by moving a slider? Why, do you ever
"write" to a solid state "disk?"
Marko
[toc] | [prev] | [next] | [standalone]
| From | Antoon Pardon <antoon.pardon@rece.vub.ac.be> |
|---|---|
| Date | 2016-07-12 13:02 +0200 |
| Subject | Re: What is precision of a number representation? |
| Message-ID | <mailman.14.1468321397.21009.python-list@python.org> |
| In reply to | #111328 |
Op 12-07-16 om 12:27 schreef Marko Rauhamaa: > Antoon Pardon <antoon.pardon@rece.vub.ac.be>: > >> Op 12-07-16 om 06:19 schreef Steven D'Aprano: >>> How do you represent 1 mm to a precision of four significant digits, >>> in such a way that it is distinguished from 1 mm to one significant >>> digit, and 1 mm to a precision of four decimal places? >> A precision is an indication of a fault tolerance. You don't indicate >> less fault tolerace by writing it as 0001. > >> Please explain how 0001 represants a difference in precision than just >> 1. > "Precision" here is not ordinary usage. Historically, it comes from the > printf(3) library function: Steven was talking about significant digits. So my use of precision was in that context. So I think your printf here is irrelevant. Talking about how your number is printed is different from talking about the significance of the digits. If you for whatever reason want to write 1 as 0001, be my guest. If you state that this somehow expresses a difference in significant digits, I would like someone to explain how. And yes I want that expressed in difference of fault or error tolerance, because that is what IMO significant digits refer to. > >> Now between which two numbers is 0001 supposed to be? > What is your problem? What practical trouble is Python's format method > giving you? This is not about Python's format. This is about someone stating a difference in significant digits. -- Antoon.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-07-12 23:16 +1000 |
| Subject | Re: What is precision of a number representation? |
| Message-ID | <5784edc7$0$1588$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #111327 |
On Tue, 12 Jul 2016 07:50 pm, Antoon Pardon wrote: > Op 12-07-16 om 06:19 schreef Steven D'Aprano: >> On Tue, 12 Jul 2016 07:51 am, Chris Angelico wrote: >> >>> say, 2,147 >>> millimeters, with a precision of four significant digits >> >> How do you represent 1 mm to a precision of four significant digits, in >> such a way that it is distinguished from 1 mm to one significant digit, >> and 1 mm to a precision of four decimal places? >> >> 0001 >> 1 >> 1.0000 > > Your question doesn't has an answer because 1 mm doesn't have a precision > of four significant digits. None of this argument has even the slightest relevance to the question of what the so-called "precision" field in a format string means with integer arguments. Regardless of any consensus, or lack thereof, about what a measurement precision of "four significant digits" might mean for a measurement of 1 unit, the meaning and usefulness of the precision field in format strings will remain. How do you get this result with format? py> "%8.4d" % 29 ' 0029' If you don't like my interpretation of leading zeroes, okay, I'm not going to defend it. It's really not that important. Perhaps after thinking about it more I'll also decide that it doesn't really make sense. When it comes to printf and the string % operator with integer types, the so-called "precision" field should not be understood as anything to do with measurement error. > A precision is an indication of a fault tolerance. You don't indicate less > fault tolerace by writing it as 0001. Measurement precision, as indicated by significant digits, doesn't have anything to do with fault tolerance. It tells you the estimated error in the measurement, not how much fault your application can withstand. "Fault tolerance" is a technical term that refers to the ability of a system, machine or device to continue working correctly even when parts of it have broken down. > Please explain how 0001 represants a difference in precision than just 1. The first is a 16-bit word; the second is a 4-bit nybble. Or, if the numbers are in decimal, perhaps the first comes from an old analogue speedometers, where there are four counters. This tells you that the largest possible number that we could count is 9999. The second in that case could come from a single analogue counter, in which case the largest number is 9. -- Steven “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse.
[toc] | [prev] | [next] | [standalone]
| From | Ethan Furman <ethan@stoneleaf.us> |
|---|---|
| Date | 2016-07-11 15:17 -0700 |
| Subject | Re: What is precision of a number representation? |
| Message-ID | <mailman.198.1468275424.2295.python-list@python.org> |
| In reply to | #111273 |
On 07/11/2016 02:51 PM, Chris Angelico wrote: > On Tue, Jul 12, 2016 at 6:56 AM, Ben Finney wrote: >> Precision is not a property of the number. It is a property of the >> *representation* of that number. >> >> The representation “1×10²” has a precision of one digit. >> The representation “100” has a precision of three digits. >> The representation “00100” has a precision of five digits. >> The representation “100.00” also has a precision of five digits. >> >> Those can all represent the same number; or maybe some of them represent >> “one hundred” and others represent “one hundred and a millionth”. >> > > Yep. Precision is also a property of a measurement, the same way that > a unit is. If I pace out the length of the main corridor in my house, > I might come up with a result of thirty meters. The number is "30"; > the unit is "meters", the precision is two significant digits, and the > accuracy depends on how good I am at pacing distance. > > This is why it's important to be able to record precisions of > arbitrary numbers. If I then measure the width of this corridor with a > laser, I could get an extremely precise answer - say, 2,147 > millimeters, with a precision of four significant digits, and > excellent accuracy. But if I multiply those numbers together to > establish the floor area of the corridor, the result does NOT have > four significant figures. It would be 64 square meters (not 64.41), > and the accuracy would be pretty low (effectively, the *in*accuracies > of both measurements get combined). But on the other hand, if you want > to know whether your new fridge will fit, you could measure it with > the same laser and come up with a figure of 1,973 mm (four sig fig), > which would mean your clearance is 174mm (four sig fig). How do you > record this? Is it 174.0? 0174? "174 with four significant figures"? 174.0, because those last tenths of a millimeter could be very important, while knowledge that there are no thousands of millimeters is already present. So, so far there is no explanation of why leading zeroes make a number more precise. -- ~Ethan~
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2016-07-12 16:21 +1000 |
| Subject | Re: What is precision of a number representation? |
| Message-ID | <57848c74$0$11093$c3e8da3@news.astraweb.com> |
| In reply to | #111298 |
On Tuesday 12 July 2016 08:17, Ethan Furman wrote: > So, so far there is no explanation of why leading zeroes make a number > more precise. Obviously it doesn't, just as trailing zeroes doesn't make a number more precise. Precision in the sense used by scientists is a property of how the measurement was done, not of the number itself. We can arbitrarily add zeroes to the end of 0.5 until the cows come home, and its still just a half, no more, no less. But scientists have a useful convention that you can indicate the measurement precision by showing trailing zeroes: 0.5 is short-hand for 0.5 ± 0.05; 0.50 is short-hand for 0.5 ± 0.005; 0.5000 is short-hand for 0.5 ± 0.00005; etc. That's just a convention, although its a useful one. But its not the only useful convention: 01 is a byte with value 1; 0001 is a double-byte quantity (short int?) with value 1; 00000001 is a 32-bit quantity with value 1; etc. We say that these examples differ in their "number of digits" instead of "number of decimal places", so the difference doesn't quite map to the scientist's meaning of the word "precision". But why should we let that stop us from using the "precision" field of a format string to represent number of digits? If not, then what are the alternatives? Using str.format, how would you get the same output as this? py> "%8.4d" % 25 ' 0025' -- Steve
[toc] | [prev] | [next] | [standalone]
| From | Random832 <random832@fastmail.com> |
|---|---|
| Date | 2016-07-12 09:36 -0400 |
| Subject | Re: What is precision of a number representation? |
| Message-ID | <mailman.16.1468330590.21009.python-list@python.org> |
| In reply to | #111319 |
On Tue, Jul 12, 2016, at 02:21, Steven D'Aprano wrote:
> If not, then what are the alternatives? Using str.format, how would
> you get the same output as this?
>
>
> py> "%8.4d" % 25
> ' 0025'
" %04d" % 25
"%8s" % ("%04d" % 25)
The latter (well, generally, "format it how you want and then use %*s to
put it in fixed columns") is something that I've actually *done*,
because it's easier to reason about.
[toc] | [prev] | [next] | [standalone]
| From | Ethan Furman <ethan@stoneleaf.us> |
|---|---|
| Date | 2016-07-11 15:29 -0700 |
| Subject | Re: What is precision of a number representation? |
| Message-ID | <mailman.199.1468276173.2295.python-list@python.org> |
| In reply to | #111273 |
On 07/11/2016 03:17 PM, Ethan Furman wrote: > So, so far there is no explanation of why leading zeroes make a number > more precise. An example of what I mean: 174 with a precision of 3 tells us that the tenths place could be any of 0-9, or, put another way, the actual number could be anywhere between 174.0 to 174.9 (or maybe 173.5 to 174.5). If we have 174 with four digits of precision, then the representation should be 174.0 and it's the hundreths we are unsure of. So my question is: if we write 174 when could the thousands /ever/ be anything besides 0? -- ~Ethan~
[toc] | [prev] | [next] | [standalone]
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
|---|---|
| Date | 2016-07-12 11:26 +1200 |
| Message-ID | <duio99F2rhiU1@mid.individual.net> |
| In reply to | #111273 |
I seem to remember Guido stating once that a design principle of the new formatting system was for the part after the colon to be the same as what you would put in an equivalent %-format, to make it easy for people to switch between them. If that principle still stands, then this would seem to be a bug. -- Greg
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | comp.lang.python
csiph-web