English Amiga Board


Go Back   English Amiga Board > Coders > Coders. General > Coders. Releases

 
 
Thread Tools
Old 12 October 2014, 00:42   #1
cla
dev

cla's Avatar
 
Join Date: Aug 2014
Location: Copenhagen
Posts: 47
Send a message via ICQ to cla
Amiga calculator

To support the Amiga community I have created a new calculator, available at aminet:
http://aminet.net/package/misc/math/amath

Current version is 1.5.1 and upcoming is version 1.5.2. The user interface is nothing special, basically just a command line interface. The program itself is more interesting. It is inspired by the open source calc: http://www.isthe.com/chongo/tech/com...lc-whatis.html

Calc is published under the GNU Lesser General Public License which makes it hard to modify for the Amiga. For the same reason amath is published under a BSD License.

Any feedback regarding features, bugs or anything else is very welcome.

Last edited by cla; 12 October 2014 at 23:55.
cla is offline  
AdSense AdSense  
Old 12 October 2014, 01:25   #2
DDNI
Targ Explorer

DDNI's Avatar
 
Join Date: Mar 2006
Location: Northern Ireland
Age: 43
Posts: 5,090
Send a message via ICQ to DDNI Send a message via MSN to DDNI
Thank you. I will look at it later tomorrow.
DDNI is offline  
Old 12 October 2014, 04:36   #3
alkis
Registered User

 
Join Date: Dec 2010
Location: Athens/Greece
Age: 46
Posts: 365
Quote:
Originally Posted by cla View Post
Calc is published under the GNU Lesser General Public License which makes it hard to modify for the Amiga. For the same reason amath is published under a BSD License.
Huh? You can modify gpl code all you want. The difference is that you have to release the source code of your modifications while in bsd license you don't have to release the source code.

Ok, and a little bug reporting now. (running on A1200 emulated with fs-uae)

Code:
amath.000 digits=30:a=1/3:a:a*a:a*a*a:2^127
Number of digits changed to 30
a = 0.333333333333333366444402248628
a*a = 0.111111111111111146646808688204
a*a*a = 0
2^127 = 4294967295
Cheers and thanks for the application
alkis is offline  
Old 12 October 2014, 05:34   #4
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 41
Posts: 2,972
Quote:
Originally Posted by alkis View Post
Ok, and a little bug reporting now.
That's not a bug, it's a precision limitation. This calculator doesn't use an arbitrary precision floating point library, so the number of digits is limited.
Thorham is offline  
Old 12 October 2014, 14:02   #5
alkis
Registered User

 
Join Date: Dec 2010
Location: Athens/Greece
Age: 46
Posts: 365
Quote:
Originally Posted by Thorham View Post
That's not a bug, it's a precision limitation. This calculator doesn't use an arbitrary precision floating point library, so the number of digits is limited.
I can see three bugs in the posted output.

#1) 1/3 is not 0.333333333333333366444402248628
#2) 1/3*1/3*1/3 is not 0
#3) 2^127 is not 4294967295 (overflow error should be the output)

But that just me.
alkis is offline  
Old 12 October 2014, 14:19   #6
alkis
Registered User

 
Join Date: Dec 2010
Location: Athens/Greece
Age: 46
Posts: 365
#4)
1/3+1/3+1/3 gives correct answer 1
1/3+1/3+1/3+1/3+1/3+1/3 gives incorrect answer 1
1/3+1/3+1/3+1/3+1/3+1/3+1/3+1/3+1/3 gives correct answer 3
alkis is offline  
Old 12 October 2014, 17:22   #7
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 41
Posts: 2,972
Quote:
Originally Posted by alkis View Post
I can see three bugs in the posted output.
Actually, there probably is a bug. At first I thought it was caused by you using 30 digits, but it happens with the default nine digits as well:

1/3+1/3+1/3=0.1

Last edited by Thorham; 12 October 2014 at 17:34.
Thorham is offline  
Old 12 October 2014, 20:46   #8
cla
dev

cla's Avatar
 
Join Date: Aug 2014
Location: Copenhagen
Posts: 47
Send a message via ICQ to cla
Thanks for the replies. I tried to reproduce the bugs.

Quote:
1/3+1/3+1/3+1/3+1/3+1/3 gives incorrect answer 1
Confirmed, all versions across platforms.

Quote:
1/3+1/3+1/3=0.1
Confirmed but seems only to occur on A1200 and below. A4000 in FS-UAE does not produce this output.

The other bugs seems to be fixed in 1.5.2

Regarding the LGPL v2.1 (calc license), I do not know if it is possible to modify within the terms of the license and still get it up and running in Amiga OS. I didn't have the courage to do it. The BSD license seemed like a much simpler solution. Also, Calc is heavily geared towards Linux libraries and tools.

Last edited by cla; 12 October 2014 at 23:57. Reason: Spelling mistakes and bad gramma
cla is offline  
Old 13 October 2014, 22:21   #9
cla
dev

cla's Avatar
 
Join Date: Aug 2014
Location: Copenhagen
Posts: 47
Send a message via ICQ to cla
Tested with an A1200 + Blizzard1230-IV today. The bugs are the same. And actually #1 is also correct
Quote:
#1) 1/3 is not 0.333333333333333366444402248628
I will try to put a constraint according to selected base. Base 10 should of cause only allow 16 digits.

Also, there seems to be a problem with negative complex numbers. I still didn't figure that one out. Could be something to do with the so called "branch cuts". Any expert advice would be appreciated
cla is offline  
Old 26 October 2014, 13:41   #10
cla
dev

cla's Avatar
 
Join Date: Aug 2014
Location: Copenhagen
Posts: 47
Send a message via ICQ to cla
A new release is now available at aminet:
http://aminet.net/package/misc/math/amath

I had to discard the custom made code for printing floating numbers. Most errors came from this piece of code. I tested all of the above cases and all passed. Credits go to developer Ryan Juckett for his awesome dragon4 algorithm. He even made a few articles on his website about it:
http://www.ryanjuckett.com/programmi...point-numbers/

I also had to make a small note about precision. Some routines does not use scaling and while others do, errors are doomed to build up as expressions grow in size. An estimated accuracy of 11 digits should be enough to cover my ass

Regarding the faulty builds for FPUs and 68000 + 68020 it turned out to be something to do with floating numbers stored in registers and possibly faulty generated optimizations. Nevertheless calculations works again with the new GCC build configuration. Details are provided in the source code.

I still didn't get much feedback about bugs and actually I don't even know if FPU and 68060 versions work. If you have access to such hardware please send feedback.

And now, enjoy the magic numbers on your favorite Amiga

Last edited by cla; 26 October 2014 at 13:46.
cla is offline  
Old 26 October 2014, 18:28   #11
daxb
Registered User
 
Join Date: Oct 2009
Location: Germany
Posts: 1,751
Can you merge some 68k exe versions into one to haven`t so much different exe`s? 2 or 3 for 68k should be enough.
daxb is offline  
Old 27 October 2014, 23:52   #12
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Quote:
Originally Posted by cla View Post
I also had to make a small note about precision. Some routines does not use scaling and while others do, errors are doomed to build up as expressions grow in size. An estimated accuracy of 11 digits should be enough to cover my ass

Regarding the faulty builds for FPUs and 68000 + 68020 it turned out to be something to do with floating numbers stored in registers and possibly faulty generated optimizations. Nevertheless calculations works again with the new GCC build configuration. Details are provided in the source code.
Most, if not all, older Amiga versions of GCC (3.x and earlier) set the precision in the FPCR to double precision. This would give 53 bits of precision but some instructions and functions are not accurate to the last bits of precision. Using double precision may be more IEEE compliant but both precision and accuracy are lost compared to the 68k FPU extended precision (cumulative errors and lack of floating point associative property can further reduce accuracy). The older GCC 68k FPU code is not the greatest. It's inconsistent and incomplete. For example, trapped 6888x instructions are used on the 68040 and 68060 (slow), the IEEE libraries are opened which is questionable when the IEEE libraries are used (inits the FPU and changes the rounding from the default best precision and accuracy), some of the FPU code is slow and large, etc. I haven't seen common big bugs with the direct 68k FPU support but it's poor quality by GCC standards.

Quote:
Originally Posted by daxb View Post
Can you merge some 68k exe versions into one to haven`t so much different exe`s? 2 or 3 for 68k should be enough.
I see 4 different potential 68k floating point targets (not counting ultra slow soft floating point support).

1) 68000+IEEE math libraries (not available in GCC)
2) 68020+6888x
3) 68040
4) 68060

Target #1 is nice because it should work on all Amiga targets although it's slow compared to direct FPU code with an FPU. Vbcc works very well linking with -lmieee although it's not the most advanced support. GCC will give it's best 68k FPU code for target #2 and it will work on the 68040 and 68060 using slow emulation traps. Compiling for target #3 and target #4 will probably not work on the 6888x when compiled with GCC which uses FSxxx and FDxxx instructions which the 6888x does not have. Compiling for target #3 and #4 with vbcc should work on the 6888x as it avoids these problems. The major difference between the 68040 and 68060 FPU is that the 68040 FPU lack the FINT/FINTRZ instructions. This causes all kinds of problems trying to avoid these instructions which results in greatly reduced accuracy and/or slow and/or bloated code. Where accuracy is more important than speed, compiling for the 68060 to use on the 68040 with OxyPatcher/CyberPatcher/MuRedox is reasonable (blame Motorola for the terrible decision to remove FINT/FINTRZ from the 68040 which they brought back for the 68060). ACalc compiled with GCC could probably get away with targets #2 and #4. Compiling with vbcc could use targets of #1, #2 and #4 for this type of program. A compiler build script for all targets probably doesn't take very long or take up very much space although this is the type of program that speed is not as important as accuracy.

There are newer versions of vbcc and it's math libraries. I have compiled the newer math libraries and includes and placed them at the following link if you want to give vbcc a try.

http://eab.abime.net/showthread.php?t=74692

and below is the link to vbcc which is easy to install unlike GCC.

http://sun.hasenbraten.de/vbcc/

There may be bugs as there have been significant changes in the direct FPU code in vbcc (please report bugs) but it is more advanced than the old GCC 68k FPU code and it's still supported and updated. There is a new version of vbcc with many updates that is nearly ready to release.
matthey is offline  
Old 28 October 2014, 13:48   #13
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,019
Quote:
Originally Posted by matthey View Post
There are newer versions of vbcc and it's math libraries. I have compiled the newer math libraries and includes and placed them at the following link if you want to give vbcc a try.

http://eab.abime.net/showthread.php?t=74692

and below is the link to vbcc which is easy to install unlike GCC.

http://sun.hasenbraten.de/vbcc/

There may be bugs as there have been significant changes in the direct FPU code in vbcc (please report bugs)
Did you test whether the new libraries work with the last vbcc 0.9b release? I didn't.
At least I know that the recent vbcc no longer works very well with the old 0.9b libraries...
phx is offline  
Old 28 October 2014, 18:44   #14
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Quote:
Originally Posted by phx View Post
Did you test whether the new libraries work with the last vbcc 0.9b release? I didn't.
At least I know that the recent vbcc no longer works very well with the old 0.9b libraries...
I have tried several combinations of vbcc and libraries in different tests which I believe includes the old version of vbcc with the new math libraries and includes. I have not done thorough testing. There could be issues especially with some old floating point vbcc bugs. I haven't received any reports of problems but that doesn't mean much. I realized there could be issues and I have considered compiling newer beta versions of vbcc for the public if necessary. It would be helpful if there were recent stable beta compiles and/or source of vbcc for download somewhere. Vbcc and vasm have matured so much that the last official release seems like it is from the stone ages. I read your other post here on EAB that you are still waiting to hear back from Volker for some time. I used to tell people there should be a new vbcc release soon but it's like it has the Amiga "two more weeks" curse now .
matthey is offline  
Old 28 October 2014, 20:04   #15
cla
dev

cla's Avatar
 
Join Date: Aug 2014
Location: Copenhagen
Posts: 47
Send a message via ICQ to cla
An updated version of documentation and source code is now available at aminet:
http://aminet.net/package/misc/math/amath.src
cla is offline  
Old 28 October 2014, 20:16   #16
cla
dev

cla's Avatar
 
Join Date: Aug 2014
Location: Copenhagen
Posts: 47
Send a message via ICQ to cla
Quote:
There are newer versions of vbcc and it's math libraries. I have compiled the newer math libraries and includes and placed them at the following link if you want to give vbcc a try.

http://eab.abime.net/showthread.php?t=74692
amath includes an adapted version of Sun Microsystems fdlibm (Freely Distributable LIBM) and as such does not depended on Amiga libraries:
http://www.netlib.org/fdlibm/readme

Calculations in the code are not handled so carefully so it does depend on GCC generated FP code.

Quote:
There may be bugs as there have been significant changes in the direct FPU code in vbcc (please report bugs) but it is more advanced than the old GCC 68k FPU code and it's still supported and updated. There is a new version of vbcc with many updates that is nearly ready to release.
The only reason I choose GCC was because of the support for C++. As far as I have been able to figure out, no other (free) compiler supports both C++ and m68k-amigaos as a target.

Most of the code in amath uses C++ techniques like inheritance and polymorphism.

Maybe it could be an idea to compile fdlibm with vbcc and link it with some GCC output ? I don't know if its possible (resolving symbolic references etc).

Last edited by cla; 28 October 2014 at 20:49.
cla is offline  
Old 28 October 2014, 21:58   #17
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Quote:
Originally Posted by cla View Post
The only reason I choose GCC was because of the support for C++. As far as I have been able to figure out, no other (free) compiler supports both C++ and m68k-amigaos as a target.

Most of the code in amath uses C++ techniques like inheritance and polymorphism.
Yea, GCC is easily the best choice for C++ on the Amiga. I am not aware of any plans to add C++ support to vbcc. C99 support has improved in vbcc which gives some advanced features of C++ but it's still a long way from C++.

Quote:
Originally Posted by cla View Post
Maybe it could be an idea to compile fdlibm with vbcc and link it with some GCC output ? I don't know if its possible (resolving symbolic references etc).
It looks like the C++ features are light at least in the LIBM code (.c renamed to .cpp?). I don't know how linking GCC and vbcc code would work out. Frank (phx) could probably tell you being the author of vlink. It's generally not worthwhile to mix compilers for the same executable in my limited experience.
matthey is offline  
Old 28 October 2014, 22:12   #18
cla
dev

cla's Avatar
 
Join Date: Aug 2014
Location: Copenhagen
Posts: 47
Send a message via ICQ to cla
Quote:
It looks like the C++ features are light at least in the LIBM code (.c renamed to .cpp?)
Yeah. fdlibm is originally pure c. I renamed all files to cpp in order to make a complete build. gcc did not want to accept a mixture of c and cpp files.

I looked at c99lm68k4 and of course mathieeedoubtrans.library but they are lacking asinh, acosh and cbrt.

Last edited by cla; 28 October 2014 at 22:18.
cla is offline  
Old 28 October 2014, 22:47   #19
cla
dev

cla's Avatar
 
Join Date: Aug 2014
Location: Copenhagen
Posts: 47
Send a message via ICQ to cla
Quote:
Most, if not all, older Amiga versions of GCC (3.x and earlier) set the precision in the FPCR to double precision. This would give 53 bits of precision but some instructions and functions are not accurate to the last bits of precision. Using double precision may be more IEEE compliant but both precision and accuracy are lost compared to the 68k FPU extended precision (cumulative errors and lack of floating point associative property can further reduce accuracy). The older GCC 68k FPU code is not the greatest. It's inconsistent and incomplete. For example, trapped 6888x instructions are used on the 68040 and 68060 (slow), the IEEE libraries are opened which is questionable when the IEEE libraries are used (inits the FPU and changes the rounding from the default best precision and accuracy), some of the FPU code is slow and large, etc. I haven't seen common big bugs with the direct 68k FPU support but it's poor quality by GCC standards.
Just to clarify: No external IEEE libraries are used in the code. All math is included. The only weak part is GCC FP code generation (emitting FINT/FINTRZ on a 68040 target etc).

Quote:
... A compiler build script for all targets probably doesn't take very long or take up very much space although this is the type of program that speed is not as important as accuracy.
I absolutely agree. The aim is accuracy. Doing my best to get there
cla is offline  
Old 29 October 2014, 00:05   #20
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Quote:
Originally Posted by cla View Post
I looked at c99lm68k4 and of course mathieeedoubtrans.library but they are lacking asinh, acosh and cbrt.
The Amiga IEEE fp math libraries (vbcc using -lmieee) lack many c99 math functions. I could create new IEEE fp math libraries with more c99 functions based on the vbcc math libraries. There are several potential advantages to new IEEE libraries with extended IEEE c99 math functions (the old ones have design flaws). I have been planning for such a project but the vbcc fp math libs need more testing first.

The vbcc m881, m040 and m060 fp math libs should have asinh, acosh and cbrt functions. It's mentioned on the page at the link although many functions, especially new ones, need more testing. Did you have trouble using these functions?

Quote:
Originally Posted by cla View Post
Just to clarify: No external IEEE libraries are used in the code. All math is included. The only weak part is GCC FP code generation (emitting FINT/FINTRZ on a 68040 target etc).
Which version of GCC are your using? If the IEEE libraries are not opened then I wonder how (or if) the FPU is initialized? The majority of GCC code I have seen opens the IEEE libraries without the programmer asking for them. They also use the IEEE libraries for some functions with the direct FPU code which is a questionable practice as the IEEE math libraries initialize the FPU and set the FPCR to their own settings. GCC usually uses double precision and round toward zero (extended precision and round toward nearest is the 68k FPU default in the FPCR) as the last double precision IEEE library opened sets it.
matthey is offline  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
BPM calculator for Octamed? lordofchaos request.Apps 4 29 May 2013 20:46
Speccy on Ti-89 calculator Fred the Fop Retrogaming General Discussion 3 27 January 2007 03:30
Vintage 1970's Commodore Calculator Steve Retrogaming General Discussion 7 05 February 2003 11:30

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 12:43.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.29856 seconds with 12 queries