How can I convert two unsigned integers that represent the digit and decimal part of a float, into one float.
I know there are a few ways todo this, like converting the decimal component into a float and multiplying it to get a decimal and added it to the digit, but that does not seem optimal.
I'm looking for the optimal way todo this.
/*
* Get Current Temp in Celecius.
*/
void GetTemp(){
int8_t digit = 0; // Digit Part of Temp
uint16_t decimal = 0; // Decimal Part of Temp
// define variable that will hold temperature digit and decimal part
therm_read_temperature(&temperature, &decimal); //Gets the current temp and sets the variables to the value
}
I want to take the Digit and Decimal parts and convert them to a float type, such that it looks like digit.decimal .
It might look like this in end, but I want to find the MOST optimal solution.
/*
* Get Current Temp in Celecius.
*/
float GetTemp(){
int8_t digit = 0; // Digit Part of Temp
uint16_t decimal = 0; // Decimal Part of Temp
// define variable that will hold temperature digit and decimal part
therm_read_temperature(&temperature, &decimal); //Gets the current temp and sets the variables to the value
float temp = SomeFunction(digit, decimal); //This could be a expression also.
return temp;
}
////UPDATE/// - July 5th
I was able to get the source code instead of leveraging just the library. I posted it in this GIST DS12B20.c.
temperature[0]=therm_read_byte();
temperature[1]=therm_read_byte();
therm_reset();
//Store temperature integer digits and decimal digits
digit=temperature[0]>>4;
digit|=(temperature[1]&0x7)<<4;
//Store decimal digits
decimal=temperature[0]&0xf;
decimal*=THERM_DECIMAL_STEPS_12BIT;
*digit_part = digit;
*decimal_part = decimal;
Although the function will not force us to return separate parts as digit and decimal, reading from the temperature sensor seems to require this (unless i'm missing something and it can be retrieved as a float).
I think the original question still stands as what is the optimal way to make this into a float in C (this is for use with AVR and an 8bit microprocessor, making optimization key) using the two parts or to be able to retrieve it directly as a float.
What you are really running into is using fixed-point numbers. These can be represented in two ways: either as a single integer with a known magnitude or multiplier (ie. "tenths", "hundredths", "thousandths", and so on; example: value from a digital scale in ten-thousandths of a gram, held in a 32-bit integer -- you divide by 10000 to get grams), or as two integers, with one holding the "accumulated" or "integer" value, and the other holding the "fractional" value.
Take a look at the <stdfix.h> header. This declares types and functions to hold these fixed-point numbers, and perform math with them. When adding fractional parts, for example, you have to worry about rolling into the next whole value, for which you then want to increment the accumulator of the result. By using the standard functions you can take advantage of built-in processor capabilities for fixed-point math, such as those present in the AVR, PIC and MPS430 microcontrollers. Perfect for temperature sensors, GPS receivers, scales (balances), and other sensors that have rational numbers but only integer registers or arithmetic.
Here is an article about it: "Fixed Point Extensions to the C Programming Language", https://sestevenson.wordpress.com/2009/09/10/fixed-point-extensions-to-the-c-programming-language/
To quote a portion of that article:
I don’t think the extensions simplify the use of fixed types very
much. The programmer still needs to know how many bits are allocated
to integer and fractional parts, and how the number and positions of
bits may change (during multiplication for example). What the
extensions do provide is a way to access the saturation and rounding
modes of the processor without writing assembly code. With this level
of access, it is possible to write much more efficient C code to
handle these operations.
Scott G. Hall
Raleigh, NC, USA
Your question contains a wrong assumption.
If you're given a decimal string and want a floating-point value, the first step should generally not be to turn it into two integers.
For instance, consider the numbers 2.1 and 2.01. What's the "decimal part" in each case? 1 and 01? Both of those equal 1. That's no good.
The only case in which this approach makes any sense is where you have a fixed number of places after the decimal point -- in which case maybe 2.1 turns into (2,1000) and 2.01 turns into (2,100), or something. But unless you've got a positive reason for doing that (which I strongly doubt) you should not do it this way.
In particular, unless therm_read_temperature is a function someone else is providing you with and whose interface you can't influence, you should make that function behave differently -- e.g., just returning a float. (If it is a function someone else is providing and whose interface you can't influence, then to get a useful answer here you'll need to tell us exactly what it's defined to do.)
Related
Is it possible to take a decimal number as input from the user without using float/double data type?
And this number has to be used further for calculation.
I'm making a function to calculate the square root of a number without using cmath library, I'm doing this for a DSP that doesn't have FPU so I can't use float/double.
If I will be using string to take input as decimal number from the user then how can I convert it into a number, and if it is converted into a number then what should be the return type of the square root function (the root will be a fractional number)?
If possible please suggest some alternative way instead of stings.
I know it is related to fixed point arithmetic but I don't know how to implement it in c++.
Foreword: Compilers can implement software floating point operations for CPU's which do not have floating point hardware, so it is often not a problem to use float and double on such systems.
I recommend using the standard fundamental floating point types as long as they are supported by your compiler.
Is it possible to take a decimal number as input from the user without using float/double data type?
Yes. User input is done using character streams. You can read input into a string without involving any numeric type.
And this number has to be used further for calculation.
To do calculation, you must first decide how you would like represent the number. There are several alternatives to hardware floating point:
Fixed point: Use the integer 100 to represent 0.0100 for example.
Software floating point: Use one integer to represent mantissa, another integer to represent the exponent and a boolean to represent sign.
Rational numbers: Use one integer to represent nominator and another to represent denominator.
Probably many others...
Each of these have different implemenations for different arithmetic operations.
Fixed point is the simplest and probably most efficient, but has both small range and poor precision near zero (well, equal precision across the entire range but poor compared to floating point which has high precision near zero and very poor precision far from zero).
Software floating point allows potentially reproducing hardware behaviour by following the ubiquitous IEEE-754 standard.
Rational numbers have problems with overflowing as well as redundant representations. I don't think they are used much except with arbitrary precision integers.
(the root will be a fractional number)
Technically, most roots are irrational and thus not fractional. But since irrational numbers are not representable by computers (except in symbolic form), the best we can achieve is some fractional number close to the actual root.
Here's my solution.
In summary, 12345 has
5 1's units,
4 10's units,
3 100's units,
2 1000's units and
1 10,000's units.
What's below is verbose description of doing this in C++. It doesn't detect every possible error like the user typing MAXINT+1 and the output returning -MAXINT; fgets has some issues regarding buffer overflows but you probably take input from some source within the greater program anyhow but just to show the principal.
int error=0; //error condition if you can't indicate err by -1 or such
int output=0;
char input[256];
fgets(input,255,stdin); //get input
//arrange the input for our purpose
input=trim(input); //trim whitespace
input=strrev(input); //reverse it (12345 now equals 54321)
//set up a loop
int len=strlen(input); //length of output
int column=0; //iterates through each char in input
int units=1; //we start with the 1's column and then 10s, 100's, etc
while (column < len) {
int val=input[column];
//nitty gritty
if ((val>'0')&&(val<'9')){ //note the quotes amounting to int values 48 and 57
val-=48; //convert the ascii/utf-8 digit into its intval
val*=units; //multiply it by the units of the column 1s,10s,100s,etc
output+=val; //add it to the output
units*=10; //end of this iteration, set up for next unit scale
}
else if (val=='-'){ //test for the unique circumstance of the minus sign
output*=-1;
break;
}
else if (val=='+'){ //test if the user is a tit and puts the positive sign
break;
}
else{
error=1; //the user typed a character not conforming to an intval
}
}
EDIT: I realise I didn't read the full question and there's also a need for a square root function. When FPU's were added extras in 8-bit, 8086, 286 and 386SX days, the standard technique was to store a look up table in memory. There are mathematical functions you can use involving natural logarithms but the expense involved in processor time was such that it was cheaper just to make a table with each value that you wanted to sqrt and lookup the table for the value.
Alright so I am trying to truncate actual values from a double with a given number of digits precision (total digits before and after, or without, decimal), not just output them, not just round them. The only built in functions I found for this truncates all decimals, or rounds to given decimal precision.
Other solutions I have found online, can only do it when you know the number of digits before the decimal, or the entire number.
This solution should be dynamic enough to handle any number. I whipped up some code that does the trick below, however I can't shake the feeling there is a better way to do it. Does anyone know of something more elegant? Maybe a built in function that I don't know about?
I should mention the reason for this. There are 3 different sources of observed values. All 3 of these sources agree to some level in precision. Such as below, they all agree within 10 digits.
4659.96751751236
4659.96751721355
4659.96751764253
However I need to only pull from 1 of the sources. So the best approach, is to only use up to the precision all 3 sources agree on. So its not like I am manipulating numbers and then need to truncate precision, they are observed values. The desired result is
4659.967517
double truncate(double num, int digits)
{
// check valid digits
if (digits < 0)
return num;
// create string stream for full precision (string conversion rounds at 10)
ostringstream numO;
// read in number to stream, at 17+ precision things get wonky
numO << setprecision(16) << num;
// convert to string, for character manipulation
string numS = numO.str();
// check if we have a decimal
int decimalIndex = numS.find('.');
// if we have a decimal, erase it for now, logging its position
if(decimalIndex != -1)
numS.erase(decimalIndex, 1);
// make sure our target precision is not higher than current precision
digits = min((int)numS.size(), digits);
// replace unwanted precision with zeroes
numS.replace(digits, numS.size() - digits, numS.size() - digits, '0');
// if we had a decimal, add it back
if (decimalIndex != -1)
numS.insert(numS.begin() + decimalIndex, '.');
return atof(numS.c_str());
}
This will never work since a double is not a decimal type. Truncating what you think are a certain number of decimal digits will merely introduce a new set of joke digits at the end. It could even be pernicious: e.g. 0.125 is an exact double, but neither 0.12 nor 0.13 are.
If you want to work in decimals, then use a decimal type, or a large integral type with a convention that part of it holds a decimal portion.
I disagree with "So the best approach, is to only use up to the precision all 3 sources agree on."
If these are different measurements of a physical quantity, or represent rounding error due to different ways of calculating from measurements, you will get a better estimate of the true value by taking their mean than by forcing the digits they disagree about to any arbitrary value, including zero.
The ultimate justification for taking the mean is the Central Limit Theorem, which suggests treating your measurements as a sample from a normal distribution. If so, the sample mean is the best available estimate of the population mean. Your truncation process will tend to underestimate the actual value.
It is generally better to keep every scrap of information you have through the calculations, and then remember you have limited precision when outputting results.
As well as giving a better estimate, taking the mean of three numbers is an extremely simple calculation.
In fortran I have to round latitude and longitude to one digit after decimal point.
I am using gfortran compiler and the nint function but the following does not work:
print *, nint( 1.40 * 10. ) / 10. ! prints 1.39999998
print *, nint( 1.49 * 10. ) / 10. ! prints 1.50000000
Looking for both general and specific solutions here. For example:
How can we display numbers rounded to one decimal place?
How can we store such rounded numbers in fortran. It's not possible in a float variable, but are there other ways?
How can we write such numbers to NetCDF?
How can we write such numbers to a CSV or text file?
As others have said, the issue is the use of floating point representation in the NetCDF file. Using nco utilities, you can change the latitude/longitude to short integers with scale_factor and add_offset. Like this:
ncap2 -s 'latitude=pack(latitude, 0.1, 0); longitude=pack(longitude, 0.1, 0);' old.nc new.nc
There is no way to do what you are asking. The underlying problem is that the rounded values you desire are not necessarily able to be represented using floating point.
For example, if you had a value 10.58, this is represented exactly as 1.3225000 x 2^3 = 10.580000 in IEEE754 float32.
When you round this to value to one decimal point (however you choose to do so), the result would be 10.6, however 10.6 does not have an exact representation. The nearest representation is 1.3249999 x 2^3 = 10.599999 in float32. So no matter how you deal with the rounding, there is no way to store 10.6 exactly in a float32 value, and no way to write it as a floating point value into a netCDF file.
YES, IT CAN BE DONE! The "accepted" answer above is correct in its limited range, but is wrong about what you can actually accomplish in Fortran (or various other HGL's).
The only question is what price are you willing to pay, if the something like a Write with F(6.1) fails?
From one perspective, your problem is a particularly trivial variation on the subject of "Arbitrary Precision" computing. How do you imagine cryptography is handled when you need to store, manipulate, and perform "math" with, say, 1024 bit numbers, with exact precision?
A simple strategy in this case would be to separate each number into its constituent "LHSofD" (Left Hand Side of Decimal), and "RHSofD" values. For example, you might have an RLon(i,j) = 105.591, and would like to print 105.6 (or any manner of rounding) to your netCDF (or any normal) file. Split this into RLonLHS(i,j) = 105, and RLonRHS(i,j) = 591.
... at this point you have choices that increase generality, but at some expense. To save "money" the RHS might be retained as 0.591 (but loose generality if you need to do fancier things).
For simplicity, assume the "cheap and cheerful" second strategy.
The LHS is easy (Int()).
Now, for the RHS, multiply by 10 (if, you wish to round to 1 DEC), e.g. to arrive at RLonRHS(i,j) = 5.91, and then apply Fortran "round to nearest Int" NInt() intrinsic ... leaving you with RLonRHS(i,j) = 6.0.
... and Bob's your uncle:
Now you print the LHS and RHS to your netCDF using a suitable Write statement concatenating the "duals", and will created an EXACT representation as per the required objectives in the OP.
... of course later reading-in those values returns to the same issues as illustrated above, unless the read-in also is ArbPrec aware.
... we wrote our own ArbPrec lib, but there are several about, also in VBA and other HGL's ... but be warned a full ArbPrec bit of machinery is a non-trivial matter ... lucky you problem is so simple.
There are several aspects one can consider in relation to "rounding to one decimal place". These relate to: internal storage and manipulation; display and interchange.
Display and interchange
The simplest aspects cover how we report stored value, regardless of the internal representation used. As covered in depth in other answers and elsewhere we can use a numeric edit descriptor with a single fractional digit:
print '(F0.1,2X,F0.1)', 10.3, 10.17
end
How the output is rounded is a changeable mode:
print '(RU,F0.1,2X,RD,F0.1)', 10.17, 10.17
end
In this example we've chosen to round up and then down, but we could also round to zero or round to nearest (or let the compiler choose for us).
For any formatted output, whether to screen or file, such edit descriptors are available. A G edit descriptor, such as one may use to write CSV files, will also do this rounding.
For unformatted output this concept of rounding is not applicable as the internal representation is referenced. Equally for an interchange format such as NetCDF and HDF5 we do not have this rounding.
For NetCDF your attribute convention may specify something like FORTRAN_format which gives an appropriate format for ultimate display of the (default) real, non-rounded, variable .
Internal storage
Other answers and the question itself mention the impossibility of accurately representing (and working with) decimal digits. However, nothing in the Fortran language requires this to be impossible:
integer, parameter :: rk = SELECTED_REAL_KIND(radix=10)
real(rk) x
x = 0.1_rk
print *, x
end
is a Fortran program which has a radix-10 variable and literal constant. See also IEEE_SELECTED_REAL_KIND(radix=10).
Now, you are exceptionally likely to see that selected_real_kind(radix=10) gives you the value -5, but if you want something positive that can be used as a type parameter you just need to find someone offering you such a system.
If you aren't able to find such a thing then you will need to work accounting for errors. There are two parts to consider here.
The intrinsic real numerical types in Fortran are floating point ones. To use a fixed point numeric type, or a system like binary-coded decimal, you will need to resort to non-intrinsic types. Such a topic is beyond the scope of this answer, but pointers are made in that direction by DrOli.
These efforts will not be computationally/programmer-time cheap. You will also need to take care of managing these types in your output and interchange.
Depending on the requirements of your work, you may find simply scaling by (powers of) ten and working on integers suits. In such cases, you will also want to find the corresponding NetCDF attribute in your convention, such as scale_factor.
Relating to our internal representation concerns we have similar rounding issues to output. For example, if my input data has a longitude of 10.17... but I want to round it in my internal representation to (the nearest representable value to) a single decimal digit (say 10.2/10.1999998) and then work through with that, how do I manage that?
We've seen how nint(10.17*10)/10. gives us this, but we've also learned something about how numeric edit descriptors do this nicely for output, including controlling the rounding mode:
character(10) :: intermediate
real :: rounded
write(intermediate, '(RN,F0.1)') 10.17
read(intermediate, *) rounded
print *, rounded ! This may look not "exact"
end
We can track the accumulation of errors here if this is desired.
The `round_x = nint(x*10d0)/10d0' operator rounds x (for abs(x) < 2**31/10, for large numbers use dnint()) and assigns the rounded value to the round_x variable for further calculations.
As mentioned in the answers above, not all numbers with one significant digit after the decimal point have an exact representation, for example, 0.3 does not.
print *, 0.3d0
Output:
0.29999999999999999
To output a rounded value to a file, to the screen, or to convert it to a string with a single significant digit after the decimal point, use edit descriptor 'Fw.1' (w - width w characters, 0 - variable width). For example:
print '(5(1x, f0.1))', 1.30, 1.31, 1.35, 1.39, 345.46
Output:
1.3 1.3 1.4 1.4 345.5
#JohnE, using 'G10.2' is incorrect, it rounds the result to two significant digits, not to one digit after the decimal point. Eg:
print '(g10.2)', 345.46
Output:
0.35E+03
P.S.
For NetCDF, rounding should be handled by NetCDF viewer, however, you can output variables as NC_STRING type:
write(NetCDF_out_string, '(F0.1)') 1.49
Or, alternatively, get "beautiful" NC_FLOAT/NC_DOUBLE numbers:
beautiful_float_x = nint(x*10.)/10. + epsilon(1.)*nint(x*10.)/10./2.
beautiful_double_x = dnint(x*10d0)/10d0 + epsilon(1d0)*dnint(x*10d0)/10d0/2d0
P.P.S. #JohnE
The preferred solution is not to round intermediate results in memory or in files. Rounding is performed only when the final output of human-readable data is issued;
Use print with edit descriptor ‘Fw.1’, see above;
There are no simple and reliable ways to accurately store rounded numbers (numbers with a decimal fixed point):
2.1. Theoretically, some Fortran implementations can support decimal arithmetic, but I am not aware of implementations that in which ‘selected_real_kind(4, 4, 10)’ returns a value other than -5;
2.2. It is possible to store rounded numbers as strings;
2.3. You can use the Fortran binding of GIMP library. Functions with the mpq_ prefix are designed to work with rational numbers;
There are no simple and reliable ways to write rounded numbers in a netCDF file while preserving their properties for the reader of this file:
3.1. netCDF supports 'Packed Data Values‘, i.e. you can set an integer type with the attributes’ scale_factor‘,’ add_offset' and save arrays of integers. But, in the file ‘scale_factor’ will be stored as a floating number of single or double precision, i.e. the value will differ from 0.1. Accordingly, when reading, when calculating by the netCDF library unpacked_data_value = packed_data_value*scale_factor + add_offset, there will be a rounding error. (You can set scale_factor=0.1*(1.+epsilon(1.)) or scale_factor=0.1d0*(1d0+epsilon(1d0)) to exclude a large number of digits '9'.);
3.2. There are C_format and FORTRAN_format attributes. But it is quite difficult to predict which reader will use which attribute and whether they will use them at all;
3.3. You can store rounded numbers as strings or user-defined types;
Use write() with edit descriptor ‘Fw.1’, see above.
How can I test how many significant figures a specified float has in c++? say if i write:
sigfigs(x);
x being the value of the float,
it would set an integer value to y, the number of sigfigs
how can i write a void function this way
this has been bugging me for some time, any answers appreciated
btw mysticial this is asking for a code to find the amount of sig figs in a float, not how many there are like the one you linked to as a duplicate -.-
This is a bit tricky, because as you should already know, floating-point numbers are often not exact, but rather some approximation of a number. For example, 10.1 ends up as 10.09999.... A double has about 15 digits of precision, so 15 is the largest value your sigfigs() function could reasonably return. And it will need to be overloaded for double and float, because of course float has only half as many digits of precision:
int sigfigs(double x); // returns 1 to 15
int sigfigs(float x); // returns 1 to 7
Now there may be more clever mathematical ways to do this, but one idea is:
int sigfigs(double x) {
int mag = log10(fabs(x));
double div = pow(10, mag);
char str[20];
int wrote = snprintf(str, sizeof(str), "%.15g", x/div);
return std::count_if(str, str + wrote, isdigit);
}
This is definitely missing some cases, but I think captures the idea: we first normalize large/small numbers so that we end up with something close to 1, then we print it with a suitable format string to allow the maximum usable precision to be displayed, then we count how many digits there are.
There are notable boundary-condition bugs at 0, 10, etc., which are left as an exercise to correct. Serendipitously, NAN produces 0 which is good; +/- infinity also produce 0.
One final note; this does not strictly conform to the usual definition of significant figures. In particular, trailing zeros after a decimal place are not accounted for, because there is no way to do so given only a double or float. For example, textual inputs of 10 and 10.00000 produce bitwise-identical results from atof(). Therefore, if you need a complete solution conforming to the academic definition of sigfigs, you will need to implement a user-defined type containing e.g. a double and an int for the sigfigs. You can then implement all the arithmetic operators to carry the sigfigs throughout your calculations, following the usual rules.
Are you trying to determine the number of bits of precision in a floating point number or the number of significant figures in a variable? C and C++ do not generally specify the format to be used for float and double, but if you know the floating point format in which the number is stored and processed, you can determine the number of bits of precision. Most hardware these days uses IEEE 754 format. Looking through the definition would be a good place to start.
Number of significant figures is an entirely different question. Definition of significant figures includes a notion of how many figures are actually meaningful, as opposed to the number of figures available due to the floating point representation. For example, if you sample a voltage with a 12-bit A/D converter (and good enough analog design that all the bits are significant) then the data that you read will have 12 significant bits, and storing it in a format with higher precision does not increase the number of significant figures. For example, you store it in a 16-bit integer or a 32-bit IEEE 754 floating point number, depending on what you plan to do with the data. In either case you still only have 12 significant bits, even though a 32-bit float has a 24-bit mantissa.
Goldberg's What Every Computer Scientist Should Now About Floating-Point Arithmetic pretty thoroughly covers the issue if significant figures and floating-point arithmetic.
This question already has answers here:
Why do I see a double variable initialized to some value like 21.4 as 21.399999618530273?
(14 answers)
Closed 6 years ago.
I am facing a problem and unable to resolve it. Need help from gurus. Here is sample code:-
float f=0.01f;
printf("%f",f);
if we check value in variable during debugging f contains '0.0099999998' value and output of printf is 0.010000.
a. Is there any way that we may force the compiler to assign same values to variable of float type?
b. I want to convert float to string/character array. How is it possible that only and only exactly same value be converted to string/character array. I want to make sure that no zeros are padded, no unwanted values are padded, no changes in digits as in above example.
It is impossible to accurately represent a base 10 decimal number using base 2 values, except for a very small number of values (such as 0.25). To get what you need, you have to switch from the float/double built-in types to some kind of decimal number package.
You could use boost::lexical_cast in this way:
float blah = 0.01;
string w = boost::lexical_cast<string>( blah );
The variable w will contain the text value 0.00999999978. But I can't see when you really need it.
It is preferred to use boost::format to accurately format a float as an string. The following code shows how to do it:
float blah = 0.01;
string w = str( boost::format("%d") % blah ); // w contains exactly "0.01" now
Have a look at this C++ reference. Specifically the section on precision:
float blah = 0.01;
printf ("%.2f\n", blah);
There are uncountably many real numbers.
There are only a finite number of values which the data types float, double, and long double can take.
That is, there will be uncountably many real numbers that cannot be represented exactly using those data types.
The reason that your debugger is giving you a different value is well explained in Mark Ransom's post.
Regarding printing a float without roundup, truncation and with fuller precision, you are missing the precision specifier - default precision for printf is typically 6 fractional digits.
try the following to get a precision of 10 digits:
float amount = 0.0099999998;
printf("%.10f", amount);
As a side note, a more C++ way (vs. C-style) to do things is with cout:
float amount = 0.0099999998;
cout.precision(10);
cout << amount << endl;
For (b), you could do
std::ostringstream os;
os << f;
std::string s = os.str();
In truth using the floating point processor or co-processor or section of the chip itself (most are now intergrated into the CPU), will never result in accurate mathematical results, but they do give a fairly rough accuracy, for more accurate results, you could consider defining a class "DecimalString", which uses nybbles as decimal characters and symbols... and attempt to mimic base 10 mathematics using strings... in that case, depending on how long you want to make the strings, you could even do away with the exponent part altogether a string 256 can represent 1x10^-254 upto 1^+255 in straight decimal using actual ASCII, shorter if you want a sign, but this may prove significantly slower. You could speed this by reversing the digit order, so from left to right they read
units,tens,hundreds,thousands....
Simple example
eg. "0021" becomes 1200
This would need "shifting" left and right to make the decimal points line up before routines as well, the best bet is to start with the ADD and SUB functions, as you will then build on them in the MUL and DIV functions. If you are on a large machine, you could make them theoretically as long as your heart desired!
Equally, you could use the stdlib.h, in there are the sprintf, ecvt and fcvt functions (or at least, there should be!).
int sprintf(char* dst,const char* fmt,...);
char *ecvt(double value, int ndig, int *dec, int *sign);
char *fcvt(double value, int ndig, int *dec, int *sign);
sprintf returns the number of characters it wrote to the string, for example
float f=12.00;
char buffer[32];
sprintf(buffer,"%4.2f",f) // will return 5, if it is an error it will return -1
ecvt and fcvt return characters to static char* locations containing the null terminated decimal representations of the numbers, with no decimal point, most significant number first, the offset of the decimal point is stored in dec, the sign in "sign" (1=-,0=+) ndig is the number of significant digits to store. If dec<0 then you have to pad with -dec zeros pror to the decimal point. I fyou are unsure, and you are not working on a Windows7 system (which will not run old DOS3 programs sometimes) look for TurboC version 2 for Dos 3, there are still one or two downloads available, it's a relatively small program from Borland which is a small Dos C/C++ edito/compiler and even comes with TASM, the 16 bit machine code 386/486 compile, it is covered in the help files as are many other useful nuggets of information.
All three routines are in "stdlib.h", or should be, though I have found that on VisualStudio2010 they are anything but standard, often overloaded with function dealing with WORD sized characters and asking you to use its own specific functions instead... "so much for standard library," I mutter to myself almost each and every time, "Maybe they out to get a better dictionary!"
You would need to consult your platform standards to determine how to best determine the correct format, you would need to display it as a*b^C, where 'a' is the integral component that holds the sign, 'b' is implementation defined (Likely fixed by a standard), and 'C' is the exponent used for that number.
Alternatively, you could just display it in hex, it'd mean nothing to a human, though, and it would still be binary for all practical purposes. (And just as portable!)
To answer your second question:
it IS possible to exactly and unambiguously represent floats as strings. However, this requires a hexadecimal representation. For instance, 1/16 = 0.1 and 10/16 is 0.A.
With hex floats, you can define a canonical representation. I'd personally use a fixed number of digits representing the underlying number of bits, but you could also decide to strip trailing zeroes. There's no confusion possible on which trailing digits are zero.
Since the representation is exact, the conversions are reversible: f==hexstring2float(float2hexstring(f))