Thread: direct computation

Alright, so you've proven that your system can go OVER the FLT_MAX, and still come back down, with good data, intact.

Now all you have to do is adjust your while loops to take advantage of that. Remember the sequence:

1) go UP, initially rather fast, in your first loop. Don't go over the FLT_MAX, by much, because the amount you can safely go over FLT_MAX, will be limited.

2) go down with your next loop, until you're fnum is less than FLT_MAX

3) go up about 10 x slower than you did before (and that 10 x is very adjustable, but should be at least 10 X smaller steps than before, until you're again back up and greater than the FLT_MAX number).

4) go down, again cutting the step size down by a factor of 10 x or more, compared to the last loop, until once again, your fnum is less than FLT_MAX

5) go up, again cutting the step size down by a factor of 10 or more, compared to the last loop.

About this time, after 5 loops, you should be able to stop right on FLT_MAX, by either subtracting one, or by adding one, to fnum. If you get close enough on the go down loop, then you'll add one. If it's on the up loop, you'll subtract one, on the end.

Or in my case, the system just reports fnum is at the maximum float value.

And you're done.

You're bringing fnum UP still. You WANT it to read fnum as #INF...

Then you bring fnum back DOWN.

if ever
1.00000001 is too slow, when multiplying, then replace it with
1.000000015
1.00000002 through 9, or
1.00000010 , or even
1.00000100

You have to be a bit creative to find what works for your system.

1.0000006 - 1.00000009 seems to be working for me, and i can alter the value after ive gotten the max value.

I guess i dont have to do any more computing after this, since im geting the direct value right after the first loop:

You've got it!

Some persistence required, but successful and educational as well. I had no idea there was "elbow room" above the FLT_MAX value.

. Thanks for all the help.

It was sure worth it.

Altho, there is still one thing im interested about.

Minimum float value is -FLT_MAX, and maximum float value is +FLT_MAX, but how come my program shows FLT_MIN on 0? Wouldnt this mean minimum FLT value is 0? I mean, why are they defined as 0 in float.h.(header im using).

Also, if i try printing long double max value, it says INF. Im using %e while trying to print it on
stdout.

Unless there was an unnoticed typo error in the program, I have no idea why any signed limit would print out as zero!

The limits for floats are in a separate header file "float.h", while the integral data type limits are in "limits.h". Do you need to include a different header file?

I'd hate to think it was a feature you'd only get if you bought the "professional" version of the compiler. That would just be wrong.

This is a part of my compiler's data in floats.h:

Code:

/* smallest positive IEEE normal numbers */
#define DBL_MIN				2.2250738585072014E-308
#define FLT_MIN				1.17549435E-38F
#define LDBL_MIN			_tiny_ldble

#define DBL_MAX			    _huge_dble
#define FLT_MAX			    _huge_flt
#define LDBL_MAX			_huge_ldble

#define DBL_MAX_EXP			+1024
#define FLT_MAX_EXP			+128
#define LDBL_MAX_EXP		+16384

#define DBL_MAX_10_EXP		+308
#define FLT_MAX_10_EXP		+38
#define LDBL_MAX_10_EXP		+4932

#define DBL_MIN_10_EXP		-307
#define FLT_MIN_10_EXP		-37
#define LDBL_MIN_10_EXP		-4931

#define DBL_MIN_EXP			-1021
#define FLT_MIN_EXP			-125
#define LDBL_MIN_EXP		-16381

and clearly includes negative numbers.

So that's a great question for your instructor - hah!