Floating point maximum range

rta53 · Mar 5, 2004

The help file in RSLogix 500 states this:

"Floating Point This file stores a # with a range of 1.1754944e-38 to 3.40282347e+38."

I understand this is scientific notation but what number does it actually represent? I entered this number in the Windows scientific calculator, clicked on Hex and then back on Dec and got this number: 2305843009213693952. Is this correct? I believe that for Integer files the limit is 32767.

JesperMP · Mar 5, 2004

I dont know how you entered the number into the windows calculator. But it cannot be correct.

The "e" in 3.40282347e+38 does not stand for the inversed natural logarithm, it simply means "exponent". And that in turn means the number 10 raised to the power of 38, which in turn is the same as a "1" with 38 "0"'s after it.

So
3.40282347e+38 = 340282347000000000000000000000000000000
1.1754944e-38 = 0.0000000000000000000000000000000000001175944

(I hope I got the number of zeroes right, but you get the idea).

rta53 · Mar 5, 2004

Thanks Jesper. I initially had thought this was what it meant but wasn't sure. It's a rather large number indeed!

bernie_carlton · Mar 5, 2004

Remember that with these floating point numbers there are a limited number of significant digits. This means that if you have reached a very high number, adding '1' to it won't make any change at all. For counting type purposes you still need to use the integer or double integer files. If they still don't count high enough you'll have to roll your own math , watching the 'carry' and 'borrow' flags.

rta53 · Mar 5, 2004

I am using the Floating Point to store a totalizer value. Last time I checked the total was up to 1,485,400 Gallons. I am adding about 25,000 Gallons per day to this total. I am also displaying this total on a Panel View. I guess I could have the total reset at 1,000,000 Gallons and have a field to display accumulated millions. At what point would the FP number become inaccurate? Does it roll over like integer files?

bernie_carlton · Mar 5, 2004

Unfortunately my SLC-500 references don't show the number of significant digits. The definitions you quoted seem to show about 9 significant digits on the plus side. That means when it gets above a few hundred million then adding just '1' won't cause an increase. I would say, resetting at 100,000,000 would be a safe bet. But check out if the 'Long' data type is available on your system. This may be an easier way to go if you don't need the decimal points.

Peter Nachtwey · Mar 5, 2004

Floating point info.

Floating point numbers have a 24 bit mantissa so they can be used like integers up to 2^24 or 16,777,216 after that adding one will do no good as you will be adding one to the bit that is not one of the 24 bits in the mantissa.

bernie_carlton · Mar 5, 2004

It was too late to edit in my last post so I'll say it here - I humbly bow to Peter's expertiese. Please ignore my ramblings about 100,000,000.

Peter Nachtwey · Mar 5, 2004

Here is a question for extra credit

In IEEE format, the mantissa is realy only 23 bits long, but I said it can represent 24 bit numbers in the post above. How is this done?

Just so you all know, 32 bit floats use this format:

SEEE EEEE EMMM MMMM MMMM MMMM MMMM MMMMM

S = Sign for the mantissa
E = Exponent
M = Mantissa

bernie_carlton · Mar 5, 2004

OK, this is what I've heard. In decimal type exponential, the mantissa is represented as a number from 1.00000 etc up through 9.99999 etc. same type of thing is true in binary but the mantissa is (binary decimal notation) .10000 etc through .1111111 etc. Now, since the very first bit position to the right of the binary point (is that what it's called? It just sounded right) is ALWAYS a '1' then it can be assumed and not stored in the actual number giving 1 more significant bit.

Just as a side note, this general discussion was from a book I had WAY BACK describing the BASIC ROMS from the TRS-80 computer. You get information from the wierdest places.

ndzied1 · Mar 5, 2004

here is a little c program that shows where things break down. It increments a long, a 32bit float and a 64bit float. It prints out the initial values and then prints out 10 lines after the first time the values are not equal.

#include "c:/borland/bcc55/include/stdio.h"



main(void)

{

	float f1=16700000.0;

	double d1=16700000.0;

	long l1=16700000;

	int i=0;

	

	printf("  long      float32    float64\n");

	printf("%10.0ld %10.1f %10.1lf\n\n", l1, f1, d1);

	printf("--------------------------------\n");

	

	for( ;l1<18000000

	{

		f1 += 1.0;

		d1 += 1.0;

		l1 += 1;

		

		if(f1 != l1)

		{

			printf("%10.0ld %10.1f %10.1lf\n\n", l1, f1, d1);

			i++;

		}

		

		if (i>10) break;

	}

}

The output from this program is:





   long      float32   float64

  16700000 16700000.0 16700000.0



--------------------------------

  16777217 16777216.0 16777217.0



  16777218 16777216.0 16777218.0



  16777219 16777216.0 16777219.0



  16777220 16777216.0 16777220.0



  16777221 16777216.0 16777221.0



  16777222 16777216.0 16777222.0



  16777223 16777216.0 16777223.0



  16777224 16777216.0 16777224.0



  16777225 16777216.0 16777225.0



  16777226 16777216.0 16777226.0



  16777227 16777216.0 16777227.0

Peter Nachtwey · Mar 6, 2004

Well done.

I just wanted to bump this to the top. I think it is important because this 'difference in magnitude problem', is the source of many floating point accuracy errors.

Float point users beware.

Mtn_Bkng_Dave · Mar 6, 2004

Your first assumption was correct

To maintain accuracy with extremely large numbers cascading of counting registers is the way to go.... a "millions" digit or whatever you decide will allow you to reset your primary counter and maintain a readable number. with a little research you may even be able to stick with integers resetting at 10k. The only determining factor is how how does the number need to go....if you need more just cascade another register.

Dave

BobB · Mar 6, 2004

Been listening to too much M&M Peter.

8 digits is about as far as you should go before adding 1 to a register and clearing the float. 10,000,000 is a good figure. 15,000,000 before you run the risk of losing accuracy, as indicated by Norm's post.

beerchug

Peter Nachtwey · Mar 7, 2004

BobB said:
Been listening to too much M&M Peter.

Who, me or you? M&M is candy you eat, not something to listen too. I got the 16777216 exactly right.

BTW, I would rather listen to the WHO "Won't get fooled again". I had the TV on and listening to the latest propaganda (LIES) about creating jobs.

BobB said:
8 digits

Actually Log10(16777216) = 7.2 digits.

BobB said:
is about as far as you should go before adding 1 to a register and clearing the float. 10,000,000 is a good figure.

OK

BobB said:
15,000,000 before you run the risk of losing accuracy, as indicated by Norm's post.

beerchug

One will loose accuracy when ever the significant bits of the mantissa of the two numbers are different by 2^24. In the example Norm gave, you would see the same thing happen with the float32s if the numbers were divided in half. It is the ratio of the two numbers and the number of significant digits in the smaller number one must worry about.

Floating point maximum range

rta53

Lifetime Supporting Member

JesperMP

Lifetime Supporting Member + Moderator

rta53

Lifetime Supporting Member

bernie_carlton

Lifetime Supporting Member + Moderator

rta53

Lifetime Supporting Member

bernie_carlton

Lifetime Supporting Member + Moderator

Peter Nachtwey

Member

bernie_carlton

Lifetime Supporting Member + Moderator

Peter Nachtwey

Member

bernie_carlton

Lifetime Supporting Member + Moderator

ndzied1

Lifetime Supporting Member

Peter Nachtwey

Member

Mtn_Bkng_Dave

Member

BobB

Lifetime Supporting Member

Peter Nachtwey

Member

Similar Topics