Splitting numeric litterals
in [Python]
|
From: Terry Reedy on 16 Jul 2010 18:51 > On 7/16/10 12:30 PM, bart.c wrote: >> 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. No, only 20 digits >>> math.factorial(1000) 402387260077093773543702433923003985719374 ... Most big ints people want to work with can be encoded similarly. -- Terry Jan Reedy
From: Steven D'Aprano on 16 Jul 2010 20:57 On Fri, 16 Jul 2010 18:30:38 +0100, bart.c wrote: >> 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. 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
From: Steven D'Aprano on 16 Jul 2010 21:02
On Fri, 16 Jul 2010 15:41:45 +0100, MRAB wrote: >> 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. 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? -- Steven |