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. |
Thank you. I will look at it later tomorrow.
|
Quote:
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 |
Quote:
|
Quote:
#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. |
#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 |
Quote:
1/3+1/3+1/3=0.1 |
Thanks for the replies. I tried to reproduce the bugs.
Quote:
Quote:
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. |
Tested with an A1200 + Blizzard1230-IV today. The bugs are the same. And actually #1 is also correct
Quote:
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 :) |
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 :) |
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.
|
Quote:
Quote:
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. |
Quote:
At least I know that the recent vbcc no longer works very well with the old 0.9b libraries... |
Quote:
|
An updated version of documentation and source code is now available at aminet:
http://aminet.net/package/misc/math/amath.src |
Quote:
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:
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). |
Quote:
Quote:
|
Quote:
I looked at c99lm68k4 and of course mathieeedoubtrans.library but they are lacking asinh, acosh and cbrt. |
Quote:
Quote:
|
Quote:
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:
|
All times are GMT +2. The time now is 13:20. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.