- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
And if you have postcodes with leading zeros (we have some in Oz) then storing them as numbers don't work.
Admin
If you don't need to do MATH with it, you likely only need it for display purposes or you might find you need to play string games on it anyway. I can't really think of a case where you'd want to store a number as a number except where there's math involved. Obviously something like a counter would probably be stored as a number, but its incrementing nature means it is being used for math anyway... (and though it may be stored in a DB as a number, it doesn't necessarily need to be treated as a number when we pull it out the DB unless we want to sort based on it later (where numbers might be a little more efficient)).
Admin
Admin
As this is not behaviour defined in the standard, but rather something that happens on a specific compiler with a specific optimization setting it would be rather unfair to show disrespect to the language for it....
Admin
Admin
For example: The international dialing code for Australia is +61 An area code within Australia is 0X where: X=2 = NSW/ACT X=3 = VIC (and Tas?) X=4 = Mobile X=7 = QLD X=8 = SA/NT/WA There used to (I think they were taken out when the numbers went to 8 digits) be some localised area codes, like country SA was (085) instead of (08), but we digress
For international callers, we drop the 0.
There are then 8 digits for the number (which has increased from 6 or 7 about 20 years ago according to certain rules). Generally, the first 4 (formally 2 or 3) of these 8 digits represent the Telephone Exchange, although in the digitalized world this is no longer guaranteed - but we digress.
Locally, most people used to leave off the area code (you can generally (excepting mobiles, I think) call other numbers within your area code without specifying it).
Firstly, people seem to write mobiles down differently to local numbers, eg: 0412 123 123 for mobiles 8123 1234 (or (08) 8123 1234) for local
But increasingly people seem to be realising that mobile numbers are the same as local numbers, and it's not uncommon anymore to see: (04) 1212 3123 (for the mobile above).
So far, this isn't a major issue, because we can strip punctuation in comparison, and even cut off area codes if we detect them. It becomes more complex, however when we realise the following numbers are possible (but not necessarily) the same: +61 8 8123 1234 011 61 8 8123 1234 08 8123 1234 8123 1234 (AFAIK, this could e(at least theoretically) xist in an area code other than 08)
Storing them is no issue as strings, but even as strings we have a problem of comparison - and a lot of takeaway stores seem to use the phone number to uniquely identify a customer....Of course, these issues are not necessarily insurmountable, but phone numbers are horribly complicated things, and are certainly not NUMBERS....
Admin
Exercise for the reader: devise a parser that can tell that 60608 is not a number but 6.022141e23 is.
Admin
Try this: Open a new sheet, and in the first cell put
and in the second putNow save it as a csv file (accepting that some formatting may be lost etc). Open the csv in something other than Excel, and we see that the string with the quotes is stored """01""" and the one without is 01. Now reopen the file in Excel and (you guessed it) the 01 becomes a 1....
IMHO Excel should be treating everything as a string when dealing with CSV format - especially something that has been created using a String function....
Admin
Any country is free to choose whatever they like as their international access code. It is standardised as "00" across Western Europe and "011" in North America. Most other countries go along with one of those two but certainly not all of them. There are a few weird ones out there that don't even begin with "0". Some former Soviet states (including Russia) still use "8" and some other countries use various things beginning with a "1".
As such, not allowing the user to enter a "+" is just asking for trouble. Who knows what they will enter instead? Maybe something flat out wrong? Maybe something right in their context but not in yours? Maybe something you need to decipher to work out? Maybe something you can't easily work out? Maybe something easily misunderstood as a local number?
The failure to understand that people do things differently in other countries and that you need to accommodate them if you want their money is an endless source of WTFs. In addition to things that won't take a phone number with a "+" in it there are the forms that won't let you enter a postcode with letters in a (mandatory) "zip code" field and even a few that expect you to pick a US state when you don't live in one (although admittedly I have not seen that particular manifestation of idiocy for quite a while now). You would expect to see this only on forms where it is expected that the users are all local, which is fair enough in many contexts, but sometimes there is also a field for country which implies that they would like to do business overseas if only they knew how to.
Admin
QED
Admin
Noones mentioned house numbers.
28A 1/27 U3/89 u2/57A 27-365 3 at 14
etc
Admin
The only place I could possibly see using a number as a number is the house number (so if one wanted to sort by house along a street), but even THAT is a WTF because not all house numbers are integers, or numbers.
PHP is such low-hanging fruit, why does Alex even bother posting them?
[image]The way I see it, there are only two types of PHP programs:
Initially written by a noob who really didn't know what he (or she) was doing, and managed to make every classic mistake in the book, or
Some sucker who has to maintain the garbage written by #1.
Face it, if you write a new application using PHP, you're doing it wrong. There is nothing that PHP does better except allow inexperienced people think they're skilled developers.
Admin
Admin
As for undefined meaning undefined, of course it would be expensive for implementations to diagnose all kinds of undefined behaviour and no one would want to incur that kind of expense all the time. But consider the Pascal standard, where the requirement is not that all kinds of undefined behaviour be diagnosed, the requirement is that implementations MUST OFFER AN OPTION where programmers can choose to require all kinds of undefined behaviour to be diagnosed. Pascal was vilified for providing an option for that amount of bondage and discipline. No one would ever accept such a safety measure in C. If people like that were in charge of automotive safety, seat belts would be illegal. People like that were in charge of nuclear power plant safety and see where that got us.
C gets the disrespect it deserves, you just need to look harder.
Admin
Also, historically, long distance calls even within a single country were considerably more expensive than local (intra-city) calls. Also phones were dialled using dials instead of push buttons. So if a phone were offered for public use by a corner store or other public facing proprietor, they would put a lock in the 9 position in the dial. Digits 1 to 9 could be dialled but 0 couldn't be dialled (except by historical phone phreaks of course). Phone numbers didn't have any 0 digits except the first digit of the city code. So local calls could be dialled but long distance calls could not be dialled.
Eventually pay phones replaced public use of phones provided by corner stores etc. (and later pay phones became obsolete because everyone except me carries a cell phone but let's not get ahead of ourselves), local numbers started to include embedded 0's the same as other digits, and the costs of calls were computed by some newfangled kind of calculating machine so it was no longer necessary to lock out the riffraff from dialling an initial 0.
Admin
Admin
Admin
Sadly, Veekun's article is pretty wrong in and of itself.
There are multiple in-depth analyses of what he got wrong floating around, but here's the HN thread that I most readily remember reading...
http://news.ycombinator.com/item?id=4177516
Akismet thinks I'm spamming, too. Silly software!
Admin
First name Max. Last name Int. Middle initial U.
Admin
Then it gets exported to .CSV, then opened in Excel which handily hacks the leading 0 off. Or converts it to scientific notation. Often both.
Admin
Admin
Admin
Admin
FTFY
Admin
As a consultant, am I supposed to keep identical copies of every 32-CPU server I'm still supporting and might-be supporting around the house, just in case one of them calls me up to fix something?
Admin
Admin
You have to store them unconventionally if a user could live in another country.
Admin
Admin
Admin
All this talk of 'numbers as text, unless you need to do maths (yes, I'm British)'...
What if you're designing a data warehouse for conspiracy theorists? That'd be a long running project I reckon!
Admin
Admin
No, it's not. It goes for things such as international standard book numbers, project numbers, employee numbers etc. just as well. Thing is, these are not really numbers, but keys.
You can't add project 4 to project 6 and expect the outcome to be project 10.
Incremental, numeric keys are a bad idea, anyway - they're a one-way trip to unscalable applications.
Admin
Admin
Because house numbers are usually, sort of, ordered. If you're looking for 1038 whatsit road and you just passed 1012 and 1014 whatsit road, you know you are moving in (probably) the right direction.
Unfortunately, it's often broken. My brother-in-law lives in a house with a number in the thousands. A couple of doors up the house numbers are in the tens of thousands. Very weird.
Admin
This is actually a really good, interesting, and useful, WTF. Can we have more of these please?
Admin
What, and break with tradition? Are you crazy?
Admin
Some human languages have this difference built-in, e.g. in Esperanto. "Because it is not a numbro, just a numero" (same as in French: nombre and numero)
Admin
numéro in French, I mean.
Admin
Yes, in the 1990s we went from 50-odd area codes to four, with the first few digits of the local number being of geographic significance. Confusing area codes like Hobart (002 or +61 02) were changed (to (03) 62 or +61 3 62). Most numbers only had a digit inserted, or other minor change. (085) became "(08) 85" which would have since been "overlaid" with "(08) 75". The renumbering also opened up the entire 04 range for mobile phones: 0G and 1G systems had various 00x and 01x prefixes while GSM started in 1992 with 041x. And there's talk of opening up 05 for mobiles too. One hundred million numbers is not enough for our population of 20-odd million!
I know very few exchanges with a full 10,000 number block: they are mostly in blocks of 1000. You can actually download a list from the Telstra website! (Starting from page 256 of the PDF)
Those are all the same number, depending where you call it from. +61 is the international prefix, it removes all ambiguity (AFAIK all mobile phones let you enter a literal "+" so you don't need to know about 00 or 011 or 0011 or 8~10 or whatever country you are in). 011 is "+" for the USA, Canada, et al. With the 08 is valid calling from anywhere in Australia, and without it is valid calling from anywhere in the 08 code - like a normal open dialling plan. (WA, NT, SA, and parts of western NSW) Indeed if you called 81231234 from the rest of NSW it could be a valid number in Sydney.
If I were in charge of numbering I'd "close" the numbering plan, remove all "area codes" and give everyone nine digit numbers. Internationally very few numbers would change (only some within +611); local numbers would gain a 2, 3, 7 or 8; while inter-area calls and mobiles would drop their initial 0. And while I'm at that I'd remove the notion of "local call" vs "long distance": calling interstate is no different to calling next door - I already get this from my voice provider.
I used to work at a pizza place that did that. All phone numbers were obviously stored as ints, but since the numbering plan is known and with nine significant digits it sort of made sense. I worked in the city which was "(07) 46xx xxxx". If you entered "21" as the phone number it became "07 4600 0021". This was handy because you could just enter the old-style six digit phone number and it would work itself out. If you entered a mobile number as nine digits beginning with 4 (or ten with 04) it would generally work, but they kept having to update the system to handle newer ranges. I remember when the 0438 range was released: entering 0438123456 would actually become "07 4612 3456". Whoops!
However, at the newest store entering "555123" actually became "07 0055 5123" because numbers beginning with 45 were introduced, which did cause some problems when going between stores. (Another WTF was the older stores had membrane keyboards and the new one had standard 101 keyboards, so you needed to know the codes the membrane keyboards would have sent out, like NAZ for $5.95 voucher or GAR for garlic bread. But I'm digressing; the computer system was replaced with a touchscreen system after I quit in 2005. The old system was a single P166 for the entire store using Wyse terminals)
Admin
Most countries with the initial 0 would be the equivalent of an American saying a phone number is "1212-555-1212". The 0 is the trunk prefix which is not used when dialling from International. But then the NANP is unique in that your trunk prefix of 1 is the same as your country code, so my example includes the trunk prefix; to be completely correct from an international perspective that number should be "+1.2125551212".
Admin
But EANs (of which ISBNs and UPC are subsets) have check digits that you add and modulo to ensure you have read the number correctly. That sounds like maths to me.
Admin
I wouldn't, because you do not do math with the entire set of digits, rather you pull it apart into its separate digits and then do math on that. It is a series of characters that fall within the range of 0-9 that you will split (string operation) then convert to numbers and perform a checksum calculation on.
If you saved it as a number field (int, double, float whatever) you would have to convert it to the string to split it then convert the pieces back to ints and do the math. Cut out one of those operations since you are not doing math on the original string of digits.
Edit: I will further mention those UPC codes or EAN's that begin with 0, save it as a number and you won't have the right number of digits to perform your checksum on, save it as a string and you will preserve your true EAN or UPC value.
Admin
Hi all. I'm the dummy who both wrote the dumb code and submitted the story. Let me clear up a few misunderstandings.
Absolutely. This was my critical mistake. My reasons for doing this were unsound, but even unsounder was introducing it so deep in the library chain that I didn't even realize the phone number had been touched by it. Immediately after discovering the bug, I removed the type-guesser and apologized to mankind.
No, not a slight excuse, that's the whole reason. If this had been in, say, an "annual salary" field, it may have jumped out faster. But it was showing up in a phone number field, and being massaged by the template into XXX-XXX-XXXX format, and we're from Dallas (where 214 is everywhere).
Which is what I did. Which is why I found the bug. Hey your hindsight is as good as mine!
Alex introduced an error when he massaged my article. The testing and production boxes are identical, and both exhibited the error. It was only on my dev box (64-bit) that things worked properly.
Speaking of which: you guys know Alex/team re-write the submissions, right? The basic facts of the story, and some of my original language – glad you guys liked the "pardner" – are here, but much of the color and some of the details are his. I didn't actually blame a co-worker or boss, test and production were both 32-bit, and I didn't actually learn anything from this.
The numbers were stored (and transmitted) as strings; it was my dumb type-guesser in the XML-reading library that broke things.
I'll not give you the former, but given that I submitted an embarrassing, self-incriminating story to a website of my peers, I'll give you the latter.
Admin
I just realized it doesn't come through in the article, but the phone number was only being int'ed before being sent to the template for rendering. It was a safe and happy string in the database and in the XML.
Admin
Also I wasn't doing it specifically to phone numbers, but to all strings that looked like numbers, which really was even stupider but it was a late night and I'd had lots of wine* and nobody checks my code before it goes into production.
*It was probably 10am and I was fully alert.
Admin
The main problem with storing phone number as number would be the loss of preceeding zeros.
Admin
If I am writing in C, it is at least partly because I don't want all of the hand-holding and its associated overhead that would be implied by a check for overflow everytime I added two numbers together. And don't tell me it can be done in "only a couple of assmembly instructions" - if I am using C, I expect maximum performance, and if results need checking, I will do it myself thank you very much.
Admin
From "The Tao of Software":
Programming languages which require that developers know and care about the number of bits in a numeric variable are ill-suited for business use.
Admin
...and even now, deep in the bowels of the advertising department, some junior copyrighter is running to his boss screaming "HEY! BOSS!! I GOT ME A IDEER!!!".
Admin