As I have stated elsewhere, Ieee754 utilizes a conversion
No, neither
IEEE 754-1985,
IEEE 754-2008, nor (current)
IEEE 754-2019 specify any "conversions" at all.
The standard only defines
- Binary32, Binary64, Binary128 binary interchange formats
- Decimal32, Decimal64, and Decimal128 interchange formats
- Arithmetic formats (representable real and complex numbers, infinities, and NaNs) using the above interchange formats
- Rounding rules
- Operations (arithmetic operations like addition, subtraction, multiplication, division, but also functions like square root, powers, trigonometric functions, and so on)
- Exception handling (especially divide by zero handling)
IEEE 754 does
not specify how numbers are converted. Really, all it says about the subject, is that however it is done, it should be done with less than half an unit in the least significant place of error, with exact half rounded according to the rounding rules.
Now, bcd fp on the other hand does not use a conversion algorithm and it therefore retains accuracy when moving fp numbers in/out,i.e. keyboard/memory/display
You most certainly need to do a conversion to BCD, if the display and/or keyboard uses binary, octal, duodecimal, or hexadecimal, and not decimal.
Some of such systems currently still in use involve astronomy (where angles are in degrees, minutes, and seconds, instead of decimal degrees) and time (when time is not in decimal seconds, but as seconds, minutes, hours, days, months, and years). Decimal is prevalent, but by no means the only one currently in use.
(In computer programs, the binary format of floating-point numbers,
"a" and
"A" conversions in C since C99, are used to provide exact floating point numbers in a binary basis (hexadecimal, i.e. four-bit digits, in base-16) when the exact decimal form would be excessively long – up to 768 decimal digits –, and the value should be conveyed in text form with maximum precision available. In most cases, the hexadecimal format is transparently supported by the C library, so that wherever a decimal real number can be input, a hexadecimal floating-point format is also acceptable. In particular,
strtod()/strtof()/strtold() will do this for you, and is the recommended way to parse floating-point inputs from strings in standard, hosted environments, in C.
If you use Bash or a related shell, you can use
printf '%a\n' number to convert
number to the hexadecimal form, and
printf '%.768g\n' number to convert to decimal form with maximum precision, with
number being either decimal or hexadecimal real number.)
whereby ieee745 fp is a joke
IEEE 754 is no joke, proven by how it is supported by almost all computing environments, and there are basically no competitors for it.
(Integer arithmetic and fixed point arithmetic as used in e.g. digital signal processing is not a competitor, since they boil down to just basic integer arithmetic, and IEEE 754 has basically nothing to do with integer arithmetic.)
IEEE 754 is commonly used even by calculators that use decimal base either use IEEE 754 Decimal types; the rest use very closely related representations (DPD, in particular), and basically just cherry-pick features from IEEE 754 instead of implementing it completely.
I don't think I have anything useful to further this thread, so I will bow out in defeat here. I failed to help.
![Cry :'(](https://www.eevblog.com/forum/Smileys/default/xcry.gif.pagespeed.ic.tehjCtKixU.png)
If anyone else happens to read through this thread, and has questions about IEEE 754 Binary
N/Decimal
N or BDC/DPD/binary arbitrary-precision arithmetic, and especially implementing them and their relative upsides and downsides, I'd recommend starting a new thread in the Programming sub-forum here. There are many members here with plenty of embedded programming experience, and the discussions can range from beginner to expert level. As for myself, I'm most interested in the implementation side of things, as shown in my
Constructing short C strings in limited or constrained situations, which we could expand into say calculators with decimal inputs and outputs, if anyone is working on that kind of stuff.
If you do start a thread there, but find my style of posts annoying/aggravating/waste of time (see e.g.
Mind over bugs: C pointer edition thread for examples), just drop me a friendly private message or email with a link to the thread, with a note
"Would you mind not participating in this thread?", and I will stay away.
In general, you can block me completely here so you don't need to read my posts at all, by opening your own Profile (near the top of each page), then Modify Profile, and in the pop-up lists, Buddies/Ignore lists... and Edit Ignore List. I add members to it if I feel I cannot respond in a mutually beneficial manner because of emotions or whatever, and about once a month or two, review the list whether that is still the case, and if not, clear the list. It, too, is just a tool, and not some sort of social game.
Disgruntled people have already added my email address to various spam lists, so there's not much point in doing that to spite me. I've got pretty good filters for that, having had an email address since 1994.