Host Engineering Forum

General Category => General Discussion => Topic started by: Mike Nash on October 17, 2014, 02:26:15 PM

Title: Floats and ints and bitwise operators...oh my!
Post by: Mike Nash on October 17, 2014, 02:26:15 PM
Here's an example of a case where I'd like some formatting in MATH box expressions:

Code: [Select]
((Drum[V0] | IF(MHR7:0 & C201, RelayWDCfg0:SD, 0)) & IF(C103, -1, RelayPanicCfg0:SD) &
 IF(ST4, ~RelayFlashCfg0:SD, -1) & ~RelayTypeTOD0:SD) | (RelayTypeTOD0:SD & TODOutputs0:SD)

Actually doesn't look too bad on screen but hard to follow scrunched up in a little MATH edit box or at runtime.

I have no idea what that is supposed to do. It did make me look into the & and | a little and I get what I think are strange results.

I am also foggy on how to format this so the instruction is a MATH box with R0 as Result

Code: [Select]
IF(X0, 1.1, 2.2) | IF(X1, 4.4, 8.8)
X0  X1    R0
 0     0    10.0
 0     1     6.0
 1     0     9.0
 1     1     5.0
So why the truncation and why the addition?
Title: Floats and ints and bitwise operators...oh my!
Post by: Controls Guy on October 17, 2014, 02:28:28 PM
It's all boolean.  It replaces 32 rungs of ladder with 12 contacts per in one MATH box.  The answer gets sent to Y32:SD.

| and & are bitwise OR and AND, so they don't have any meaning in a floating point context.  I'm using them on bitpack DINTs.
Title: Floats and ints and bitwise operators...oh my!
Post by: franji1 on October 17, 2014, 02:38:27 PM
X0  X1    R0
 0     0    10.0
 0     1     6.0
 1     0     9.0
 1     1     5.0
should be
IF(X0, IF(X1, 5.0, 9.0), IF(X1, 6.0, 10.0))
Title: Floats and ints and bitwise operators...oh my!
Post by: Mike Nash on October 17, 2014, 03:05:04 PM
X0  X1    R0
 0     0    10.0
 0     1     6.0
 1     0     9.0
 1     1     5.0
should be
IF(X0, IF(X1, 5.0, 9.0), IF(X1, 6.0, 10.0))

But my question is more "why is the truncation and summing even happening?" I am not trying to get particular results, I just don't see where the results are coming from. In other words, I want to know what types of things I can do and what I had better avoid due to unexpected (by me) results.
Title: Floats and ints and bitwise operators...oh my!
Post by: Controls Guy on October 17, 2014, 03:08:11 PM
It's taking the IEEE 32-bit representation of the floating point values and ORing them bitwise.  Like I said, it's meaningless to try to do bit ops on floats, unless you're actually working on the value knowing the format (mantissa, exponent, etc.)

Here's the Wikipedia article on how 32-bit floats are encoded:  https://en.wikipedia.org/wiki/Single-precision_floating-point_format (https://en.wikipedia.org/wiki/Single-precision_floating-point_format)
Title: Floats and ints and bitwise operators...oh my!
Post by: franji1 on October 17, 2014, 03:09:21 PM
But my question is more "why is the truncation and summing even happening?"
In your version, you are bit-wise OR-ing floating point numbers.  That is not a good idea.  Only do bit-wise operations on integer types.
Title: Floats and ints and bitwise operators...oh my!
Post by: plcnut on October 17, 2014, 03:13:10 PM
"why is the truncation and summing even happening?"

You are combining BITwise instructions with real numbers. When you take a Real value of 5.0 and view is as bits, and then take the Real value of 2.0 and view it as bits and then OR the bits, you will get a series of bits that make sense as bits, but when you view those same bits as Real numbers, they *may* not resemble anything related to 5.0 and 2.0.
Title: Floats and ints and bitwise operators...oh my!
Post by: Mike Nash on October 17, 2014, 03:16:08 PM
AH! I get the bitwise ORing part now. I was using the 1,2,4 and 8s just so I would know where the results were coming from without realizing I was setting myself up!
Title: Floats and ints and bitwise operators...oh my!
Post by: b_carlton on October 17, 2014, 04:50:44 PM
Just out of curiosity I had to try it. The bitwise OR of 5.0 and 2.0 is ... 5.0   Big disappointment.
Title: Floats and ints and bitwise operators...oh my!
Post by: plcnut on October 17, 2014, 05:04:49 PM
Big disappointment.

I didn't pick very good numbers did I...
Hopefully it communicated a point though... about... Floating points ;D
Title: Floats and ints and bitwise operators...oh my!
Post by: Mike Nash on October 17, 2014, 06:20:14 PM
Just out of curiosity I had to try it. The bitwise OR of 5.0 and 2.0 is ... 5.0   Big disappointment.

Well now I am confused again. The simulator shows MATH R125 5.0 | 2.0 = 7.0 which is what I would expect per my new understanding.
Title: Floats and ints and bitwise operators...oh my!
Post by: b_carlton on October 17, 2014, 07:35:13 PM
I used the floating point calculator at http://www.h-schmidt.net/FloatConverter/IEEE754.html

5.0 gives a hex representation of 40A0 0000
2.0 gives a hex representation of 4000 0000

which bitwise ORed should give    40A0 0000 or 5.0

But the instruction help information clearly notes that it is not meant for Real values. This is probably why.
Title: Floats and ints and bitwise operators...oh my!
Post by: Controls Guy on October 21, 2014, 10:56:40 AM
Byte extraction casts!  I was hoping they were there and when I checked sure enough they were! Why do we not have a thumbs-up emoticon??

Feature request:  Restore our ability when viewing numeric memory locations in ASCII mode in a Data View to specify how many registers (or characters) to show on a line (like DS5 behavior).  Sometimes we still have to store text in numeric memory even though we have a string type now, and it also helps with Ctrl-Enter'ing multiple blocks at a time.

Thanks!
Title: Floats and ints and bitwise operators...oh my!
Post by: BobO on October 21, 2014, 11:27:24 AM
Byte extraction casts!  I was hoping they were there and when I checked sure enough they were! Why do we not have a thumbs-up emoticon??

Because we are better PLC developers than forum managers. ;)
Title: Floats and ints and bitwise operators...oh my!
Post by: franji1 on October 21, 2014, 11:40:39 AM
Feature request:  Restore our ability when viewing numeric memory locations in ASCII mode in a Data View to specify how many registers (or characters) to show on a line (like DS5 behavior).
That's what STRINGs are for.  You get a lot more ASCII display capabilities using STRINGs.

For raw numeric, you can still see the ASCII data, just one numeric element at a time.  There currently is no good way to specify the variable "length" in Data View.  Hence, you can still get as many as you want, up to 99 in one Data View.
Title: Floats and ints and bitwise operators...oh my!
Post by: BobO on October 21, 2014, 11:42:51 AM
Feature request:  Restore our ability when viewing numeric memory locations in ASCII mode in a Data View to specify how many registers (or characters) to show on a line (like DS5 behavior).
That's what STRINGs are for.  You get a lot more ASCII display capabilities using STRINGs.

Except when interacting with external servers, Mark. He's wanting to access something like Modbus memory as strings. It is a reasonable request.
Title: Floats and ints and bitwise operators...oh my!
Post by: Controls Guy on October 21, 2014, 11:48:46 AM
That's exactly right, BobO.  Externally accessible memory for names of stuff.  I could store it in a string type, but the only place it ever gets accessed is via Modbus so there'd be no point.  I'd leave the names in local HMI memory and never even transmit them to the PLC, except that a subset of them need to be visible from other HMI's.

Also, the total number of registers for all the strings I'd like to see simultaneously will often exceed 99, and will certainly exceed the number of lines visible on screen.
Title: Floats and ints and bitwise operators...oh my!
Post by: Controls Guy on October 21, 2014, 10:57:54 PM
Interestingly, Bernie,

R101 | R102 != R101:S | R102:S

If you do it the casted way, it does the bitwise OR you'd expect (at least if sent to an :S cast destination register).  If you do it without casting, 5.0 | 2.0 = 7.0.

I'm guessing that since OR wants integer arguments, if you don't explicitly cast them, it translates them to INT's by value, then does the bitwise OR.  Thus, 5.0 | 2.0   ->   5 | 2   ->   7   ->   7.0 (if assigned to a real register).

Hosties?
Title: Floats and ints and bitwise operators...oh my!
Post by: b_carlton on October 21, 2014, 11:46:55 PM
The help file does mention that floats are converted before a bitwise operation so that kind of blows the purpose. it's ok because they specifically warned against it.
Title: Floats and ints and bitwise operators...oh my!
Post by: Controls Guy on October 22, 2014, 12:43:29 AM
What is this "manual" you speak of?   Are you suggesting there's information I'm supposed to read first before just plunging ahead and doing stuff?   :D
Title: Floats and ints and bitwise operators...oh my!
Post by: BobO on October 22, 2014, 09:28:50 AM
There really isn't a right way to do a wrong thing. Bitwise operations are inherently integer, so we covert before the operation. Is that 100% what you wanted? Probably not, but it's more likely to produce a meaningful answer for the bulk of users than would leaving it float.

Since our cast operators are 'reinterpretors' rather than converters, you could cast the float to an integer, do the bitwise operation, output to a float cast to integer, then use as float. Haven't tried it, but that should work.
Title: Floats and ints and bitwise operators...oh my!
Post by: Controls Guy on October 22, 2014, 09:53:33 AM
Agreed, BobO.  I don't think anyone's contending that it should be any different than it is; we were assuming that it did bitwise ops on the bits as is, and that therefore the user simply shouldn't be using bit ops on floating point arguments.  Turns out you've cushioned it a little bit for the guys doing the stuff they're not supposed to be doing.  Any further discussion was just learning how it worked in detail (because it's interesting and to avoid using it for something it won't do, and even unanticipated behavior can be useful once you understand the rules).  No worries!
Title: Floats and ints and bitwise operators...oh my!
Post by: BobO on October 22, 2014, 10:39:01 AM
Agreed, BobO.  I don't think anyone's contending that it should be any different than it is; we were assuming that it did bitwise ops on the bits as is, and that therefore the user simply shouldn't be using bit ops on floating point arguments.  Turns out you've cushioned it a little bit for the guys doing the stuff they're not supposed to be doing.  Any further discussion was just learning how it worked in detail (because it's interesting and to avoid using it for something it won't do, and even unanticipated behavior can be useful once you understand the rules).  No worries!

I got that. I was just trying to clarify how it worked and give you a glimpse inside our discussions. Virtually every debate/discussion we've seen on the forum has already happened here at Host. When we have an arbitrary choice of how to deal with an exception condition, we try to choose the way that takes the pointy stick away from the noob.

And what I described is the answer to this behavior:

Quote from: Controls Guy
R101 | R102 != R101:S | R102:S

Title: Re: Floats and ints and bitwise operators...oh my!
Post by: Controls Guy on October 22, 2014, 10:51:25 AM
When we have an arbitrary choice of how to deal with an exception condition, we try to choose the way that takes the pointy stick away from the noob.

You're no fun -- pointy sticks are what chlorinate the gene pool!   :D
Title: Re: Floats and ints and bitwise operators...oh my!
Post by: BobO on October 22, 2014, 10:53:23 AM
When we have an arbitrary choice of how to deal with an exception condition, we try to choose the way that takes the pointy stick away from the noob.

You're no fun -- pointy sticks are what chlorinate the gene pool!   :D

Ok...that got an actual LOL! ;D