Re: financial computations

Re: financial computations

[Robert Dewar]

In article <391725AA.4F68ED72@gmx.de>,
  Christoph Seelhorst <christoph.seelhorst@gmx.de> wrote:
> Hi,
>
> I am looking for a free Ada packet for financial computations.
I
> already checked my ASE CDs, could not find any there.
> My idea was to do some Ada program for my personal money
stuff, just as
> an exercise to get back to Ada (have to do C at work :-().
> Any hints are welcome.


Look at the information systems annex (fully implemented
in all GNAT versions) for helpful basic stuff for dealing
with high precision decimal values.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: financial computations

[Gautier]

Christoph Seelhorst:

> My idea was to do some Ada program for my personal money stuff, just as
> an exercise to get back to Ada (have to do C at work :-().

Maybe like _that_ : http://members.xoom.com/s_perret/ada.html ?

:-) G.

financial computations

[Christoph Seelhorst]

Hi,

I am looking for a free Ada packet for financial computations.  I
already checked my ASE CDs, could not find any there.
My idea was to do some Ada program for my personal money stuff, just as
an exercise to get back to Ada (have to do C at work :-().
Any hints are welcome.

Christoph

Re: financial computations

[Robert Dewar]

In article <39182A7C.C1358EE2@easystreet.com>,
  Al Christians <achrist@easystreet.com> wrote:
> Robert Dewar wrote:
> >
> > What artithmetic do you use in these functions?
> > Note that the use of floating-point for many financial
> > computations, e.g. interest rate calculations for many
> > instruments, is illegal.
> >
>
> This would be way off-topic for this newsgroup, except that
> you
> are stating it as a reason to use your firm's product, so I'll
> inquire:  What do you mean?  What instruments?  Illegal where?
> According to what law or ruling?   Are you typing about the
SIA
> rules for bond calculations?  Certainly not the truth in
lending
> law?  The Cobol Programmers' Full Employment Act?

No, I'm not stating it as "a reason to use [my] firm's product."
As far as I know, almost no one is doing fiscal calculations
in Ada 95. I do know of Ada 83 fiscal calculations that use
scaled integer arithmetic.

The point is that in several contexts, including bond interest
calculations, the calculation of interest must be done precisely
in decimal arithmetic, with specified truncation or rounding
semantics. You can only approximate this in floating-point.

> Fixed-point decimal exponentiation is what ought to be
> illegal, on  the grounds that it takes to long, as anyone who
> has done this in Cobol knows too well.

COBOL has no defined semantics for exponentiation, so I do not
know what you are talking about here at all.



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: financial computations

[Robert Dewar]

In article <39188680.ECE27C06@quadruscorp.com>,
  "Marin D. Condic" <mcondic-nospam@quadruscorp.com> wrote:
> I suppose I should put some disclaimer, etc. on that web page.

You definitely should put a disclaimer there. A lack of a
disclaimer can be interpreted as a warrancy of fitness for
purpose in some jurisdictions. THe fact that you do not charge
for software in no way releives you of consequential damages
if you are

> Maybe even some licensing stuff

Indeed! right now you have copyrighted material on your web
site, and as far as I see no one can download copies of it
without violating that copyright.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: financial computations

[Al Christians]

Robert Dewar wrote:
> in several contexts, including bond interest
> calculations, the calculation of interest must be done precisely
> in decimal arithmetic, with specified truncation or rounding
> semantics. You can only approximate this in floating-point.

That's not quite the same thing as illegal, is it?

With 64-bit mantissae available in several programming languages, 
including Ada according to GNAT, if I know the rules, I can 
approximate this stuff for a million lifetimes before I lose 
a cent.  Realistically, I expect that when I do lose that penny 
there will be some character at hand who will point out the 
error and gloat without mercy. I would hate to deny him that 
pleasure.  It's like playing solitaire.  If I always did it 
according to the book, what would the kibitzers do?  How could
I sustain my humility without at least one grievous error per 
eon?

> 
> 
> COBOL has no defined semantics for exponentiation, so I do not
> know what you are talking about here at all.
> 

Let me practice some mentalism, go a little deeper into my catatonic 
trance, and look deep into our past ....   I see a COBOL compiler  
... I see ADD ... I see SUBTRACT ... I see MULTIPLY ... I see DIVIDE 
... but I don't see EXPONENTIATE.  Could be you are right about 
this one, Robert. But wait, what's this?  I see COMPUTE ...  It has 
expressions ...  It has arithmetic operators ... It has +, -, /, *, 
and, aha,  ** for exponentiation ... and ** is very, very  slow.  
When I wake up it will be almost finished ....

Re: financial computations

[DuckE]

> With 64-bit mantissae available in several programming languages,
> including Ada according to GNAT, if I know the rules, I can
> approximate this stuff for a million lifetimes before I lose
> a cent.  Realistically, I expect that when I do lose that penny
> there will be some character at hand who will point out the
> error and gloat without mercy. I would hate to deny him that
> pleasure.  It's like playing solitaire.  If I always did it
> according to the book, what would the kibitzers do?  How could
> I sustain my humility without at least one grievous error per
> eon?
>

I'm speaking out of my field, but I vaguely remember learning something
about this in college (more than 15 years ago).  As I recall obtaining the
"correct" answer in financial calculations has as much (or more) to do with
convention, than with precise mathematical results.

I wonder if there's a newsgroup alt.bean-counter.calculations?

;-)

SteveD

Re: financial computations

[Robert Dewar]

In article <39182D26.F4FDB0F8@quadruscorp.com>,
  "Marin D. Condic" <mcondic-nospam@quadruscorp.com> wrote:
> Check my web page. Under the Ada Programming page, there is a
page
> called Utilities Version 3a which contains a large number of
financial
> functions. (Along with many other things! :-) If there are
computations
> that you want which are not there, let me know and maybe I can
add them.

What artithmetic do you use in these functions?
Note that the use of floating-point for many financial
computations, e.g. interest rate calculations for many
instruments, is illegal.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: financial computations

[Al Christians]

Robert Dewar wrote:
> 
> What artithmetic do you use in these functions?
> Note that the use of floating-point for many financial
> computations, e.g. interest rate calculations for many
> instruments, is illegal.
> 

This would be way off-topic for this newsgroup, except that you
are stating it as a reason to use your firm's product, so I'll
inquire:  What do you mean?  What instruments?  Illegal where?
According to what law or ruling?   Are you typing about the SIA
rules for bond calculations?  Certainly not the truth in lending
law?  The Cobol Programmers' Full Employment Act?  

Fixed-point decimal exponentiation is what ought to be illegal, on 
the grounds that it takes to long, as anyone who has done this in
Cobol knows too well.  Interest calculations often require 
exponentiation with non-integer exponents.  The results of these 
calculations cannot be computed exactly, so any means of computation, 
fixed or floating point is an approximation.  I can see that the law 
might require some certain accuracy in the approximations, but I 
don't expect that the law would care whether the decimal point was 
fixed or floating through the intermediate calculations.   With
enough precision, either approach could match the monetary values
produced by the other.


Al

Re: financial computations

[Marin D. Condic]

Christoph Seelhorst wrote:
> 
> Hi,
> 
> I am looking for a free Ada packet for financial computations.  I
> already checked my ASE CDs, could not find any there.
> My idea was to do some Ada program for my personal money stuff, just as
> an exercise to get back to Ada (have to do C at work :-().
> Any hints are welcome.
> 
Check my web page. Under the Ada Programming page, there is a page
called Utilities Version 3a which contains a large number of financial
functions. (Along with many other things! :-) If there are computations
that you want which are not there, let me know and maybe I can add them.

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

"I'd trade it all for just a little more"
    --  Charles Montgomery Burns, [4F10]
======================================================================

Re: financial computations

[Marin D. Condic]

Robert Dewar wrote:
> What artithmetic do you use in these functions?

Take a look and see. Most stuff is done with decimal types, but some
computations take floating point. (Generic parameters, of course.)
There's places where it makes sense.

> Note that the use of floating-point for many financial
> computations, e.g. interest rate calculations for many
> instruments, is illegal.
> 
Goodness! The Software Police are going to come get me now! Where can I
hide? :-)

I make no claims as to the appropriateness or fitness for a given
purpose any of the stuff I've put out there may have. If there are legal
requirements that must be satisfied for what you are implementing, then
I guess you need to make sure you satisfy them. My code might serve as
an example of how the computations should be done.

I suppose I should put some disclaimer, etc. on that web page. Maybe
even some licensing stuff. But so few people seem to be using any of it
that I have not bothered.

BTW: If you look over the computations and have suggestions for
improvements, feel free to send them to me.

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

"I'd trade it all for just a little more"
    --  Charles Montgomery Burns, [4F10]
======================================================================

Re: financial computations

[Al Christians]

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

Re: financial computations

[Robert A Duff]

Al Christians <achrist@easystreet.com> writes:

> Seems that Gnat implemented these as an array of nibbles (4-bit 

Isn't "nybble" the correct spelling?

- Bob

Re: financial computations

[Robert Dewar]

In article <3918A193.9800E973@easystreet.com>,
  Al Christians <achrist@easystreet.com> wrote:
> Robert Dewar wrote:
> > in several contexts, including bond interest
> > calculations, the calculation of interest must be done
precisely
> > in decimal arithmetic, with specified truncation or rounding
> > semantics. You can only approximate this in floating-point.
>
> That's not quite the same thing as illegal, is it?

Actually, yes it is. The relevant codes require adherence
to the prescribed approaches, and specify penalties for
non-compliance.

> With 64-bit mantissae available in several programming
> languages,
> including Ada according to GNAT, if I know the rules, I can
> approximate this stuff for a million lifetimes before I lose
> a cent.

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 (you might want to look
at what Kahan has to say about decimal vs binary arithmetic,
there are a LOT of surprises for the uninitiated there).

> Realistically, I expect that when I do lose that penny
> there will be some character at hand who will point out the
> error and gloat without mercy.

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

> > COBOL has no defined semantics for exponentiation, so I do
not
> > know what you are talking about here at all.
> >

> Let me practice some mentalism, go a little deeper into my
> catatonic  trance, and look deep into our past ....   I see a
> COBOL compiler   ... I see ADD ... I see SUBTRACT ... I see
> MULTIPLY ... I see DIVIDE ... but I don't see EXPONENTIATE.
> Could be you are right about this one, Robert. But wait,
> what's this?  I see COMPUTE ...  It has expressions ...  It
> has arithmetic operators ... It has +, -, /, *,  and, aha,  **
> for exponentiation ... and ** is very, very  slow. When I wake
> up it will be almost finished ....

Well I have to admit that I set a bit of a trap there that you
fell right into. 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. It is for example
quite fine to use floating-point for all calculations in
COMPUTE. There was even talk of REQUIRING the use of IEEE
long form floating-point for COMPUTE in the 9x standard, but
that was too controversial. There is definitely no need for
** to be very very slow, given that it can perfectly well
be done in floating-point.

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++). That's an important
difference with the verbs ADD SUBTRACT MULTIPLY DIVIDE which
have precise implementation-independent semantics. So I am
afraid your catatonic trance is not serving you well. COBOL is
a fairly complex language. Few know it really well from a
language definition point of view, and the subset of people
who really know COBOL *and* Ada 95 is even smaller.

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 :-)

Robert Dewar


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: financial computations

[Robert Dewar]

In article <3918be1c.0@news.pacifier.com>,
  "DuckE" <nospam_steved@pacifier.com> wrote:

> I'm speaking out of my field, but I vaguely remember learning
something
> about this in college (more than 15 years ago).  As I recall
obtaining the
> "correct" answer in financial calculations has as much (or
more) to do with
> convention, than with precise mathematical results.


Right, obviously you cannot compute the interest on a 7.5%
bond completely accurately, and there are all sorts of
complications (for example, sometimes bonds have an annual
yield, meaning that they are a worse buy in leap years, but
more often the nominal yearly yield is converted to a daily
yield).

The instrument will typically specify *EXACTLY* how the
interest is to be computed, down to whether rounded or
truncated computations should be used. The result of these
calculations *IS* the actual interest on the bond (precisely,
it is not an approximation, since the yield is defined by
the definition of these calculations -- the nominal 7.5% is
just that, nominal). So your vague memory here is exactly
right.


Sent via Deja.com http://www.deja.com/
Before you buy.