Base prefix notation

majenko:
0bnnnnnnnn is C/C++

Bnnnnnnnn is a set of #defines in hardware/arduino/cores/arduino/binary.h:

#define B0 0

#define B00 0
#define B000 0
#define B0000 0
#define B00000 0
#define B000000 0
#define B0000000 0
#define B00000000 0
#define B1 1
#define B01 1
#define B001 1
...




If you want to be "proper", use 0bnnnnnnnn.

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:

So... what is octal notation?

But octal notation (leading zero)

D'oh! I should really read completely. All that slobber on my foot makes walking slippery. :wink:

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...) :wink:

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

int c3=076; <--- This is troublesome
int c4=098; <--- Ahhhh!!!!!! (actually throws a compiler error!)

I don't know why it always makes me crack up, but I love this comment in the 2nd edition of K&R:

Everyone's favorite trivial change: 8 and 9 are not octal digits

So pre-ANSI, your 098 might not have thrown an error, but I have no idea what it would do.

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 maybe for those programming languages which number the months of the year from 0 to 11 (such as C and ECMAScript).

I believe if you read the C language standard, you will find not a single reference to months of the year, or how they should be subscripted.

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.

I guess I just don't get the hostility to zero-origin indexing.

AWOL:
I guess I just don't get the hostility to zero-origin indexing.

It is not hostility to zero-origin indexing so much as hostility to a gotcha. Programming is hard enough without gotchas.

As for zero-origin indexing: following your logic, why aren't the days within each month numbered starting from zero?

following your logic,

Read my sig :wink:

Because they are already numbered.

Note that the days of the week (tm_wday) are "days since sunday". (0-6)
Days of the year (tm_yday) are "days since Jan 1". (0-364/365)

Actually the day of the month one is the wired one since it is the only one not stated as x since y.

majenko:
0bnnnnnnnn is C/C++

No it isn't. It is a Gnu extension.

majenko:
If you want to be "proper", use 0bnnnnnnnn.

If you want to be proper, use hexidecimal (0x followed by 0..9, a..f, or A..F) or octal (0 followed by 0..7).

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

KeithRB:

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

odometer:

KeithRB:

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

That's why 8 out of 10 cats prefer strftime()...

KeithRB:

int c3=076; <--- This is troublesome
int c4=098; <--- Ahhhh!!!!!! (actually throws a compiler error!)

I don't know why it always makes me crack up, but I love this comment in the 2nd edition of K&R:

Everyone's favorite trivial change: 8 and 9 are not octal digits

So pre-ANSI, your 098 might not have thrown an error, but I have no idea what it would do.

Those old compilers (from the mid 70s of the previous century) just considered, say, 099 to be equal to 8*9+9 == 81.

kind regards,

Jos

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.