Re: financial computations

[Al Christians <achrist@easystreet.com>]

Robert Dewar wrote:
> 
> The relevant codes require adherence
> to the prescribed approaches, and specify penalties for
> non-compliance.
> 

Can you give a specific example?

> 
> That's quite incorrect, because you need to control whether
> each operation truncates or rounds, and that is not possible
> with floating-point, since the floating-point engine itself
> is typically set to round all the time, and as I am sure you
> know rounding followed by truncatation is not equivalent to
> truncation. Also everything has to be done as if it were in
> scaled decimal. You cannot use floating-point binary to
> accurately represent scaled decimal 

I've yet to see a set of legal requirements that required anywhere
near the 18 or so digits that my FPU will support.  If rounding or
truncation at a certain digit is mandated by the requirements, I
can do that explicitly, although approximately.  There is some little
bit of round-off or truncation error, but all that is happening down 
around $0.0000000000001 on a million-dollar bond, so the chance that 
it has any effect on any number actually looked at or used by anyone 
is way less than my chance of winning the 300 megabuck lottery, and 
I didn't even buy a ticket.   If you have any specific example where 
that's not so, I'd love to see it.

> 
> The problems are very much worse than simply losing a penny!
> 

Can you give a specific example?

> Well I have to admit that I set a bit of a trap there that you
> fell right into. 

How do you live with yourself?  

> I assure you I would not have made the
> statement about ** being undefined without knowing what I
> was talking about (I know COBOL rather well, see below) :-)
> COMPUTE has undefined arithmetic semantics. 

That which is not elsewhere defined is defined by an 
implementation.  

> There is definitely no need for ** to be very very slow, 
> given that it can perfectly well be done in floating-point.
> 

So why was it so slow?  Were you pushing data into the FPU one
byte at a time?  Using a slow FPU emulation library?  Or doing 
the exponentiation in fixed point as some kind of a power series?      
BTW, for everything else,  Realia's performance was good, but
not for exponentiation.  Questions for the Supreme Court:  
(1) If I do the calculations using FPU emulation on a machine 
that has only fixed-point instructions, is that legal or not 
legal under the statutes in question?  (2) If I write a program 
that I think is fixed point to comply with the law, but my 
compiler or firmware was written by some genius who knows how
much faster the FPU is, so he uses it behind my back, will we
both go to jail? 

> However, many (most?) COBOL shops deprecate, or even forbid
> the use of COMPUTE completely precisely because it has undefined
> semantics (just like Fortran, or C, or C++). 

I've known several that strongly discouraged it, but only because it
was so slow.

> By the way, in case people don't know I was one of the principle
> authors of Realia COBOL, one of the main PC based COBOL
> compilers, now marketed by Computer Associates, so I am indeed
> a member of that smaller subset :-)
> 

BTW, that reminds me, to get back on topic, has the implementation 
of Comp-3 packed decimals in Gnat been changed yet so that the 
binary representation will be compatible with the likes of Realia?  
Seems that Gnat implemented these as an array of nibbles (4-bit 
digits), and one can't make any assumptions about the position of 
nibbles in an array within a byte in Ada, and Gnat actually mapped 
the nibble with the lower subscript to the least significant bits 
of the byte, but your packed decimal routines did make the opposite 
assumption.  I have code to fix this around here somewhere if 
you'd like to see it.



Al