"Flash Gordon" <spam@flash-gordon.me.uk> wrote in message
> 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.
>
You can use a double to hold integers. It has got several advantages, such
as being able to hold more digits of precision than a 32 bit type, degrading
gracefully under hyperinflation - it will no longer give exact results, of
course, but if there are 6 trillion dollars to the pound that will be the
least of any American's worries - and giving you a free check that rounding
has actually been applied.

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

"Malcolm McLean" <regniztar@btinternet.com> writes:
[...]
> You can use a double to hold integers. It has got several advantages,
> such as being able to hold more digits of precision than a 32 bit
> type, degrading gracefully under hyperinflation - it will no longer
> give exact results, of course, but if there are 6 trillion dollars to
> the pound that will be the least of any American's worries - and
> giving you a free check that rounding has actually been applied.

As I understand it, inexact results in monetary calculations are
*never* acceptable. Using a floating-point type might give you an
acceptable range over which exact values can be represented, but if
you go outside that range you *silently* get inexact results.

In a typical modern implementation, both double and long long are 64
bits -- but long long doesn't waste bits on an exponent, and can
therefore represent a much wider range of integer values exactly.
Many implementations that don't support long long nevertheless support
a 64-bit integer type by another name.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

"Keith Thompson" <kst-u@mib.org> wrote in message
news:lnodebyzto.fsf@nuthaus.mib.org...
>As I understand it, inexact results in monetary calculations are
>*never* acceptable.
>
These sorts of rules go out of the window when you have hyperinflation. If
the dollar becomes nearly worthless - which <OT> is what will happen if the
Fed doesn't sharpen up its attitude to liquidity </OT> the amounts cease to
have any real meaning anyway. Your users will just be glad that the system
is still handling transactions.
>
> In a typical modern implementation, both double and long long are 64
> bits -- but long long doesn't waste bits on an exponent, and can
> therefore represent a much wider range of integer values exactly.
> Many implementations that don't support long long nevertheless support
> a 64-bit integer type by another name.
>
I see you edging towards the camapign for 64 bit ints.

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

Tor Rustad said:
> 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.
>>>>>> [...] 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?
<snip>
>
> So, you talked about *rounding*.
>
> FYI, calculations using rounding, are not done *exactly*.

Fine, but we're actually talking about different things. I'm talking about
"calculations needed for double entry bookkeeping". You are talking about
"calculations needed for currency conversion". These are two different
ideas.

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

"Malcolm McLean" <regniztar@btinternet.com> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message
> news:lnodebyzto.fsf@nuthaus.mib.org...
>>As I understand it, inexact results in monetary calculations are
>>*never* acceptable.
>>
> These sorts of rules go out of the window when you have
> hyperinflation. If the dollar becomes nearly worthless - which <OT> is
> what will happen if the Fed doesn't sharpen up its attitude to
> liquidity </OT> the amounts cease to have any real meaning
> anyway. Your users will just be glad that the system is still handling
> transactions.

Hyperinflation is unlikely to cause amounts of money to exceed 2**64-1
(about 18 quintillion). Even if it did, the response would almost
certainly be to issue a new devalued currency (one new dollar equal to
one trillion old dollars, for example).

>> In a typical modern implementation, both double and long long are 64
>> bits -- but long long doesn't waste bits on an exponent, and can
>> therefore represent a much wider range of integer values exactly.
>> Many implementations that don't support long long nevertheless support
>> a 64-bit integer type by another name.
>>
> I see you edging towards the camapign for 64 bit ints.

Absolutely not. If you think I am, you need to re-read what I've
written (and remember that "int" and "integer" are not synonymous).

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

"Keith Thompson" <kst-u@mib.org> wrote in message
> Hyperinflation is unlikely to cause amounts of money to exceed 2**64-1
> (about 18 quintillion). Even if it did, the response would almost
> certainly be to issue a new devalued currency (one new dollar equal to
> one trillion old dollars, for example).
>
The Eurpean Central bank pumped in 400 billions of Euros of liquidity last
August. There are about 650 billion Euros of currency in circulation. They
are hoping that most of that 400 billion will come back in before anyone
demands it in cash, however assuming that the full amount is taken up, they
will need to pump in about 600 billion to have the same effect next time.
Then it will be 1 trillion. Printing money is O(N^2). Pull that trick more
than a few times and you'll get up to 18 quintillion remarkably quickly.

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

Richard Heathfield wrote:
> Tor Rustad said:
>> 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.
>>>>>>> [...] 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?
> <snip>
>> So, you talked about *rounding*.
>>
>> FYI, calculations using rounding, are not done *exactly*.
>
> Fine, but we're actually talking about different things. I'm talking about
> "calculations needed for double entry bookkeeping". You are talking about
> "calculations needed for currency conversion". These are two different
> ideas.

Methinks, you initially only considered single currency.

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

Keith Thompson wrote, On 03/11/07 18:00:
> "Malcolm McLean" <regniztar@btinternet.com> writes:
> [...]
>> You can use a double to hold integers. It has got several advantages,
>> such as being able to hold more digits of precision than a 32 bit
>> type, degrading gracefully under hyperinflation

The only degradation an accountant would consider graceful would be an
error message along the lines of, "I am most terribly sorry but your
finances are beyond my humble capacity to compute."

> - it will no longer
>> give exact results, of course,

In other words incorrect and leading to the company submitting them as
accounts or using them for any of a number of other purposes being find
large (to the company) amounts of money.

> but if there are 6 trillion dollars to
>> the pound that will be the least of any American's worries - and
>> giving you a free check that rounding has actually been applied.
>
> As I understand it, inexact results in monetary calculations are
> *never* acceptable.

Correct. If the tax returns are found to be incorrect that can lead to
large fines. If you submit accounts that are incorrect you can get
fined. If you sell the SW that is provably at fault in such cases then
the company could pursue you for damages.

> Using a floating-point type might give you an
> acceptable range over which exact values can be represented,

Yes, and people have actually used double for precisely that reason.

> but if
> you go outside that range you *silently* get inexact results.
>
> In a typical modern implementation, both double and long long are 64
> bits -- but long long doesn't waste bits on an exponent, and can
> therefore represent a much wider range of integer values exactly.
> Many implementations that don't support long long nevertheless support
> a 64-bit integer type by another name.

Agreed. Having a 64 bit integer type available when you need it is very
useful. Having fixed point arithmetic (especially fixed decimal point
rather than binary point) would also be very useful, more useful for me
that a lot of what went in to C99 ;-).
--
Flash Gordon

Tor Rustad said:

> Richard Heathfield wrote:
>> Tor Rustad said:
>>>
>>> FYI, calculations using rounding, are not done *exactly*.
>>
>> Fine, but we're actually talking about different things. I'm talking
>> about "calculations needed for double entry bookkeeping". You are
>> talking about "calculations needed for currency conversion". These are
>> two different ideas.
>
> Methinks, you initially only considered single currency.

Yes, that's right, I did. And the introduction of a discussion of multiple
currencies blurred the issue in my mind for a little while. Taking a step
back and thinking about it, I realised it represented a completely
separate issue.

I still stand by my statement that you can do double-entry book-keeping
*exactly*.

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

"Flash Gordon" <spam@flash-gordon.me.uk> wrote in message
>
> Correct. If the tax returns are found to be incorrect that can lead to
> large fines. If you submit accounts that are incorrect you can get fined.
> If you sell the SW that is provably at fault in such cases then the
> company could pursue you for damages.
>
The British Inland Revenue doesn't care about odd pennies. It might be
different in other jurisdictions.
Accountants do, but for internal quality control purposes.

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

Malcolm McLean wrote, On 03/11/07 23:44:
> "Flash Gordon" <spam@flash-gordon.me.uk> wrote in message
>>
>> Correct. If the tax returns are found to be incorrect that can lead to
>> large fines. If you submit accounts that are incorrect you can get
>> fined. If you sell the SW that is provably at fault in such cases then
>> the company could pursue you for damages.
>>
> The British Inland Revenue doesn't care about odd pennies. It might be
> different in other jurisdictions.

My SW sends data direct to HMRC and they *do* care about pennies, just
not in the way you might expect. On certain returns you are *required*
to specify pounds and pence and the pence are *required* to be .00, and
they specify the rounding (which is down) that you are *required* to
use. Getting the pounds wrong (and you only have to be one penny out to
do that sometimes) is not permitted.

Also, pennies add up to a lot of money.

> Accountants do, but for internal quality control purposes.

They care for more than that since the pennies add up.

Also, this was with reference to using floating point numbers in
financial SW and what happens when you get beyond the range that can be
accurately represented, that can lead to errors far larger than pennies.
--
Flash Gordon

>Keith Thompson wrote, On 03/11/07 18:00:
>> As I understand it, inexact results in monetary calculations are
>> *never* acceptable.

Well, it depends on the purpose of the calculations ... for instance
if I am doing a rough estimate of future values of various funds
flows, I do not need exact results, because I am putting in estimates
for rates of return and only expect a rough estimate as output. :-)

However, in other areas, well:

In article <fa8vv4xpdr.ln2@news.flash-gordon.me.uk>,
Flash Gordon <spam@flash-gordon.me.uk> wrote:
>Correct. If the tax returns are found to be incorrect that can lead to
>large fines. If you submit accounts that are incorrect you can get
>fined. If you sell the SW that is provably at fault in such cases then
>the company could pursue you for damages.

Someone rather more well off than I am used a certain Borland
product to calculate his US taxes, some years ago. He actually
owed somewhere around five million dollars, if I remember right;
but the tax software claimed he owed a negative number.

He called their support people and directed their attention to
their guarantee of correctness, which said that, in the case of
any error on their part, they would pay the difference between what
their software computed, and what was actually owed. Fun times
ensued. :-)

(The culprit turned out to be internal use of 32-bit integer types.
Once the correct number was computed, he had another adventure:
it turns out that one cannot write ordinary checks [or "cheques",
for those in the UK and Canada] for more than about one million
dollars at a time. In his case, it sufficed to simply send five
of them.)

>... Having a 64 bit integer type available when you need it is very
>useful. Having fixed point arithmetic (especially fixed decimal point
>rather than binary point) would also be very useful, more useful for me
>that a lot of what went in to C99 ;-).

One can always use the 64-bit integral type along with "manual"
fixed-point scaling, so that, e.g., 215256249812543 represents
$2,152,562,498,125.43 (a little over two trillion dollars, or about
what Iraq will most likely cost US taxpayers). One must still take
care to avoid rounding errors with internal calculations, though;
I note that a number of COBOL compilers allow up to 63 decimal
digits in intermediate results, to avoid problems here.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

Chris Torek wrote, On 04/11/07 10:07:
>> Keith Thompson wrote, On 03/11/07 18:00:
>>> As I understand it, inexact results in monetary calculations are
>>> *never* acceptable.
>
> Well, it depends on the purpose of the calculations ... for instance
> if I am doing a rough estimate of future values of various funds
> flows, I do not need exact results, because I am putting in estimates
> for rates of return and only expect a rough estimate as output. :-)

Yes, I can see that. The same would actually apply to some of the
reports we produce which are purely for budgetary purposes. However, so
much is for purposes where accuracy is a legal requirement that we just
do everything accurately.

> However, in other areas, well:
>
> In article <fa8vv4xpdr.ln2@news.flash-gordon.me.uk>,
> Flash Gordon <spam@flash-gordon.me.uk> wrote:
>> Correct. If the tax returns are found to be incorrect that can lead to
>> large fines. If you submit accounts that are incorrect you can get
>> fined. If you sell the SW that is provably at fault in such cases then
>> the company could pursue you for damages.
>
> Someone rather more well off than I am used a certain Borland
> product to calculate his US taxes, some years ago. He actually
> owed somewhere around five million dollars, if I remember right;
> but the tax software claimed he owed a negative number.

Humans often beet computers at spotting the obviously wrong results :-)

> He called their support people and directed their attention to
> their guarantee of correctness, which said that, in the case of
> any error on their part, they would pay the difference between what
> their software computed, and what was actually owed. Fun times
> ensued. :-)

Yes, I can imagine.

> (The culprit turned out to be internal use of 32-bit integer types.
> Once the correct number was computed, he had another adventure:
> it turns out that one cannot write ordinary checks [or "cheques",
> for those in the UK and Canada] for more than about one million
> dollars at a time. In his case, it sufficed to simply send five
> of them.)

Seems a daft restriction to me.

>> ... Having a 64 bit integer type available when you need it is very
>> useful. Having fixed point arithmetic (especially fixed decimal point
>> rather than binary point) would also be very useful, more useful for me
>> that a lot of what went in to C99 ;-).
>
> One can always use the 64-bit integral type along with "manual"
> fixed-point scaling, so that, e.g., 215256249812543 represents
> $2,152,562,498,125.43 (a little over two trillion dollars, or about
> what Iraq will most likely cost US taxpayers).

This is, indeed, what we do. It would just simplify the SW a lot if we
did not have to do it.

> One must still take
> care to avoid rounding errors with internal calculations, though;
> I note that a number of COBOL compilers allow up to 63 decimal
> digits in intermediate results, to avoid problems here.

Old languages still have some advantages :-)
--
Flash Gordon

On Nov 3, 2:54 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
> Tor Rustad said:
>
> > Richard Heathfield wrote:
> >> Tor Rustad said:
>
> >>> FYI, calculations using rounding, are not done *exactly*.
>
> >> Fine, but we're actually talking about different things. I'm talking
> >> about "calculations needed for double entry bookkeeping". You are
> >> talking about "calculations needed for currency conversion". These are
> >> two different ideas.
>
> > Methinks, you initially only considered single currency.
>
> Yes, that's right, I did. And the introduction of a discussion of multiple
> currencies blurred the issue in my mind for a little while. Taking a step
> back and thinking about it, I realised it represented a completely
> separate issue.
>
> I still stand by my statement that you can do double-entry book-keeping
> *exactly*.

I disagree. If there are any rational or exponential calculations,
then it is not possible.
Examples:
Depreciation calculations
Interest calculations
Investments (Future value, Present value, Annuities...)

user923005 said:

> On Nov 3, 2:54 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
>> [...] the introduction of a discussion of
>> multiple currencies blurred the issue in my mind for a little while.
>> Taking a step back and thinking about it, I realised it represented a
>> completely separate issue.
>>
>> I still stand by my statement that you can do double-entry book-keeping
>> *exactly*.
>
> I disagree. If there are any rational or exponential calculations,
> then it is not possible.
> Examples:
> Depreciation calculations
> Interest calculations
> Investments (Future value, Present value, Annuities...)

Yes, but it's the same blurring. The "how much interest should be added?"
question cannot be answered exactly (except by chance, of course) - it
must be rounded. But double-entry book-keeping is about putting one
*monetary* amount into two ledgers, once on the debit side and once on the
credit side. This can be done exactly.

--
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, On 05/11/07 23:40:
> user923005 said:
>
>> On Nov 3, 2:54 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
>>> [...] the introduction of a discussion of
>>> multiple currencies blurred the issue in my mind for a little while.
>>> Taking a step back and thinking about it, I realised it represented a
>>> completely separate issue.
>>>
>>> I still stand by my statement that you can do double-entry book-keeping
>>> *exactly*.
>> I disagree. If there are any rational or exponential calculations,
>> then it is not possible.
>> Examples:
>> Depreciation calculations
>> Interest calculations
>> Investments (Future value, Present value, Annuities...)
>
> Yes, but it's the same blurring. The "how much interest should be added?"
> question cannot be answered exactly (except by chance, of course) - it
> must be rounded.

In the case of interest calculations (an a lot of other financial
calculations), the rounding is actually part of the definition of the
algorithm you are required to use in calculating the new value. So it
can be argued that such calculations always provide an exact answer.

> But double-entry book-keeping is about putting one
> *monetary* amount into two ledgers, once on the debit side and once on the
> credit side. This can be done exactly.

Not only can, but is actually required to be done exactly.
--
Flash Gordon

user923005 <dcorbit@connx.com> writes:

> > I still stand by my statement that you can do double-entry book-keeping
> > *exactly*.
>
> I disagree. If there are any rational or exponential calculations,
> then it is not possible.
> Examples:
> Depreciation calculations
> Interest calculations
> Investments (Future value, Present value, Annuities...)

My impression was that there are reglementary texts who precise exactly how
those should be computed, included the rounding rules.

BTW, I doubt very much that they have any relationship with the rounding
rules of any implementation of floating point, even decimal FP. And we
know the problems caused by double rounding.

Yours,

--
Jean-Marc

Flash Gordon said:

> Richard Heathfield wrote, On 05/11/07 23:40:

<snip>

>> But double-entry book-keeping is about putting one
>> *monetary* amount into two ledgers, once on the debit side and once on
>> the credit side. This can be done exactly.
>
> Not only can, but is actually required to be done exactly.

THANK you! At last someone sees what I'm getting at. I was beginning to
despair of my ability to explain this.

--
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:
> Flash Gordon said:
>
>> Richard Heathfield wrote, On 05/11/07 23:40:
>
> <snip>
>
>>> But double-entry book-keeping is about putting one
>>> *monetary* amount into two ledgers, once on the debit side and once on
>>> the credit side. This can be done exactly.
>> Not only can, but is actually required to be done exactly.
>
> THANK you! At last someone sees what I'm getting at. I was beginning to
> despair of my ability to explain this.

Tor's Theorem 1:

R.H. is not always correct, when he think he is.

Proof:

Double-entry bookkeeping, means there will be at least two accounts. For
sake of argument, let us pick a UK bank, with both sterling and euro
accounts.

The whole point about double-entry, is to detect errors and fraud, a
bank insider (with access to one account), who tries to credit an
account will probably be caught, when there is a mis-match between the
two "books" (assuming proper audit trails exists).

From the UK bank perspective, there is no way these calculations can
always be done *exactly* between multiple currencies. A book-entry in
e.g. sterling, of an euro account, need to be converted to euro at some
point in time, which typically involve the process of rounding
(following specific rules).

The obvious requirement our UK bank has, will be to match each account
at some cut-off times each day. This calculation should be done
*exactly*. If the currency conversion has already been done at this
point, there is no simple way to match the books *exactly*.

∎


Tor's Conjecture 1:

R.H. is not always correct, when he get the last word.

Proof:

\remark Soon to be known as "Tor's Theorem 2".

;-)

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

Tor Rustad wrote, On 06/11/07 11:38:
> Richard Heathfield wrote:
>> Flash Gordon said:
>>
>>> Richard Heathfield wrote, On 05/11/07 23:40:
>>
>> <snip>
>>
>>>> But double-entry book-keeping is about putting one
>>>> *monetary* amount into two ledgers, once on the debit side and once on
>>>> the credit side. This can be done exactly.
>>> Not only can, but is actually required to be done exactly.
>>
>> THANK you! At last someone sees what I'm getting at. I was beginning
>> to despair of my ability to explain this.
>
> Tor's Theorem 1:
>
> R.H. is not always correct, when he think he is.
>
> Proof:
>
> Double-entry bookkeeping, means there will be at least two accounts. For
> sake of argument, let us pick a UK bank, with both sterling and euro
> accounts.
>
> The whole point about double-entry, is to detect errors and fraud, a
> bank insider (with access to one account), who tries to credit an
> account will probably be caught, when there is a mis-match between the
> two "books" (assuming proper audit trails exists).
>
> From the UK bank perspective, there is no way these calculations can
> always be done *exactly* between multiple currencies.

Yes there is.

> A book-entry in
> e.g. sterling, of an euro account, need to be converted to euro at some
> point in time, which typically involve the process of rounding
> (following specific rules).

Each account is in a specific currency and the books for that account
are kept in the currency the account is in. A person or organisation can
have multiple accounts each in a different currency. This means that the
only way to convert money from one currency to another is to move it
from one account to another, and at that point the rounding occurs as
part of the conversion using defined rules and a specified conversion
rate, and those rules specify *exactly* what will be credited to one
account and debited from the other.

> The obvious requirement our UK bank has, will be to match each account
> at some cut-off times each day. This calculation should be done
> *exactly*. If the currency conversion has already been done at this
> point, there is no simple way to match the books *exactly*.

Incorrect, it is easy as long as you follow the requirements above.

If anyone is interested enough I could ask one of my brothers who was
doing application support & maintenance for one of the large
organisations in the City of London that works with lots of currencies.

> Tor's Conjecture 1:
>
> R.H. is not always correct, when he get the last word.
>
> Proof:
>
> \remark Soon to be known as "Tor's Theorem 2".
>
> ;-)

I don't think that Richard believes he is always correct.
--
Flash Gordon

Tor Rustad said:

> Richard Heathfield wrote:
>> Flash Gordon said:
>>
>>> Richard Heathfield wrote, On 05/11/07 23:40:
>>
>> <snip>
>>
>>>> But double-entry book-keeping is about putting one
>>>> *monetary* amount into two ledgers, once on the debit side and once on
>>>> the credit side. This can be done exactly.
>>> Not only can, but is actually required to be done exactly.
>>
>> THANK you! At last someone sees what I'm getting at. I was beginning to
>> despair of my ability to explain this.
>
> Tor's Theorem 1:
>
> R.H. is not always correct, when he think he is.

I can certainly accept that as a working hypothesis, and it agrees with a
fair amount of observational evidence, but I take issue with your proof.

> Proof:
>
> Double-entry bookkeeping, means there will be at least two accounts. For
> sake of argument, let us pick a UK bank, with both sterling and euro
> accounts.

Fine, but all the entries in the sterling account will be in sterling, and
all the entries in the Euro account will be in Euros. If a transaction
occurs between the two accounts, then it will be done at a particular
exchange rate that is prevalent at the date and time of the transaction,
and this exchange rate will be recorded for auditing purposes. Also, the
exchange rate will be applied according to strict rounding rules. When the
Euro was in the process of being introduced, the European Commission wrote
a whole pile of papers giving advice to companies on how to handle this
stuff in the accounts. I remember ploughing through them - not a task to
make a bunny happy, I assure you.

> Tor's Conjecture 1:
>
> R.H. is not always correct, when he get the last word.

Word games. The last word is yours if you want it - I'm done here.

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

Flash Gordon said:

<snip>

> I don't think that Richard believes he is always correct.

Interesting philosophical point there, Flash! :-)

As a matter of fact, I *do* think I'm correct, for the obvious reason that,
if I thought I were /in/correct, naturally I would modify my position.
(Doesn't everyone think that way?)

But you're right insofar as I am willing to entertain the possibility that
I could be mistaken; and if I am shown to be mistaken (as I have been, on
far more occasions than I could possibly enumerate), obviously I change my
mind, thus becoming *even more* correct than I was before! :-)

Seriously, there are people here who know far more about C than I do,
people like James K, Jack K, most if not all of the Chrises, Dann, Ben
P... and these people have corrected me (correctly!) on many occasions;
also, they frequently give correct answers to questions that I'd have got
very wrong indeed if I hadn't had the good sense to keep my fingers shut.

I guess I attract flak from the trolls because I don't suffer fools gladly,
and a troll is first and foremost a fool. (A fool is not necessarily a
troll, of course, which explains the /other/ flak I get.)

--
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, On 06/11/07 13:34:
> Flash Gordon said:
>
> <snip>
>
>> I don't think that Richard believes he is always correct.
>
> Interesting philosophical point there, Flash! :-)
>
> As a matter of fact, I *do* think I'm correct, for the obvious reason that,
> if I thought I were /in/correct, naturally I would modify my position.
> (Doesn't everyone think that way?)

<snip>

You have misinterpreted my statement. I didn't say that you don't always
believe you are correct, I said that you don't believe you are always
correct. I.e. I stated that I believe you know that you are not perfect
and are sometimes incorrect, not that you state things that you believe
you are incorrect at the time you state them.
--
Flash gordon