Simple Arithmetic - Help

[larryllix]

2 minutes ago, mmb said:

This applies to the climate module - correct?  I don't have that one...

No. It applies to the ISY setup on the last tab. IIRC

[mmb]

59 minutes ago, larryllix said:

No. It applies to the ISY setup on the last tab. IIRC

Do you have a guide that shows how to access it?  Google searches aren't pulling up anything.

Cancel that, I just did the calculations.  I'll see what the ticket comes back with...

Thanks!

[kclenden]

On 11/7/2019 at 9:03 PM, larryllix said:

I never do my calculations in a State variables.

Using State variables can be very useful for debugging purposes.  Whenever a State variable changes values it is recorded in the Event Viewer log.  Thus by watching the Event Viewer you can follow all changes to the variable.  But, as you mentioned, you need to make sure the State variable isn't being used to trigger other programs that might mess up your calculations.  And, after debugging, I'd definitely recommend converting the State variable to an Integer variable if you're not going to be using it to trigger programs.  Besides avoiding unexpected program interplay, I'd think fewer State variables would place less stress on the ISY's computing resources.

[mmb]

2 minutes ago, kclenden said:

Using State variables can be very useful for debugging purposes.  Whenever a State variable changes values it is recorded in the Event Viewer log.  Thus by watching the Event Viewer you can follow all changes to the variable.  But, as you mentioned, you need to make sure the State variable isn't being used to trigger other programs that might mess up your calculations.  And, after debugging, I'd definitely recommend converting the State variable to an Integer variable if you're not going to be using it to trigger programs.  Besides avoiding unexpected program interplay, I'd think fewer State variables would place less stress on the ISY's computing resources.

Thanks further upin this post a forum member suggested putting waits after each calculation and watch how they change in the Variable/Integer window.  It was very helpful and I understand how it works now - I followed up with a ticket to UDI for an explanation.

[mmb]

On 11/11/2019 at 7:02 PM, mmb said:

Thanks further upin this post a forum member suggested putting waits after each calculation and watch how they change in the Variable/Integer window.  It was very helpful and I understand how it works now - I followed up with a ticket to UDI for an explanation.

Update - in the end it was a simple matter of switch F to C in a couple of files in the Polyglot node and then doing an update on the ISY in the Nodeserver tab

[Jimini]

This comment of mine is a bit late and out of order but I found this thread by searching for one related to arithmetic and/or precision.  This was the only find.  And I couldn't find any discussion of this in the ISY users guide.  My comment regards an earlier statement that one can change the precision of integer type variables up to 8.  The 8 includes the ones place, so only 7 decimal places.  However, it is important to keep in mind that apparently this 8 possible digits appears to include those on both sides of the decimal point.  I am trying to include a formula that squares a number of order 50 and then multiplies it by a number of order 0.005 before completing the calculation with a few more steps.  I declared all the variables involved to have precision 6 (could have used 5) as I didn't want to lose the contribution of the quadratic term.  Squaring the first number as the first step produced a negative result, a common symptom of twos-complement binary arithmetic.  Backing the precision down to 4 and setting the constants (e.g. the number of order 0.005) to be 100 times larger, removed the negative intermediate result and then dividing the final result by 100 produced the expected final result.  Changing the order to multiply by the number of order 50 by the number of order 0.005 first and then complete the square by multiplying that result by the first number of order 50 did not produce a negative result but still an incorrect one.  I don't have an explanation for that but working with precession of all variables at 4 did give me the correct result with no problem with overflow.  

Also, thank you kclenden for the tip about using state variables and the Event Viewer for testing this.  It was much easier than sending out notifications.  

[larryllix]

This comment of mine is a bit late and out of order but I found this thread by searching for one related to arithmetic and/or precision.  This was the only find.  And I couldn't find any discussion of this in the ISY users guide.  My comment regards an earlier statement that one can change the precision of integer type variables up to 8.  The 8 includes the ones place, so only 7 decimal places.  However, it is important to keep in mind that apparently this 8 possible digits appears to include those on both sides of the decimal point.  I am trying to include a formula that squares a number of order 50 and then multiplies it by a number of order 0.005 before completing the calculation with a few more steps.  I declared all the variables involved to have precision 6 (could have used 5) as I didn't want to lose the contribution of the quadratic term.  Squaring the first number as the first step produced a negative result, a common symptom of twos-complement binary arithmetic.  Backing the precision down to 4 and setting the constants (e.g. the number of order 0.005) to be 100 times larger, removed the negative intermediate result and then dividing the final result by 100 produced the expected final result.  Changing the order to multiply by the number of order 50 by the number of order 0.005 first and then complete the square by multiplying that result by the first number of order 50 did not produce a negative result but still an incorrect one.  I don't have an explanation for that but working with precession of all variables at 4 did give me the correct result with no problem with overflow.  

Also, thank you kclenden for the tip about using state variables and the Event Viewer for testing this.  It was much easier than sending out notifications.  

ISY precision only counts the fractional digits.

 

Every intermediate resultant must fit in the whole number capacity of each variable.

 

The variables are 32 bits so max is +/- 2^31 divided by the precision^10.

 

Sent using Tapatalk

 

 

 

[Jimini]

Yes, I agree that each intermediate step that stores a result into a variable must fit within the precision available for that variable but it's doing something more sophisticated than just converting all floating point numbers to 32-bit binary integers by shifting the decimal point and then doing 32-bit arithmetic.  For multiplication, it appears to be doing a double precision operation, i.e. 64-bit multiplication, before adjusting the result to match the specified precision of the 32-bit variable into which it will be stored.  Very nice how it keeps track of the specified precision step by step.

[larryllix]

27 minutes ago, Jimini said:

Yes, I agree that each intermediate step that stores a result into a variable must fit within the precision available for that variable but it's doing something more sophisticated than just converting all floating point numbers to 32-bit binary integers by shifting the decimal point and then doing 32-bit arithmetic.  For multiplication, it appears to be doing a double precision operation, i.e. 64-bit multiplication, before adjusting the result to match the specified precision of the 32-bit variable into which it will be stored.  Very nice how it keeps track of the specified precision step by step.

If an intermediate resultant overflows the variable, the results will be truncated at the significant end, by binary truncation. If the resultant of an arithmetic operation overflows the capacity of the variable's positive numbers representation, the resultant will appear as negative.

The results of storing any number that exceeds the capacity of a variable's capacity will appear scrambled and unrelated to the user, and further calculations. AS we increase the precision used in ISY variables, the capacity for larger quantities diminishes. ISY does not support floating point. Only fixed point. It can be a problem transferring results around into different variable with different precisions in order to handle large numbers and yet preserve fraction resultants.

eg: Using an 8 bit signed register, multiplying 127 x 2  will result in a -2 answer. We would expect 254, but any number with the MSbit set, will result in a negative interpretation that may confuse later calculations.