Re: Current implementation of exp() is faulty.
CChris wrote:
> Both quootes are right, but we still don't understand each other.
>
> The pasted in strings come from a professional software specialised in maths
> computations, not from anything written in Euphoria. So I'm sure most of the
> digits there are not noise.
Heh. Yes, we are not understanding one another! :)
Yes, I know you are using Mathemetica, right? I'm not saying that the digits
*from Mathematica* are noise. I'm saying is that they are noise as an input, not
as an output.
> To guard against any cutoff effect, I requested
> many more digits than should matter to compute a double.
> As I said, that way, even if the last few were noise, it wouldn't matter. All
> relevant digits are guaranteed.
>
> Which Euphoria parser are you talking about?
> Neither get() nor value() are invoked.
> When exwc.exe reads "atom_to_float64(1565146.159101750457681234), it uses an
> internal routine, called my_sscanf() in source\scanner.e, which turns a string
> into atoms. This routine does not check how many decimal places are given. But
> indeed, the 18th digit will very rarely matter at all.
I could be talking about any parser. The error is still there.
>
> I tried the implementation I suggested, but it is closer to the exact value
> only
> for x>=10 or slightly below. For x greater than say 20, it is almost good.
>
> CChris
Here's the problem: You use Mathematica to calculate a value, which it does
using an arbitrary precision and who knows how the number is stored internally.
Then you print out that number which is now in a decimal representation as
represented by a string of ASCII characters.
Then you take said string of ASCII characters and, using Euphoria (value(),
get(), my_sscanf() doesn't matter) and convert those ASCII characters back to a
binary representation of a number. This becomes your "expect" value.
Within the program under test, first a number is converted from ASCII to a
binary representation. Then some operations are performed on that binary
representation (raising e to some power, say). Now, this binary representation
can differ by several least significant bits from your expect value because of
parsing precision errors. But if you converted from double to ASCII and then
printed out the decimal representation, it should match the first 16 significant
figures of your expect string.
I don't have Euphoria handy right now, but if we are still miscommunicating then
I'll try an experiment later and post the results.
Basically, take a number with 17 significant figures. Use atom_to_float64() to
get the byte representation of it. Change the least significant bits by some
number, say 1 or 2 or 4 or 8 or whatever. Then use float64_to_atom() and then
print out the number and compare to your original number.
Maybe I'm wrong.
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
|
Not Categorized, Please Help
|
|
