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 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#111466

Op 15-07-16 om 10:40 schreef Jussi Piitulainen:
> Antoon Pardon writes:
>
>> Op 15-07-16 om 08:06 schreef Marko Rauhamaa:
>>> Common usage among educated speakers ordinarily is the yardstick for
>>> language questions.
>> But educated about what exactly?
>>
>> Each time someone talks about "a steep learning curve" in order to
>> indicate something is difficult to master, he is using it wrong,
>> because actual steep learning curves indicate something can be
>> mastered quickly.
>>
>> Now I suspect most people who talk about steep learning curves are
>> educated, they just aren't educated about learning curves and so I
>> think common usage among educated speakers is inadequate as a yard
>> stick.
> I think I see your point, but I think it's also easy to think the axes
> of the metaphor so that it makes sense:
>
> c      ,
> o     ,
> s    ,
> t . .
>  l e a r n i n g

Only for someone who is not very familiar with how we graphically
represent results. The cost/effort is always put on the X-ax because
that is what we directly control and also because that is what always
increases. You can't unspent time in trying to master something. We
make this choice because we want a mathematical function.

What if you have a set back? How do you show that on your graph?

Ask people if they prefer a steep or shallow pay check curve. Most
seem very quick in choosing for the steep curve.

-- 
Antoon

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

#111471

Antoon Pardon writes:

> Op 15-07-16 om 10:40 schreef Jussi Piitulainen:
>> Antoon Pardon writes:
>>
>>> Op 15-07-16 om 08:06 schreef Marko Rauhamaa:
>>>> Common usage among educated speakers ordinarily is the yardstick for
>>>> language questions.
>>> But educated about what exactly?
>>>
>>> Each time someone talks about "a steep learning curve" in order to
>>> indicate something is difficult to master, he is using it wrong,
>>> because actual steep learning curves indicate something can be
>>> mastered quickly.
>>>
>>> Now I suspect most people who talk about steep learning curves are
>>> educated, they just aren't educated about learning curves and so I
>>> think common usage among educated speakers is inadequate as a yard
>>> stick.
>> I think I see your point, but I think it's also easy to think the axes
>> of the metaphor so that it makes sense:
>>
>> c      ,
>> o     ,
>> s    ,
>> t . .
>>  l e a r n i n g
>
> Only for someone who is not very familiar with how we graphically
> represent results. The cost/effort is always put on the X-ax because
> that is what we directly control and also because that is what always
> increases. You can't unspent time in trying to master something. We
> make this choice because we want a mathematical function.
>
> What if you have a set back? How do you show that on your graph?

Nice points, thank you. You may be simply right on this, and I may have
learnt something.

> Ask people if they prefer a steep or shallow pay check curve. Most
> seem very quick in choosing for the steep curve.

I'm not at all sure how I would answer. By asking what is meant?
Because to me it sounds like a trick question to begin with.

There's an old story they tell in my family about a child who begs for
bread from a house. The lady of the house asks if they want a one-hand
slice (yhe käe leipä) or a two-hand slice (kahe käe leipä), and when the
poor hungry child asks for the two-hand slice, they get a slice so thin
that it needs to be held with both hands. That's mean.

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

#111477

On Fri, 15 Jul 2016 11:28 pm, Jussi Piitulainen wrote:

> There's an old story they tell in my family about a child who begs for
> bread from a house. The lady of the house asks if they want a one-hand
> slice (yhe käe leipä) or a two-hand slice (kahe käe leipä), and when the
> poor hungry child asks for the two-hand slice, they get a slice so thin
> that it needs to be held with both hands. That's mean.


Ha, that's exactly the same story my grandmother (who was Estonian-Russian)
used to tell me. If you don't mind me asking, what nationality are you?




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

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

#111478

Steven D'Aprano writes:

> On Fri, 15 Jul 2016 11:28 pm, Jussi Piitulainen wrote:
>
>> There's an old story they tell in my family about a child who begs for
>> bread from a house. The lady of the house asks if they want a one-hand
>> slice (yhe käe leipä) or a two-hand slice (kahe käe leipä), and when the
>> poor hungry child asks for the two-hand slice, they get a slice so thin
>> that it needs to be held with both hands. That's mean.
>
>
> Ha, that's exactly the same story my grandmother (who was
> Estonian-Russian) used to tell me. If you don't mind me asking, what
> nationality are you?

Finnish. Karelian enough that it probably is the exact same story.

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

#111463

Antoon Pardon <antoon.pardon@rece.vub.ac.be>:

> Op 15-07-16 om 08:06 schreef Marko Rauhamaa:
>> Common usage among educated speakers ordinarily is the yardstick for
>> language questions.
>
> But educated about what exactly?

In this case we are talking about those people who actively talk about
significand/mantissa. By and large, they call the thing mantissa.

I'm not at all irritated or confused by that (even if my opinion
mattered). I *am* irritated by Americans using "Km" for kilometer and
"msec" for millisecond (even though my opinion doesn't matter).


Marko

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

#111464

Op 15-07-16 om 11:20 schreef Marko Rauhamaa:
> Antoon Pardon <antoon.pardon@rece.vub.ac.be>:
>
>> Op 15-07-16 om 08:06 schreef Marko Rauhamaa:
>>> Common usage among educated speakers ordinarily is the yardstick for
>>> language questions.
>> But educated about what exactly?
> In this case we are talking about those people who actively talk about
> significand/mantissa. By and large, they call the thing mantissa.

I think there is an important difference between actively talking about
something and being educated (about it).

I have known people who actively talked about negative feedback while
what they actually meant was a vicious circle that technically was
possitive feedback but with results they wanted to avoid.

-- 
Antoon Pardon.

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

#111454

On Friday, July 15, 2016 at 5:11:46 AM UTC+12, Ian wrote:
> Just because it's already common to use the wrong term doesn't mean
> the usage should be promulgated further.

Yes of course. The only logically-acceptable meaning of “mantissa” is “female mantis”, and any other usage is to be the immediate target of derisive laughter and scorn.

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

#111441

On 2016-07-14 15:30, Ian Kelly wrote:
> On Jul 14, 2016 1:52 AM, "Steven D'Aprano"
> <steve+comp.lang.python@pearwood.info> wrote:
>>
>> On Thursday 14 July 2016 15:18, Ian Kelly wrote:
>>
>>> Side note, neither do floating point numbers, really; what is often
>>> called the mantissa is more properly known as the significand. But
>>> integers don't have that either.
>>
>> Er, then what's a mantissa if it's not what people call a float's mantissa?
>>
>> What makes you say it is "more properly" known as the significand?
>>
>> I'm not necessarily disputing what you say, I'm wondering what is your
>> justification for it.
>
> http://mathworld.wolfram.com/Significand.html
> http://mathworld.wolfram.com/Mantissa.html
>
> The significand of -3.14159 is the sequence of digits 314159. The
> mantissa of -3.14159 is the number 0.85841.
>
> I don't have a copy of the IEEE-754 standard, but I believe that it
> also uses the term "significand" and specifically avoids the term
> "mantissa".

Confirmed.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

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

#111488

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:
>>
>> How about “mantissa length”, then. That sufficiently neutral for you?
> 
> That makes even less sense for integers.

Perhaps you would prefer the more gender-neutral term “persontissa” ...

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

#111489

On Sat, Jul 16, 2016 at 9:35 AM, Lawrence D’Oliveiro
<lawrencedo99@gmail.com> wrote:
> 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:
>>>
>>> How about “mantissa length”, then. That sufficiently neutral for you?
>>
>> That makes even less sense for integers.
>
> Perhaps you would prefer the more gender-neutral term “persontissa” ...

I would laugh, but gender issues are extremely significand to a lot of people...

ChrisA

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

#111425

On 2016-07-14 01:45, Ian Kelly wrote:
> 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.
>
Perhaps "precision or whatever"? :-)

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

#111388

On Wed, 13 Jul 2016 00:21:17 -0600, Ian Kelly <ian.g.kelly@gmail.com>
declaimed the following:

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

	Ugh... After using integers to keep accuracy in the LSB, you know toss
it out the window by converting to a float which may have an inexact
representation.

	Presuming you kept track of the decimal place during all those integer
operations, format as an integer, then split it at the decimal and insert a
"." at the spot.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#111395

Dennis Lee Bieber writes:

> On Wed, 13 Jul 2016 00:21:17 -0600, Ian Kelly <ian.g.kelly@gmail.com>
> declaimed the following:
>
>> 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)
>>
>
> 	Ugh... After using integers to keep accuracy in the LSB, you
> know toss it out the window by converting to a float which may have an
> inexact representation.
>
> 	Presuming you kept track of the decimal place during all those
> integer operations, format as an integer, then split it at the decimal
> and insert a "." at the spot.

Of course floats fail (for this task) when the number exceeds their
integer range, but what would be a number within that range, preferably
well within that range, where they also fail? I didn't find any.

I tried to find one using the following code. First I found cases where
the output was different, but every single time (!) it was a bug in the
"safer" routine. Dismiss that as my incompetence, the fact remains that
the "dangerous" floating-point variant was never wrong at all while the
erroneous outputs from my "safer" formatters were off by an order of
magnitude. Floating point errors would be in the digits that matter
least.

No. The bugs were not in the regex. I was unsure of combining *? with
{1,2} that way - it never failed. I wasn't any surer of the non-regex
code - it kept failing.

import re, random

components = re.compile(r'(-?)(\d*?)(\d{1,2})')
def safer(x):
    sign, whole, decimals = components.fullmatch(str(x)).groups()
    return '{}{:>01}.{:>02}'.format(sign, whole, decimals)

def dangerouser(x):
    return '{:.2f}'.format(x/100)

for n in random.sample(range(-9000000000,9000000001), 1000000):
    x, y = safer(n), dangerouser(n)
    if x == y: continue
    print('differ:', n, x, y)

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

#111392

On Wed, Jul 13, 2016 at 9:46 PM, Dennis Lee Bieber
<wlfraed@ix.netcom.com> wrote:
> On Wed, 13 Jul 2016 00:21:17 -0600, Ian Kelly <ian.g.kelly@gmail.com>
> declaimed the following:
>
>>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)
>>
>
>         Ugh... After using integers to keep accuracy in the LSB, you know toss
> it out the window by converting to a float which may have an inexact
> representation.
>
>         Presuming you kept track of the decimal place during all those integer
> operations, format as an integer, then split it at the decimal and insert a
> "." at the spot.

Or just use divmod:

>>> "%d.%02d" % divmod(1<<200, 100)
'16069380442589902755419620923411626025222029937827928353013.76'

ChrisA

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

#111397

Chris Angelico writes:

> On Wed, Jul 13, 2016 at 9:46 PM, Dennis Lee Bieber
> <wlfraed@ix.netcom.com> wrote:
>> On Wed, 13 Jul 2016 00:21:17 -0600, Ian Kelly <ian.g.kelly@gmail.com>
>> declaimed the following:
>>
>>> 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)
>>>
>>
>>         Ugh... After using integers to keep accuracy in the LSB, you
>> know toss it out the window by converting to a float which may have
>> an inexact representation.
>>
>>         Presuming you kept track of the decimal place during all
>> those integer operations, format as an integer, then split it at the
>> decimal and insert a "." at the spot.
>
> Or just use divmod:
>
>>>> "%d.%02d" % divmod(1<<200, 100)
> '16069380442589902755419620923411626025222029937827928353013.76'

I'm not quite ready to blame floating point for this difference yet:

>>> "%d.%02d" % divmod(-1,100)
'-1.99'
>>> "%.2f" % (-1/100)
'-0.01'

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

#111399

On Wed, Jul 13, 2016 at 11:16 PM, Jussi Piitulainen
<jussi.piitulainen@helsinki.fi> wrote:
>> Or just use divmod:
>>
>>>>> "%d.%02d" % divmod(1<<200, 100)
>> '16069380442589902755419620923411626025222029937827928353013.76'
>
> I'm not quite ready to blame floating point for this difference yet:
>
>>>> "%d.%02d" % divmod(-1,100)
> '-1.99'
>>>> "%.2f" % (-1/100)
> '-0.01'

Ehhhh, forgot about that :D Negative numbers and modulo *always* trip
me up, because different languages have different rules. I inevitably
have to go check the docos.

ChrisA

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

#111401

Chris Angelico writes:

> On Wed, Jul 13, 2016 at 11:16 PM, Jussi Piitulainen wrote:
>>> Or just use divmod:
>>>
>>>>>> "%d.%02d" % divmod(1<<200, 100)
>>> '16069380442589902755419620923411626025222029937827928353013.76'
>>
>> I'm not quite ready to blame floating point for this difference yet:
>>
>>>>> "%d.%02d" % divmod(-1,100)
>> '-1.99'
>>>>> "%.2f" % (-1/100)
>> '-0.01'
>
> Ehhhh, forgot about that :D Negative numbers and modulo *always* trip
> me up, because different languages have different rules. I inevitably
> have to go check the docos.

Julia's "Euclidean division" (div, rem, divrem) would result in '0.-1'
above :) while fld, mod, fldmod (floored or floor or flooring division)
would be the same as Python's //, %, divmod.

Python 3.4.3 help text for divmod says it returns ((x-x%y)/y, x%y) but
that's not quite correct, because type. Probably // is intended.

There are easily half a dozen different integer divisions rounding
towards or away from zero or up or down or to nearest integer with
different ways of breaking ties and matching the sign of dividend or
divisor, and a couple of other details, yet I'm not sure if any of them
alone would do the job at hand :) Leave it for someone smarter.

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

#111402

On Thu, Jul 14, 2016 at 12:23 AM, Jussi Piitulainen
<jussi.piitulainen@helsinki.fi> wrote:
> Python 3.4.3 help text for divmod says it returns ((x-x%y)/y, x%y) but
> that's not quite correct, because type. Probably // is intended.

Starting with 3.5, it says it returns the tuple (x//y, x%y).

ChrisA

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

#111284

On 7/11/2016 1:24 PM, Ethan Furman wrote:
> 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.

I do have an undergraduate degree in math and a career in statistics, 
and I cannot remember seen 'precision' used in relation to integers.  So 
I would call it a 'non-standard extension' of the notion.

> But I'm always willing to learn.  So please explain what 123 with a
> precision of five integer digits means,

What it could mean is that we have an count selected from the range 
00000 to 99999 inclusive.  But what I just said is the usual way of 
saying that, as it does not limit the lower and upper limits to 0s and 9s.

> and what to do we gain by saying such a thing?

Confusion.

Precision is usually used in reference to measurement, and while 
measurement is based on counting, it is not the same thing.  If 123 is a 
count, then its precision is 1 count, not k digits.  Or one could say 
that all digits are precise. What is ambiguous without context is 
whether counts with trailing 0s, like 120 or 100 are exact or rounded. 
100, as a cound, could have a precision of 1, 2, or 3 (significant) 
digits.  Context sometimes says things like 'to the nearest hundred 
thousand'.

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'

Thus, my title for a post noting the same change might be "Upgrade in 
new-style formats".
(format and If one want leading 0s,

-- 
Terry Jan Reedy

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

#111287

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'

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

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

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

csiph-web