int, float

[Link]

I have to convert an float number to int without using casting i= (int) f,
without printf and others. I can only use int, char and structs. Can anyone
help?

Thanks
Juerg

 

[David Harmon]

I have to convert an float number to int without using casting i= (int) f,
without printf and others. I can only use int, char and structs.

What is it about the standard built-in conversion from float to int
(what you call "casting") that makes it unsuitable for your application?
Anything else is doing it the hard way.

 

[osmium]

I have to convert an float number to int without using casting i= (int) f,
without printf and others. I can only use int, char and structs. Can anyone
help?

I assume this is a student assignment. The first step is to find out how
your platform encodes a float. Look at the documentation that came with
your compiler. It is almost certain that an int is encoded as a two's
complement binary number and it's size will be in <limits.h>. Are you sure
that unions are forbidden? They might turn out to be handy, too.

Sounds like a fun and informative exercise.

 

[Link]

Yes, I have it to do in the hard way - Its only a little box (not pc) and so
I can't use all libs (reduced memory, ...)
You know someting about working with exp, mantissa and so, only with int and
struct?

 

[Link]

Its a work on a little box with not much memory and I'm using borland turbo
compiler (TC)

typedef struct _MF {
unsigned long m : 23;
unsigned int e : 8;
unsigned int s : 1;
} MF;

union are ok.

You know more about working with mantissa, exponent and so?

 

[Victor Bazarov]

I have to convert an float number to int without using casting i= (int) f,
without printf and others. I can only use int, char and structs. Can anyone
help?

What is it, a well-camouflaged homework? Most processors that
can work with floating point numbers directly can load them into
their register as FP and store as an int. Two instructions, no
printf necessary. If you are so bound to a particular "box" as
you claim, use assembly language. Or does your processor lack
any support for floating-point numbers?

 

[Gianni Mariani]

Its a work on a little box with not much memory and I'm using borland turbo
compiler (TC)

typedef struct _MF {
unsigned long m : 23;
unsigned int e : 8;
unsigned int s : 1;
} MF;

union are ok.

You know more about working with mantissa, exponent and so?

Well, you've virtually answered your question -

given that the floating point number is:

(s ? -1: 1 ) x m x 2^(e)

I think you can figure it out - however, be careful with 'e'. Is 'e'
really unsigned ? You also need to know what "m" is - is m really
normalized - meaning is the expression really :

(s ? -1: 1 ) x m x 2^(e-23)

Can you figure it out from there ?

 

[David Harmon]

Its a work on a little box with not much memory and I'm using borland turbo
compiler (TC)

Use the Borland assembly source out (the -S option if I recall) and
look at what it generates for the cast. Then consider whether you still
think you can do better. If you can, the assembly source will probably
give some clue as to which way to go.

As for comp.lang.c++, we do try to keep to standard portable stuff
here, so twiddling mantissas and such will not be too popular.
See the welcome message posted twice per week in comp.lang.c++ or
available at http://www.slack.net/~shiva/welcome.txt

 

[Ron Natalie]

What is it, a well-camouflaged homework? Most processors that
can work with floating point numbers directly can load them into
their register as FP and store as an int.

Too bad that doesn't include pentiums.

 

[Andy Buchanan]

Too bad that doesn't include pentiums.

It doesn't? FILD/FIST don't work? Bit on the slow side, but they
always worked for me.....

 

[Ron Natalie]

It doesn't? FILD/FIST don't work? Bit on the slow side, but they
always worked for me.....

FIST isn't slow. However, FIST won't in most cases convert between
float and int as the processor is almost certainly in round mode. Therefore
you have two options:

1. Modify the fcw to change the state to truncation, do the fist, then put it
back. This is EGREGIOUSLY SLOW.
2. Subtract .5 from the value before doing the fist. (This is actually pretty fast
but I don't know ANY compiler that does this).

 

[Martin Eisenberg]

FIST isn't slow. However, FIST won't in most cases convert
between float and int as the processor is almost certainly in
round mode. Therefore you have two options:

1. Modify the fcw to change the state to truncation, do the
fist, then put it back. This is EGREGIOUSLY SLOW.
2. Subtract .5 from the value before doing the fist. (This is
actually pretty fast but I don't know ANY compiler that does this).

The x87 round-to-nearest mode chooses the even value in case of a
tie, so 3.0 is "truncated" as 3.0 - 0.5 = 2.5 -> 2; probably not the
intended result.


Martin

 

[Ron Natalie]

The x87 round-to-nearest mode chooses the even value in case of a
tie, so 3.0 is "truncated" as 3.0 - 0.5 = 2.5 -> 2; probably not the
intended result.

Prescott by the way has a new FISTTP instructions that always truncates
(regardless of the FCW). I guess enough C programmers finally screamed.

 

[Andy Buchanan]

FIST isn't slow.

If I'm doing thousands of them it starts to add up
IIRC it's 6 cycles or so, that hurts when I've managed
to finese away just about every expensive calculation
in an inner loop. It's all relative I suppose.

However, FIST won't in most cases convert between
float and int as the processor is almost certainly in round mode. Therefore
you have two options:
1. Modify the fcw to change the state to truncation, do the fist, then put it
back. This is EGREGIOUSLY SLOW.
2. Subtract .5 from the value before doing the fist. (This is actually pretty fast
but I don't know ANY compiler that does this).

Well okay, you're right of course, but generally when I've had to hit
the assembler for performance reasons I've usually been quite happy to
accept this single bit error.