I did what I mentioned earlier and replaced the repeated division in FS. by
repeated multiplication and one division. I didn't benchmark it rigorously,
but it seems to be nearly as fast as the method where we multiply by 1/10, but
it doesn't have the accuracy problems. For example:
The new meth
Engineering notation is also on the todo list (see FE. in the standard). I
don't know about the HP25, but many older HP calculators used the Saturn
microprocessor that could handle 16 BCD digits.
http://en.wikipedia.org/wiki/Saturn_(microprocessor)
I've seen the 4th stuff -- definitely a lot of
A point to fs. For small systems float with 3-4 decimal places is
perfect when measuring standard stuff except when measure frequency
or time. What could be nice to have is engineering notation. I have
got it on my HP-25, and frankly, I do not understand how they did it
on such small footprint. No
Leon, did you see the ans float from the 4th forth? There is an ans
float library and zen float library as well. Lot of routines for
both.. Pito
--
This SF.net Dev2Dev email is sponsored by:
Show off your parallel progr
The f* is ~4.7ms and f/ is ~91ms (not 13ms as I had written, sorry)
at 25MHz clock. So we went from 1.7sec to 0.5sec when printed E15,
that is 1.7-0.5 = ~1.2sec less.
check: 15 * (0.091-0.0047) = ~1.29sec less.. P.
--
Th
At the moment, there's no way to print a fixed number of digits, but it won't
be hard to do -- a simple way would be to replace the last begin-while-repeat
look with a do-loop of the number of digits you want and strip out the stuff
dealing with M.
It's something I hope to get around to eventua
Yes, 0.1 is $3dcc = 0.0999403953552
from that the result will be 3.14158984478e+/-15 (shall be
3.1415926535e+/-15).
Our result is 3.1415851, or 3.1415874 - so quite precise. However, I
would simply recommend to print with 4 decimal places only. For
atmega users -3.1415E-27 might be ok, I gu
I've avoided division by reciprocal multiplication because it introduces
rounding errors (.1 in decimal is infinitely repeating in binary). That said,
we already have some rounding errors, so it may be worth doing -- although
these new rounding errors do look slightly more severe.
I'll think ab
Leon, I did following - I put print"#" in f* and print"%" in f/:
> 987654321. d>f _1e9 f*
# ok
> fs.
%9.###8###7###6###5###3###6###4E17 ok
> 987654321. d>f _1e-9 f*
# ok
> fs.
#9.###8###7###6###5###3###2###6E-1 ok
> 987654321. d>f _1e-9 f/
% ok
> fs.
%9.###8###7###
The current method repeatedly divides (for large numbers) or multiplies (for
small numbers) by 10 until the float is in the range [1,10). f/ is slow, which
makes it slow to print large numbers. f* is faster because I saw a way to do
the math with integers using m* -- I didn't see a similar good
FYI: f+ f- f* f/ duration (@25MHz):
> : measure
oktimer-start
ok400 0 do _pi fdup fdrop fdrop loop
oktimer-stop 400 s>f f/ fs. ." sec";
ok
> measure
2.6214392E-5 sec ok
> : measure
oktimer-start
ok400 0 do _pi fdup f+ fdrop loop
oktimer-stop 400 s>f f/ fs. ." sec";
ok
> measure
1.12721896E-3 sec ok
Nooop, fs. still slow, even with fconstants:
> measure
3.1415851E-15
545 ms ok
> measure
3.1415915E15
1646 ms ok
> measure
-3.1415915E15
1646 ms ok
> measure
-3.1415851E-15
545 ms ok
P.
--
This SF.net Dev2Dev email i
I did replace all those conversions within .fs with constants:
1 s>f 2 s>f f/ fconstant _half
1 s>f fconstant _1
2 s>f fconstant _2
4 s>f fconstant _4
8 s>f fconstant _8
10 s>f fconstant _10
it is now 3x faster:
> measure
-3.1415851E-15
545 ms ok
>
P.
-
> 1. it seems the fs. routine presition itself is 7 digits which is
> good
> 2. it seems the f/ most notably with larger operands (eg. +/- 1e15)
> introduces errors so the result's precision drops to 6 digits or
> less
Yes, the number of decimal points it prints should be related to the size of
t
Leon,
I did a lot of various tests I am not going to publish and to make
the story short:
1. it seems the fs. routine presition itself is 7 digits which is
good
2. it seems the f/ most notably with larger operands (eg. +/- 1e15)
introduces errors so the result's precision drops to 6 digits or
less
Leon, thanks! I am very happy that you publish the float updates!
Pito.
PS: Leon, is there any chance to name the .zip updates with e.g. a
date in it as it is uneasy to recognise and track the files based on
those codes like "..-float-9e1ace1.zip"
P.
>
> PS I'm not sure if these type of updates
16 matches
Mail list logo
