Hi, Marius!
Let's rather continue this discussion on the list. Be invited to bounce my article there if you reply publicly.
Perhaps in the distant future `LongestReal' will have greater precision than `Extended' ;)
Yes, I expect that too. That's why we have `LongestReal' as an alias for `LongReal' (= `Extended').
I understand that. But how can I determine the precision of data in a portable way?
I don't know right now, but it should be possible. With high probability, someone on the list knows a way.
The goal I'm trying to achieve is to get the value of a real number to a string in a not-scientific notation with highest possible precision.
You can't do it this way. In order to express some numbers represented in one system (say, the binary system) you need an infinite number of digits to express it in another system (say, the decimal one). 1/3, for instance, is a finite fraction in a system based on 3.
[...] I agree with the first half: BP should also output 70 digits (add some zeroes, for example).
Zeros would be intuitive, but simply wrong in most cases.
I see that I should have asked this question in another way: how to get decimal representation of a real number with maximum precision.
You can't without loss of precision.
A hexadecimal representation would do it.
Greetings,
Peter
Hi!
11-Jul-98 18:13 Peter Gerwinski wrote:
Let's rather continue this discussion on the list.
I wanted to, but, well, I forgot to change To: header field...
Be invited to bounce my article there if you reply publicly.
I understand that. But how can I determine the precision of data in a portable way?
I don't know right now, but it should be possible. With high probability, someone on the list knows a way.
The goal I'm trying to achieve is to get the value of a real number to a string in a not-scientific notation with highest possible precision.
You can't do it this way. In order to express some numbers represented in one system (say, the binary system) you need an infinite number of digits to express it in another system (say, the decimal one). 1/3, for instance, is a finite fraction in a system based on 3.
Yes (some time ago I investigated the case of Trunc(0.256*1000) resulting in value of 255).
Let's put it another way: I want to know the least number of decimal digits that are enough to specify any value with highest precision. For `Extended' type (IIRC it has 64 bits for mantissa part, but I'm not quite sure about that) it would be log10(2^64) ~= 19.2659197224947965 decimal digits.
[...] I agree with the first half: BP should also output 70 digits (add some zeroes, for example).
Zeros would be intuitive, but simply wrong in most cases.
I see that I should have asked this question in another way: how to get decimal representation of a real number with maximum precision.
You can't without loss of precision.
I could do with a little loss of precision - say by using 19 decimal digits (equivalent to 63.1166338028598846 bits). I do not want some user to think Pi is actually 3.141592653589793238512338873703165976280... ^ incorrect digits start here
While it also may be useful to know what numbers FPU is working with, I think in other cases it will only be confusing.
I have written an expression parser and evaluator in Borland Pascal and I do not use calculators any more (besides most of them do not have 18 digit precision, not to mention another functionality). In the past I have relied on BP run-time system to show only `accurate' (I hope you understand what I have in mind ;) digits and it would be very great if I could rely on GPC too. I do not request this to be the default behavior, but I would want to know of a way to achieve it.
A hexadecimal representation would do it.
However most people are still using decimal representation -- and there's little hope of changing that. :-)
Yours, -- Marius Gedminas "A Hacker is any person who derives E-mail: mgedmin@pub.osf.lt joy from discovering ways to WWW: http://www-public.osf.lt/~mgedmin/ circumvent limitations." rab'86
-
Marius Gedminas -
Peter Gerwinski