Re: Curious Omission In New-Style Formats

[Chris Angelico]

On Sat, Jul 16, 2016 at 9:35 AM, Lawrence D’Oliveiro
 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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Lawrence D’Oliveiro]

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” ...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Jussi Piitulainen]

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.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Steven D'Aprano]

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.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Steven D'Aprano]

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

> Steven D'Aprano writes:
> 
> [in response to my attempt to understand "steep learning curve"]
> 
>> "Learning curve" or "experience curve" is not just an metaphor, it is
>> an actual technical term. See the Wikipedia article:
>>
>> https://en.wikipedia.org/wiki/Learning_curve
>>
>>
>> Now, there are a couple of ways that we can interpret the idiom of
>> "steep learning curve". One is the way Wikipedia interprets it: as a
>> mistake.
> 
> [- -]
> 
> Ouch. Next time I hear anyone use the phrase, if I need to know whether
> they mean "easy to learn" or "hard to learn" or something else, I think
> I'll ask them...

You really don't need to. "Steep learning curve" in ordinary English ALWAYS
means that it is hard to make progress and then gets easier once you have
mastered it. Its a common idiom.

If you're talking to an actual expert in the field about an actual graph,
then it might be worth asking them what they mean. And the chances are they
will mean exactly the same thing as ordinary people, and they'll just
say "turn your head to the side, see how steep the graph is at the start".

That's my prediction.



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

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Antoon Pardon]

Op 15-07-16 om 15:38 schreef Jussi Piitulainen:
> Antoon Pardon writes:
>
>> No, that is what people come up with afterwards. If you just start a
>> conversation about how people learn and how long it would take to get
>> some mastery and how we could present progress in a graph, virtually
>> everyone uses the conventional axes layout. This talk about swapped
>> axes only come from people who used the steep learning curve metaphor,
>> when you then try to show them what an actual steep learning curve
>> implies.
> Or from people who try to be charitable when other people use it. At
> least I like to think that that's what I did.

Sure, you can be charitable when other people use it. IME that doesn't
contradict that when you somehow find yourself in need of actually
graphing these kind of numbers you are likely to follow the conventional
layout.

-- 
Antoon Pardon.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Antoon Pardon]

Op 15-07-16 om 15:39 schreef Random832:
>
> On Fri, Jul 15, 2016, at 07:44, Antoon Pardon wrote:
>
>> No, that is what people come up with afterwards. If you just start a
>> conversation about how people learn and how long it would take to get
>> some mastery and how we could present progress in a graph, virtually
>> everyone uses the conventional axes layout.
> _Why_ do you think this? The natural way to graph progress vs effort is
> to have progress on the horizontal access and effort on the vertical
> axis, because that's what you get when you're climbing a literal hill,
> the only context in the universe where "vertical" and "horizontal"
> aren't arbitrarily assigned but are real spatial dimensions.

No that is not the natural way. That is the way you pick afterwards if
you want your graph to resemble the metaphor. But it is not the way
people "naturally" graph these numbers, if the metafor was not put
into their head in first place. Certainly not people who actually study
these kind of things.

> The only reason to do it the other way is an association with time and
> the convention of using time for the horizontal axis.

No the reason is, we prefer the graph to be a function. That is for every x
at most one y. Using the axes the other way around would mean that set backs
would result in multiple y values for the same x.

-- 
Antoon Pardon.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Jussi Piitulainen]

Antoon Pardon writes:

> No, that is what people come up with afterwards. If you just start a
> conversation about how people learn and how long it would take to get
> some mastery and how we could present progress in a graph, virtually
> everyone uses the conventional axes layout. This talk about swapped
> axes only come from people who used the steep learning curve metaphor,
> when you then try to show them what an actual steep learning curve
> implies.

Or from people who try to be charitable when other people use it. At
least I like to think that that's what I did.

(I'm not at all inclined to do that about certain other terms, but those
discussions are also not inclined to go anywhere.)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Random832]

On Fri, Jul 15, 2016, at 07:44, Antoon Pardon wrote:

> No, that is what people come up with afterwards. If you just start a
> conversation about how people learn and how long it would take to get
> some mastery and how we could present progress in a graph, virtually
> everyone uses the conventional axes layout.

_Why_ do you think this? The natural way to graph progress vs effort is
to have progress on the horizontal access and effort on the vertical
axis, because that's what you get when you're climbing a literal hill,
the only context in the universe where "vertical" and "horizontal"
aren't arbitrarily assigned but are real spatial dimensions.

The only reason to do it the other way is an association with time and
the convention of using time for the horizontal axis.

> This talk about swapped axes only come from people who used the steep
> learning curve metaphor, when you then try to show them what an actual
> steep learning curve implies.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Jussi Piitulainen]

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.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Jussi Piitulainen]

Steven D'Aprano writes:

[in response to my attempt to understand "steep learning curve"]

> "Learning curve" or "experience curve" is not just an metaphor, it is
> an actual technical term. See the Wikipedia article:
>
> https://en.wikipedia.org/wiki/Learning_curve
>
>
> Now, there are a couple of ways that we can interpret the idiom of
> "steep learning curve". One is the way Wikipedia interprets it: as a
> mistake.

[- -]

Ouch. Next time I hear anyone use the phrase, if I need to know whether
they mean "easy to learn" or "hard to learn" or something else, I think
I'll ask them...

Thanks.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Antoon Pardon]

Op 15-07-16 om 12:56 schreef Steven D'Aprano:
> On Fri, 15 Jul 2016 06:40 pm, Jussi Piitulainen wrote:
>
>> 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.
> That's not necessarily the case. See below.

I think it does.

>
> "Learning curve" or "experience curve" is not just an metaphor, it is an
> actual technical term. See the Wikipedia article:
>
> https://en.wikipedia.org/wiki/Learning_curve

I know and the technical term precedes the metaphor.

> Remember that the English idiom of a steep learning curve is not just hard
> to learn. It means that something takes a lot of effort to gain mastery
> over, after which things become easier.

Yes things/practicing become easier, mastering even further does not.

> Here is a curve that matches the common idiom. It is (1) steep, (2) requires
> a lot of effort for very little progress at the beginning, and (3) becomes
> easier with time:
>
>
> K   x
> n  x
> o x
> w   x
> l x 
> e  x
> d  x
> g x
> e
> + Effort or cost or time

I think you are making things up now. I have never seen an actual learning
curve with that shape. All learning curves I have seen show the law of
diminishing (marginal) returns.

> Another way to interpret it is to ask, what's the *cost* (in time, or
> effort) to gain a certain amount of knowledge? That's equivalent to
> swapping the X and Y axes:

Which you don't expect because if swapping axes was common, most people
would understand that talking about steep or shallow curves would be
meaningless since you wouldn't know whether is was steep with standaard
ax positions or steep with swapped ax posititions.

>
> Cx
> o   x
> sx
> t
> ·  x
> o
> r
> ·
> t x
> i
> m
> e
> + Knowledge gained
>
>
>
> That's not the conventional layout of the axis, but it does make sense, and
> it's more likely that people have this reversed layout in mind when
> thinking about "steepness of learning" than it is that they were thinking
> about the original curve and misinterpreting the meaning of the gradient.

No, that is what people come up with afterwards. If you just start a 
conversation
about how people learn and how long it would take to get some mastery and how we
could present progress in a graph, virtually everyone uses the conventional axes
layout. This talk about swapped axes only come from people who used the steep
learning curve metaphor, when you then try to show them what an actual steep
learning curve implies.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Antoon Pardon]

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

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Steven D'Aprano]

On Fri, 15 Jul 2016 06:40 pm, Jussi Piitulainen wrote:

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

That's not necessarily the case. See below.


>> 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
> 
> First two steps l-e plain sailing. Next two steps a-r steep climb. Cost
> is the effort that makes the learner experience the learning as steep.
> (Spending more *time* without ever paying much attention may not be the
> best of ideas - it may be the worst of ideas - if the goal is to learn
> but it still fits the graph: cost goes up for little or no gain.)
> 
> Perhaps more proper to call that a cost-to-learn curve or something?
> But when it becomes unwieldy, it gets shortened to something shorter,
> and here the more informative component has won. Maybe.

"Learning curve" or "experience curve" is not just an metaphor, it is an
actual technical term. See the Wikipedia article:

https://en.wikipedia.org/wiki/Learning_curve


Now, there are a couple of ways that we can interpret the idiom of "steep
learning curve". One is the way Wikipedia interprets it: as a mistake.
According to this conventional explanation, people have *wrongly* imagined
a curve like this:

(for best results, view using a fixed width font like Courier)

K   x
nx
ox
w
l  x 
e
d  
g x
e
+ Effort or cost or time needed to gain that knowledge or skill


as being "hard to learn" at the beginning, when in fact it shows the
opposite: with just a little bit of effort, you can learn a lot. But (so
goes the conventional explanation) people think of steep in the sense of
climbing a steep mountain, and think that it shows that the learning
process is really hard at the start.

I believe Wikipedia is wrong. I think that there is a natural interpretation
of "steep learning curve" which matches *both* the idiomatic and technical
meanings, with the same graph.

Remember that the English idiom of a steep learning curve is not just hard
to learn. It means that something takes a lot of effort to gain mastery
over, after which things become easier.

Learning Ancient Etruscan is hard for beginners and experts alike, because
there is so little information available about Ancient Etruscan that even
the experts can hardly be said to have mastered the language. That would
not often be described as a steep learning curve, as it lacks the sense of
getting easier with time. Learning Etruscan might have a curve like this:

K
n   x
o x
w x
l   x 
e x
d   x
g x
e
+ Effort or cost or time

It's hard at the beginning, because you don't know the language; then it
gets a bit easier, for a while, then it gets difficult again because you
run out of information about the language.

Here is a curve that matches the common idiom. It is (1) steep, (2) requires
a lot of effort for very little progress at the beginning, and (3) becomes
easier with time:


K   x
n  x
o x
w   x
l x 
e  x
d  x
g x
e
+ Effort or cost or time


Mastery makes the going easy, but it takes a long time to see any real
progress. You can interpret the "steepness" in two ways: it's steep (easy)
for experts, and if you turn your head to the side, it's steep (hard, like
climbing a steep mountain) at the beginning).

Another way to interpret it is to ask, what's the *cost* (in time, or
effort) to gain a certain amount of knowledge? That's equivalent to
swapping the X and Y axes:

Cx
o   x
sx
t
·  x
o
r
·
t x
i
m
e
+ Knowledge gained



That's not the conventional layout of the axis, but it does make sense, and
it's more likely that people have this reversed layout in mind when
thinking about "steepness of learning" than it is that they were thinking
about the original curve and misinterpreting the meaning of the gradient.






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

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Antoon Pardon]

Op 15-07-16 om 11:20 schreef Marko Rauhamaa:
> Antoon Pardon :
>
>> 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.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Marko Rauhamaa]

Antoon Pardon :

> 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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[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

First two steps l-e plain sailing. Next two steps a-r steep climb. Cost
is the effort that makes the learner experience the learning as steep.
(Spending more *time* without ever paying much attention may not be the
best of ideas - it may be the worst of ideas - if the goal is to learn
but it still fits the graph: cost goes up for little or no gain.)

Perhaps more proper to call that a cost-to-learn curve or something?
But when it becomes unwieldy, it gets shortened to something shorter,
and here the more informative component has won. Maybe.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Antoon Pardon]

Op 15-07-16 om 08:06 schreef Marko Rauhamaa:
> Ian Kelly :
>
>> On Jul 14, 2016 11:37 AM, "Marko Rauhamaa"  wrote:
>>> Where do you get the idea that the common usage is "wrong?" What do
>>> you use as a standard?
>> Is it "wrong" to consider some usages "wrong"? By what standard?
>>
>> I'm not interested in arguing over philosophy, so I won't.
> 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.

-- 
Antoon Pardon

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Marko Rauhamaa]

Ian Kelly :

> On Jul 14, 2016 11:37 AM, "Marko Rauhamaa"  wrote:
>> Where do you get the idea that the common usage is "wrong?" What do
>> you use as a standard?
>
> Is it "wrong" to consider some usages "wrong"? By what standard?
>
> I'm not interested in arguing over philosophy, so I won't.

Common usage among educated speakers ordinarily is the yardstick for
language questions.

However, I'm cool with "cuz I say so."


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Lawrence D’Oliveiro]

On Friday, July 15, 2016 at 12:17:27 PM UTC+12, Ian wrote:

> Is it "wrong" to consider some usages "wrong"? By what standard?

Do you say “head over heels” or “heels over head”? “Burgle” or “burglari{s,z}e”?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Ian Kelly]

On Jul 14, 2016 11:37 AM, "Marko Rauhamaa"  wrote:
>
> Ian Kelly :
> > On Thu, Jul 14, 2016 at 10:02 AM, Marko Rauhamaa 
wrote:
> >>In American English, the original word for [significand] seems to
> >>have been mantissa (Burks[1] et al.), and this usage remains
> >>common in computing and among computer scientists.  >>https://en.wikipedia.org/wiki/Significand#Use_of_.22mantissa.22>
> >
> > Just because it's already common to use the wrong term doesn't mean
> > the usage should be promulgated further.
>
> Where do you get the idea that the common usage is "wrong?" What do you
> use as a standard?

Is it "wrong" to consider some usages "wrong"? By what standard?

I'm not interested in arguing over philosophy, so I won't.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Lawrence D’Oliveiro]

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.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Marko Rauhamaa]

Ian Kelly :
> On Thu, Jul 14, 2016 at 10:02 AM, Marko Rauhamaa  wrote:
>>In American English, the original word for [significand] seems to
>>have been mantissa (Burks[1] et al.), and this usage remains
>>common in computing and among computer scientists. >https://en.wikipedia.org/wiki/Significand#Use_of_.22mantissa.22>
>
> Just because it's already common to use the wrong term doesn't mean
> the usage should be promulgated further.

Where do you get the idea that the common usage is "wrong?" What do you
use as a standard?


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Ian Kelly]

On Thu, Jul 14, 2016 at 10:02 AM, Marko Rauhamaa  wrote:
> Ian Kelly :
>
>> The significand of -3.14159 is the sequence of digits 314159. The
>> mantissa of -3.14159 is the number 0.85841.
>
> Fight it all you want. However:
>
>In American English, the original word for [significand] seems to
>have been mantissa (Burks[1] et al.), and this usage remains common
>in computing and among computer scientists.
>https://en.wikipedia.org/wiki/Significand#Use_of_.22mantissa.22>

Just because it's already common to use the wrong term doesn't mean
the usage should be promulgated further.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Marko Rauhamaa]

Ian Kelly :

> The significand of -3.14159 is the sequence of digits 314159. The
> mantissa of -3.14159 is the number 0.85841.

Fight it all you want. However:

   In American English, the original word for [significand] seems to
   have been mantissa (Burks[1] et al.), and this usage remains common
   in computing and among computer scientists.
   https://en.wikipedia.org/wiki/Significand#Use_of_.22mantissa.22>


   This digit string is referred to as the significand, mantissa, or
   coefficient.
   https://en.wikipedia.org/wiki/Floating_point#Floating-point_numbers>

and, FWIW:

   Liukulukuun kuuluu neljä osaa: etumerkki (s), mantissa (m), kantaluku
   (k) ja eksponentti (c). [...]

  x = (−1)^s mk^c.

   https://fi.wikipedia.org/wiki/Liukuluku>


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Robert Kern]

On 2016-07-14 15:30, Ian Kelly wrote:

On Jul 14, 2016 1:52 AM, "Steven D'Aprano"
 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

--
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Ian Kelly]

On Jul 14, 2016 1:52 AM, "Steven D'Aprano"
 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".
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Steven D'Aprano]

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.


-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Ian Kelly]

On Wed, Jul 13, 2016 at 9:39 PM, Lawrence D’Oliveiro
 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:
>>> 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?

Because integers don't have a mantissa.

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.

Back to naming, I think the best you could do would just be something
utterly generic like "formatted size". It doesn't help that in some
cases it represents a minimum size and in other cases a maximum, so
you can't even characterize it with that.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Lawrence D’Oliveiro]

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?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[MRAB]

On 2016-07-14 01:45, Ian Kelly 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.


Perhaps "precision or whatever"? :-)

--
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Ian Kelly]

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.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Lawrence D’Oliveiro]

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?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Chris Angelico]

On Thu, Jul 14, 2016 at 12:23 AM, Jussi Piitulainen
 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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Jussi Piitulainen]

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'
>
> E, 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.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Antoon Pardon]

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


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Chris Angelico]

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'

E, 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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Jussi Piitulainen]

Chris Angelico writes:

> On Wed, Jul 13, 2016 at 9:46 PM, Dennis Lee Bieber
>  wrote:
>> On Wed, 13 Jul 2016 00:21:17 -0600, Ian Kelly 
>> 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'
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Jussi Piitulainen]

Dennis Lee Bieber writes:

> On Wed, 13 Jul 2016 00:21:17 -0600, Ian Kelly 
> 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(-90,91), 100):
x, y = safer(n), dangerouser(n)
if x == y: continue
print('differ:', n, x, y)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Chris Angelico]

On Wed, Jul 13, 2016 at 9:46 PM, Dennis Lee Bieber
 wrote:
> On Wed, 13 Jul 2016 00:21:17 -0600, Ian Kelly 
> 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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[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


-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Lawrence D’Oliveiro]

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.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Marko Rauhamaa]

Ian Kelly :

> 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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Ian Kelly]

On Mon, Jul 11, 2016 at 9:38 PM, Steven D'Aprano  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
> '  007b'
>
> 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 007b have very different
> meanings: the first is a byte, the second may be a short int, and the third
> may be a long int.

And what about 0007b? After all, the very example that started this
thread wanted 5 hex digits, not a nice, even power of 2.

> Why shouldn't we use the "precision" field for this?

For the same reason that we shouldn't use the "mean" function to calculate sums.

 If you truly wanted to format the number with a precision
 of 5 digits, it would look like this:

 0x123.00
>>>
>>> Er, no, because its an integer.
>>
>> Which is why if you actually want to do this, you should convert it to
>> a decimal or a float first (of course, those don't support hexadecimal
>> output, so if you actually want hexadecimal output *and* digits after
>> the (hexa)decimal point, then I think you would just have to roll your
>> own formatting at that point).
>
> What? No no no. Didn't you even look at Lawrence's example? He doesn't want
> to format the number with decimal places at all.

I was referring to the example above. I'm completely aware that it's
not the same as what Lawrence wanted.

> Converting an integer to a float just to use the precision field is just
> wrong.

What if I've been doing my math with fixed-point integers (because I
don't know about or just don't like decimals), and now I want to
format them for output? Is this just wrong?

'{:.2f}'.format(int_value / 100)

> Now lets go the other way. How to you distinguish between a distance
> measured using an unmarked metre stick, giving us an answer of 123 metres,
> versus something measured with a 10km ruler(!) with one metre markings?
> Obviously with *leading* zeroes rather than trailing zeroes.

Fair enough, but I still wouldn't call that "precision".

> It *does* matter for measuring curves, but paradoxically the bigger the
> measuring stick (the more leading zeroes) the worse your measurement is
> likely to be. This is the problem of measuring coastlines and is related to
> fractal dimension. Suppose I lay my 10km long measuring stick along some
> piece of coastline, and measure it as 00123 metres. (It's a *thought
> experiment*, don't hassle me about the unfeasibly large stick. Divide
> everything by a thousand and call it a 10m stick marked in millimetres if
> you like.) Chances are that if I used a 1 metre measuring stick, and
> followed the contour of the coast more closely, I'd get a different number.
> So the more leading zeroes, the less accurate your measurement is likely to
> be. But interesting as this is, for most purposes either we're not
> measuring a curve, or we are but pretend we're not and ignore the fractal
> dimension.

If you use a 1 meter stick to measure the coastline, you'll go mad as
the tide keeps ruining your careful measurements. Best to just use the
10 km stick and get it over with.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Steven D'Aprano]

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.23000... 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
'  007b'

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 007b 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 

Re: Curious Omission In New-Style Formats

[Ian Kelly]

On Mon, Jul 11, 2016 at 5: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.
>
> 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'
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Ethan Furman]

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~
--
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Gregory Ewing]

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
--
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Gregory Ewing]

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
--
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Terry Reedy]

On 7/11/2016 3:27 PM, Ian Kelly wrote:

On Mon, Jul 11, 2016 at 12:54 PM, Terry Reedy  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

--
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Random832]

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 & 0xf

If you have "5" as a parameter, you can get the desired constant as (1
<< x*4) - 1.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Michael Torrie]

On 07/11/2016 01:27 PM, Ian Kelly wrote:
> On Mon, Jul 11, 2016 at 12:54 PM, Terry Reedy  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



-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Ian Kelly]

On Mon, Jul 11, 2016 at 12:54 PM, Terry Reedy  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'
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Terry Reedy]

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 
0 to 9 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

--
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Ian Kelly]

On Mon, Jul 11, 2016 at 10:28 AM, Steven D'Aprano  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 000123 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.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Ethan Furman]

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~
--
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Steven D'Aprano]

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

> On Sun, Jul 10, 2016 at 6:34 PM, Lawrence D’Oliveiro
>  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.0.

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.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Ian Kelly]

On Sun, Jul 10, 2016 at 6:34 PM, Lawrence D’Oliveiro
 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.

> 

Well, str.format does not use the same syntax as printf.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Lawrence D’Oliveiro]

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.


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Ian Kelly]

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'
>
> but not in new-style formats:
>
> >>> "{:#0.5x}".format(0x123)
> Traceback (most recent call last):
>   File "", line 1, in 
> 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.
-- 
https://mail.python.org/mailman/listinfo/python-list