casting non-lvalues

I know the handy trick to cast float bits to ints and vice versa using *(int*)(&fNum) and its inverse, but what about when I want to cast non lvalue bits to a float.

for example, I can't think of a reason I would ever need to do this, but lets pretend I want to make a macro that generates a negative float, and I wrote the macro as follows:

Code:

---

//forgive me for any errors in this, its only an example
#define MAKE_NEG_FLOAT(exp,mantissa) \
(0x80000000 | (((exp)&0x000000FF)<<23) | ((mantissa)&0x008FFFFF)

---

and then lets say I want to call a function that accepts a float and I want to pass in whatever this function returns.

Code:

---

void func(float num);
//...
func( MAKE_NEG_FLOAT(10, 0) );

---

The MAKE_NEG_FLOAT macro resolves to an integer, and then the func will cast that to a float rather than converting it to a float with the same bits. My question is this: is there any way, given the setup or a similar setup of code, that would allow me to convert the non-lvalue integer return of a macro directly to a float without casting? Any hackish, crazy way would make me happy, as long as its quick to process and/or could be compiled out with a decent optimized compiler.

One option is a union.

Code:

---

#include <stdlib.h>
#include <stdio.h>

typedef union
{
  int i;
  float f;
} int_float;

int main(void)
{
  int_float num = {0};

  printf("%d\n",num.i);
  printf("%f\n",num.f);

  num.f = 1;
  printf("%d\n",num.i);
  printf("%f\n",num.f);

  return 0;
}

---

Another option is the casting trick you showed above.

IMO, such things tend to assume too much about the implementation and should be shunned. Such behavior is undefined.

A union would be workable except that it needs to use existing variable types (such as standard 32 bit floats and ints), and the trick I specified does not work for non lvalues (IE, I cant do this: "*(int*)&(0xFFFFFFFF)"), and the macro that I made up resolves to an rvalue.

Quote:

---

IMO, such things tend to assume too much about the implementation and should be shunned. Such behavior is undefined.

---

I am not writing a library to distribute on the web or port to other platforms. I need it for a specific purpose for which the implimentation is already known. Also, the only thing I am assuming is the 32 bit IEEE floating point standard, which, if it could not be assumed, would indicate to me that I am working on a platform that does not adhere to even the most basic of standards.

I am asking for a solution to a problem, not a criticism of its purpose.

Code:

---

func( 0.0f + YOURBROKENSTUFF(10,0) );

---

Quzah.

wow, lotta testy people today...

the only thing thats broken about that is your assumptions...

adding 0.0f to the return value of the macro will only cause the value that it created ( 0x85000000 ) to be cast to a float (2231369728.0f) and then add it to 0.0f, resulting in... well I assume you know at least basic math.

The whole point of the question is that you cannot modify bits directly in a float, but you can also not cast rvalues to a float using the methods I mentioned previously.

There is no need to turn this innocent question into a flame war.

There are other formats, and the "value of a union member other than the last one stored into" is unspecified*. Casting does much the same, except it turns off error checking.

But if you want to be testy yourself, at least specify the exact platform and situation. After all, the is a C forum, and your answer is not in the general case.

*Not undefined as inferred earlier.

I believe I did specify the standard as the IEEE Standard (754), but the point of the question has nothing to do with which floating point standard I am using. The question is essentially this: "how do i put rvalue bits inside of a variable for which bit modification is not allowed by C without creating a temporary variable?"

I use a float simply because it is the most common and easy to understand form of my question.

Quote:

---

Originally Posted by ...

wow, lotta testy people today...

the only thing thats broken about that is your assumptions...

adding 0.0f to the return value of the macro will only cause the value that it created ( 0x85000000 ) to be cast to a float (2231369728.0f) and then add it to 0.0f, resulting in... well I assume you know at least basic math.

The whole point of the question is that you cannot modify bits directly in a float, but you can also not cast rvalues to a float using the methods I mentioned previously.

There is no need to turn this innocent question into a flame war.

---

Ok, let's start this off right then:

1) You post some vague ........, like so:

Quote:

---

but what about when I want to cast non lvalue bits to a float.

---

What exactly is a "non lvalue bits"? You want to make the right side a float? Or what exactly? Ok, so ........ing add 0.0 to it, and now it's a float.

2) You then say:

Quote:

---

pretend I want to make a macro that generates a negative float

---

What the hell is a "negative float"? A negative floating point number? Well, that's tough too. How about subtracting whatver it is from 0.0f?

3) Then you say:

Quote:

---

and then lets say I want to call a function that accepts a float and I want to pass in whatever this function returns.

---

Man, where to start with this? First off, this doesn't even parse as an English sentence. It's wrong. Well, ok, treat it as C. Well that doesn't work either, because MACROS do not return anything! They're not functions! They can evaluate to something, but they don't "return" anything.

4) Then you go on to say:

Quote:

---

The MAKE_NEG_FLOAT macro resolves to an integer, and then the func will cast that to a float rather than converting it to a float with the same bits. My question is this: is there any way, given the setup or a similar setup of code, that would allow me to convert the non-lvalue integer return of a macro directly to a float without casting?

---

Which I suppose means: "I have some floating point number, and I want to do bit shifting on it, and convert it back to a float." I guess. Is that what you're trying to do? Well you can't, because it's not defined by the standard, which means: ANYTHING YOU DO WILL DIFFER AT WILL! Seriously. If it's not defined, you have no control over what happens. It's prefectly fine for it to change each run time. It probably won't, but you can't assume that. Because it's not defined.

The bytes of a floating point number aren't stored as they are as an integer. That's why you can't shift them. That's why you can't mask them off. That's why anything you do to them isn't defined.

Oh, but you don't want to hear that. That's too bad. See, other people read this forum too. So forgive me if I point out things that people want to do that are wrong according to the standard. No, wait a minute, I don't give a ........ what you think. If you don't want to hear it's wrong, don't try to do something that's wrong. Or rather, don't ask people how to do something that's wrong, if you don't want them to tell you it's wrong.

Oh, wait, it gets better...

5) You also spit out this gem:

Quote:

---

adding 0.0f to the return value of the macro will only cause the value that it created ( 0x85000000 ) to be cast to a float (2231369728.0f) and then add it to 0.0f, resulting in... well I assume you know at least basic math.

---

Well now, had you actually said you just wanted to mung up the the bits and then take these munged up bits, turn them back into a floating point number, in the first place we'd have been all clear wouldn't we?

In short: No. Why would there be? Why would there be a way to take any random integer value and assume it's not really an integer, but a floating point number? Why on earth would the C language let you do this without a cast. Because that is what you want:

Quote:

---

is there any way, given the setup or a similar setup of code, that would allow me to convert the non-lvalue integer return of a macro directly to a float without casting?

---

What? How does this even make sense? Oh, right. There is a way! I forgot about it!

Code:

---

#include <stdstupid_float_magic.h>

---

I always forget that!

[edit]
Wait wait wait! It's even better! I forgot this one:

Quote:

---

I can't think of a reason I would ever need to do this, but lets pretend

---

And you're miffed because some one told you it's undefined. What a ........ing idiot.
[/edit]

Quzah.

i am happy to have found a forum that prefers insults over answers.

first, you are right, macros dont 'return'... I misspoke. what i should have said was, i want what this macro resolves to.

second, i know that floating point numbers arent stored the same way as integers. i think i made this pretty obvious with how my fake, useless macro worked: the IEEE floating point standard that i as well as most processors use defines a float like this:

http://www.psc.edu/general/software/...ieee/ieee.html

performing actions on the bits in a float can hardly be considered magic. adding to the exponent bits results in multiplications by two, similar to the way shifting works in addition. similarly, other operations can be performed on the varioius bits to get certain outcomes. if you think this is "........ing stupid", then you may want to take it up with the people who came up with the standard, not me.

Quote:

---

Seriously. If it's not defined, you have no control over what happens.

---

i disagree. assming i know the format that my floats are in, i have every means at hand to make the values exactly what i want them to be.

all of this badmouthing and insulting aside...

the only question i had was the one i stated before:

"how do i put rvalue bits inside of a variable for which bit modification is not allowed by C without creating a temporary variable?"

whether or not the answer to this question is safe or reliable or portable, i dont care. i want to know if its doable. consider it an excercise of knowlege rather than a viable solution to a problem if you have to...


oh, and here is some help figuring out what lvalue and rvalue mean, so that in the future you will be able to read my sentances:
http://cplus.about.com/od/cprogrammi...def_lvalue.htm


[EDIT]

there was an error in my stupid little example macro, for those of you who are still looking for things to ridicule me on. it should have went something more like this:

(0x80000000 | (((exp)&0x000000FF)<<23) | ((mantissa)&0x007FFFFF))

[/EDIT]

Quote:

---

i disagree. assming i know the format that my floats are in, i have every means at hand to make the values exactly what i want them to be.

---

You can disagree all you like. It doesn't make you right. Floating point numbers are inprecise. Therefore, unless you have memorized every single point at which it decides to round, the best you'll get is "close", which is what floating point numbers are. They're "close". They're not accurate.

Quote:

---

"how do i put rvalue bits inside of a variable for which bit modification is not allowed by C without creating a temporary variable?"

---

Well I guess you just answered your own question, didn't you?

Oh, and the whole "rvalue" issue doesn't exist as far as your not being able to modify it and as to your passing it to a function. When you pass anything to a function, it's automaticly assigned to an lvalue in the call. To use your example:

Code:

---

5.5f = somefunc( ); /* 5.5f is an "rvalue", because it's not a variable, it's a numeric constant */
somefunc( 5.5f ); /* 5.5f is automaticly a "lvalue" when it reaches the function */

---

Anything you pass to this function will automaticly be in an "lvalue" when it gets there. It's impossible to have an "rvalue" reach a function call. Furthermore, were this not a floating point number, you could automaticly mung its bits in the assignment:

Code:

---

somefunc( 5 << 3 );

---

So, as stated, to do the same thing to a float, you cast it to an integer first. You can play with void pointers or whatever you like, but the end result is some value ending up stuck in a variable when it reaches the function. It'll get there in a variable. Don't believe me?

Code:

---

#include<stdio.h>
void foo( float f )
{
    f = 1.0;
    printf("f is %f\n", f );
}

int main( void )
{
    foo( 10.10 );
    return 0;
}

---

There's no such thing as an "rvalue" reaching a function. Ever. It's not going to happen.

So really, to simply clarify the issue, you could have just asked:

"Is there any way for me to shift a numeric floating point constants' bits without using a variable or a cast?"

See how clear that is? Now, a union is going to use a variable. You don't want that. Now you don't want a cast either. Therefore your answer is: no.

[edit]

Quote:

---

for those of you who are still looking for things to ridicule me on.

---

For those of you still looking for a reason to whine, you were the one who turned this into a flame war. Dave simply stated that what you want to do isn't defined by the standard. Then you got your britches in a bunch about it for some reason.
[edit]


Quzah.

>> "how do i put rvalue bits inside of a variable for which bit modification is not allowed by C without creating a temporary variable?" <<

There is no way to take the address of an r-value in C:

Quote:

---

Originally Posted by C89 Draft

3.3.3.2 Address and indirection operators

The operand of the unary & operator shall be either a function designator or an lvalue that designates an object that is not a bit-field and is not declared with the register storage-class specifier.

---

I think you will have to stick the value in a variable or possibly use assembly.

maybe an example will help. bit modification is not allowed directly by C, correct? I will use these macros for the rest of this post:

#define FBITS(f) (*(int*)&f)
#define BITSTOF(f) (*(float*)&f)

but i can still do this:

#include <stdfloating_point_magic.h>
float f = 2.0f;
FBITS(f) |= 0x80000000;

and suddely, like magic, i have a -2.0f where my 2.0f used to be. so its not true that i cant modify a float's bits with predictable results. so how about this:

#include <stdfloating_point_magic.h>
int i = 0x40000000;
float f = BITSTOF(i);

again, magically, i get exactly what i wanted, 2.0f.

but now lets say for some reason i cant have the int, and i must do this directly:

float f = BITSTOF(0x40000000);

this obviously doesnt work.

my question is, is there something that can be done in C that would allow me to get from that hex value to a floating point 2.0f without creating a temporary integer?


oh, and thanks for that clarification of how function parameters are allocated as memory on the stack. i have a firm grasp of low level floating point manipulation and lvalue/rvalue functionality, but i had no idea how functions work.

thank you for keeping it civil, anonytmouse.

i wanted to avoid assmebly, i have been given enough of a hard time with my portability as it is. were it possible to bust out in assembly, though, it would have been fairly easy, and is how i would normally do it under these circumstances. i was merely curious of the possibility of C supporting this somehow, since it is definitely possible for the processor to do this without creating a temporary variable.

Too all:
Cool the sarcasm. Thank you.

>> my question is, is there something that can be done in C that would allow me to get from that hex value to a floating point 2.0f without creating a temporary integer? <<

No.

>> since it is definitely possible for the processor to do this without creating a temporary variable. <<

I'm only an assembler novice, but I would have thought that 0x40000000 would be placed in an integer register and would have to be placed elsewhere to be treated as a float. [edit]I suppose you may be able to copy the value directly from the register to the calling stack, missing the temporary variable required in C.[/edit]

Quote:

---

Originally Posted by ...

maybe an example will help. bit modification is not allowed directly by C, correct? I will use these macros for the rest of this post:

#define FBITS(f) (*(int*)&f)
#define BITSTOF(f) (*(float*)&f)

but i can still do this:

#include <stdfloating_point_magic.h>
float f = 2.0f;
FBITS(f) |= 0x80000000;

and suddely, like magic, i have a -2.0f where my 2.0f used to be. so its not true that i cant modify a float's bits with predictable results.

---

Guess what, idiot? You no longer have a floating point number. You turned it into an integer with a cast. The very thing you said you didn't want.

Furthermore, your macro fails with a true rvalue. Stop passing it lvalues. In none of these examples are you tweaking the "bits of an rvalue". You're always tweaking the bits of an lvalue. Which is the opposite of what you said you actually wanted to do. Don't believe me? I'll prove it. Compile this. I dare you.

Code:

---

#include<stdio.h>

#define FBITS(f) (*(int*)&f)

int main( void )
{
    float f;
       
        f = FBITS( 2.0 );
    return 0;
}
/*
gcc -o moron moron.c -Wall -pedantic -ansi

moron.c: In function `main':
moron.c:9: error: invalid lvalue in unary `&'
*/

---

I can hear you now: "But it said lvalue smart ass! I thought you said rvalue! HAH!"

I did. You cannot manipulate an rvalue. Therefore, any manipulation must be turned into... wait for it... an lvalue! As you've already been told by anon.

So, what if I pass it f instead? Well, that's not changing an rvalue! It's changing an lvalue! You've already been told you can't tweak an rvalue. Now you've been shown again. Still feel like proving yourself wrong? Go ahead.

Oh, and apparently in your great wisdom, you've forgotten the simplest way to get a "negative float":

Code:

---

foo = 0.0f - wtfe;

---

Can't see the forest for the trees, eh brainy?

Quote:

---

i have a firm grasp of low level floating point manipulation and lvalue/rvalue functionality, but i had no idea how functions work.

---

No dude, you truely don't have a ........ing clue.

Quzah.

you forced him to use cuss words, uh oh.

I am going to finish up this thread with one final statement in my defense, and then i will not reply to it again.

the examples that i specified work, as i said they did, and the last example doesnt work, exactly like i said. I was showing you what worked and what didnt work, in the hopes that all of your anger and frustration came from you not understanding the question. i know what an lvalue is, i know what an rvalue is, i know how floats work. of course you cant put a 2.0f in FBITS, i already said that didnt work with the hex number i used in the final example. thats the reason that i posted in the first place; i know assembly can do it, i wanted to know if, through some strange way, C could do it.

I already got the best answer I am going to get and a hell of a lot else besides, so I am officially done asking. Thank you to everyone that didnt get involved in all of the pettiness. Go ahead and get the last word, I'm sure you had a few insults that youve been saving for this moment. perhaps involving my mother?

(and to think, i used to recommend this place to people).


[edit to anonytmouse]
you can freely move values from integer registers into floating point variables in memory, as long as they are the same size as the variable you are writing to. here is an example from some "fast squareroot" code that i picked up a while back:

#define ASM_SQRT(float_num, float_answer)\
__asm mov eax, float_num \
__asm sub eax, 0x3f800000 \
__asm sar eax, 1 \
__asm add eax, 0x3f800000\
__asm mov float_answer, eax

(compiles in visual studio)

[/edit]

Quote:

---

you can freely move values from integer registers into floating point variables in memory, as long as they are the same size as the variable you are writing to. here is an example from some "fast squareroot" code that i picked up a while back:

Code:

---

#define ASM_SQRT(float_num, float_answer)\
__asm mov eax, float_num \
__asm sub eax, 0x3f800000 \
__asm sar eax, 1 \
__asm add eax, 0x3f800000\
__asm mov float_answer, eax

---

(compiles in visual studio)

---

But you've still got the one copy operation to get from an int to a float: __asm mov float_answer, eax. Won't the C code result in much the same thing?

Code:

---

int fake_float = 0x40000000;
// Use fake_float as a float using your #define BITSTOF(f) (*(float*)&f) macro

---

As I mentioned in my edit, if you wanted to pass 0x40000000 directly to a function you may be able to avoid a temp variable by using assembler.
[edit]
I compiled this with GCC:

Code:

---

#include <stdio.h>

#define BITSTOF(f) (*(float*)&f)

void printfloat(float f)
{
        printf("%.2f\n", f);
}

int main(void)
{
        int fake_float = 0x40000000;
        printfloat(BITSTOF(fake_float));
        getchar();
}

---

and got this (the interesting bit):

Code:

---

        subl        $12, %esp
        pushl        $0x40000000
        call        _printfloat

---

So it appears the compiler is smart enough not to use a temporary variable.
[/edit]
This sort of stuff is likely to defeat the optimiser, so I'd want to be sure that there is an actual performance improvement that is worth the bother.

Well, I'm an ass, everyone knows that. :) But at any rate, here we go:

Your first post, I did misread, which is why you got the answer of turning whatever your macro returned into a float by adding 0.0f to it. However, reading this line again:

Quote:

---

My question is this: is there any way, given the setup or a similar setup of code, that would allow me to convert the non-lvalue integer return of a macro directly to a float without casting?

---

And you see where my answer comes from:

Code:

---

foo( 0.0f + YOURMACRO( ... ) );

---

It's now a float. Even an rvalue is turned into a float with that. (float + anything) is in fact a float. What you apparently wanted was to manipulate the bits of an rvalue, which isn't what you ask in that question. You say "turn this rvalue into a float". I did. I turned it directly into a float. You didn't say: "Turn this value into the bits of a floating point number." Which is something entirely different.

You have a macro which returns the "rvalue" of 5. You may as well say:

Code:

---

#define FOO 5

---

for all intents and purposes. Ok, now you say: "Is there any way, given the setup or similar setup of code, that would allow me to convert the non-lvalue integer [sic]return of a macro directly into a float without casting?" Sure. Here:

Code:

---

bar( 0.0f + FOO );

---

Didn't that do what you asked? Sure looks like a floating point number to me.

Quote:

---

Originally Posted by Dave_Sinkula

IMO, such things tend to assume too much about the implementation and should be shunned. Such behavior is undefined.

---

Dave's opinion (IMO see that? IMO...) is that you should avoid such things. You don't like Dave's opinion. You also don't like my wording, or my solution, version, whatever:

Quote:

---

Originally Posted by ...

wow, lotta testy people today...

the only thing thats broken about that is your assumptions...

---

If your macro wasn't broken, why ask the question? Nevermind.

Then you also add more information:

Quote:

---

A union would be workable except that it needs to use existing variable types (such as standard 32 bit floats and ints), and the trick I specified does not work for non lvalues (IE, I cant do this: "*(int*)&(0xFFFFFFFF)"), and the macro that I made up resolves to an rvalue.

---

You don't specificly say that in your first post. See how it pays to be clear? Oh, also, "standard 32bit floats and its" aren't standard. The standard does not say an int has to be 32 bits. It doesn't even say floats have to be 32 bits. All it ever sets are minimums. But I'm sure you knew that.

Dave replies again, because as I mention, you didn't specify at the time anything about what you needed other than you wanted some hackish fix for rvalues (if we stretch your question a bit).

Quote:

---

Originally Posted by Dave_Sinkula

There are other formats, and the "value of a union member other than the last one stored into" is unspecified*. Casting does much the same, except it turns off error checking.

But if you want to be testy yourself, at least specify the exact platform and situation. After all, the is a C forum, and your answer is not in the general case.

*Not undefined as inferred earlier.

---

You don't state at all in your first post anything about IEEE floating point standards, which is what Dave had to go by at the time of his post.

Then I rant a bit about how I think you're an idiot for a while. But in the midst of that, I show you the simplest way to make your negative float, which you apparently didn't see, or didn't like. But the fact is, it's the easiest way to do it, rvalue or no.

Then you follow up with how you really can manipulate the bits of a floating point number, which is wrong.

Quote:

---

performing actions on the bits in a float can hardly be considered magic. adding to the exponent bits results in multiplications by two, similar to the way shifting works in addition.

---

No it doesn't. You're wrong. You cannot preform bitwise operations on floating point numbers. Period. It doesn't matter what you say to this, you're wrong.

No, wait, you think you can:

Quote:

---

#define FBITS(f) (*(int*)&f)
#define BITSTOF(f) (*(float*)&f)

but i can still do this:

#include <stdfloating_point_magic.h>
float f = 2.0f;
FBITS(f) |= 0x80000000;

and suddely, like magic, i have a -2.0f where my 2.0f used to be. so its not true that i cant modify a float's bits with predictable results. so how about this:

---

But you're wrong. At this point it's really sad. See, I wasn't even starting this post to flame you. I was starting it to simply walk through the thread, say I was wrong and an ass, but also to step through the thread.

But at this point, you are clearly wrong, and you can't even see it. You cannot manipulate the bits of a floating point number. It doesn't happen. The only way you can even remotely pretend to do so, is because you typecast it to an integer. Then, it's no longer a floating point number! You're operating on an integer. The language doesn't let you manipulate the bits of a floating point number, because there is no C standard way to store them. That's why you can't do it. That's why you have to fake it with a cast. And no, you cannot fully get the exact results you want. It's impossible. Oh, sure, for some numbers it may turn out so it looks right, but it is not accurate, for the simple fact that floating point numbers aren't accurate. It's impossible to have high precision accurate floating point numbers. IT doesn't happen.

Your manipulation isn't of a float, it's of an integer. It's no longer a float... now I'm just being redundant.

Then you're told that you can't get the address of an rvalue. Which means you can't manipulate them directly.

Then I tell you you're an idiot few more times, and that you still don't know what you're talking about. You say you do, and at the time of this post, it's quite clear you still don't. But you're done replying apparently, except you really aren't, because you're editing your post as I write...

In short, I'm an ass, everyone knows it, and you still don't know what you're talking about. But at least you know something, which is that no, you can't get the address of an rvalue.


Quzah.