Amiga calculator

[cla]

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.

[DDNI]

Thank you. I will look at it later tomorrow.

[alkis]

Originally Posted by cla

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)

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

[Thorham]

Originally Posted by alkis

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.

[alkis]

Originally Posted by Thorham

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]

#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

[Thorham]

Originally Posted by alkis

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

[cla]

Thanks for the replies. I tried to reproduce the bugs.

1/3+1/3+1/3+1/3+1/3+1/3 gives incorrect answer 1

Confirmed, all versions across platforms.

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.

[cla]

Tested with an A1200 + Blizzard1230-IV today. The bugs are the same. And actually #1 is also correct

#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]

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

[daxb]

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.

[matthey]

Originally Posted by cla

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.

Originally Posted by daxb

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.

[phx]

Originally Posted by matthey

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...

[matthey]

Originally Posted by phx

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 .

[cla]

An updated version of documentation and source code is now available at aminet:
http://aminet.net/package/misc/math/amath.src

[cla]

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.

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).

[matthey]

Originally Posted by cla

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++.

Originally Posted by cla

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.

[cla]

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.

[cla]

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).

... 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

[matthey]

Originally Posted by cla

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?

Originally Posted by cla

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.