req. code for convert float to ascii
 

Hi,

Floating-point stuff isn't my cup of tea at all, but sometimes i find fp values in existing code and can't do much with them.
It appears the OS does not provide anything to show these.
I know C standard lib can do this, but using C is not ideal for me.

So if someone here has short, easy-to-use, accurate float display routine that does not have external dependencies, you would make someone happy :great

Note that if you wanted a new idea for a coding contest, this may be it too :D

32-bit floats should be enough for now, but other sizes are welcome too.

Count me off, not even for me a right cup of tea :)
But I'm curious about it.

I guess only integer instructions are accepted..

Yes but 68020+ is ok for me so extracting fields should be easy.

you mean displaying a float as text?

I would create a simple SAS-C program, disassemble it and pick on the conversion part.

If this is for debugging rather than presentation, I'd just show them as raw hexadecimal. Plenty of tools exist that can show the IEEE interpretation of a 32 or 64-bit hexadecimal. Next up the complexity scale is showing it in decimal scientific notation but still as a power of two exponent. Generally it will always be a decimal strictly between 0 and 0.5 with some power of two exponent. Thats only about as complicated as converting integer to ASCII.

If it's just for general presentation in other contexts and you need to display it as a decimal with power of ten exponent... Well that's going to more complicated. I would probably reconsider my position on dependencies in this case.

Yes. Something that shows f.e. $3f400000 as "0.75".


This is my fallback solution.
It's not as easy as it looks because navigating in disassembled C library code inside of a program isn't exactly straightforward. It may also have lots of options i don't need, or depend on external libraries.
Source for such C lib code would help, though.



I already have raw hex, but now i want to get something more handy and general purpose.


Probably, but i need something easy to integrate in programs. Then it would be my library code i can reuse at will.


Currently I can only extract integer and fractional part and show them as decimal values for a coarse evaluation but it is not ideal. I lose range and accuracy.


Ideally this is what i want, possibly with a few formatting options. :spin

But hey, if it was easy, i'd just have done it and not opened a thread here ;)

That's right, the Os does not include such functions, for reasons beyond my understanding.


You find functions here:


http://aminet.net/dev/lib/ThorLib.lha


This is a link library containing a couple of support functions, in particular converting between various floating point types and ASCII.


Link library means that only small segments of the entire library appear in your binary, not the whole thing.


In particular, in thor/conversions.h, you find the following:


which converts an extended precision (80 bit) number to ASCII, and you also find


which converts a 32 bit single precision (mathieeesingbas) number to extended precision.


With those two, you get the functionality you need.


There are also some lower level functions that give you a bit more freedom in formatting.

This is more or less the same as what jotd suggested...

Is source code available ?


What about the size of the output buffer ?

I'm wondering... are you interested in understanding how this conversion works? In such case, the source code is only partially interesting because it's mostly on mathematics and not so on the code which contains some "magic constants" that are not immediately obvious. If so, I can provide you the details, and you can then implement it yourself.


If you're only looking for a function that is doing its job, then you would not need sources. Just link to it, and you're be happy.



It's BTW assembler, there is no really good way to do this conversion from C.



32 bytes should be enough. The precision is 16 digits if I recall, plus the exponent.

Yes, the details would be fine.
Ideally the method must not use floats itself, just extract exponent and mantissa (which is easy) then do its job on integers.

Ok then, I'll walk you through. It will be a series of posts then because the entire thing is a bit too long to fit into a single post (plus, it will not be very helpful in this form). Yes, it is surely all integer, it does not need any of the math libraries and neither the FPU. The math libraries do not provide you with the precision I wanted, and the FPU may not be available.

The general outline is the following: First, the main function AToX() is a small wrapper around a lower level function which extracts the sign, the decimal exponent of the number in binary form, and the mantissa as a sequence of ASCII digits. From that, one can clearly build the desired string by placing the decimal dot in the right place and adjusting the exponent, plus some "optical rounding" if desired. This function also covers some special cases such as 0, +INF, -INF and the NANs.

The lower levels are more interesting and I will provide some snippets one after another.

First step is to extract from the floating point number an approximation of the decadic logarithm of the number. This takes the binary exponent and the leading bits of the mantissa to compute an approximation of log10(input). This is where the "magic constants" are. This is an approximation that is fixed up later.

Second step is to normalize the input such that the mantissa comes between 0.1 and 1. This takes the log10() from the first step, then runs into a multiplication chain which multiplies the number by powers of 10 of the form 10^(2^n), using the binary expansion of the exponent from the first step. That is the long but algorithmically not so complex part.

Third step is to perform some rounding and normalization of the resulting mantissa, i.e. to ensure that it is really between 0.1 and 1, plus fixup of the exponent from the first step.

The last step is just continuously multiplying the extracted mantissa by 10, and always removing the next decimal digit from its integer part, storing it in the output buffer. That is also fairly trivial.

The entire conversion, however, goes over several subroutines, so it is a bit lengthy. I'll start with the next post with the first step.

Why not just convert to FFP and then use fpa to convert?

http://amigadev.elowar.com/read/ADCD.../node015B.html

Edit: it's fpa not fta.

Here is the first part of the job. Creating a normalized representation.

This code I actually took from SoftIEEE because I added the comments there, but it performs the same function. The contents of (a0) are a positive extended precision number. The function up in the call stack removes the sign and filtered already 0, INF and NAN out and converted them right away.

The purpose of the function above is to normalize the input number to one that is between 1 and 0.1, and an approximation of the decimal exponent is returned in d0.

More on TimesIntPowTen later, even though the function itself is rather trivial.

Here's the code I use in my disassember, loosely based on a disassembly of SASC printf.

The main 32 bit routine is shown below. Complete source code for single/double/extended formats is attached.

Note that while this code seems to work OK I haven't thoroughly tested it. Accuracy is not as good as I would like, and some 'corner' cases are not handled well. Floor and ceiling values for 64 and 80 bit format are hard coded because they take too long to calculate. Rounding is a bit iffy. I don't even try to handle packed decimals or subnormals.

Getting floating point 'right' under all circumstances is surprisingly difficult. I recently discovered that the assembler I use doesn't produce correct floating point numbers, so I can't even disassemble some code and then reassemble it to check for correct conversion. There are lots of online converters with inscrutable code that assume you have a particular environment (javascript, Intel fpu etc.) whose accuracy cannot be verified. I am not by any means an expert on floating point formats. However when several online calculators can't even agree (let alone show proof that their algorithms are correct) it doesn't inspire confidence.

Good lord, what an absolute pain :scream Quite the opposite of converting integers to ASCII :rolleyes

Next function in row is TimesIntPowTen, which multiplies a number with a power of 10. This is required to get the mantissa normalized to the interval [0.1,1] (or mostly), given the log10() approximation from yesterday's post.

ExtMul is an extended precision multiplication in 80 bits. It is not very interesting, it just multiplies the two 64 bit mantissas and adds the exponents, and fixes the exponent offset. I believe I can leave that to the reader.

The interesting part here is that I do not use a continuous multiplication by 10 (or 1/10) for normalization because that would just accumulate errors. Instead, an arbitrary power of 10 (10^n) is split up into multiplications with powers of 10 to powers of 2, i.e. write

where b_i is either 0 or 1, which is here in the carry after shifting n in register d2 to the right.

The tables PowTenTable and InvPowTen contain numbers of the form 10^(2^i) with i from 1 to 12 and 10^(-2^i) also from i=1 to 12, corresponding to the range of extended precision. It is probably no coincidence that the 68882 contains the same numbers in its constant ROM, probably for exactly the same purpose.

To be continued...

Yes, it is unfortunately quite involved, expecially if you want to keep the precision high and waste as little bits as possible. For double precision input (and this was the target development of my functions) you need extended precision to avoid "wasting precision". For extended precision, you would again need some extra bits, but even the 68882 does not do that and has only a precision of ~8ulp for its extended to packed decimal conversion. This conversion function is almost the same as the conversion to ASCII.


I still wonder why CBM did not include that in mathieeedoubtrans. The latter library is more or less a direct copy from the Greenhill C compiler CBM used back then (and for the compilation of intuition up to 3.1) until they switched to lattice (which then became SAS/C). The Greenhill C math library surely included something similar, but the function is probably poor to isolate since it requires several subroutines (as mine does).



The amiga.lib fpa function is rather low quality (along with a lot of other stuff in that library) and not very precise.


There is something similar in Aztec C, but their implementation is comparibly poor and of low precision. SAS/C is ok mathematically, the only thing I did not like is that they perform some "optical rounding", i.e. their function aims at generating "nice" numbers such that 0.9999999 is displayed as 1.0, even though it is not 1.0. I did not like that.

There's the old Cephes software floating point library. Has libraries for single precision all the way up to 336 bit floats: https://netlib.org/cephes/ (I use those 336 bit floats with Lua on my A1200 as a calculator)

Yes, this is what i asked for. Thanks.


This is because it can not really be 'right'. Contrary to integer, float does not provide exactness. This is the main reason why i don't use floats whenever i can do otherwise.
My goal here is to get something that does a 'good enough' job (i.e. is at worse slightly off but never completely wrong).



Perhaps this can be made an option.
Sure that showing 0.9999999 as 1.0 is wrong, but then what about 0.1 ? Without a little rounding, it is never shown as 0.1 as this number can not be represented exactly with a binary float.

So here comes the rest. The remaining code removes the remaining binary exponent, then adds 0.5ulp of the output precision, and then uses a long shift register, multiplying the mantissa with 10 each times and copying the integer part to the target buffer.

It expects the floating point number in a0 and generates results in a1, the number of digits in d0.
...and that it is. All you need to do now is to take the integer exponent from the first step, from that compute where the decimal dot in the output buffer is, and "format" the mantissa generated by the above function according to your likes. If you want to, you can include some "optical rounding" there.
The higher level function for that is again not particularly interesting, it is pretty much boilerplate code and does not require assembly.