[Date Prev][Date Next][Subject Prev][Subject Next][ Date Index][ Subject Index]

Calculate?



Dear SysOp:

Have you noticed the anomalous way that function SM evaluates arithmetic
expressions containing parentheses? Consider the following examples (values to
the right of the equal sign are the results returned by func SM):

A: 1+1=2 B: (1+1)=-2 C: 1+(1+1)=3 D: (1+1)+1=-1 E: (1+(1+1))=-3 F: 1+(1+1)+1=4

Examples A and B suggest that func SM attempts to recognize the accountant's
convention of showing negative numbers with parentheses. Fair enough. But
look at C and D! Both of these expressions logically should evaluate to 3, but
in D the parenthetical is evaluated first as -2, which is then added to 1 to
give -1. In other words, in C the parentheses function as *logical* operands,
whereas in D they're interpreted as accountant's parens. Examples E and F
reveal the same inconsistent usage. The "rule" seems to be that an initial
open parens signals the accountant's convention (even if the parens don't
enclose the whole expression!), whereas internal parens are interpreted
logically. The result is a very strange-looking math!

In my view, to preserve the mathematical integrity of func SM, the accountant's
convention should be abandoned -- or at least there should be a default value
to suppress its being taken into account. It's hard to feel confident about
using func SM for real-world applications when it yields results like those
above! For this reason, I abandoned it in the little calculator program
attached to the preceding message and used the PV operator instead. I would
have preferred func SM because it automatically inserts commas in large numbers
-- a nice amenity. However, accuracy has got to be the first order of
business!