AFAIK the result of an A-correlative has always been an integer.
That's why I don't store numbers with decimal points.
Ever heard of input conversions (i.e. MD2) ?
That allows your users to enter decimal points but stores the data
internally as integers.
In your case 399 * 3 = 1197 which with an
These aren't bugs. They are features :)
Going all the way back to the beginnings with pick and microdata/reality, math
in the F and A processing codes has been integer only. This was on purpose, for
speed I think. And it works fine if you follow the fundamental rule of not
using decimal points
I suspect part of the reason is accuracy, as well. Base 10 decimals don't
necessarily convert to an exact base 2 decimal. 1.2 converts to something like
1.001100110011001100110011... Storing them as integers, then manipulating
them within the code preserves the accuracy.
Drew
Kate
The original A and S types on PICK-like systems were designed purely with
integer arithmethic in mind - hence the use of the MDn and MRn conversions
to scale and descale. They are not designed for floating point work, so it's
no surprise they don't give the answers you expect.
And with
topas is great for watching you system performance in real time. I find
that an interval or time slice of around 7 seconds works best
Description
The topas command reports selected statistics about the activity on the
local system. The command uses the curses library to display its output
in
