Can anybody point me to reference material on converting a floating point value (IEEE 32-bit) to ASCII? I googled c.a.e and this question has come up many times. The answer always seems to be:
"It's really hard to do it generally, but here's how you do it if you always want two decimal places and the value is between 0 and 10000."
There must be some info available on the best way to do it in the more general case.
--
Grant Edwards grante Yow! Join the PLUMBER'S
at UNION!!
visi.com
sprintf spings to mind.
It's not diificult if you look carefully at the IEEE floating-point format. A few years ago I wrote ADSP-218x assembler routines to convert between IEEE, fixed-point and ADI's two-word floating-point. You could always use sscanf if you are writing in C. 8-)
Leon
-- Leon Heller, G1HSM Email: aqzf13@dsl.pipex.com My low-cost Philips LPC210x ARM development system: http://www.geocities.com/leon_heller/lpc2104.html
Plauger's "The Standard C Library" gives a complete implementation of .*printf along with reasonable explanations of how it works. He might have a different definition of "best" than you do, though.
Regards,
-=Dave
-- Change is inevitable, progress is not.
Let's assume I don't have sprintf() available.
The only one I can lay hands on is in newlib, and it comes with huge overhead to impure pointers and whatnot.
-- Grant Edwards grante Yow! I don't know WHY I at said that... I think it visi.com came from the FILLINGS inmy read molars...
Really? I'm quite familar with the IEEE floating point format, having written converters to/from various other FP formats (VAX, TI, etc.). Perhaps I'm just stupid, but I just don't see a "not difficult" way of converting to a base-10 text representation.
I am writing in C, but sscanf goes the wrong direction, and newlib's sprintf has _way_ too much overhead.
[Why do so many people assume that if you're writing in C, you've got complete Posix run-time library support?]
--
Grant Edwards grante Yow! Edwin Meese made me
at wear CORDOVANS!!
visi.com
Thanks! You're the first one to come up with a useful answer.
Probably.
It seems to me that there are two general routes to take:
1) Assume nothing about machine representation: multiply/divide by powers of 10 then converting to integer. 2) Do something fancy taking advantage of assuming IEEE 32-bit representation.
--
Grant Edwards grante Yow! I'm having an
at EMOTIONAL OUTBURST!! But,
visi.com uh, WHY is there a WAFFLE
in my PAJAMA POCKET??
No. Because there *is* no such thing as "the best" way in the more general case. The best way can only be defined sensibly after you've removed pretty much *all* the generality. You pick a set of target platforms, a supported numerical range, the output precision, a set of features you need to have (%f like only, or %g like only? Freely selectable precisions?), and what your speed/size compromise is going to be. Then you can begin to ask about how best to achieve exactly that.
There's a world of difference between a platform-specific, ugly, in-house-usage-only, fixed-format output routine for a strictly limited purpose, on one end, and the fully-fledged Standard C exportable library function sprintf() whose implementation you like so little.
-- Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de) Even if all the snow were burnt, ashes would remain.
Hi, sprintf is part of the standard library so it should be there. It is a big module and not very fast but so are all the other floating point routines. If your project is hardware / speed limited then you really should consider upgrading or not using floating point at all.
Do you want scientific notation (1.234E05) or a value with a specific number of decimals ?
The scientific notation is quite easy, since you just have to adjust the value to be in the range 0.1 =
1.0, in which case the sum must be divided by 10.0 and the exponent updated.Now it is quite easy to extract digits starting from the left end of the value x.
I think Wirth published this kind of algorithm in some of his books promoting Pascal, apparently for some Burroughs computer, but it should be adaptable to other floating point formats.
Paul
Hello, Grant! You wrote on 19 Feb 2004 22:24:01 GMT:
GE> Can anybody point me to reference material on converting a GE> floating point value (IEEE 32-bit) to ASCII? I googled c.a.e GE> and this question has come up many times.
Try googling for dtoa() instead - that's the internal function which does all the actual work. I still had to add some wrapper around it to make it simple enough to use, but it is at least a good starting point...
Regards, Arkady.
What makes you think I've got a "standard library"?
This is an _embedded_ system.
-- Grant Edwards grante Yow! INSIDE, I have the at same personality disorder visi.com as LUCY RICARDO!!
Scientific notation would be tolerable.
I was thinking about that yesterday as an alternative to either repeated mult/div or using log10()
[...]
I'll look for that, thanks.
--
Grant Edwards grante Yow! You mean you don't
at want to watch WRESTLING
visi.com from ATLANTA?
... snip ...
The problem there is that the solution is specific to the FP format, and thus non-portable. This may not matter in most embedded systems. You can avoid this by simply multiplying (or dividing) by 10.0 until the 0.1 .. 1.0 range is reached. You can improve this somewhat by preliminary use of a constant 10.0ENnn, where nn is such that the overall value is exact. This will greatly reduce the accumulated roundoff errors. But don't try to 'improve' that by replacing division by multiplication with 0.1 etc., which will really create roundoff problems.
--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
USE worldnet address!
big
If
printf, sprintf, fprintf, ... are very memory hungry too. Many systems can handle floting point with ease if such gigantic library routines are avoided!
In one of my past projects (16 bit uC w. "lot" of RAM..4 kB) a single call to printf used >50% of stack! That is however NOT a reason to avoid floating points, it is just a reason to avoid such function calls. There may be a reason to avoid floating points altogether, but this is not it.
I would go simply to do multiplications with 10 and/or 0.1 as needed... and then utilizing ints.. fairly simple and effective when compared to those floating point monster functions...
Pygmi
But you can use the floating point *part* of the printf routines to do the job. Open Source doesn't have to be used intact, you can just borrow parts as long as you fulfill the license restrictions.
-- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX
That's a good point. Much of the RAM usage in printf can be avoided by finding the floating-point conversion routine and calling it directly. That way you can throw out all of the format-string parsing stuff, the output buffering, etc.
--
Grant Edwards grante Yow! I want to kill
at everyone here with a cute
visi.com colorful Hydrogen Bomb!!
what compiler are you using? how old is it?
If you're asking me, I'm using GCC 3.3.
-- Grant Edwards grante Yow! It don't mean a at THING if you ain't got visi.com that SWING!!
Isee,and on an 8051 I suppose?
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.