hi, Leon,
Maybe you can port the float lib of PForth to amforth:
http://pforth.googlecode.com/svn/trunk/fth/floats.fth
unitTest: http://pforth.googlecode.com/svn/trunk/fth/t_floats.fth
Best Regards
> I've finally added a function to output floats (in scientific notation):
>
>> 355 s>f 113
FYI: calc with f/ instead of f*:
> _1 _pi f* _1e15 f/ timer-start fs. timer-stop fs.
3.1415911E-15 6.5011706E-1 ok
> _1 _pi f* _1e-15 f/ timer-start fs. timer-stop fs.
3.1415932E15 7.0254588E-1 ok
> _-1 _pi f* _1e15 f/ timer-start fs. timer-stop fs.
-3.1415911E-15 6.3963132E-1 ok
> _-1 _pi f* _1
tart fs. timer-stop fs.
-3.141593E15 6.5011706E-1 ok
> _-1 _pi _1e-15 f* f* timer-start fs. timer-stop fs.
-3.1415899E-15 6.2914553E-1 ok
> Pito
- PŮVODNÍ ZPRÁVA -
Od: "pito"
Komu: [email protected], [email protected]
Předmět: Re: [Amforth-devel] p
Bug in latest source:
\THREE VERSIONS, PICK YOUR POISON <<
--
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/in
Thanks! I will play with it today. From my prospective no objection
to work with 4.1.
Pito
> Any objections if I make the floating point code
> version 4.1 dependent so that
> I can use 2>R, 2R> and 2LITERAL?
> -Leon
---
gt;From: "pito"
>Subject: Re: [Amforth-devel] printing floats
> 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
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###
s. (e.g. can replace repeated division by
repeated multiplication and one division), but f/ is what really needs
optimization. I'm probably going to hold off on any of that until I get input
working.
-Leon
>Saturday 04 September 2010
>From: "pito"
>Subject: Re: [Amfor
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
I've finally added a function to output floats (in scientific notation):
> 355 s>f 113 s>f f/ fs.
3.1415927 ok
> 1 s>f f2/ f2/ f2/ f2/ fs.
6.25E-2 ok
> 12345 s>f fs.
1.23449993E4 ok
You can see from the second example that rounding problems do happen. That can
be avoided... if you don't mind
22 matches
Mail list logo
