Keith Thompson <kst-u@mib.org> writes:

> Richard <rgrdev@gmail.com> writes:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> [...]
>>> Another worry is that things one knows to true with certainty about
>>> some code today can be false tomorrow. Someone (I think is was Keith
>>> Thompson) said they "got nervous" about certain constructs (it was bit
>>> operations on signed types) and I thought how useful it is to have a
>>> well developed sense of nervousness in C. 'int' indexes make me a
>>> little nervous. Not a lot, a little.
>>
>> In what way? 0 to N. Nothing to worry about. N is well within the limits
>> 99.9999% of the time. And you need to be aware if it isn't in order to
>> specifically move to size_t or long or whatever.
>
> 100% is better than 99.9999%.

Ridiculous comment.

So do you use BIGINT libraries when you have any line which says

x+=y ?

My 99.99% thing was about when the programmer *knows* the limits of the
operation are in "int" capabilities. Also indicating he knows if the
limits are too much and then he can use the size_t. Yes, by using size_t
all the time he doesnt even have to think about it. But, hes a pretty
poor programmer if he is writing loops etc without some idea of the
scales involved.

>
> And probabilities like that tend not to apply to software. If you're
> convinced that something will work 99.9999% of the time, some
> malicious hacker could find a way to exploit the 0.0001% case.
>
>>> The '_t' is a bit ugly but what should the committee have done? I've
>>
>> Used a different name?
>
> Too late.

Yes. Obviously. It's just a civil conversation saying it is an ugley and
misleading name IMO for such a supposedly "core" type.

Larry__Weiss wrote On 10/29/07 22:14,:
> [...]
> Many common tax return computations use floating point calculations (at
> least for U.S. income taxes).
>
> Sales taxes are usually done as a percentage of an amount.

Sales taxes are usually *stated* as a percentage
but *computed* by table-lookup.

--
Eric.Sosman@sun.com

On Tue, 30 Oct 2007 11:06:51 -0400, Eric Sosman <Eric.Sosman@sun.com>
wrote:

>Larry__Weiss wrote On 10/29/07 22:14,:
>> [...]
>> Many common tax return computations use floating point calculations (at
>> least for U.S. income taxes).
>>
>> Sales taxes are usually done as a percentage of an amount.
>
> Sales taxes are usually *stated* as a percentage
>but *computed* by table-lookup.

Not in our software. Given the fact that we handle multiple tax rates
in multiple taxing jurisdictions, there would be an awful lot of
tables.

--
Al Balmer
Sun City, AZ

Tor Rustad wrote, On 29/10/07 23:50:
> Dann Corbit wrote:
>> Flash Gordon" <spam@flash-gordon.me.uk> wrote in message
>
> [...]
>
>>> Increasing the number of reads and writes by 10% would be unpopular
>>> unless it brought some other massive benefit, and your proposed
>>> change would not provide my customers with any benefit, only costs.
>>
>> I suspect that MonetDB may be ful for your application.
>> Frequently, read based problems have a huge benefit from in-memory
>> column storage (e.g. 10-100x faster).
>> You would need at least one machine with large memory, though.
>
> I rather suspect, nobody would really want to replace their financial
> DB2 or Nonstop DB systems. Changing the DB infrastructure on a
> business-critical system, could be very expensive.

It would be, especially as we have not yet gone as far as using an SQL
engine. We are actually using DIsam.

We are actually looking at moving to SQL databases as the back end and
have a long-running project working on the port, but there are specific
commercial reasons for the SQL engines we need to support.

> Performance requirements might be important, but correctness, risk,
> fault-tolerance, disaster-recovery, scalability, fail-over-time etc. are
> typically more important, at least if Gordon is not talking about some
> back-office system, but rather an online transaction environment, like
> e.g. a stock-exchange or an EFTPOS host.

It is a major back-office system. It is the system that a number of
large companies are using for entering all their requisitions, orders,
invoices and goods received notes, matching invoices to GRNs and lots of
other stuff. Also lots of reporting on all this data. It is business
critical for the companies using it.

> There is no simple answers to tuning such high-integrity systems, and
> the usual lesson apply, first perform measurement to identify the
> bottlenecks. If no benefits, don't do it.

Actually, the first rule is do not even consider looking at it or
bothering doing any measurements unless there is known to be a good
reason to start looking. As long as the code is fast enough (which it is
currently) we will concentrate on writing code to meet new and changed
requirements as correctly as possible and fixing the existing bugs. We
will only worry about measuring when there is a performance problem
significant enough to be worth the costs of investigating it.
--
Flash Gordon

"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
> Yes, but has anyone actually advised size_t in a case when the array
> index is certainly known to be less than INT_MAX?
>
I have. The problem is that a lot of arrays are unbounded but must be quite
small. It's quite hard to say what is the maximum number of children in a
class, for instance, but 255 is unmanageable.
The temptation is to use int for Nchildren. However you'll soon create a
situation where you've got a mix of signed and unsigned, int and size_t, and
you've got to juggle two types. It's manageable until you need to pass
indices by indirection, then all of a sudden the system gums up.
>
> The '_t' is a bit ugly but what should the committee have done? I've
> not seen a good alternative.
>
It should have realised that it wasn't fixing up a little problem with
malloc(). It was making a fundamental change to the language. Very few
size_t's hold sizes in terms of bytes of memory.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

"Richard Heathfield" <rjh@see.sig.invalid> wrote in message
> Malcolm McLean said:
>
> <snip>
>
>> if we're not doubling speed at least we aren't really speeding things up.
>
> Wrong. I can cite a 20% reduction in run-time in a (fairly hefty) program
> that had taken 25 seconds to produce one particular kind of quotation.
>
Another case is interactive graphics. It doesn't matter how long your
calculation takes as long as you make the next frame. If you miss it by a
few microseconds, you've got all of 17 millseconds to play with until the
next one come along.

However generally I regard a 100% speedup as about the threshold for code
worth my time optimising.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

user923005 wrote:

[...]

> I am not suggesting a replacement. I am suggesing a tool for OLAP.

OK, I assumed the financial system in question, rather was OLTP.

--
Tor <bwzcab@wvtqvm.vw | tr i-za-h a-z>

Dann Corbit wrote:
> "Tor Rustad" <tor_rustad@hotmail.com> wrote in message
> news:9c-dnQDPb81DwLva4p2dnAA@telenor.com...
>> Malcolm McLean wrote:
>>> In reality we would use a floating point rather than an integer type.
>> No, most financial institutions are not even allowed to use floating-point
>> for financial calculations. In fact, I have only seen fixed point
>> calculations, when dealing with money.
>
> Even for time value of money calculations (e.g. compound interest)?

I haven't programmed or audited code for compound interest calculations,
but when I analyzed all the COBOL sources (for Y2K bugs) of a major
in-house system, no floating-point code was scanned (approx 300.000 LOC).

COBOL has built in support for fixed-point calculations, so when dealing
with monetary computations on mainframes, that's the natural pick IMO.

--
Tor <bwzcab@wvtqvm.vw | tr i-za-h a-z>

On Oct 30, 4:41 pm, Tor Rustad <tor_rus...@hotmail.com> wrote:
> Dann Corbit wrote:
> > "Tor Rustad" <tor_rus...@hotmail.com> wrote in message
> >news:9c-dnQDPb81DwLva4p2dnAA@telenor.com...
> >> Malcolm McLean wrote:
> >>> In reality we would use a floating point rather than an integer type.
> >> No, most financial institutions are not even allowed to use floating-point
> >> for financial calculations. In fact, I have only seen fixed point
> >> calculations, when dealing with money.
>
> > Even for time value of money calculations (e.g. compound interest)?
>
> I haven't programmed or audited code for compound interest calculations,
> but when I analyzed all the COBOL sources (for Y2K bugs) of a major
> in-house system, no floating-point code was scanned (approx 300.000 LOC).
>
> COBOL has built in support for fixed-point calculations, so when dealing
> with monetary computations on mainframes, that's the natural pick IMO.

I would be very leery of fixed point calculations used to calculate
interest over time.

I use a modified version of Moshier's Qfloat and perform all
calculations with 100 digits of precision. It can calculate "U.S.
national debt" sized amounts over centuries and not lose a penny.

Of course, it is possible that your COBOL compiler has done something
like that.

Flash Gordon wrote:
> Tor Rustad wrote, On 29/10/07 23:50:

[...]

>> Performance requirements might be important, but correctness, risk,
>> fault-tolerance, disaster-recovery, scalability, fail-over-time etc.
>> are typically more important, at least if Gordon is not talking about
>> some back-office system, but rather an online transaction environment,
>> like e.g. a stock-exchange or an EFTPOS host.
>
> It is a major back-office system. It is the system that a number of
> large companies are using for entering all their requisitions, orders,
> invoices and goods received notes, matching invoices to GRNs and lots of
> other stuff. Also lots of reporting on all this data. It is business
> critical for the companies using it.

OK, if availability requirements (SLA) of this back-office system, are
near a major OLTP host, my point should still hold though.

>> There is no simple answers to tuning such high-integrity systems, and
>> the usual lesson apply, first perform measurement to identify the
>> bottlenecks. If no benefits, don't do it.
>
> Actually, the first rule is do not even consider looking at it or
> bothering doing any measurements unless there is known to be a good
> reason to start looking. As long as the code is fast enough (which it is
> currently) we will concentrate on writing code to meet new and changed
> requirements as correctly as possible and fixing the existing bugs. We
> will only worry about measuring when there is a performance problem
> significant enough to be worth the costs of investigating it.

Unless the transaction volume (and system) is rather static,
measurements are useful for capacity planning too. Since, the system is
business-critical for multiple companies, doing some measurements is
needed, view it as a stress test in the production environment.
Bottlenecks, can be an early-warning of a bug, or mis-configuration.

--
Tor <bwzcab@wvtqvm.vw | tr i-za-h a-z>

Tor Rustad wrote, On 31/10/07 00:14:
> Flash Gordon wrote:
>> Tor Rustad wrote, On 29/10/07 23:50:
>
> [...]
>
>>> Performance requirements might be important, but correctness, risk,
>>> fault-tolerance, disaster-recovery, scalability, fail-over-time etc.
>>> are typically more important, at least if Gordon is not talking about
>>> some back-office system, but rather an online transaction
>>> environment, like e.g. a stock-exchange or an EFTPOS host.
>>
>> It is a major back-office system. It is the system that a number of
>> large companies are using for entering all their requisitions, orders,
>> invoices and goods received notes, matching invoices to GRNs and lots
>> of other stuff. Also lots of reporting on all this data. It is
>> business critical for the companies using it.
>
> OK, if availability requirements (SLA) of this back-office system, are
> near a major OLTP host, my point should still hold though.

Well, a hundred people sitting twiddling their thumbs is expensive, as
is being fined for not getting your monthly returns in to the government
on time :-)

>>> There is no simple answers to tuning such high-integrity systems, and
>>> the usual lesson apply, first perform measurement to identify the
>>> bottlenecks. If no benefits, don't do it.
>>
>> Actually, the first rule is do not even consider looking at it or
>> bothering doing any measurements unless there is known to be a good
>> reason to start looking. As long as the code is fast enough (which it is
>> currently) we will concentrate on writing code to meet new and changed
>> requirements as correctly as possible and fixing the existing bugs. We
>> will only worry about measuring when there is a performance problem
>> significant enough to be worth the costs of investigating it.
>
> Unless the transaction volume (and system) is rather static,

For any given customer it tends to be fairly static once they are up and
running.

> measurements are useful for capacity planning too.

Well, we have measurements of how it performs in the real world, i.e.
how many users customers manage support on a given size of server with
an acceptable level of performance.

> Since, the system is
> business-critical for multiple companies, doing some measurements is
> needed, view it as a stress test in the production environment.

Ah, but we have the *real* stress test of real stressed users ;-)

> Bottlenecks, can be an early-warning of a bug, or mis-configuration.

Well, each customer has there system configured differently because they
all use it differently. Note that this is SW we sell to customers that
they run on their own servers.

Seriously, we (the company) have a lot of experience of how the system
performs in the real world, so those doing the testing of new releases
notice if the performance has been reduced significantly. Also because
of all this experience we don't need further measurements to tell
customers what size of server they need. With certain major upgrades
were we know performance could be affected we do some performance
testing, and if we ever need to do real optimisation we will do some
profiling (I've even found a suitable tool for us to use). However,
until we need to do optimisation we have more important things to do,
things which our customers consider more important.
--
Flash Gordon

"Tor Rustad" <tor_rustad@hotmail.com> wrote in message
> Malcolm McLean wrote:
>>
>> In reality we would use a floating point rather than an integer type.
>
> No, most financial institutions are not even allowed to use floating-point
> for financial calculations. In fact, I have only seen fixed point
> calculations, when dealing with money.
>
The mean of a set of integers is rational. It is not necessarily an integer.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

"Malcolm McLean" <regniztar@btinternet.com> wrote:

> "Tor Rustad" <tor_rustad@hotmail.com> wrote in message
> > Malcolm McLean wrote:
> >
> >> In reality we would use a floating point rather than an integer type.
> >
> > No, most financial institutions are not even allowed to use floating-point
> > for financial calculations. In fact, I have only seen fixed point
> > calculations, when dealing with money.
> >
> The mean of a set of integers is rational. It is not necessarily an integer.

That would argue for using a rational type, not a floating type.

Richard

Malcolm McLean wrote:
>
> "Tor Rustad" <tor_rustad@hotmail.com> wrote in message
>> Malcolm McLean wrote:
>>>
>>> In reality we would use a floating point rather than an integer type.
>>
>> No, most financial institutions are not even allowed to use
>> floating-point for financial calculations. In fact, I have only seen
>> fixed point calculations, when dealing with money.
>>
> The mean of a set of integers is rational. It is not necessarily an
> integer.

So, the mean can (usually) be represented internally exact.

Furthermore, many of the calculations needed for double entry
bookeeping, can be done exactly by banks.

--
Tor <bwzcab@wvtqvm.vw | tr i-za-h a-z>

Tor Rustad said:

> Malcolm McLean wrote:
>>
>> "Tor Rustad" <tor_rustad@hotmail.com> wrote in message
>>> Malcolm McLean wrote:
>>>>
>>>> In reality we would use a floating point rather than an integer type.
>>>
>>> No, most financial institutions are not even allowed to use
>>> floating-point for financial calculations. In fact, I have only seen
>>> fixed point calculations, when dealing with money.
>>>
>> The mean of a set of integers is rational. It is not necessarily an
>> integer.
>
> So, the mean can (usually) be represented internally exact.
>
> Furthermore, many of the calculations needed for double entry
> bookeeping, can be done exactly by banks.

Why "many" rather than "all"? Since double-entry book-keeping is a way of
recording financial transactions (i.e. transfers of an exact integer
number of base currency units, e.g. pennies, cents, pesos or whatever),
I'm struggling to imagine any real-world double-entry-relevant calculation
that /cannot/ be done exactly. Even if the numbers involved are colossal,
they can still be processed exactly. You might need a bignum lib to do it,
but you *can* do it.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Richard Heathfield wrote:
> Tor Rustad said:
>
>> Malcolm McLean wrote:
>>> "Tor Rustad" <tor_rustad@hotmail.com> wrote in message
>>>> Malcolm McLean wrote:
>>>>> In reality we would use a floating point rather than an integer type.
>>>> No, most financial institutions are not even allowed to use
>>>> floating-point for financial calculations. In fact, I have only seen
>>>> fixed point calculations, when dealing with money.
>>>>
>>> The mean of a set of integers is rational. It is not necessarily an
>>> integer.
>> So, the mean can (usually) be represented internally exact.
>>
>> Furthermore, many of the calculations needed for double entry
>> bookeeping, can be done exactly by banks.
>
> Why "many" rather than "all"? Since double-entry book-keeping is a way of
> recording financial transactions (i.e. transfers of an exact integer
> number of base currency units, e.g. pennies, cents, pesos or whatever),
> I'm struggling to imagine any real-world double-entry-relevant calculation
> that /cannot/ be done exactly. Even if the numbers involved are colossal,
> they can still be processed exactly. You might need a bignum lib to do it,
> but you *can* do it.

What if the currency of the transaction, is different from the currency
of the account?

We still have only one currency here, but e.g. UK banks could perhaps
accept transactions in Euro's too? How was the transition to Euro done
in France, Germany etc?

--
Tor <bwzcab@wvtqvm.vw | tr i-za-h a-z>

Tor Rustad said:

> Richard Heathfield wrote:
>> Tor Rustad said:
>>
<snip>
>>>
>>> Furthermore, many of the calculations needed for double entry
>>> bookeeping, can be done exactly by banks.
>>
>> Why "many" rather than "all"? Since double-entry book-keeping is a way
>> of recording financial transactions (i.e. transfers of an exact integer
>> number of base currency units, e.g. pennies, cents, pesos or whatever),
>> I'm struggling to imagine any real-world double-entry-relevant
>> calculation that /cannot/ be done exactly. Even if the numbers involved
>> are colossal, they can still be processed exactly. You might need a
>> bignum lib to do it, but you *can* do it.
>
> What if the currency of the transaction, is different from the currency
> of the account?

I think you'll find that the banks fudge the amount so that it comes to a
whole number of pennies/cents/whatever.

> We still have only one currency here, but e.g. UK banks could perhaps
> accept transactions in Euro's too? How was the transition to Euro done
> in France, Germany etc?

Badly, it seems. In 1997, 1 Euro was supposed to be worth around 73p, and
it's currently only worth about 69p, so it's dropped by about 5.5% over 10
years.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

On Nov 2, 10:37 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
> Badly, it seems. In 1997, 1 Euro was supposed to be worth around 73p, and
> it's currently only worth about 69p, so it's dropped by about 5.5% over 10
> years.

More accurately, both currencies have declined in value (due to
inflation) but the Euro has depreciated more rapidly than the Pound
since 1997.

>
> --
> Richard Heathfield <http://www.cpax.org.uk>
> Email: -http://www. +rjh@
> Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
> "Usenet is a strange place" - dmr 29 July 1999

Richard Heathfield wrote:
> Tor Rustad said:
>
>> Richard Heathfield wrote:
>>> Tor Rustad said:
>>>
> <snip>
>>>> Furthermore, many of the calculations needed for double entry
>>>> bookeeping, can be done exactly by banks.
>>> Why "many" rather than "all"? Since double-entry book-keeping is a way
>>> of recording financial transactions (i.e. transfers of an exact integer
>>> number of base currency units, e.g. pennies, cents, pesos or whatever),
>>> I'm struggling to imagine any real-world double-entry-relevant
>>> calculation that /cannot/ be done exactly. Even if the numbers involved
>>> are colossal, they can still be processed exactly. You might need a
>>> bignum lib to do it, but you *can* do it.
>> What if the currency of the transaction, is different from the currency
>> of the account?
>
> I think you'll find that the banks fudge the amount so that it comes to a
> whole number of pennies/cents/whatever.

I don't know what "fudge" means, but I assume you still argue your
point, as you always do!

I expect, account transfers in e.g. UK these days, to be available
between sterling and euro accounts, and such conversion could result in
rounding. That's the reason I wrote *many*, and not *all*.

I'm right, or I'm right?

--
Tor <bwzcab@wvtqvm.vw | tr i-za-h a-z>

Tor Rustad said:

> Richard Heathfield wrote:
>> Tor Rustad said:
>>
>>> Richard Heathfield wrote:
>>>> Tor Rustad said:
>>>>
>> <snip>
>>>>> Furthermore, many of the calculations needed for double entry
>>>>> bookeeping, can be done exactly by banks.
>>>> Why "many" rather than "all"? Since double-entry book-keeping is a way
>>>> of recording financial transactions (i.e. transfers of an exact
>>>> integer number of base currency units, e.g. pennies, cents, pesos or
>>>> whatever), I'm struggling to imagine any real-world
>>>> double-entry-relevant calculation that /cannot/ be done exactly. Even
>>>> if the numbers involved are colossal, they can still be processed
>>>> exactly. You might need a bignum lib to do it, but you *can* do it.
>>> What if the currency of the transaction, is different from the currency
>>> of the account?
>>
>> I think you'll find that the banks fudge the amount so that it comes to
>> a whole number of pennies/cents/whatever.
>
> I don't know what "fudge" means,

fiddle, tweak, finagle, frob...

> but I assume you still argue your
> point, as you always do!

Well, it's funny you should say that, because I'm going to stop arguing it
here. "I think you'll find" means precisely that - i.e. what I've said is
what I think happens, but I could certainly be wrong.

> I expect, account transfers in e.g. UK these days, to be available
> between sterling and euro accounts, and such conversion could result in
> rounding. That's the reason I wrote *many*, and not *all*.
>
> I'm right, or I'm right?

I don't know whether or not you are right. I suspect that you're mistaken,
but I could easily be wrong.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Francine.Neary@googlemail.com wrote:
> On Nov 2, 10:37 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
>> Badly, it seems. In 1997, 1 Euro was supposed to be worth around 73p, and
>> it's currently only worth about 69p, so it's dropped by about 5.5% over 10
>> years.
>
> More accurately, both currencies have declined in value (due to
> inflation) but the Euro has depreciated more rapidly than the Pound
> since 1997.
>

The Euro and the Pound have declined against what? The Pound buys
US$2.08 now. The Euro buys $1.45 or so. They seem strong against the dollar.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

"Richard Heathfield" <rjh@see.sig.invalid> wrote in message
news:XtydnZXsaupsOLbanZ2dnUVZ8t2snZ2d@bt.com...
> Tor Rustad said:
>
>> What if the currency of the transaction, is different from the currency
>> of the account?
>
> I think you'll find that the banks fudge the amount so that it comes to a
> whole number of pennies/cents/whatever.
>
> Badly, it seems. In 1997, 1 Euro was supposed to be worth around 73p,
> and it's currently only worth about 69p, so it's dropped by about 5.5%
> over
> 10 years.
>
1 Euro isn't worth 69p. If you can trade it at all you'd probably get more
like 50p for it. Trade thousands of Euros and you'll be able to get better
terms.

That's the answer to Tor's question. A bank cannot covert 100 Euros to 69
pounds 21.23456p applying the exchange rate. It's got to trade those Euros
with someone who has pounds. And it will settle on a whole number of
pennies.


--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Malcolm McLean wrote, On 03/11/07 07:13:
>
> "Richard Heathfield" <rjh@see.sig.invalid> wrote in message
> news:XtydnZXsaupsOLbanZ2dnUVZ8t2snZ2d@bt.com...
>> Tor Rustad said:
>>
>>> What if the currency of the transaction, is different from the currency
>>> of the account?
>>
>> I think you'll find that the banks fudge the amount so that it comes to a
>> whole number of pennies/cents/whatever.
>>
>> Badly, it seems. In 1997, 1 Euro was supposed to be worth around 73p,
>> and it's currently only worth about 69p, so it's dropped by about
>> 5.5% over
>> 10 years.
>>
> 1 Euro isn't worth 69p. If you can trade it at all you'd probably get
> more like 50p for it. Trade thousands of Euros and you'll be able to get
> better terms.
>
> That's the answer to Tor's question. A bank cannot covert 100 Euros to
> 69 pounds 21.23456p applying the exchange rate. It's got to trade those
> Euros with someone who has pounds. And it will settle on a whole number
> of pennies.

Similarly with all other transactions and accounting practices that I am
aware of. You are always *required* to round (either up to, down to or
to the nearest) whole whatever. The exact rounding rules change
depending on what you are doing, but they are always exactly specified.

Oh, and in our multi-currency system we store the amount in the original
currency and the exchange rate on each transaction so we can do exact
calculation in originating currency and correctly rounded calculations
in the target currency. This adds a whole load more integer calculations
on money to the SW.
--
Flash Gordon

Richard Heathfield wrote:
> Tor Rustad said:
>
>> Richard Heathfield wrote:
>>> Tor Rustad said:
>>>
>>>> Richard Heathfield wrote:
>>>>> Tor Rustad said:
>>>>>
>>> <snip>
>>>>>> Furthermore, many of the calculations needed for double entry
>>>>>> bookeeping, can be done exactly by banks.
>>>>> Why "many" rather than "all"? Since double-entry book-keeping is a way
>>>>> of recording financial transactions (i.e. transfers of an exact
>>>>> integer number of base currency units, e.g. pennies, cents, pesos or
>>>>> whatever), I'm struggling to imagine any real-world
>>>>> double-entry-relevant calculation that /cannot/ be done exactly. Even
>>>>> if the numbers involved are colossal, they can still be processed
>>>>> exactly. You might need a bignum lib to do it, but you *can* do it.
>>>> What if the currency of the transaction, is different from the currency
>>>> of the account?
>>> I think you'll find that the banks fudge the amount so that it comes to
>>> a whole number of pennies/cents/whatever.
>> I don't know what "fudge" means,
>
> fiddle, tweak, finagle, frob...

So, you talked about *rounding*.

FYI, calculations using rounding, are not done *exactly*.

--
Tor <bwzcab@wvtqvm.vw | tr i-za-h a-z>