Splitting numeric litterals

[candide]

The escape sequence \ENTER allows to split a string over 2 consecutive
lines. On the other hand, it seems impossible to split a numeric
litteral across multiple lines, compare :
.... 000\
.... 000"
'1000000000'
.... 000\
File "<stdin>", line 2

000\
^

SyntaxError: invalid syntax

Is this the general behaviour ? So, how do you edit code containing a
very very long numeric constant ?

 

[Steven D'Aprano]

The escape sequence \ENTER allows to split a string over 2 consecutive
lines. On the other hand, it seems impossible to split a numeric
litteral across multiple lines [...]
Is this the general behaviour ?

Yes. You can't put any whitespace in the middle of a numeric literal:

File "<stdin>", line 1
n = 4 2
^
SyntaxError: invalid syntax

So, how do you edit code containing a very very long numeric constant ?

s = (
"1234567890123456789012345678901234567890"
"1234567890123456789012345678901234567890"
"1234567890123456789012345678901234567890"
"1234567890123456789012345678901234567890"
"1234567890123456789012345678901234567890"
)
assert len(s) == 200
n = int(s)

 

[MRAB]

The escape sequence \ENTER allows to split a string over 2 consecutive
lines. On the other hand, it seems impossible to split a numeric
litteral across multiple lines, compare :

... 000\
... 000"
'1000000000'
... 000\
File "<stdin>", line 2
000\
^
SyntaxError: invalid syntax


Is this the general behaviour ? So, how do you edit code containing a
very very long numeric constant ?

Normally it's only string literals that could be so long that you might
want to split them over several lines. It is somewhat unusual to have a
_numeric_ literal that's very very long!

For an integer literal you could use a string literal and convert it to
an integer:

 

[candide]

MRAB a écrit :

want to split them over several lines. It is somewhat unusual to have a
_numeric_ literal that's very very long!

I agree. But consider RSA-155 for instance ...

For an integer literal you could use a string literal and convert it to
an integer:

OK.

In C, the following code is allowed :

int x=1000\
000\
000;

but not very usefull for sure !

 

[Lawrence D'Oliveiro]

Normally it's only string literals that could be so long that you might
want to split them over several lines. It is somewhat unusual to have a
_numeric_ literal that's very very long!

Seems a peculiar assumption to make in a language that allows integers of
arbitrary length, does it not?

 

[MRAB]

Seems a peculiar assumption to make in a language that allows integers of
arbitrary length, does it not?

What's the recommended maximum line length in Python? 80 characters? If
you take into account indentation, etc, that's still a long integer. And
it's still only the _recommended_ maximum.

 

[Steven D'Aprano]

What's the recommended maximum line length in Python? 80 characters? If
you take into account indentation, etc, that's still a long integer. And
it's still only the _recommended_ maximum.

Not only that, but it only takes 73 digits to write out the total number
of particles in the entire universe:

1000000000000000000000000000000000000000000000000000000000000000000000000

or 1e72. (Of course that's the lower-bound, estimates range from 1e72 all
the way up to 1e87.) So for anything related to counting or labelling
actual, physical objects, you will be dealing with smaller numbers than
that. E.g. the number of grains of sand on the earth has been estimated
(very roughly) as a mere 1000000000000000000000000, or 25 digits.

It always makes me laugh when I receive an invoice from some company, and
the account number or invoice number is (e.g.) 1000000023456789. Who do
they think they're fooling?

 

[MRAB]

Not only that, but it only takes 73 digits to write out the total number
of particles in the entire universe:

1000000000000000000000000000000000000000000000000000000000000000000000000

or 1e72. (Of course that's the lower-bound, estimates range from 1e72 all
the way up to 1e87.) So for anything related to counting or labelling
actual, physical objects, you will be dealing with smaller numbers than
that. E.g. the number of grains of sand on the earth has been estimated
(very roughly) as a mere 1000000000000000000000000, or 25 digits.

It always makes me laugh when I receive an invoice from some company, and
the account number or invoice number is (e.g.) 1000000023456789. Who do
they think they're fooling?

It's possible that they're splitting it into fields.

 

[bart.c]

Not only that, but it only takes 73 digits to write out the total number
of particles in the entire universe:

1000000000000000000000000000000000000000000000000000000000000000000000000

or 1e72. (Of course that's the lower-bound, estimates range from 1e72 all
the way up to 1e87.)
So for anything related to counting or labelling
actual, physical objects, you will be dealing with smaller numbers than
that. E.g. the number of grains of sand on the earth has been estimated
(very roughly) as a mere 1000000000000000000000000, or 25 digits.

Big integers tend to be used for playing around with mathematical ideas, and
they have to be exact. So if you wanted to hardcode 1000! for some reason,
you'd need some 2568 digits which is a little awkward on one line.

It always makes me laugh when I receive an invoice from some company, and
the account number or invoice number is (e.g.) 1000000023456789. Who do
they think they're fooling?

I used to do that. Giving someone an invoice number, or product serial
number, 000001 doesn't exactly give the impression of a thriving business.

 

[Robert Kern]

Big integers tend to be used for playing around with mathematical ideas, and
they have to be exact. So if you wanted to hardcode 1000! for some reason, you'd
need some 2568 digits which is a little awkward on one line.

This happens too rarely to justify adding line-spanning integer literals to the
language's syntax.

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

 

[Terry Reedy]

On 7/16/10 12:30 PM, bart.c wrote:

No, only 20 digits402387260077093773543702433923003985719374 ...

Most big ints people want to work with can be encoded similarly.

 

[Steven D'Aprano]

I used to do that. Giving someone an invoice number, or product serial
number, 000001 doesn't exactly give the impression of a thriving
business.

Sure, and there's nothing wrong with (say) 1000234 as your starting
figure. I know people who put the year as the starting four digits:
201012345, say. But when you're a one-man company, is anyone going to
think that you've genuinely put out 1000000000023456789 invoices to date?

Even if you're a giant multinational corporation, such a number is just
ridiculous, and it is user-hostile, especially when dealing with the
robot interface to their help-desk or paying bills by phone.

"Enter your invoice number followed by the hash-key."

1 *beep* 0 *beep* 0 *beep* 0 *beep* 0 *beep* 0 *beep* 0 *beep* 0 *beep* 0
*beep* 0 *beep* 2 *beep* 3 *beep* 4 *beep* 5 *beep* 6 *beep* ... 7 *beep*
8 * beep* 9 *beep* # *beep*

"Sorry, that invoice number is incorrect. Please try again."

 

[Steven D'Aprano]

It's possible that they're splitting it into fields.

Anything is possible. It's possible that they're encoding secret
instructions to their army of sleeper agents in the invoice numbers too,
but how likely is it?

Good accounting practice is to treat invoice numbers as a simple unique
numeric key. Every accounting software I've used has started the invoices
at some value N, and returned N+1, N+2, N+3, ... with the starting value
N user-configurable. But even if some software flies in the face of all
accounting principles, good database design, and common sense, by
overloading invoice numbers to include "fields" (of what?), what is the
likelihood that my fields just happen to be virtually all zero?