Re: bits for floating value and converting

In article <f438227d-c530-4e3d-937a-7b1bca04d3fd@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
<myfem.analyzer@xxxxxxxxx> wrote:
Hi, Walter Roberson:

Based on your explanation, *(int*)&x will get the "IEEE 754 single
precision floating point Representation" of x, and *(float*)&i will
convert that representation back to a floating number?

Also, what is the algorithm to covert between "IEEE 754 single
precision floating point Representation" and normal floating number?


What I said was,

The exact value you got from the reinterpretation, 1065353216,
is equivilent to hex 0x3f800000 . Through experience, I recognize
that as the IEEE 754 single precision floating point
representation of 1.0 .

That is, on *your* system, *(int*)&x gave you a particular result, and I
recognize that result as being IEEE 754 single precision representation.
In other words, your "normal floating point numbers" -happen- to
be internally represented in IEEE 754 single precision format.
They already -are- in that format on your machine. On other machines
that did not happen to use IEEE 754 but which did happen to have
sizeof(int) == sizeof(float), then *(int*)&x would get at whatever
representation happened to be used on -that- machine. Perhaps VAX-F
format.

There is no question about algorithms to convert between IEEE 754
and "normal floating number" because "normal floating numbers" do not
exist as an independant entity. There are merely a whole bunch of
different standard (and not so standard) ways of representing floating
point numbers, and whatever system you are running on will use -one-
of them (actually, it might even use several different ones).
IEEE 754 is as "normal" as you get in the general purpose computing world.

*(int*)&x did not change anything about the bits themselves at the
location of the variable x: it just allowed you to examine them in
a different format. *(float*)&i would not change anything about
the bits themselves at the locaton of the variable i: it would just
allow you to exmaine them in a different format. Though if you
used *(float*)&i = SomeValue and i happened to be properly
aligned and the same size as a float, then the floating point
representation of SomeValue would be stored at the location of the
variable i .
--
We regret to announce that sub-millibarn resolution bio-hyperdimensional
plasmatic space polyimaging has been delayed until the release
of Windows Vista SP2.
.

Relevant Pages

  • Re: Rounding Float in C and Remove those Zeros
    ... I was referring to the floating point representation I learned in school. ... Since seeing some of the earlier posts I have looked into IEEE 754 and it *is* quite different - and an improvement. ... In fixed-point it's possible for 1.0 not to be exactly representable. ...
    (comp.lang.c)
  • Re: SoA Vs OO
    ... The vast majority of programmers using IEEE floating ... Check out this quote from Microsoft Research on IEEE 754 floating point: ... " IEEE Standard 754 floating point is the most common representation today ... compensate for the difference between the reality and the abstraction. ...
    (comp.object)
  • Re: SoA Vs OO
    ... The vast majority of programmers using IEEE floating ... Check out this quote from Microsoft Research on IEEE 754 floating point: ... " IEEE Standard 754 floating point is the most common representation today ... compensate for the difference between the reality and the abstraction. ...
    (comp.programming)
  • Re: Ruby Numbers
    ... familiar with the implementation of Ruby but my best guess is that Ruby ... converted the value 4.1 into the IEEE double floating point representation ... IEEE format cannot accurately represent the value 4.1, ... compare, with the equals operator, floating point values, in any language. ...
    (comp.lang.ruby)
  • Re: How do you keep track of what all the numbers mean?
    ... that if you develop a floating point representation of a system, ... but I would suspect that scaling constants is a main part of it. ... There will be an assumed scaling between the floating point ... will depend upon the input signal power. ...
    (comp.dsp)