So (as AWOL says) the Arduino "nicety" is actually a kludge that one should probably avoid if one wants to develop good habits to use outside of ArduinoLand(tm). I'll keep my habit of converting "B" to "0b" when cleaning up examples that I'm learning from...
And base 5 is common in counting. I, II, III, IIII, IIII
Thinking back on it, that is probably where I got it from.
Edit: corrected quote tags... One of the few times I forget to preview my post, and I put a "/" in the wrong place...
AWOL:
Though why anyone would consider expressing a literal of more than four bits in binary is beyond me.
I've seen (and used) occasions where on a single byte the placement of the high bits is more important than the value. Particularly bit-masking for flags, it's easier (for me) to see the 6th, 4th, 2nd and 1st bits are high (counting 1-8 starting with LSb on the right) on 0b00101101 instead of 0x2D or 45 (let alone 055 (yes, I can learn)).
Sembazuru:
(Side note about the "beings with 10 fingers" comment... Back when I used to wait tables I developed a finger counting method that, while is actually base 5 (1,2,3,4,10,11,12,13,14,20, etc...), I called "groups of 5" that I used for counting number of chairs or people in a room. Quickly move my fingers behind my back, and then when back in the safety of the waiter's station or kitchen count 25 for the left thumb, 5 for each left finger, and 1 for each right digit. To the customers it just looks like I'm standing there looking over the room with my hands behind my back. My short-term memory for numbers is so short, I needed to keep track on my fingers so I didn't loose count if someone asked me where the bathroom is... So much for base 10 being default...)
There actually is a combination base-5 / base-10 method called "chisanbop".
Right fingers (except for thumb) = 1 unit per finger
Right thumb = 5 units
Left fingers (except for thumb) = 10 units per finger
Left thumb = 50 units
And as for losing track of numbers, I too am very distractable. Only for me it's not limited to numbers.
I wonder: why is it considered less socially acceptable to refuse to acknowledge someone who is interrupting you, than it is to interrupt someone? Why isn't the interrupter the "bad guy"?
As for a leading zero for octal: I doubt that a worse piece of design in programming language syntax exists anywhere. Except maybe for those programming languages which number the months of the year from 0 to 11 (such as C and ECMAScript).
Let's see: I believe that the relevant rule in many programming languages (including the Arduino programming environment) goes like this:
Numbers with only decimal digits (0 through 9) are decimal.
Except if they begin with 0, in which case they are octal.
Except if they contain a decimal point, in which case they are decimal after all.
Please correct me if I am wrong.
The leading zero and 0x notation is only used for integers, so the presence of a decimal point changes the game so to speak.
While the months are not part of the language, they are part of the time.h suite of the standard library - which is defined byt he standard. K&R are very careful to point out that the months number represents the "months since January" (italics in original). Harbison and Steele point out the same distinction - which probably came from unix.
odometer:
As for a leading zero for octal: I doubt that a worse piece of design in programming language syntax exists anywhere. Except maybe for those programming languages which number the months of the year from 0 to 11 (such as C and ECMAScript).
Let's see: I believe that the relevant rule in many programming languages (including the Arduino programming environment) goes like this:
Numbers with only decimal digits (0 through 9) are decimal.
Except if they begin with 0, in which case they are octal.
Except if they contain a decimal point, in which case they are decimal after all.
Please correct me if I am wrong.
except if they contain a decimal point or an exponent, I think. 02e4 = 20000.0
As for zero-origin indexing: following your logic, why aren't the days within each month numbered starting from zero?
Because they are already numbered.
As are the months of the year.
Really, who understands month "1" to be February but a programmer, and then only in the context of source code?
Woe to that programmer if s/he uses that month numbering in a user interface...
As for zero-origin indexing: following your logic, why aren't the days within each month numbered starting from zero?
Because they are already numbered.
As are the months of the year.
Really, who understands month "1" to be February but a programmer, and then only in the context of source code?
Woe to that programmer if s/he uses that month numbering in a user interface...
I would guess, that if you start looking at date calculations, you would find that the 0 based method is more natural, and in fact there are a lot of (day-1) calculations in the code.
0 based lets you use modulo in calculations easily.
KeithRB:
I would guess, that if you start looking at date calculations, you would find that the 0 based method is more natural, and in fact there are a lot of (day-1) calculations in the code.
0 based lets you use modulo in calculations easily.
If you want to go that route, I recommend you think of the year as running from the beginning of March to the end of February. This makes dealing with leap years a lot simpler (if, in some ways, less intuitive).
If we reckon the human date "March 1" (of any year) as machine date 0, then machine date 31 will always mean April 1; machine date 61 will always mean May 1; Halloween and Christmas Day will come every year without fail on machine dates 244 and 299, respectively; and your girlfriend will wallop you if you don't special-case machine date 350.