Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > bitwise on float

Reply
Thread Tools

bitwise on float

 
 
Richard Heathfield
Guest
Posts: n/a
 
      05-19-2007
Walter Roberson said:

<snip>

> Secondly, it is undefined behaviour to access a union
> member through a type other than the last type that was used
> to store the variable (unless the new access type is a structure
> of identical type elements -- the "prefix" rule.)


In C89 at least, it's actually implementation-defined. See C89 3.3.2.3.
I cannot find similar wording in C99, however.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
 
Reply With Quote
 
 
 
 
Walter Roberson
Guest
Posts: n/a
 
      05-19-2007
In article <464e0262$0$13207$(E-Mail Removed)>,
Carramba <(E-Mail Removed)> wrote:

>reason two:
>because in the I have been shouted and treat malicious then I have
>posted something that wasn't related to ansi c. and underlying problem
>isn't so I just posted only what are my intentions to do.


I have gone back through google groups and reviewed all of the
comp.lang.c postings that mention "Carramba", and I have been unable to
find any postings in which you were shouted at or treated maliciously
for posting non-ANSI questions. I did find postings in which you were
asking about changing the console size and about changing text colour,
and about sending output to a printer, but in each case I only see
polite responses that the matter was system specific and that you would
have to ask elsewhere.

I do see one response of, "You already got an answer. If you don't like
it, tough." when you persisted in asking a question after it had
several times been indicated that the matter was system-specific;
I do not find any shouting or malicious treatment there. But I do
see that you -continued- to ask the same question there, posting:

the only one who a posting poinless stuff is you and others who have
bugging my whether my post is pointless or not... if you don\t like my
post just skip it instead of mayking full of you selfs

Do you have references to postings in which you feel that you were
shouted at or treated maliciously?
--
"law -- it's a commodity"
-- Andrew Ryan (The Globe and Mail, 2005/11/26)
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      05-19-2007
http://www.velocityreviews.com/forums/(E-Mail Removed)-cnrc.gc.ca (Walter Roberson) writes:
> In article <(E-Mail Removed) .com>,
> christian.bau <(E-Mail Removed)> wrote:
>>On May 18, 3:15 pm, Carramba <(E-Mail Removed)> wrote:
>>> Hi!
>>> I now that I can't do straight forward any bitwise operation on float
>>> (double etc..). But I wondering what is the easiest/best way to do this?
>>> I was thinking if I have float x=1.1111 so I can multiple it by 1000 to
>>> get 11111 and the preform bitwise like <<2 to get 88888 and then divide
>>> by 1000 to go back to float 8.8888. but these seem like "nasty" way to
>>> do it. So maybe some of you have great tips?

>
>>Your post has lead to quite a long and rather pointless debate. You
>>could help by telling us: What is it actually that you are trying to
>>achieve? Forget about "bitwise operations", they are just your idea
>>how you could achieve this. Tell us _what_ you want to achieve.

>
> The OP already answered this in
> <464e0262$0$13207$(E-Mail Removed)>
>
> Summary: genetic algorithms on encoded operations.


Is there a reasonably brief explanation that would make sense to those
of us who aren't familiar with genetic algorithms?

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      05-19-2007
Keith Thompson said:

> (E-Mail Removed)-cnrc.gc.ca (Walter Roberson) writes:
>>
>> Summary: genetic algorithms on encoded operations.

>
> Is there a reasonably brief explanation that would make sense to those
> of us who aren't familiar with genetic algorithms?


A genetic algorithm, at its simplest, is one for which you express a
candidate solution to a problem as a bit-string, and have some way to
evaluate the fitness of that solution (for example, if it's TSP, the
fitness is the total distance travelled, where low is good). You
generate lots of random solutions, sort them by fitness, eliminate the
weakest, and breed the remainder using standard genetic crossover and
mutation techniques (crossover basically means "take so many bits from
the father solution, then yay many from the mother solution, switching
back and forth at random points until you have a complete child
solution", and mutation means "flip N randomly-selected bits").

Iterate until you have a solution that you consider "good enough".

GAs are not generally a great idea if you're after an exact solution,
but they can home in on "good enough" solutions surprisingly quickly.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      05-19-2007
Richard Heathfield <(E-Mail Removed)> writes:
> Keith Thompson said:
>> (E-Mail Removed)-cnrc.gc.ca (Walter Roberson) writes:
>>> Summary: genetic algorithms on encoded operations.

>>
>> Is there a reasonably brief explanation that would make sense to those
>> of us who aren't familiar with genetic algorithms?

>
> A genetic algorithm, at its simplest, is one for which you express a
> candidate solution to a problem as a bit-string, and have some way to
> evaluate the fitness of that solution (for example, if it's TSP, the
> fitness is the total distance travelled, where low is good). You
> generate lots of random solutions, sort them by fitness, eliminate the
> weakest, and breed the remainder using standard genetic crossover and
> mutation techniques (crossover basically means "take so many bits from
> the father solution, then yay many from the mother solution, switching
> back and forth at random points until you have a complete child
> solution", and mutation means "flip N randomly-selected bits").
>
> Iterate until you have a solution that you consider "good enough".
>
> GAs are not generally a great idea if you're after an exact solution,
> but they can home in on "good enough" solutions surprisingly quickly.


Thanks, that's helpful.

So it seems that it would work best if two solutions whose bit-strings
differ by only a few bits are in some sense "close" to each other, or
at least are likely to have some meaningful relationship to each
other.

For example, if the bit-strings are MD5 checksums, and "fitness" is
determined by whether the bit-string is the MD5 checksum of a
particular input, then a GA isn't going to do much good; two very
similar inputs will have completely dissimilar checksums.

Representations of floating-point numbers can vary from one system to
another, though the IEEE standard representation is very common these
days. Trying GA on floating-point numbers, viewing their
representations as bit-strings, sounds interesting; at the very least,
discovering that it doesn't work could be useful.

Getting back to the OP's question, the language simply doesn't define
bitwise operations on floating-point types. But you can do it
indirectly.

If you don't care about absolute portability, you can choose an
unsigned integer type that's the same size as your floating-point
type. (The language doesn't guarantee that there is such a type.)
For example, on many systems, types double and unsigned long long are
both 64 bits. You can define a typedef, to be modified for different
implementations, for whichever unsigned type is the same size as
double. (C doesn't provide such a typedef because there's not much
use for it in general.)

With some risk of non-portability, you can declare a union:

typedef unsigned long long double_unsigned; /* this may vary */
union kludge {
double d;
double_unsigned u;
};

You can then store a double value in the "d" member, then perform your
bitwise operations on the "u" member, and read the modified value of
the "d" member.

Strictly speaking, storing a value in one member of a union and
reading another member is not permitted. In practice, it's likely to
work, and what you're doing is pretty much inherently non-portable
anyway.

An alternative to a union would be to use memcpy() to copy the
representation of a floating-point object to an unsigned integer
object and vice versa.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      05-19-2007
Keith Thompson said:

<snip>

> So it seems that [the GA approach] would work best if two solutions
> whose bit-strings
> differ by only a few bits are in some sense "close" to each other, or
> at least are likely to have some meaningful relationship to each
> other.


Actually, that doesn't matter very much. What does matter, though, is
that any bitstring should be *valid* - i.e. a legal solution. So
doubles aren't a great way to go, because it's too easy to break them.

> For example, if the bit-strings are MD5 checksums, and "fitness" is
> determined by whether the bit-string is the MD5 checksum of a
> particular input, then a GA isn't going to do much good; two very
> similar inputs will have completely dissimilar checksums.


Yes, and in any case the "fitness" there is Boolean! Either it's right
or it's useless. That isn't a good application for GAs. TSP actually
makes a good illustration of the "fitness function" - the shorter the
distance, the better the solution, but even quite a long distance might
still constitute reasonable fitness, at least until some better,
fitter, shorter competitors come along.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
 
Reply With Quote
 
Army1987
Guest
Posts: n/a
 
      05-20-2007

"Keith Thompson" <(E-Mail Removed)> ha scritto nel messaggio
news:(E-Mail Removed)...
> Richard Heathfield <(E-Mail Removed)> writes:
>> A genetic algorithm, at its simplest, is one for which you express a
>> candidate solution to a problem as a bit-string, and have some way to
>> evaluate the fitness of that solution (for example, if it's TSP, the
>> fitness is the total distance travelled, where low is good). You
>> generate lots of random solutions, sort them by fitness, eliminate the
>> weakest, and breed the remainder using standard genetic crossover and
>> mutation techniques (crossover basically means "take so many bits from
>> the father solution, then yay many from the mother solution, switching
>> back and forth at random points until you have a complete child
>> solution", and mutation means "flip N randomly-selected bits").
>>
>> Iterate until you have a solution that you consider "good enough".
>>
>> GAs are not generally a great idea if you're after an exact solution,
>> but they can home in on "good enough" solutions surprisingly quickly.

>
> Thanks, that's helpful.
>
> So it seems that it would work best if two solutions whose bit-strings
> differ by only a few bits are in some sense "close" to each other, or
> at least are likely to have some meaningful relationship to each
> other.
>
> For example, if the bit-strings are MD5 checksums, and "fitness" is
> determined by whether the bit-string is the MD5 checksum of a
> particular input, then a GA isn't going to do much good; two very
> similar inputs will have completely dissimilar checksums.
>
> Representations of floating-point numbers can vary from one system to
> another, though the IEEE standard representation is very common these
> days. Trying GA on floating-point numbers, viewing their
> representations as bit-strings, sounds interesting; at the very least,
> discovering that it doesn't work could be useful.
>
> Getting back to the OP's question, the language simply doesn't define
> bitwise operations on floating-point types. But you can do it
> indirectly.
>
> If you don't care about absolute portability, you can choose an
> unsigned integer type that's the same size as your floating-point
> type. (The language doesn't guarantee that there is such a type.)


You can use arrays of unsigned char, unless you have to move bit
strings horizontally (and even if you do, you can invent something
for that).

/* not tested */
#include <string.h>
#include <stdlib.h>
#include <time.h>
#include <limits.h>
double child(double father, double mother)
{
unsigned char father_rep[sizeof(double)];
unsigned char mother_rep[sizeof(double)];
double child_val;
unsigned char child_rep[sizeof(double)];
size_t i;
int j;

srand((unsigned)time(NULL) ^ (unsigned)clock());
memcpy(father_rep, &father, sizeof father);
memcpy(mother_rep, &mother, sizeof mother);
memset(child_rep, '\0', sizeof child_rep);
for (i = 0; i < sizeof(double); i++)
for (j = 0; j < CHAR_BIT; j++) {
if (rand() < RAND_MAX / 2)
child_rep[i] |= father[i] & (1U << j);
else
child_rep[i] |= mother[i] & (1U << j);
if (rand() < RAND_MAX / 100) /*random mutations*/
child_rep[i] ^= 1U << j;
}
memcpy(&child_val, child_rep, sizeof child_val);
return child_val; /* but beware of trap representations */
}
(You could have more sophisticated algorithms for choosing from
which parent to take a bit.)


 
Reply With Quote
 
none
Guest
Posts: n/a
 
      05-21-2007
Keith Thompson wrote:
>
> Strictly speaking, storing a value in one member of a union and
> reading another member is not permitted. In practice, it's likely to
> work, and what you're doing is pretty much inherently non-portable
> anyway.
>


Sorry to hijack the thread, but this is precisely what I use unions for.
If this is not allowed, then what is the point of unions?

I have used a union (completely non-portably, I realise), to
transparently separately access the 4 bytes of a long integer on some
systems.

Cheers,
mvdw
 
Reply With Quote
 
Carramba
Guest
Posts: n/a
 
      05-21-2007
Keith Thompson skrev:
> Richard Heathfield <(E-Mail Removed)> writes:
>> Keith Thompson said:
>>> (E-Mail Removed)-cnrc.gc.ca (Walter Roberson) writes:
>>>> Summary: genetic algorithms on encoded operations.
>>> Is there a reasonably brief explanation that would make sense to those
>>> of us who aren't familiar with genetic algorithms?

>> A genetic algorithm, at its simplest, is one for which you express a
>> candidate solution to a problem as a bit-string, and have some way to
>> evaluate the fitness of that solution (for example, if it's TSP, the
>> fitness is the total distance travelled, where low is good). You
>> generate lots of random solutions, sort them by fitness, eliminate the
>> weakest, and breed the remainder using standard genetic crossover and
>> mutation techniques (crossover basically means "take so many bits from
>> the father solution, then yay many from the mother solution, switching
>> back and forth at random points until you have a complete child
>> solution", and mutation means "flip N randomly-selected bits").
>>
>> Iterate until you have a solution that you consider "good enough".
>>
>> GAs are not generally a great idea if you're after an exact solution,
>> but they can home in on "good enough" solutions surprisingly quickly.

>
> Thanks, that's helpful.
>
> So it seems that it would work best if two solutions whose bit-strings
> differ by only a few bits are in some sense "close" to each other, or
> at least are likely to have some meaningful relationship to each
> other.


well this is not necessary the case, because some bit-strings can get
into "local-maximum",
and this is bad is they get "locked it there", this is the reason one
perform bit-flip, to avoid this situation. and most GA algorithms works
on optimization/max/min problems thus it's essential to not get stuck in
local maximum, btw this is main problem of GA's

> For example, if the bit-strings are MD5 checksums, and "fitness" is
> determined by whether the bit-string is the MD5 checksum of a
> particular input, then a GA isn't going to do much good; two very
> similar inputs will have completely dissimilar checksums.
>
> Representations of floating-point numbers can vary from one system to
> another, though the IEEE standard representation is very common these
> days. Trying GA on floating-point numbers, viewing their
> representations as bit-strings, sounds interesting; at the very least,
> discovering that it doesn't work could be useful.
>
> Getting back to the OP's question, the language simply doesn't define
> bitwise operations on floating-point types. But you can do it
> indirectly.
>
> If you don't care about absolute portability, you can choose an
> unsigned integer type that's the same size as your floating-point
> type. (The language doesn't guarantee that there is such a type.)
> For example, on many systems, types double and unsigned long long are
> both 64 bits. You can define a typedef, to be modified for different
> implementations, for whichever unsigned type is the same size as
> double. (C doesn't provide such a typedef because there's not much
> use for it in general.)
>
> With some risk of non-portability, you can declare a union:
>
> typedef unsigned long long double_unsigned; /* this may vary */
> union kludge {
> double d;
> double_unsigned u;
> };
>
> You can then store a double value in the "d" member, then perform your
> bitwise operations on the "u" member, and read the modified value of
> the "d" member.


very interesting proposition, since portability is'nt requirement
I thought maybe it would by good soliution to extend you suggestion
and build struct:

typedef bit_string{
double bit-string;
char sing_bit;
char exponent;
long mantissa;
void* convert_to_struct(void* b);
void* convert_to_double(void* b);
}

were convert_to_struct is a pointer to a function that "tears" double
apart and stores it part values, then I would would by able to perform
bit-flip and crossover operation on it's parts and then get double back
with function convert_to_double. Does this sound sane and doable?

> Strictly speaking, storing a value in one member of a union and
> reading another member is not permitted. In practice, it's likely to
> work, and what you're doing is pretty much inherently non-portable
> anyway.
>
> An alternative to a union would be to use memcpy() to copy the
> representation of a floating-point object to an unsigned integer
> object and vice versa.
>

 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      05-21-2007
none said:

> Keith Thompson wrote:
>>
>> Strictly speaking, storing a value in one member of a union and
>> reading another member is not permitted. In practice, it's likely to
>> work, and what you're doing is pretty much inherently non-portable
>> anyway.
>>

>
> Sorry to hijack the thread, but this is precisely what I use unions
> for. If this is not allowed, then what is the point of unions?


It *is* allowed - Keith is wrong about that, at least in C90. But its
effect is implementation-defined.

As for the point of unions, it ain't type-punning, that's for sure.

In days gone by, when men were real men, women were real women, and you
could actually read a core dump from top to bottom in an hour or so,
memory was scarce (which was /why/ you could read a core dump in an
hour), and yet it was sometimes necessary to have big ol' records,
maybe as big as a few kilobytes - you know, huge - and of several
different kinds. But you only actually needed any /one/ kind at a time.
So you shoved all the different structs into a union, to save memory.
*That* was the point of them. It isn't any more, of course. Nowadays,
people seem to want to use them to try to be clever.

> I have used a union (completely non-portably, I realise), to
> transparently separately access the 4 bytes of a long integer on some
> systems.


Well, actually, getting at the object representation of an object is one
way you /can/ use them portably - in the sense that the operation has
the same meaning on all platforms. What it doesn't mean is that the
object representation itself is the same on all platforms, as you have
undoubtedly discovered for yourself anyway.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
float to string to float, with first float == second float Carsten Fuchs C++ 45 10-08-2009 09:47 AM
retrieve bitwise float representation Ulrich Eckhardt Python 3 06-11-2009 01:20 PM
Bitwise Operations on double, float siryuhan@gmail.com C++ 4 05-18-2007 11:42 AM
need code to convert float format to internal java float format which is kept in 4 bytes integer Andy Java 7 05-10-2004 09:26 PM
Re: float->byte->float is same with original float image. why float->ubyte->float is different??? bd C Programming 0 07-07-2003 12:09 AM



Advertisments