Scaling integer tags only gives integer results

If I divide a tag value by 10 and use a format string of ##0.##, I would expect to see at least 1 decimal place in the display.
eg 1234 / 10 = 123.4

Instead it’s truncated.
eg 1234 / 10 = 123

The data type of the item must be a float for the precision to show up.

That’s what I was afraid of.

My 20+ year old hand calculator can treat int and float interchangeably. You would think 'modern' computer languages could do the same. :unamused:

For those that don’t fully understand, my last post was not directed at the IA guys. It was aimed at static typed languages (such a Java) that can not seamlessly convert between various types of numbers forcing programmers to jump through hoops every time something is divided or otherwise crosses an arbitrary boundary.

ok, I’ll get off my soap box and get back to work now…

[quote=“Robert”]
My 20+ year old hand calculator can treat int and float interchangeably. You would think ‘modern’ computer languages could do the same.
[/quote]

Well, it doesn’t really use ints at all- it just converts everything to a float by default, which isn’t actually very desirable, but in a calculator it doesn’t matter since the results don’t go anywhere.

Python is actually very smart about this. Since you don’t have to define local variables and their types, it just goes by the typed number format. So, as long as one of the numbers is a float, a float will be returned, i.e. 1234/10.0. I kind of like being in control of the resultant data type, and don’t want the programming language to make assumptions. I mean, ignoring formatting for a moment, what if I pass in 4/2 in one place, and 9/5 somewhere else? How would the language know I actually wanted a float returned, or know where the result is going (an INT field in an SQL table? A float in a PLC register)?

This is going off topic but:

Radudo (Perl6) has the concept of fractional numbers. If you set a value to 9/5 it stays 9/5 to the last possible moment. ie: you can add 2/3 and 1/6 and get 5/6 back. Unless you want it formatted as #.## in which case you get 0.83 when you format it.

I know python is very smart about this. So is perl and php and any number of other languages. Java is not. And Ignition is written in Java(for very good reasons). C is not. Most PLC's (I'm guessing) are written in C. Thus we have the situation that caused this thread where 1234 / 10 = 123 because the underlying technology (Java/C) cannot handle the automatic casting of a int to a float.

Personally, I want the greatest accuracy possible until I want to display/use the final result. And I want the language to do it for me. I don't want to have to write float x = (float)y / (float)z everywhere I might be creating a float val from an int calculation.

Ask any high school kid what 1234 / 10 is. They will tell you it's 123.4 . The only reason programmers are stuck with int4, int8, float4, etc is because it was too hard for early computers and computer language developers to black box it all and so they exposed the inner workings and forced the programmers to deal with it.

(and here I was going to get back to work :unamused: )

(I case you were wondering, I have 20+ years of C and 10+ years of perl/php/python experience (guess which I prefer :slight_smile: ))

[quote=“Robert”]This is going off topic but:

snip

Ask any high school kid what 1234 / 10 is. They will tell you it’s 123.4 . The only reason programmers are stuck with int4, int8, float4, etc is because it was too hard for early computers and computer language developers to black box it all and so they exposed the inner workings and forced the programmers to deal with it.

[/quote]

in my opinion of course

1234 / 10 is 123 if we take into account precision. If you meant 1234.0 / 10.0 , then yes it is 123.4

I prefer my language not to guess at what data type I am using. If i’m working w/ 2 ints, the result should be an int w/ a predictable level of precision. If I want to do Float math, i’d rather cast it implicitly.

I’m sure there are many that disagree with me. I’d rather not see this descend into bunch of posts saying that one way is better then the other. C, Java and the like make a distinction, perl, php, python, etc don’t. Pick the language that let’s you do what you have to do.

In my case, I’ve just changed all my analog tags to be floats. Problem solved.

Let’s all get back to the purpose of this forum: Making Ignition a better product.

(I only posted this because it gives 150 posts. I’m a General now! :slight_smile:

I’m a little late to this party, but…

  1. You’re right that in Java, 1234/10 is 123. The reasons why have been thoroughly hashed out above. However, just because Ignition is written in Java doesn’t mean that it follows Java’s arithmetic conventions…
  2. I agree with you. 1234/10 is 123.4. Casual users (by this I mean users without a computer science degree or years of programming experience) should not need to be aware of the difference between division of 2’s compliment integers vs IEEE floating point division.
  3. This is the most important point. 1234/10 IS 123.4 in Ignition. In fact, we made the division operator more like grade-school and less like C-programming on purpose, for the reasons mentioned in #2.

So: where did you observe the integer division behavior?

I’ve talked to Travis about what I was trying to do. He thought it was reasonable and was going to add the feature request to your list of things to do.