baconwaifu / propforth

Automatically exported from code.google.com/p/propforth
0 stars 0 forks source link

Comments for float.f #162

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
Point to the detailed external explanation for software float

Comments could tell us where to look for more detail on where this came from, 
and how it is used, etc.

Would this be an adequate reference?

http://en.wikipedia.org/wiki/Single-precision_floating-point_format

http://steve.hollasch.net/cgindex/coding/ieeefloat.html

http://groups.csail.mit.edu/cag/scale/papers/seltsame-meng.pdf

Or should we just say "Google: IEEE floating point" ?

Original issue reported on code.google.com by prof.bra...@gmail.com on 29 Sep 2012 at 5:05

GoogleCodeExporter commented 8 years ago

Original comment by prof.bra...@gmail.com on 29 Sep 2012 at 5:05

GoogleCodeExporter commented 8 years ago
I edited float.f for 2.5 to make it run on 5.0. I got it to work and it passes 
the test program. I now see you also did this.

It works pretty well for the normal math.
However:
1. Since the log, exp, and trig functions use the prop's lookup tables the 
accuracy is a bit low.
2. The inverse trig functions are not implemented.
3. There is a bug. Base prefixes for integers, b1010 d9090 hF0F0 and z, are not 
allowed. I assume the number parser for floats doesn't recognize the prefix as 
a number and gives this error message "UNDEFINED WORD hF0F0".

To improve math accuracy have you considered using "CORDIC" routines to obtain 
the 24bit accuracy needed for float numbers for the log, exp, and trig  
functions?

I added a float version of my Non-Destructive stack displaying words. I have 
found these very useful when debugging complicated stack operations.

I attached my whole working file.

Duane J

Original comment by ziggy1...@gmail.com on 17 Dec 2012 at 5:04

Attachments:

GoogleCodeExporter commented 8 years ago
I had updated float.f as part of 5.3, the bug of not recognizing hex is fixed 
in fisnumber and fnumber.

The base functions were implemented and tested. The log/trig function were an 
experiment, and I agree the accuracy is low.

Did not have a strong direction for these routines, performance? precision? 
completeness of library?

Currently I use this to calculate and prescale fixed point routines, do not 
really have any requirements.

Suggestions are welcome.

Original comment by salsa...@gmail.com on 19 Dec 2012 at 8:41

Attachments:

GoogleCodeExporter commented 8 years ago

Original comment by salsa...@gmail.com on 23 Feb 2013 at 8:15