Amazon.com Widgets fundamental problem / dealing with program 7.6
Welcome, Guest. Please login or register.
Did you miss your activation email?
November 26, 2014, 10:23:30 PM
Home Help Search chat Login Register 
News: Read this please.The Great Kangaroo Escape Looking for reviews of the 4th ed on Amazon!   Twitter:  @skochan
                     

+ Official Forum for Programming in Objective-C (the iPhone Programming Language) - Stephen Kochan
|-+ Old Stuff
| |-+ Program Examples
| | |-+ Chapter 7
| | | |-+ fundamental problem / dealing with program 7.6
Pages: [1] Go Down
Print
Author Topic: fundamental problem / dealing with program 7.6 (Read 2192 times)
SiriusA
Newbie
*
Posts: 22






on: July 17, 2009, 12:05:47 PM

I'm having a fundamental issue with program 7.6 and after wracking my brains I think I've pinned the issue to a problem with the statement (in 7.6) that reads "numerator /= u;" -- which keeps coming up as 0 when I run it.

I've replicated the issue in the following code program:


#import <Foundation/Foundation.h>

int main (int argc, const char * argv[]) {
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

   long double thing;
   
   thing = .125;
   NSLog (@"if we set it: %Lg", thing);   
   
   thing = 1/8;
   NSLog (@"but if we divide: %Lg", thing);
   
    [pool drain];
    return 0;
}

here is what I'm getting:

2009-07-17 11:58:00.568 test2[6588:10b] if we set it: 0.125
2009-07-17 11:58:00.572 test2[6588:10b] but if we divide: 0

my expectation is that in both cases "thing" should be set to 0.125 -- but it's not when doing the equation. I'm convinced I'm overlooking something VERY simple in all of this but I can't figure out what.

Thanks for any help!
Logged
skochan
Administrator
Hero Member
*****
Posts: 3114







Reply #1 on: July 17, 2009, 12:16:11 PM

Please go back to Chapter 4 and reread the discussion on integer arithmetic (pp 58-60).

Cheers,

Steve Kochan

Logged
SiriusA
Newbie
*
Posts: 22






Reply #2 on: July 17, 2009, 12:28:52 PM

thank you for your fast reply! I'm ashamed I forgot that section (as it had stood out at the time).

however, I did think about this when trying to diagnose the issue and had replaced my int declarations with double long as, on page 55, you show that a double long maybe "12.341".

does this mean that a double long may HOLD a decimal place value but that any arithmetic must be done under a float in order to manage decimal places while the math's being performed?

(I hope I'm not tiring your patience!)

BTW: LOVE The book.
Logged
rgronlie
Global Moderator
Full Member
*****
Posts: 212







Reply #3 on: July 17, 2009, 01:25:05 PM

When doing arithmetic the compiler will implicitly convert the numbers to the highest order of number in the equation.

It doesn't care about the type of variable the result will be stored in while performing the arithmetic. It will do an implicit conversion (pg. 62) to match the type of the variable after the arithmetic has been done.

(int / int ) generates an int
(float / int) generates a float
(int / float ) generates a float
(int / double ) generates a double
(float / double ) generates a double

1 = integer
1.0 = double
1.0f = float

 1 / 8 = 0 // only integers present so only integer math is performed

 1.0 / 8 = 0.125 // contains a floating point number (a double)so floating point math is performed

or you could explicitly typecast it

(double)1 / 8 = 0.125
Logged

Sanity: Minds are like parachutes. Just because you've lost yours doesn't mean you can borrow mine.
SiriusA
Newbie
*
Posts: 22






Reply #4 on: July 17, 2009, 04:31:56 PM

ha!

I had written an extensive response to rgonlie -- loaded with thanks for trying to enlighten me -- further describing my confusion when I hypothesized and then tested a theory that seemed ridiculous. my proof was to change

thing = 1/8;

to

thing = 1.0 / 8.0;

and voila! it worked! ("thing = (float) 1 / (float) 8;" also worked).

this just seems so counter-intuitive to me. I would imagine that the compiler would take the numbers 1 and 8 (admittedly, ints as wrintten), do the math (resulting in a float) and then down-convert the result to fit the variable in which the result is to be stored. in other words, were the "receiving" variable an into, it would shoe-horn 0.125 into it as 0. I had assumed that the truncation comes at the end of this process but my experiment suggests it comes at the beginning. (see below)

I'd appreciate any further wise words as this does seem to contradict the book and rgonlie's response. for the moment, however, I seem to understand where to look if the results are not as expected.

#import <Foundation/Foundation.h>

int main (int argc, const char * argv[]) {
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

   int      intVar;
   float   floatVar;

   intVar = (float) 1 / (float) 8;
   NSLog (@" intVar = %i", intVar);

   floatVar = (float) 1 / (float) 8;
   NSLog (@" floatVar = %f", floatVar);

   floatVar = 1 / 8;
   NSLog (@" floatVar = %f", floatVar);
   
    [pool drain];
    return 0;
}

2009-07-17 16:31:30.532 test2[6973:10b]  intVar = 0
2009-07-17 16:31:30.534 test2[6973:10b]  floatVar = 0.125000
2009-07-17 16:31:30.536 test2[6973:10b]  floatVar = 0.000000

Logged
SiriusA
Newbie
*
Posts: 22






Reply #5 on: July 17, 2009, 04:36:12 PM

ok, I've answered my own question (moments later) -- or perhaps you were trying to explain this all along, dunno.

p.63 reads "whenever to operands in an expression are integers (and this applies to short, unsigned, and long integers as well), the operation is carried out under the rules of integer arithmetic."

that's the short and the long of it. so, the compiler makes a (smart) choice. it sees integers and says "I'll save time/space/money/energy by doing this all as integer arithmetic."

makes sense to me now. sorry to be so daft (and to have forgotten what I read earlier in the week.

thanks!
Logged
Pages: [1] Go Up
Print
Jump to:



Login with username, password and session length

Powered by MySQL Powered by PHP Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!
Entire forum contents (c) 2009 classroomM.com. All rights reserved.