C / C++ / MFC

Re: conversion confusion...[Modified]

23-Jun-05 21:00

Ok I`ve got this weird problem here....
In a certain func I wrote I need to split a double into 2 integers, the fractional part up to x digits and the decimal part.
See here for the splitting part:

void AFunction( double dNumber, int acc )<br />
{<br />
 //acc is the nr of digits of the fractional part that should be converted.<br />
 int nDecim = (int)dNumber; // this correctly keeps the decimal part.<br />
<br />
 int nFract = (int) ( (double)(dNumber-nDecim) * pow(10,acc) ); //this line has a problem<br />
<br />
 .... //do loads of stuff, like keeping COSMOS1 in undetectable orbit<br />
}

the bizarre thing is that the calculation of nFract works in most of the cases, except in some cases where there is only 1 decimal (e.g. when acc=3, 2.222(nFract=221) and 1.111(nFract=110) fail, but 3.333 doesn`t nor does 22.222 or 11.111...?? Confused | :confused:

)

So I figured, maybe the compiler got confused or so D'Oh! | :doh:

. I split the calculation of nFract in 4 lines and debugged...
(results I mention are with params dNumber=2.222, and acc =3

<br />
int nDecim = (int)dNumber;    // result: nDecim = 2 ok<br />
double dTemp = dNumber - nDecim; // result dTemp = 0.222 ok<br />
int nFactor = pow(10,acc); // result nFactor = 1000 ok<br />
int nFract = dTemp * nFactor // result nFract = 221 NOT OK!!!!!<br />
//so hey I figured lets try an extra step...<br />
double dInterMd = dTemp * nFactor; // result dInterMd = 222.0 ok haha getting close!!<br />
nFract = (int)dInterMd; //result nFract = 221 NOT OK!!!???<br />

once again 22.222 with acc 3 works fine 1.111 has similar problem 3.333 works fine...
I`m at a loss here... What the hell is going wrong?????

ThatsAlok23-Jun-05 21:20

ThatsAlok

23-Jun-05 21:20

GDavy wrote:
In a certain func I wrote I need to split a double into 2 integers, the fractional part up to x digits and the decimal part.

What about this Code Mr Davy,

CString MainStr,;
int Num1,Num2;
 // get Double in String
  MainStr.Format("%e",100.200);

// Get Non decimal Part
 Num1=atoi(MainStr.Left(MainStr.Find('.')));

//get decimal part
 Num2=atoi(MainStr.Right(MainStr.GetLength()-MainStr.ReverseFind('.')-1));

I havn't tested this code, but i believe it will work Smile | :)

"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow

cheers,
Alok Gupta

Re: conversion confusion...[Modified]

GDavy23-Jun-05 21:57

23-Jun-05 21:57

thx for the reply..
I`m trying to avoid conversion to string and getting the data out of there, to avoid excess memory and process time..
I know in modern days noone cares about mem or process time anymore, but the devices I write for have limits.
(and keeping Cosmos 1 in that undetectable orbit requires process speed Poke tongue | ;-P

)

Weiye Chen23-Jun-05 21:26

Weiye Chen

23-Jun-05 21:26

Did you try converting the double value to string and manipulate from there, like finding the '.' character and extracting the string before and after it?

<font=arial>Weiye Chen
Life is hard, yet we are made of flesh...

GDavy23-Jun-05 22:20

23-Jun-05 22:20

)

Rage23-Jun-05 21:51

Rage

23-Jun-05 21:51

GDavy wrote:
What the hell is going wrong?????

From the MSDN, about conversion:

From double To long, Method: Truncate at decimal point. If result is too large to be represented as long, result is undefined.

~RaGE();

GDavy23-Jun-05 22:03

23-Jun-05 22:03

Thx for the reply..

the numbers I pass as parameters are small enough to be contained in an integer (see the values I passed in original post where problem occurs)

The problem lies in rounding I found out... somehow it keeps some rounding bit around when converting the double to int. So going from there I will fix the problem I think (hope) Unsure | :~

mekanoo23-Jun-05 22:33

23-Jun-05 22:33

....ha ! what a buggy thing..!
did you think about bitwise extraction ?
single and double are stored in a defined as'IEEE_754' standard:
1.Bit = +/-
2.-9. is Exponent
10.-32. is Mantisse
but all is counted from right to left &
starting with 0. to 31......so
have look at these definitions and get your numbers as bits from there

Typ Gesamtgröße Mantisse Exponent Bias
single 32 bit 23 bit 8 bit 127
double 64 bit 52 bit 11 bit 1023
Smile | :)

http://www.computerbase.de/lexikon/IEEE_754

mekanoo23-Jun-05 22:53

23-Jun-05 22:53

...a little grammar confusion in my last reply....

i want to add:
i had to deal with the extraction of 'float'= single and 'real'= double data
from a stream.
so i looked for bit-manipulation code thats around..because it's not really easy.
1. the exponent is stored with added value to avoid negative numbers...
2. the whole number is a expression from 2^xyz ....
&&&

--------------
if that doesn't help you really then it gives you at least ahint for the reason of that conversion phanomena.
-------------
.Net Framework helped me out there wit the BitConverter Class.... Suspicious | :suss:

GDavy23-Jun-05 23:21

23-Jun-05 23:21

Thanks for the reply..
I looked up the IEEE standard you mentioned for floating point arithmetic.. Nice documentation, thanks. It's indeed explaining the peculiar behaviour I noticed.
Been so long since I looked at a basic C-type at such a low level that it was a nice refreshment!
Rose | [Rose]

mekanoo24-Jun-05 0:13

24-Jun-05 0:13

Gary R. Wheeler24-Jun-05 3:25

Gary R. Wheeler

24-Jun-05 3:25

void AFunction(double dNumber,int acc)
{
  int nDecimal = (int)dNumber;
  double dFract = dNumber - (double)nDecimal;
  double dFactor = 1.0;
  for (int dFi = 0; dFi < acc; dFi++) dFactor *= 10.0;
  int nFract = (int)((dFract * dFactor) + 0.5);
}

Hmm. I made the scale factor a double, and calculated it with a simple loop (the fastest solution would be to use an array lookup). I also rounded the result.

Software Zen: delete this;

mekanoo25-Jun-05 2:32