Re: 0.0 versus 0.0f
From: Florent (spambucket_at_myoddweb.com)
Date: 10/20/04
- Next message: Ando Sonenblick: "Win32 mailing list?"
- Previous message: Joseph M. Newcomer: "Re: controls"
- In reply to: Joseph M. Newcomer: "Re: 0.0 versus 0.0f"
- Next in thread: Joseph M. Newcomer: "Re: 0.0 versus 0.0f"
- Reply: Joseph M. Newcomer: "Re: 0.0 versus 0.0f"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 20 Oct 2004 02:06:39 +0100
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:rjabn05jovnmh2rahjm4pc7oqrnfca7g7e@4ax.com...
> Actually, it says it is a float rather than a DOUBLE, not an "int". A
> float is a
> single-precision floating-point number, on an x86 this is 32 bits.
> Otherwise, it is a
> double, a 64-bit floating point value.
Sorry I am missing something here, where did I say a DOUBLE, (in upper or
lower case)?
And I did use the "int" correctly. I was trying to explain in simple terms
that if the numbers are treated as "int" then there might be a problem.
I am not sure what DOUBLE vs. float has to do with what I said.
>
> 10/20 is not "optimized as an integer"; optimization has little to do with
> this.
Yes it is optimised. That's why you forcefully need to tell the compiler
when it is a float, a long or what ever.
> The computation specified is an integer divide of 10 by 20, and whether it
> is done a compile
> time or run time, an integer divide of 10 by 20 always gives 0.
Is it not what I said? 10/20 is treated as Integers and that is why it will
return 0.
had you said 10/20.f the application would have treaded the equation has
floats. hence the reason for the "f".
The OP asked for a difference between the two and I gave it.
>
> I'm not sure what a "math processor" is; all x86 chips since the 486 have
> built-in
> floating point operations, so an external floating-point math coprocessor
> no longer exists
> as a concept. And C has NEVER had a dependence of the presence or absence
> of a math
> coprocessor; the language defines what is supposed to happen, and whether
> that occurs in
> hardware or software doesn't matter.
Yes, you are right it is a math co-processor sorry for the typo. But I
suspect you knew all along what I meant.
"Built in floating point operations" sounds a lot like co-processor to me, I
never said it was internal or external but thanks for pointing that valuable
piece of information out.
And the language does define what happens, but how is the language supposed
to know what you were trying to do? maybe by using things like "f".
That is precisely <sic> why I said, if you do "10/20" but in fact wanted
"10/20.f" then you need to tell the program what you wish to do.
>
> And what is a "carriage"?
Sorry my english failled me here. I was talking about binary equations when
you carry over.
The reason i said it was simply to touch on why (int)10/(int)20 will return
0 and needs to be defined as 10/20.f
Something like, http://mathforum.org/library/drmath/view/55951.html
> joe
>
Florent
-- http://www.myoddweb.com http://www.myoddweb.com/forum
- Next message: Ando Sonenblick: "Win32 mailing list?"
- Previous message: Joseph M. Newcomer: "Re: controls"
- In reply to: Joseph M. Newcomer: "Re: 0.0 versus 0.0f"
- Next in thread: Joseph M. Newcomer: "Re: 0.0 versus 0.0f"
- Reply: Joseph M. Newcomer: "Re: 0.0 versus 0.0f"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
