   how do I make float accurate?
  Kudos everyone. I'm currently writing an object that turns any data type into c string. Sort of like the function lota() in stdlib. I would be done except for the weirdness of floats. My algorithm for parsing the number works on the amount of digets in that number, and the base system of that number. The problem with floats and doubles, is that they seems to lose accuracy as they traverse the math and functions thrown at it. <.14!=.1399999>  Heres is some of my code. // wnum = whole number, dnum = decimal number   int wnum = static_cast(num);  // WHAT THE HELL? I for some reason this bbs isn't showing the greater then, less than brackets. Damn it. I know there shouldbe (greater than - int - less than)double/float dnum = num - wnum; This is how I'm seperating the whole number and the fractional part. Maybe this is where the inconsistancy arises. How can I keep everything consistant. Argh, it's hard to be articulate when I'm so tired. Ok heres some code that just messes up.    float num = 20.14f;   int wnum = static_cast(num);  // WHAT THE HELL? I for some reason this bbs isn't showing the greater then, less than brackets. Damn it. I know there shouldbe (greater than - int - less than)float dnum = num - wnum;    cout << dnum << endl; // output should be .14, but its // 13.9999 instead See the problem here? If I make it double it fixes it, but only for a little while. As the numbers grow or change, even weirder problems arises.[edited by - xorjesus on February 2, 2004 10:31:33 PM][edited by - xorjesus on February 2, 2004 10:32:46 PM]
quote:Original post by xorjesus   Kudos everyone. I'm currently writing an object that turns any data type into c string. Sort of like the function lota() in stdlib. I would be done except for the weirdness of floats. My algorithm for parsing the number works on the amount of digets in that number, and the base system of that number. The problem with floats and doubles, is that they seems to lose accuracy as they traverse the math and functions thrown at it. <.14!=.1399999>  Heres is some of my code.  *snip*This is how I'm seperating the whole number and the fractional part. Maybe this is where the inconsistancy arises. How can I keep everything consistant. Argh, it's hard to be articulate when I'm so tired. Ok heres some code that just messes up. *snip*See the problem here? If I make it double it fixes it, but only for a little while. As the numbers grow or change, even weirder problems arises.[edited by - xorjesus on February 2, 2004 10:31:33 PM][edited by - xorjesus on February 2, 2004 10:32:46 PM] First: angle brackets (< ) and ( >) cause the forum software to interpret the enclosing text as HTML tags; bad tags are thrown out. Square brackets ([ ) and ( ]) can be just as bad, because they represent forum-specific tags. (Try indexing an array with i for the subscript, and you get loads and loads of italicized text). To bypass the tag interpretation, enclose source code in source tags ( source and /source enclosed in square ([ ]) brackets). This will format your code into a scrolling, syntax-colored mini-window which is easier for us to peruse. You could also insert spaces inbetween the brackets and the enclosed text to force the software to not interpret it as tags, but it's easier to just use [ source] and [ /source].Second: You are always going to have floating point imprecision when trying to pack floating point data into binary representations of finite length. Increased type size can reduce the imprecision, but it will still be there. The format that floating point types are represented in also represents some values poorly (as you have witnessed), and these problems are only exacerbated as computations are performed, due to small round-off errors and other inconsistencies creeping in.It might be helpful to read up on the IEEE floating point format. A good example link is here.Quoted from the article (and relevant to your example):quote:Somewhat surprisingly, this means that approximations are used for many real numbers that can be represented exactly in decimal numeration. For instance, 7/5 is 1.4 exactly in decimal numeration, but the .4 part cannot be expressed as a sum of powers of two; 7/5 has an infinite binary expansion 1.011001100110011001100..., just as in decimal numeration a fraction like 27/11 leads to an infinite decimal expansion 2.4545454545.... In a single-precision representation, the expansion is rounded off at the twenty-third digit after the binary point. Thus 7/5 is not actually stored as 7/5, but (in single precision) as the very close approximation 11744051/8388608, which can be expressed as a sum of powers of two. GolemBlender--The Gimp--Python--Lua--SDLNethack--Crawl--ADOM--Angband--Dungeondweller [edited by - VertexNormal on February 2, 2004 10:55:49 PM];  Thank you very much vertex. This information just saved me hours of work. The article is very indepth and I will have to spend some time injesting it. Looks like I''ll have to use another method to turn a float into a c string. Thanks again. ;  ... nono, the whole point was that you *can''t* do anything about it. The float value *doesn''t contain the information needed* to let you put .14 in and get .14 out. If you want to be able to write .14 and have it mean *exactly* the result of dividing 14 by 100, then you need to implement your own numeric type. And you won''t even be able to pass .14 or .14f to your constructor, because the value will get destroyed in transit. Instead you''ll have to have it take a string as a constructor or something. 