h a l f b a k e r yCogito, ergo sumthin'
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Normal counting schemes, in any base, "roll over" periodically from 9999... to 10000.... People assign all sorts of artificial importance to these rollover events (Y2K, odometer rollover, all sorts of cultural emphasis on 10 and 100 and 1000, prices that always end in .99).
If we used a numbering
scheme based instead on a Gray code, there would be no such major rollover events. (Part of the definition of a Gray code is that only one digit changes between each number and the next.) People would therefore be more rational about numeric increments, and the world would be a better place. Ahem.
Gray code
http://hissa.nist.g.../HTML/graycode.html
[jutta, Dec 01 2001]
Odd number pricing and Melville E. Stone
http://www.uscg.mil...nchor%20January.doc
Caution! This is a Mac Word doc. The mention of odd number pricing is at the very end of the doc, on page 14. [bristolz, Dec 02 2001, last modified Oct 21 2004]
[link]
|
| |
Not really. Every number more than '1, 2, 3...' would be a mile long. Instead of going 99->100, this would seem to make it necessary to go 99-991 or something. People would just start attaching importance to when a new digit was added. |
|
| |
Or, the other way, there would BE no 99->100', or even 9->10 and we'd be stuck with only 10 numbers. |
|
| |
Modern odometers are designed to run up to one million - 1, and none of these cars will ever live to see that anyway. |
|
| |
Rollover, and having milestones, is useful -- to have round numbers for estimates. And to avoid adding digits, you'd need to know the maximum range you were dealing with at any time. |
|
| |
The counting system of every nation, whether decimal, duodecimal, base60, base 5; arabic or roman; numerals have all incorporated this system. We'd have to work out a whole new system in common language for specifying numbers. |
|
| |
Computers use roll-over, because it's easy to construct an adder like this. SImilarly, arithmetic in our current number system is based around steady increments and carrying overflows. If you can find any use for this, other than a disguised and very late anti-millennial rant, please explain. |
|
| |
Hah! Some time ago someone I know was trying to fix a problem on a digital video switcher and mumbled something about the "Gray code" being wrong coming off a shaft encoder. Now I (kind of) know what he meant.
This is why I keep coming here. |
|
| |
Wow, I didn't think it would be so unpopular. I guess people tend to get ticked off at any suggestion that basic foundations (calendar systems, numbering systems, etc.) be reformed. |
|
| |
Computers do use gray code, though admittedly not for arithmetic. Is there no way to perform "native" arithmetic with a gray code, or to make estimates? |
|
| |
This isn't an antimillennial rant. If anything, I'm a lot more annoyed by artificial pricing (psychologically, 1.99 seems a lot less than 2.00, so prices always end in .99 or .95). In general, people psychologically measure the difference between two numbers by looking at how many digits vary. The idea here is to use a numbering system where that estimation is actually (close to) valid, rather than often wrong (as is currently the case). |
|
| |
You didn't get the 1.99 problem in good old £ s d. Sorry, rant!
I don't think that your ever going to cure the 'significant number' problem by using other, different counting methods. It's something inherent in numbers. The 'magic' of numerology has fascinated people since numbers were invented. Short of doing away with numbers altogether (now there's a project worth a grant), I don't see how you're going to solve this (and even if you did, people would just find something equally daft to get fixated on). Croissant for the thought though. |
|
| |
I found a mention of odd number pricing, and I quote it here because it was in a Macintosh format Word doc that may be problematic for some (see link):
"Who is Melville E. Stone? If you have ever bought anything you owe Mr. Stone a debt of gratitude. Mr. Stone was the publisher of the Chicago Daily News. In 1875, he came up with the idea of odd pricing of merchandise by subtracting a penny from the price (e.g., $1.99). Now, Mr. Stone was just a publisher of a newspaper. However, he knew human nature. Through studying some test subjects he found out that people would think they were getting a better deal if the item was priced a few pennies cheaper than a whole dollar. Of course, he couldn't implement the policy alone, he had to have some help. So he enlisted the aid of his advertisers and they in turn introduced the pricing through the ads in his paper. The rest is history. So the next time you hear some announcer screaming "it's only $19.99" or if you see an advertisement for $14.95, think of Mr. Melville E. Stone." |
|
| |
Whilst £1.99 pricing is obviously articfical, if you had some kind of counting system that was truely continuous, like a (colour) grey scale, with 0 at white and 100 at black, say, People would have a very hard time comparing prices or judging the cost of stuff. It's the same a celebrating New Year's Eve. You're really celebrating the passing of time, you're just celebrating it at new year. |
|
| |
Gray code was developed to address a specific class of problem involving parallel interfaces with systems exhibiting asynchronous state changes. Mechanical positioning is a classic example of this class of problem. The problem is that most common numbering systems require that the digits change *synchronously* for the values to remain valid. |
|
| |
If digits were to change asynchronously, then a transition from 99 to 100 might come out 099-->199-->109-->100 instead of simply 099-->100. Although the intermediate values are short-lived at the interface itself, in the absence of a reference clock to coordinate multiple digit changes (we are interfacing an asynchronous system, after all) each of these values must be treated as a state change with the same weight as the final state change. The errors introduced by this process will then continue to propagate through the digital system as the collected data is processed. |
|
| |
Gray code overcomes the problem by forcing successive state changes to involve only one digit. No clock is needed because a state change will never require two or more digit changes to be coordinated. |
|
| |
Sorry if the above snippet goes over anyone's head. 3 paragraphs is not really enough space to adequately cover a topic that normally occupies anywhere from 5 pages to a whole chapter in a communication theory textbook. |
|
| |
Another tiny problem with gray codes is that they are not unique: there's more than one ordering for any n-bit gray code (columns can be swapped as you like). We'd have to carry around huge tables listing what order we were using. |
|
| |
Incidentally, gray codes are also used in electronic design, for counters and particularly for state machine variables. Since it uses a certain amount of energy to change the value of a register, gray codes allow for a very power-efficient arrangement where only one bit need be changed per increment of a counter. In state machines, they allow for the change from one state to another consecutive state with the minimum number of control signals. |
|
| |
In any case, it sounds like the answer to a question nobody asked. <for normal counting, as the original idea.> |
|
| |
Multi-byte greycode counts can be useful for keeping track of quantities where an atomic increment operation is required. My preferred counting scheme would go [note: decimal used rather than bytes for clarity]: |
|
| |
000..009, 019, 010..018, 028, 029, 020..027, 037..036, ... 082..081, 091..090, 190..199, etc. |
|
| |
To convert a value stored in this way to a 'normal' count, simply add each digit to the following one, mod 10. To convert a normal number to greycode, subtract each digit from the next mod 10. These computations may easily be done before storing a number or after retrieving it from storage. |
|
| |
And this is easier than a sticky note, a pen and a normal number how? |
|
| |
Step back a little and see that any form of numerics or mathamatic is just a symbol system humans use to represent/understand/discuss the functions of the world around us - the menu is not the meal kinda thing... Enywayz, regarless of the symbol system used (binary, decimal, hex, greyscale,....), once the mind is adept at using a different symbol system, the same old human psychology will be drizzled over top. |
|
| |
There is no escaping our humanity... |
|
| |
I heard reason for the 4.99 pricing scheme, however, not for the origins, but the continuation. This has to do with comuterised tills. If somebody buys something for 5 pounds, dollars, yen, whatever. It is very easy for them to hand the chashier a £5 note, and for the cashier to place that note descretely in their pocket. If however, the item is priced £4.99, the buyer is still likely to pay with a £5 note, but will require change. The cashire is then forced to enter the transaction into the till in order to open the money drawer and obtain the customer's change; a log of the transaction has been made, and it will therefore be noticed, and obvious who is to blame, if there's money missing. |
|
| |
//You didn't get the 1.99 problem in good old £ s d. Sorry, rant!// |
|
| |
Did cashiers used to price items at £1.19.11? |
|
| |
Alternate suggested count sequence: 000..009, 019..010, 020..029..., 099..090, 190..199, 180..189... 109..100, 200 up etc. |
|
| |
If a number is odd, subtract the number to its right from nine. Perform this option right-to-left convert TO graycode; perform it left-to-right to convert FROM graycode. |
|
| |