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?
>>
>>
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
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
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
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:
>>
>>
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
>>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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]
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
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
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
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
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
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
> >
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
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
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
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
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
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
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).
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:
>>
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,
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:
>
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
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
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
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
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
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
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
On Tue, Jul 12, 2016 at 2:19 PM, Steven D'Aprano wrote:
> On Tue, 12 Jul 2016 07:51 am, Chris Angelico wrote:
>
>> say, 2,147
>> millimeters, with a precision of four significant digits
>
>
> How do you represent 1 mm to a precision of four significant digits, in such
> a way
On Tue, 12 Jul 2016 07:51 am, Chris Angelico wrote:
> say, 2,147
> millimeters, with a precision of four significant digits
How do you represent 1 mm to a precision of four significant digits, in such
a way that it is distinguished from 1 mm to one significant digit, and 1 mm
to a precision of
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
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
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
On Tue, Jul 12, 2016 at 9:14 AM, Jan Coombs
wrote:
> Thees all look good, but you may get into trouble if you trust a
> PC with them!
>
> If the language/PC uses floating point representation then it
> will assign a fixed number of bits for the fractional part,
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
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
On Tue, 12 Jul 2016 07:51:23 +1000
Chris Angelico wrote:
[snip]
>
> Yep. Precision is also a property of a measurement, the same
> way that a unit is. If I pace out the length of the main
> corridor in my house, I might come up with a result of thirty
> meters. The number is
On Tue, Jul 12, 2016 at 6:56 AM, Ben Finney wrote:
> Precision is not a property of the number. It is a property of the
> *representation* of that number.
>
> The representation “1×10²” has a precision of one digit.
> The representation “100” has a precision of three
Ethan Furman writes:
> I will readily admit to not having a maths degree, and so of course to
> me saying the integer 123 has a precision of 5, 10, or 99 digits seems
> like hogwash to me.
Precision is not a property of the number. It is a property of the
*representation* of
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'
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
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
>>
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
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
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
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
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
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
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'
>>
>
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:
>
> >>>
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
67 matches
Mail list logo