I've recently been doing some work using SANE (updating the ORCA/C math
libraries, which should be available in a new release hopefully fairly
soon). In the course of that, I've run into some situations where
SANE's behavior is buggy or differs from the documentation. In
particular, the first issue below is a definite bug, and programs
calling SANE may wish to work around it (e.g. by not calling FX2L/FX2C
on negative numbers). The others issues are less serious and at least
some are errors in the documentation rather than bugs in SANE, but
anyone using SANE should be aware of them.

* FX2L and FX2C can yield the wrong value for certain negative integers
(e.g. -2147483648). I think the numbers affected are negative integers
that have zeros in at least the bottom 16 bits (in two’s-complement
representation). For such numbers, the errors occur fairly frequently
but not always. They seem to occur even more commonly (maybe always) if
the bottom 32 bits are zero. This only seems to affect integer inputs,
not non-integer numbers that round to such integers.

* Conversions of out-of-range values to comp do not always yield the
comp NAN. This may be related to the above issue.

* The definition of the SANE extended format allows for what are
sometimes called unnormalized numbers, where the integer part i is 0,
the fraction f is nonzero, and the exponent is not the minimum possible
value. In all cases, the exact same numeric value can be represented as
a normalized number (with i=1) or a subnormal number (with i=0 and the
minimum possible exponent). The manual includes unnormalized numbers
within its definition of “denormalized” numbers, but FCLASSX actually
classifies them as normalized, even in the case where their value is
subnormal. (AFAIK SANE does not output unnormalized numbers, so this
should rarely come up in practice.)

* For the FREM calls, Apple Numerics Manual 2nd Ed., p.94 says “The Y
register receives $80 if n is negative and 0 otherwise,” but p. 253
says “sign(Yreg) ← sign of n”. These descriptions are inconsistent with
each other in the case of 65816 SANE (with 16-bit registers), and it
turns out neither of them is quite right. It appears that the low-order
eight bits of Y are set to $80 or 0, but the high-order bits may not be
0 or have the sign as described.

* Apple Numerics Manual 2nd Ed., p. 256 shows comparisons where the
type of DST varies but SRC is always extended. The actual behavior is
the reverse of this: SRC varies and DST is always extended. I think
this is a misprint in the manual. The behavior is described correctly
on p. 96, and also (for 6502 SANE) in the corresponding table in Apple
Numerics Manual 1st Ed.

* “The fclass functions should return the sign of the passed number in
n-bit and Y. They do not report the sign at all, though, which has to
be considered a bug.” (Noted by Soenke Behrens in lsaneglue docs.)

I've also posted a copy of this list that I will keep updated if I find
additional issues:
https://gist.github.com/sheumann/594fae25142102e0eb8521cc8c81b6f6

--
Stephen Heumann

On 12/21/2021 8:37 PM, Stephen Heumann wrote:

> * FX2L and FX2C can yield the wrong value for certain negative
> integers (e.g. -2147483648). I think the numbers affected are
> negative integers that have zeros in at least the bottom 16 bits (in
> two’s-complement representation). For such numbers, the errors occur
> fairly frequently but not always. They seem to occur even more
> commonly (maybe always) if the bottom 32 bits are zero. This only
> seems to affect integer inputs, not non-integer numbers that round to
> such integers.
>

Stephen,

For some reason the math error and specifically the number 2147483648
struck a memory I had about a similar issue with UltraMacros for AppleWorks.

I finally found that it was referenced in Joe L. Walter's UltraMacros
Reference Manual. I've quoted it below, but don't really know if it will
be of any help to you. If not, please disregard.

>
> The extended math commands allow 26 special Ultra 4 variables to
> handle numbers ranging from negative 21 million to positive 21
> million with up to two decimal places.

> This allows you to calculate financial transactions without needing
> the spreadsheet, or to do any other math which is beyond the range of
> Ultra's normal 0-65535 limits.

> One limitation is that the result of a multiplication or division can
> not exceed 214,748.36, at least if you want an accurate answer.
> Additions and subtractions work all the way up to the maximum value.
> Multiplications and divisions are limited because of the need to
> maintain two decimal place accuracy.

> Ed: Because of this "limitation" for multiplication or division I
> would hesitate to use these extended math commands unless I knew for
> sure that there was no chance my data could exceed the limitation.
> Practice safe Hex, create a spreadsheet and do the calculations
> there.

> Here are the ranges. (The second columns have commas to make the
> numbers more readable, but you can't use commas in your macros. You
> must write the numbers as they appear in the first columns of each
> group.)

> Extended Variables Normal Ultra 4 (integers only)
> --------------------------------------------------------------
>
> Lowest: -21,474,836.47 0
> Highest: 21,474,836.47 65,535

What I don't understand is this -- supposedly the AppleWorks Spreadsheet
doesn't suffer from these limitations, but I know for certain that it
uses the SANE package.

Hugh Hood

On Wednesday, December 22, 2021 at 9:15:26 PM UTC-8, Hugh Hood wrote:
> What I don't understand is this -- supposedly the AppleWorks Spreadsheet
> doesn't suffer from these limitations, but I know for certain that it
> uses the SANE package.

Do the 8-bit and 16-bit SANE packages have different limitations?

On 2021-12-23 05:15:19 +0000, Hugh Hood said:

> For some reason the math error and specifically the number 2147483648
> struck a memory I had about a similar issue with UltraMacros for
> AppleWorks.

2147483648 is 2^31, so the range of values that can be represented in a
signed 32-bit number is -2147483648 to 2147483647. I noticed the bug
in SANE by testing the behavior at the limits of various types,
although the bug can also affect other values.

> I finally found that it was referenced in Joe L. Walter's UltraMacros
> Reference Manual. I've quoted it below, but don't really know if it
> will be of any help to you. If not, please disregard.
<description from UltraMacros manual snipped>
>
> What I don't understand is this -- supposedly the AppleWorks
> Spreadsheet doesn't suffer from these limitations, but I know for
> certain that it uses the SANE package.

From the description you quoted, it sounds like the special variables
in UltraMacros use a 32-bit fixed point representation with two digits
after the decimal point. That is not a format used by SANE, so
UltraMacros probably does the computations directly without going
through SANE.

The AppleWorks spreadsheet is different and does use SANE. However, it
uses the 8-bit 6502 version of it, which I haven't tested. It is
possible it might have some of the same issues I found, but I don't
know, and even if it did I'm not sure if that would actually affect
anything in AppleWorks.

--
Stephen Heumann