Clever trick or just just useless?

[flintstone]

Hi,

I found the code snippet I attached in a Flexmotion VI and it checks for counter overflow by subtracting the two unsigned long timestamp values and testing whether the result is <0. Now I've tried a similar construct at my machine and it behaves just as expected: The 32 bit counter rolls over as it should but since we are testing an unsigned value to be <0 the test never gives result "true".

Since the code in the "false" branch simply uses the result of the subtraction that should not be a practicat problem but I am wondering whether there is some clever trick behind that or if that is just the useless.

Cheers,

flintstone

By the way: Sorry for the double "just" and for the (succeeded) experiment whether one can rate the own topic.

Edited September 25, 2012 by flintstone

[drjdpowell]

The timers output unsigned U32 numbers, and the subtraction will produce the same U32. This cannot be less than zero so that code never executes. Which is not a problem since the subtraction will already handle the rollover satisfactorily; for example: 1 − 4294967295 = 2.

Understanding unsigned numbers and rollover is tricky; I usually have to experiment to remind myself how it works every time I have to do it.

— James

[Yair]

Like both of you already surmised, a U32 can't be negative, so the case isn't actually executed. I'm going with "useless".

If I had to guess, I would guess that either the person who did this used an algorithm which was designed for a signed integer or they simply didn't notice that a negative U32 is meaningless. I would say the latter is more likely, because comparing the two numbers would be simpler than subtracting and checking for less than zero. If this was a more standardized algorithm, I'm guessing it would do the comparison.

[Rolf Kalbermatter]

The timers output unsigned U32 numbers, and the subtraction will produce the same U32. This cannot be less than zero so that code never executes. Which is not a problem since the subtraction will already handle the rollover satisfactorily; for example: 1 − 4294967295 = 2.

Understanding unsigned numbers and rollover is tricky; I usually have to experiment to remind myself how it works every time I have to do it.

— James

I'm not sure where the claim comes from, about that understanding unsigned numbers is difficult. It supposedly is the reason that Java doesn't have unsigned integers since the original Java inventers claimed, that nobody understands them correctly anyhow so a language better does not provide support for them. I still have the feeling that they did not understand it and assumed that what is true for them must be true for everyone. Now if you need to implement binary protocol parsing that contains unsigned integers you really have to go nilly willy to get the right result in Java.

[drjdpowell]

I'm not sure where the claim comes from, about that understanding unsigned numbers is difficult.

From me. I find them a bit difficult. Just a bit.

[shoneill]

From me. I find them a bit difficult. Just a bit.

I don't know why people are hacking around on the poor old unsigned integers. They're a positive lot and never have anything ngative to say about anyone.

[flintstone]

Thanks for your replies. Unsigneds really are not too complicated (could be that my hw developing experience from the past years helps me there a lot).

Good to know that LV uses binary numbers just as the rest of the world does.

Cheers,

flintstone

[Aristos Queue]

Which VI did you pull that from? Because, yeah, the true case will never execute.

[Rolf Kalbermatter]

Thanks for your replies. Unsigneds really are not too complicated (could be that my hw developing experience from the past years helps me there a lot).

Yes hardware exposure on digital logic certainly helps the understanding. If you think of integers as a simple register or counter, the oddball in the mix is rather the signed integer than the unsigned due to its use of one's complements!

Think about it. The MSB is the sign!

-128 => 0x80

-1 => 0xFF

1 => 0x01

127 => 0x7F

A naive approach to this could be instead (offset notation):

-128 => 0x00

127 => 0xFF

or (separate sign bit):

-127 => 0x8F

-0 => 0x80

0 => 0x00

127 => 0x7F

The reason computer use the one's complement is that all the others are rather difficult to implement efficiently in logic for either addition and especially subtraction.

Since the code in the "false" branch simply uses the result of the subtraction that should not be a practicat problem but I am wondering whether there is some clever trick behind that or if that is just the useless.

I have seen such code too in the past and simply assumed that the original programmer either didn't think further than his nose, or may have used signed integers before, then in a frenzy to avoid coercion dots, changed them to unsigned without reviewing all the code and noticing the now superfluous positive check. In one or two cases the effective code was in fact in the negative branch of the case which of course never could happen, so that made me scratching my head a bit.

[flintstone]

@Aristos Queue: It is the Wait Reference.flx.

@rolfk: I did quite some VHDL programming in the past years and am confident about my skills there but I'm with LV now for some months and then you never know whether there is some hidden knowledge behind stuff like this .