PDA

View Full Version : Float vs. Double

rjfiske
Jan 9, 2006, 04:36 PM
Hi everyone. Total noob question... especially directed at those that have read and gone through "Programming in Objective-C" by Stephen Kochan. I'm stuck at a stupid example in the book (chapter 6 - implementation of a Calculator class). I'll save you the details of the entire code unless you request it... in which case I can send directly. Here's the skinny of my problem:

The results of the code in the book are nowhere near what I'm getting. Through troubleshooting I've narrowed it to calling the variables in the program Float vs. Double. For instance:

Calling "value1" and "value2" as double (as it does in the book) gives me the wrong result:

...
double value1, value2;

I get the user imput of value1 and value2 (along with the arithmetic operator) like so:

scanf ("%1f %c %1f", &value1, &operator, &value2);

adding 1+1 (the assignments of value1 and value2) gives me a result of .02. Last I checked this is wrong. Adding 2+2 gives me 4.00. Ok that's great. But adding 2+3 gives me 34.00. And get this... adding 9+9 gives me 524288.25. WHAT ON EARTH???

By the way, in case you haven't figured it out the printf command looks something like this:

printf ("The result is %.2f\n", [deskCalc accumulator]);

Ok for kicks I decided to find out what would happen by calling "value1" and "value2 as a FLOAT. It seems to give me the right result, everytime:

float value1, value2;

Adding 1+1 gives me 2.00 (perfect). Adding 2+2 gives me 4.00 (perfect). And adding 2+3 gives me 5.00 (again perfect). Adding 9+9 gives me 18.00 (that's 4 in a row). So why on earth should changing it from double to float make any difference?? The book uses double so I should be able to as well, yes?

Again, be easy on me. I have never had any programming experience beyond simple Access and Excel macros... and some Adobe After Effects expressions so I'm sure it's a simple answer. And if you need me to post the full code somewhere let me know how. Finally if any of you know of a discussion board specifically for readers of the "Programming in Objective-C" book I mentioned that would be awesome too. Thanks everyone in advance!

balamw
Jan 9, 2006, 04:43 PM
scanf ("%1f %c %1f", &value1, &operator, &value2);
methinks you misread "%lf" for "%1f", "%lf" tells scanf to read in a long float, i.e. a double. Otherwise, it just shoves a float into where you called out a double and you get precisely they kind of behavior you saw since the bits don't line up.

B

rjfiske
Jan 9, 2006, 04:51 PM
methinks you misread "%lf" for "%1f"

B

Youthinks correctly. I can't believe I wasted 5 hours of my life yesterday when you solved the problem in 10min. Man this forum is great. And thank YOU so much for your help. Your answer both made me happy and pissed me off at the same time! :p

- rjfiske

balamw
Jan 9, 2006, 05:03 PM

I've had lots of fun with scanf myself over the years, so I've paid my dues.

B

Jan 17, 2006, 03:20 PM
In java, float gives a 32bit number and double a 64bit number, basically a 32bit will go faster through the processor* but is less accurate (eg with pi or something) double also allows you to have bigger numbers... to be honest with basic programming it doesn't really matter, unless you are processing lots and lots or numbers it won't make any difference on a modern computer...

*=unless its a G5 when it should be the same for both...;)

bousozoku
Jan 17, 2006, 03:43 PM

I've had lots of fun with scanf myself over the years, so I've paid my dues.

B

It's always sadly humourous when someone new forgets the & operator and gets a memory access error.

I've always loved the power of sscanf and sprintf because I've worked with a lot of data import/export and it's so nice to use the definitions given me to create exact formatting templates to be used.

Catfish_Man
Jan 18, 2006, 12:41 AM
In java, float gives a 32bit number and double a 64bit number, basically a 32bit will go faster through the processor* but is less accurate (eg with pi or something) double also allows you to have bigger numbers... to be honest with basic programming it doesn't really matter, unless you are processing lots and lots or numbers it won't make any difference on a modern computer...

*=unless its a G5 when it should be the same for both...;)

Actually 64 bit float support is nothing new. The G5 adds 64 bit int (long long) support.

reikon
Jan 18, 2006, 06:58 AM
Actually 64 bit float support is nothing new. The G5 adds 64 bit int (long long) support.

Mean endians :P

uaaerospace
Jan 18, 2006, 07:52 AM
I can't believe I wasted 5 hours of my life yesterday when you solved the problem in 10min.

Welcome to programming! I wish I had a dollar for every time I had a similar occurrence. ;) Josh

gekko513
Jan 18, 2006, 08:59 AM
Actually 64 bit float support is nothing new. The G5 adds 64 bit int (long long) support.
It doesn't add support for long long, it just makes them go a lot faster. You can use 64 bit long long on 32-bit systems, too.

On a 64-bit architecture the regular long is the data type that changes from being 32 bit to being 64 bit.

... if we're talking C++.

Catfish_Man
Jan 18, 2006, 03:55 PM
It doesn't add support for long long, it just makes them go a lot faster. You can use 64 bit long long on 32-bit systems, too.

On a 64-bit architecture the regular long is the data type that changes from being 32 bit to being 64 bit.

... if we're talking C++.

As far as I know, long long operations on 32 bit archs are compiled into multiple 32 bit operations to fake having 64 bit capabilities (i.e. no hardware support). I could be wrong about this though. Also, whether or not long is 64 bit on 64 bit archs varies with the architecture :/ You may be right that Apple's decided to go with sizeof(long) == 64; there was a KB article on it a while ago, but I don't remember the details.

gekko513
Jan 18, 2006, 04:04 PM
As far as I know, long long operations on 32 bit archs are compiled into multiple 32 bit operations to fake having 64 bit capabilities (i.e. no hardware support). I could be wrong about this though. Also, whether or not long is 64 bit on 64 bit archs varies with the architecture :/ You may be right that Apple's decided to go with sizeof(long) == 64; there was a KB article on it a while ago, but I don't remember the details.
True enough, but compiling for 32 bit computers still supported 64 bit long long, even if the hardware didn't support 32 bit integer math. So support for long long wasn't the new thing, just that it was now compiled to more efficient 64 bit machine instructions. So obviously 64 bit integer hardware instructions was indeed new, but not the support for 64 bit long long types. I guess I was just nitpicking.

savar
Jan 18, 2006, 06:46 PM
As far as I know, long long operations on 32 bit archs are compiled into multiple 32 bit operations to fake having 64 bit capabilities (i.e. no hardware support). I could be wrong about this though. Also, whether or not long is 64 bit on 64 bit archs varies with the architecture :/ You may be right that Apple's decided to go with sizeof(long) == 64; there was a KB article on it a while ago, but I don't remember the details.

Of course. You can do anything in software. On the HC11 (a low end Freescale (formerly Motorola) microcontroller, there is no FPU. But you can still do floating point math if you link in the HC11 floating point library. Of course, simple operations take 1000-10000x as long to execute as they would with a real FPU. There's also a library to perform 16-bit arithmetic on the 8-bit microcontroller.

cait-sith
Jan 18, 2006, 09:00 PM
when in doubt, read the man page for the function.

the formatting arguments are clearly given in the man pages.

http://www.hmug.org/man is a good resource, sometimes i will look for a man page and not be able to find it on the local console. (go figure..)

another common mistake is changing your print statement from something like printf("%d %g\n", x, y) to printf("%d", x, y) .. you remember to modify the format string but not change the variables you are printing.

`mike

btw.. use %g for double formatting

TangoCharlie
Jan 19, 2006, 02:46 AM
In java, float gives a 32bit number and double a 64bit number, basically a 32bit will go faster through the processor* but is less accurate (eg with pi or something) double also allows you to have bigger numbers... to be honest with basic programming it doesn't really matter, unless you are processing lots and lots or numbers it won't make any difference on a modern computer...

*=unless its a G5 when it should be the same for both...;)

Actually, many 32bit processors handle floats in 64bit registers, and so 64bit floats don't carry a performance hit at all. I remember on the sgi's that the MIPS processors were optimized for 64bit floats (double) and 32bit floats were actually slower (granted, that was a 64bit CPU). The 68040 (not the LC versions) actually had 80bit doubles, and some people who did serious maths
thought that the first PowerPC's (the 601) were actually a step backward. I believe this is why the 68k emulation on the PowerPC emulated an 68LC040 (i.e. without an FPU).