Underscores in Python numbers

[Steven D'Aprano]

Re: Underscores in Python numbers

On Sun, 20 Nov 2005 01:39:04 +0000, Steve Holden wrote:
[color=blue]
> Steven D'Aprano wrote:
> [...][color=green]
>> Likewise, base conversion into arbitrary bases is not, in my opinion,
>> common enough a task that support for it needs to be built into the syntax
>> for literals. If somebody cares enough about it, write a module to handle
>> it and try to get it included with the Python standard modules.
>>[/color]
> In fact Icon managed to offer a syntax that allowed every base up to 36
> to be used: an "r" was used to indicate the radix of the literal, so hex
> 453FF would be represented as "16r453FF". This worked fine. Upper- and
> lower-case letters werw regarded as equivalent.[/color]

Forth goes significantly further than that: you can tell the Forth
interpreter what base you are using, and all numbers are then read and
displayed using that base. Numbers were case sensitive, which meant Forth
understood bases to at least 62. I don't remember whether it allows
non-alphanumeric digits, and therefore higher bases -- I think it does,
but am not sure.

Nevertheless, I don't believe that sort of functionality belongs in the
language itself. It is all well and good to be able to write 32r37gm, but
how often do you really need to write numbers in base 32?



--
Steven.

[Steven D'Aprano]

Re: Underscores in Python numbers

On Sun, 20 Nov 2005 01:39:04 +0000, Steve Holden wrote:
[color=blue]
> Steven D'Aprano wrote:
> [...][color=green]
>> Likewise, base conversion into arbitrary bases is not, in my opinion,
>> common enough a task that support for it needs to be built into the syntax
>> for literals. If somebody cares enough about it, write a module to handle
>> it and try to get it included with the Python standard modules.
>>[/color]
> In fact Icon managed to offer a syntax that allowed every base up to 36
> to be used: an "r" was used to indicate the radix of the literal, so hex
> 453FF would be represented as "16r453FF". This worked fine. Upper- and
> lower-case letters werw regarded as equivalent.[/color]

Forth goes significantly further than that: you can tell the Forth
interpreter what base you are using, and all numbers are then read and
displayed using that base. Numbers were case sensitive, which meant Forth
understood bases to at least 62. I don't remember whether it allows
non-alphanumeric digits, and therefore higher bases -- I think it does,
but am not sure.

Nevertheless, I don't believe that sort of functionality belongs in the
language itself. It is all well and good to be able to write 32r37gm, but
how often do you really need to write numbers in base 32?



--
Steven.

[Peter Hansen]

Re: Underscores in Python numbers

Steven D'Aprano wrote:[color=blue]
> Dealing with numeric literals with lots of digits is
> a real (if not earth-shattering) human interface problem: it is hard for
> people to parse long numeric strings.[/color]

I'm totally unconvinced that this _is_ a real problem, if we define
"real" as being even enough to jiggle my mouse, let alone shattering the
planet.

What examples does anyone have of where it is necessary to define a
large number of large numeric literals? Isn't it the case that other
than the odd constants in various programs, defining a large number of
such values would be better done by creating a data file and parsing it?

And if that's the case, one could easily define any convention one
desired for formatting the raw data.

And for the odd constant, either take a moment to verify the value, or
define it in parts (e.g. 24*60*60*1000*1 000 microseconds per day), or
write a nice little variant on int() that can do exactly what you would
have done for the external data file if you had more values.

-Peter

[Peter Hansen]

Re: Underscores in Python numbers

Steven D'Aprano wrote:[color=blue]
> Dealing with numeric literals with lots of digits is
> a real (if not earth-shattering) human interface problem: it is hard for
> people to parse long numeric strings.[/color]

I'm totally unconvinced that this _is_ a real problem, if we define
"real" as being even enough to jiggle my mouse, let alone shattering the
planet.

What examples does anyone have of where it is necessary to define a
large number of large numeric literals? Isn't it the case that other
than the odd constants in various programs, defining a large number of
such values would be better done by creating a data file and parsing it?

And if that's the case, one could easily define any convention one
desired for formatting the raw data.

And for the odd constant, either take a moment to verify the value, or
define it in parts (e.g. 24*60*60*1000*1 000 microseconds per day), or
write a nice little variant on int() that can do exactly what you would
have done for the external data file if you had more values.

-Peter

[Roy Smith]

Re: Underscores in Python numbers

Steven D'Aprano <steve@REMOVETH IScyber.com.au> wrote:[color=blue]
> That's a tad unfair. Dealing with numeric literals with lots of digits is
> a real (if not earth-shattering) human interface problem: it is hard for
> people to parse long numeric strings.[/color]

There are plenty of ways to make numeric literals easier to read without
resorting to built-in language support. One way is:

sixTrillion = 6 * 1000 * 1000 * 1000 * 1000

Or, a more general solution might be to write a little factory function
which took a string, stripped out the underscores (or spaces, or commas, or
whatever bit of punctuation turned you on), and then converted the
remaining digit string to an integer. You could then write:

creditCardNumbe r = myInt ("1234 5678 9012 3456 789")

Perhaps not as convenient as having it built into the language, but
workable in those cases which justify the effort.

[Roy Smith]

Re: Underscores in Python numbers

Steven D'Aprano <steve@REMOVETH IScyber.com.au> wrote:[color=blue]
> That's a tad unfair. Dealing with numeric literals with lots of digits is
> a real (if not earth-shattering) human interface problem: it is hard for
> people to parse long numeric strings.[/color]

There are plenty of ways to make numeric literals easier to read without
resorting to built-in language support. One way is:

sixTrillion = 6 * 1000 * 1000 * 1000 * 1000

Or, a more general solution might be to write a little factory function
which took a string, stripped out the underscores (or spaces, or commas, or
whatever bit of punctuation turned you on), and then converted the
remaining digit string to an integer. You could then write:

creditCardNumbe r = myInt ("1234 5678 9012 3456 789")

Perhaps not as convenient as having it built into the language, but
workable in those cases which justify the effort.

[Mike Meyer]

Re: Underscores in Python numbers

Steven D'Aprano <steve@REMOVETH IScyber.com.au> writes:[color=blue]
> On Sat, 19 Nov 2005 13:08:57 -0500, Peter Hansen wrote:[color=green]
>> Umm... in other words, "the underscore is under-used so let's assign
>> some arbitrary meaning to it" (to make the language more like Perl
>> perhaps?).[/color]
>
> +1
>
> I *really* don't like the idea of allowing underscores in numeric
> literals. Firstly, for aesthetic reasons: I think 123_456 is seriously
> ugly. Secondly, for pragmatic reasons, I think it is too easy to mistype
> as 123-456. I know that Python can't protect you from typing 9-1 instead
> of 901, but why add special syntax that makes that sort of error MORE
> common?)[/color]

I've seen at least one language (forget which one) that allowed such
separators, but only for groups of three. So 123_456 would be valid,
but 9_1 would be a syntax error. This kind of thing might help with
the detecting typos issue, and probably won't be noticed by most
users.

<mike
--
Mike Meyer <mwm@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Mike Meyer]

Re: Underscores in Python numbers

Steven D'Aprano <steve@REMOVETH IScyber.com.au> writes:[color=blue]
> On Sat, 19 Nov 2005 13:08:57 -0500, Peter Hansen wrote:[color=green]
>> Umm... in other words, "the underscore is under-used so let's assign
>> some arbitrary meaning to it" (to make the language more like Perl
>> perhaps?).[/color]
>
> +1
>
> I *really* don't like the idea of allowing underscores in numeric
> literals. Firstly, for aesthetic reasons: I think 123_456 is seriously
> ugly. Secondly, for pragmatic reasons, I think it is too easy to mistype
> as 123-456. I know that Python can't protect you from typing 9-1 instead
> of 901, but why add special syntax that makes that sort of error MORE
> common?)[/color]

I've seen at least one language (forget which one) that allowed such
separators, but only for groups of three. So 123_456 would be valid,
but 9_1 would be a syntax error. This kind of thing might help with
the detecting typos issue, and probably won't be noticed by most
users.

<mike
--
Mike Meyer <mwm@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Roy Smith]

Re: Underscores in Python numbers

Mike Meyer <mwm@mired.or g> wrote:[color=blue]
> I've seen at least one language (forget which one) that allowed such
> separators, but only for groups of three.[/color]

That seems a bit silly. Not all numbers are naturally split into groups of
three. Credit card numbers are (typically) split into groups of four.
Account numbers are often split into all sorts of random groupings.

[Roy Smith]

Re: Underscores in Python numbers

Mike Meyer <mwm@mired.or g> wrote:[color=blue]
> I've seen at least one language (forget which one) that allowed such
> separators, but only for groups of three.[/color]

That seems a bit silly. Not all numbers are naturally split into groups of
three. Credit card numbers are (typically) split into groups of four.
Account numbers are often split into all sorts of random groupings.

[Raymond Hettinger]

Re: Underscores in Python numbers

Gustav Hållberg wrote:[color=blue]
> I tried finding a discussion around adding the possibility to have
> optional underscores inside numbers in Python. This is a popular option
> available in several "competing" scripting langauges, that I would love
> to see in Python.
>
> Examples:
> 1_234_567
> 0xdead_beef
> 3.141_592[/color]

I suppose it could be done. OTOH, one could argue that most production
code has no business hardwiring-in numerical constants greater than 999
;-)

[Raymond Hettinger]

Re: Underscores in Python numbers

Gustav Hållberg wrote:[color=blue]
> I tried finding a discussion around adding the possibility to have
> optional underscores inside numbers in Python. This is a popular option
> available in several "competing" scripting langauges, that I would love
> to see in Python.
>
> Examples:
> 1_234_567
> 0xdead_beef
> 3.141_592[/color]

I suppose it could be done. OTOH, one could argue that most production
code has no business hardwiring-in numerical constants greater than 999
;-)

[Mike Meyer]

Re: Underscores in Python numbers

Roy Smith <roy@panix.co m> writes:[color=blue]
> Mike Meyer <mwm@mired.or g> wrote:[color=green]
>> I've seen at least one language (forget which one) that allowed such
>> separators, but only for groups of three.[/color]
> That seems a bit silly. Not all numbers are naturally split into groups of
> three. Credit card numbers are (typically) split into groups of four.
> Account numbers are often split into all sorts of random groupings.[/color]

True. But how often do you want to add two account numbers, or
multiply two credit card numbers? Or display them in hex, or otherwise
treat them as something other than a string that happens to be
composed of digits?

<mike
--
Mike Meyer <mwm@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Mike Meyer]

Re: Underscores in Python numbers

Roy Smith <roy@panix.co m> writes:[color=blue]
> Mike Meyer <mwm@mired.or g> wrote:[color=green]
>> I've seen at least one language (forget which one) that allowed such
>> separators, but only for groups of three.[/color]
> That seems a bit silly. Not all numbers are naturally split into groups of
> three. Credit card numbers are (typically) split into groups of four.
> Account numbers are often split into all sorts of random groupings.[/color]

True. But how often do you want to add two account numbers, or
multiply two credit card numbers? Or display them in hex, or otherwise
treat them as something other than a string that happens to be
composed of digits?

<mike
--
Mike Meyer <mwm@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[David M. Cooke]

Re: Underscores in Python numbers

Peter Hansen <peter@engcorp. com> writes:
[color=blue]
> Steven D'Aprano wrote:[color=green]
>> Dealing with numeric literals with lots of digits is
>> a real (if not earth-shattering) human interface problem: it is hard for
>> people to parse long numeric strings.[/color]
>
> I'm totally unconvinced that this _is_ a real problem, if we define
> "real" as being even enough to jiggle my mouse, let alone shattering the
> planet.
>
> What examples does anyone have of where it is necessary to define a
> large number of large numeric literals? Isn't it the case that other
> than the odd constants in various programs, defining a large number of
> such values would be better done by creating a data file and parsing
> it?[/color]

One example I can think of is a large number of float constants used
for some math routine. In that case they usually be a full 16 or 17
digits. It'd be handy in that case to split into smaller groups to
make it easier to match with tables where these constants may come
from. Ex:

def sinxx(x):
"computes sin x/x for 0 <= x <= pi/2 to 2e-9"
a2 = -0.16666 66664
a4 = 0.00833 33315
a6 = -0.00019 84090
a8 = 0.00000 27526
a10= -0.00000 00239
x2 = x**2
return 1. + x2*(a2 + x2*(a4 + x2*(a6 + x2*(a8 + x2*a10))))

(or least that's what I like to write). Now, if I were going to higher
precision, I'd have more digits of course.

--
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke
|cookedm(at)phy sics(dot)mcmast er(dot)ca