bugs

[ookami]

Hi,

I just checked out SpeedCrunch (0.7-060204, the version that ships
with kubuntu) a little and found some bugs. Here's the list:
1. Poor performance of exp: exp(100) yields 2.6881120..*10^43 on
SpeedCrunch, the true value is 2.6881171..*10^43, so the result is
valid to 6 digits only.
2. When evaluating the term (1/3)*3 I get the not normalized result
10.00...0e-1.
3. Strange overflow behaviour:
3a: Speed Crunch seems to overflow at 1e150. Entering 1e150 as an
expression returns NaN, which is OK, though I'd prefer getting an
indication of why. 1e149/1e-10 returns 0.00..0e159, which is odd.
3b: There seems to be no consistent overflow limit: Entering 1e150
is forbidden, but 1e149*10 is accepted.
4. Is there a reason why the underflow/overflow limits (1e-69/1e150)
are not balanced with respect to 1? This way simple operations like
multiplication or division may underflow unexpectedly.

kind regards

Wolf Lammen

[Ariya Hidayat]

Thanks for reporting.

We're aware of the accuracy problem. Unfortunately, that's not easy
(or requires too much effort) to fix since the calculation engine of
SpeedCrunch is based on GNU bc's code, which is not good and also
quite slow. I expect that we should switch using something e.g. hfloat
for post 0.7 version (could be 0.8 or 0.9).

Best regards,

Ariya

[Ariya Hidayat]

Forgot to write about this:

For exp(x), the accuracy is not good because x is not reduced to the
range 0<x<1. I saw that that's what bc mathlib does. Therefore, I
implemented the same method for development version of SpeedCrunch and
now exp(100) gives correct result.

Regards,

Ariya

[ookami]

I just had a closer look at your calculating engine in number.c. You
are right, the engine is awfully slow, and it is written in a terrible
style. There are tons of duplicated code, a bunch of thinkos, where
the programmers waste processor cycles, and one bug in line 975, where
an early-out branch is not finished with a "return 0;" statement,
rendering that branch useless. Many algorithms can easily be
accelerated without much effort, even when retaining the BCD-like data
structure.
But you do not employ costly numerical algorithm in your calculator,
so I think, you can get away with it. For starters I'd suggest, you
build a thin floating point layer on top of it. Floating point numbers
are more appropriate for a (scientific) calculator than bc's native
integer and fix point arithmetic.
If you want to exchange the engine, consider GMP, and the math library
MPFR built on it. Both are lightning fast, and their interface is
quite complete and easy to understand.

kind regards

Wolf Lammen

[Ariya Hidayat]

> I just had a closer look at your calculating engine in number.c. You
> are right, the engine is awfully slow, and it is written in a terrible
> style. There are tons of duplicated code, a bunch of thinkos, where
> the programmers waste processor cycles, and one bug in line 975, where
> an early-out branch is not finished with a "return 0;" statement,
> rendering that branch useless. Many algorithms can easily be
> accelerated without much effort, even when retaining the BCD-like data
> structure.

> But you do not employ costly numerical algorithm in your calculator,
> so I think, you can get away with it. For starters I'd suggest, you
> build a thin floating point layer on top of it. Floating point numbers
> are more appropriate for a (scientific) calculator than bc's native
> integer and fix point arithmetic.

It's supposed to be wrapped in HMath/HNumber classes (see
hmath.h/cpp). However, the implementation is still suboptimal. I had
no time nor mood to work-around bc code anymore.

Note that when we switch the "engine", we just need to adapt
HMath/HNumber. The rest of SpeedCrunch code shouldn't be modified.
That was the idea behind the wrapper.

> If you want to exchange the engine, consider GMP, and the math library
> MPFR built on it. Both are lightning fast, and their interface is
> quite complete and easy to understand.

I already considered MPFR. However, I still have to find out on how to
create an easy way to build SpeedCrunch under Win32 and Mac OS X. On
Linux/BSD, MPFR (or GMP) library is widely available, but not on other
platforms. And including the whole MPFR+GMP code in SpeedCrunch will
be less practical.

Something more lightweight, still actively maintained, properly
license (at least GPL or LGPL) would be a better choice. For
SpeedCrunch, it does not need to be as fast or as powerful as GMP.
We're not building the next Pari/GP :-)

Regards,

Ariya