I think that you have misunderstood my question, probably because it was badly phrased. I should have asked "Does it matter if the period variable is signed in the context of the BWD sketch" ?
No. These guys are talking about edge cases.
However they are trying to train you to use the right types, which cover all situations, not just 50% of them.
[quote author=Nick Gammon link=msg=2132548 date=1425974637]
No. These guys are talking about edge cases.
However they are trying to train you to use the right types, which cover all situations, not just 50% of them.
[/quote]I get that, but surely it is a case of using the correct variable type for the circumstances. Heaven forbid that I would want to time a period of 40 days using millis() but if I did then I would not use a signed long for the period variable.
If we were to use the right type of variable to "cover all situations" then we would never use ints, signed or otherwise, in case the value of the variable exceeded what the int could hold, and would use longs instead.
Horses for courses.
AWOL:
But if you only use ">" you guarantee that the blink will be late, unless you adjust "interval".
Maybe no big deal if it's "only" 1 millisecond in a 1000, but shorten those times, and things start to become significant.
That's right. I was also thinking about this... it's about documentation and "fulfilling contracts" as well. Specifications, if you like, or at least expectations. In this case, the specification is not explicitly stated. The documentation doesn't even make a reference to the frequency of the blink. It has to be inferred from the "1000" figure. Actually, I see that as a failure. There should be some lines in there to explain what the target behaviour is (not only to enable proper verification, but also to set a good example for learning coders). Yes, even though it is an example. Perhaps especially because it is an example.
That is exactly why, I read the revised code (with the unsigned number corrections made in 2013) and couldn't see anything wrong. My only expectation was the only one that was given, which was "blink an LED". If I had seen something in the comments like "flashes at a 2Hz rate", it might have twigged some small part of my brain to look for compliance to that requirement. But I was really looking for something more insidious like a complete failure to flash, like the behaviour of the code I didn't see (with signed numbers) after running for 50 days.
I'm not trying to dodge the bullet here. It might have taken me longer to find that bug anyway (usually I have no help solving problems from anybody and I have to keep hitting my head against the wall until I get it). But can you see how I was blindsided a bit?
There should also be a comment about the square wave frequency possibly becoming slower and not completely without jitter.
Yes.
UKHeliBob:
I get that, but surely it is a case of using the correct variable type for the circumstances. Heaven forbid that I would want to time a period of 40 days using millis() but if I did then I would not use a signed long for the period variable.If we were to use the right type of variable to "cover all situations" then we would never use ints, signed or otherwise, in case the value of the variable exceeded what the int could hold, and would use longs instead.
Horses for courses.
The documentation for millis() will lead you to use the correct datatype. I have a feeling that too many new programmers are just copying sketches and never bother to read the reference.
To your second point, longs can overflow just as ints can. So they don't cover all situations. Just saying.
To your second point, longs can overflow just as ints can. So they don't cover all situations. Just saying.
You just reinforced my point about using the correct variable type for the circumstances.
I absolutely agree - there is no specification, but seeing the number "1000", there is an expectation of a 0.5Hz blink rate.
As Nick has pointed out, it's all about best practice, and getting into good habits.
Until very recently, the Servo Sweep example also contained a mistake:
for(pos = 0; pos <= 180; pos += 1) // goes from 0 degrees to 180 degrees
The line was identical, except the "<=" was simply a "<", so the code and the comment disagreed.
UKHeliBob:
If we were to use the right type of variable to "cover all situations" then we would never use ints ...
Well "all situations" includes the Galactic Goat which is pursuing your spacecraft.
I mentally excluded that one.
Or is it a "gigantic mutant star goat"? My recollection of memes is a bit hazy.
"mutant star goat" it was.
Golgafrinchans, beware.
Was it a signed or unsigned goat though ?