In comp.lang.javascript message <07c28fab-b585-4a49-8f70-50f5c8f30425@i3
1g2000yqm.googlegroups.com>, Tue, 29 Jun 2010 20:12:53, Scott Sauyet
Dr J R Stockton wrote:
You seem to be on a different path than I'm following.
Not really; I'm just ahead of you, and perhaps past where you were
intending to stop. I've written my comparatively fast and imperfectly
accurate routines, now parsFlotA parsFlotB parsFlotC parsFlotD.
I understand
that you're looking for a reliable-even-if-inefficient converter of
string representations of base-n numbers to floating point numbers.
I'm less interested in that than in a practical-even-if-less-provably-
correct version.
There are, evidently, many ways of getting an approximate answer,
especially if ECMA string to/from number routines are used. If you look
at what I've found about some of the major-browser implementations, you
will see while anything using their conversion routines cannot
reasonably be trusted cross-browser, unless it is compared cross-browser
with a known-good routine.
Finding a digit 2 in a binary number string is like
hearing the 13th stroke of a church clock.
But what is your basis for demonstrating the quality of a converter?
If a String is in the proper format to represent a base-n number and
that number is representable as an IEEE-754 floating point number,
should our algorithm choose the closest IEEE-754 value, subject to the
standard rounding rules?
It is that others can examine my code and see that it must give the
right answer. At present, that's fairly easy for the sign and mantissa.
It's a bit harder for the exponent; but big errors are not deceptive,
even though they may be annoying. Any reasonable rounding rule can be
applied without difficulty.
Yes, but you're assuming that we can in some straightforward way show
that an unwrapped function or some other parseFloat is as accurate as
possible. I don't know if this can be done, and if you think it can,
I would love to see your evidence.
It is <URL:
http://www.merlyn.demon.co.uk/js-maths.htm#BEA>, once seen to
have been debugged and once the comment is adjusted so that a sufficient
number of people can understand the code. It uses the method that one
would use with pencil and paper.
It is easy to get parseFloat(S, R) fully accurate. Take the part before
the point and keep halving it in base-R arithmetic, pushing the
remainders until there is nothing left, and reverse them. Take the part
after the point and keep doubling it in base-R arithmetic, pushing the
remainders until one has 54 (sic) bits, of which the first will be a 1.
The 54th alone is sufficient to tell whether 1 has to be added to the
53rd. One now has the bits needed for the mantissa of an IEEE Double.
Start with zero and keep doubling and adding in to get what will be the
value after scaling in the exponent. Then consider whether there are
any special cases : "0.0" is such (since the code suggested so far will
fill the memory with zero bits while hoping to find a 1 bit); just test
the string for it and if found return a correctly-signed zero.
Exponent notation, once parsed for pattern, is easy if the exponent is
to the same radix; for approximate results, parseInt the exponent and
multiply/divide it in enough times (or trust Math.pow(Rdx, Expo)), and
for my method just shift the point in the string at the beginning.
I think e+, e-, E+, E- would be clearer and would not be overly
restrictive.
One could, for radix not 10, use lower case for the digits and upper-
case E for the separator.
Although its goal is somewhat different from the other functions on
the page, I did include it on my latest test page:
<
http://scott.sauyet.com/Javascript/Test/2010-06-29a/>
<
http://scott.sauyet.com/Javascript/Test/2010-06-29a/index.phps>
It's not really ready for that, unless you have reviewed and tested it
comprehensively. Today's version is different. Tomorrow's will be
different again. Give your users a textarea into which they can paste
code for test.
Also, if you examine the first of those of your pages, you find in "John
Stockton 3" a visible and invalid line
for (K=0, Cy=0 ; K= 0) Scale /= 2
but in my real code there are a few other lines between the second K and
the following =. Your innerHTML needs to be processed by something like
function SafeHTML(S) {
return S.split("&").join("&").split("<").join("<").
split(">").join(">") } // IAS
if it may contain '<' '>' or '&' ('<' '>' do not always *need* to be
replaced; but they always can be).
Yes, it's very easy for functions defined like that. Simply
F.now = new Date();
function Fn() { alert(Fn.now) ; Fn.now = new Date() ; alert(1) }
Fn()
alert(Fn.now)
Fn()
works. I must have done something else wrong when trying to do
something like that. Thanks.
<
http://www.bbc.co.uk/radio7/programmes/schedules>
links to John Major on Cricket.
"Malformed"?! I'm not sure that a bias in favor of blunt auditory