On Sun, 26 Dec 2021 18:52:14 +0000, Manu Raju wrote:

> On 25/12/2021 05:44, Andrey Tarasevich wrote:
>> On 12/24/2021 5:00 PM, Manu Raju wrote:
>>>>
>>>> #include <stdio.h>
>>>> #include <stdlib.h>
>>>> #include <math.h>
>>>>
>>>> int main()
>>>> {
>>>>    float P = 100000; // Loan Amount
>>>>    float r = 7.5; // Advertised Interest Rate
>>>>    int n = 12; // Loan Period
>>>>    float payBack = (P * r / 1200 * pow(1 + r / 1200, n)) / (pow((1 +
>>>> r / 1200), n) - 1);
>>>>    float Opening = P; // Opening Balance
>>>>    float closing = 0;  // Closing Balance
>>>>    float interest = 0;
>>>>    float Total = 0;
>>>>    float repaid = 0;
>>>>
>>>>    printf("\nMonthly payment is: %.2f\n", payBack);
>>>>
>>>>      printf("%10s %14s %13s %10s %14s %12s\n", "Month", "Beginning",
>>>> "Interest", "Total", "Repayment", "Balance");
>>>>
>>>>      for (int i = 1; i <= n; i++)
>>>>      {
>>>>          for (int j = 0; j <= n; j++)
>>>>          {
>>>>              interest = Opening * r / 1200;
>>>>              Total = Opening + interest;
>>>>              repaid = payBack;
>>>>              closing = Total - payBack;
>>>>          }
>>>>          printf("%10d %14.0f %13.0f %10.0f %14.0f %12.0f\n", i,
>>>> Opening, interest, Total, repaid, closing);
>>>>          Opening = closing;
>>>>      }
>>>>      return 0;
>>>> }
>>
>>
>> 9. "Magical constants"? What on Earth is `1200`?
>
>
> It is just a figure 12 * 100. You first need to convert percentage into
> decimals by dividing by 100; Then you need to divide the number again by
> 12 to give monthly rate. Interest rate is normally annual rate. Hope
> this explains the magic number.

Well, you've explained it to us, but not to whomever will read your program next.

A good part of the art of programming is writing readable code; readable to you,
readable to you in 5 years from now, readable to the programmer that has to make
the next change to it, readable to the programmer who has to fix the bug in it.

Your use of 1200 is confusing, unless you already know that it facilitates the
conversion of a yearly interest rate expressed as a percent into a monthly
interest rate expressed as a decimal. It is worth noting that, should you
change the loan period expressed in P, you would /also/ have to change this
1200 "magic number" appropriately (or is P a "loan period in years"? if so,
then I believe that your interest calculations are wrong.)

--
Lew Pitcher
"In Skills, We Trust"

On 26/12/2021 19:22, Lew Pitcher wrote:
>
>
> Your use of 1200 is confusing, unless you already know that it facilitates the
> conversion of a yearly interest rate expressed as a percent into a monthly
> interest rate expressed as a decimal. It is worth noting that, should you
> change the loan period expressed in P, you would /also/ have to change this
> 1200 "magic number" appropriately (or is P a "loan period in years"? if so,
> then I believe that your interest calculations are wrong.)
>
>

The figure of 1200 will NEVER change. There will always be 12 months in
a year and we will always have to divide by 100 to express percentage as
decimals.

The interest rate can change and period (I used n) can also change. I used (n = 12) in my program to fit the table for people to see but
you can have 360 (30 years * 12). The program will still work.

Tim did a very good job to write a function. Did you see it? It is here.

<===========================================================================================>

void show_payment_table(double amount, double yearly_percentage_rate,
int months)
{ double const monthly_rate = yearly_percentage_rate / 100 / 12;
double const compounded = pow(1 + monthly_rate, months);
double const adjustment = compounded / (compounded - 1);
double const payment = amount * monthly_rate * adjustment;

double balance = amount;

printf("\nMonthly payment is: %.2f\n", payment);

printf("%10s %14s %13s %10s %14s %12s\n",
"Month", "Beginning", "Interest", "Total", "Repayment",
"Balance");

for (int i = 1; i <= months; i++)
{
double const interest = balance * monthly_rate;
double const owing = balance + interest;
double const remaining = owing - payment;

printf("%10d %14.2f %13.2f %10.2f %14.2f %12.2f\n",
i, balance, interest, owing, payment, remaining);
balance = remaining;
}

<===========================================================================================>

Now in the main function you just need to use it like so:

<===========================================================================================>

show_payment_table(250000, 5.0, 360);

<===========================================================================================>

This program is part of a big project where users will insert their
figures to calculate their repayments. all they need to enter will be
the Loan Amount, Interest Rate, and the Duration of the Loan. the
program will give them the schedule they can base their decision on. The
Windows Form/WPF will be used for these entries and "ASP.Net/MVC" for
the web site.

Best regards and have a very Happy New Year.

On 26/12/2021 21:30, Manu Raju wrote:
> On 26/12/2021 19:22, Lew Pitcher wrote:
>>
>>
>> Your use of 1200 is confusing, unless you already know that it facilitates the
>> conversion of a yearly interest rate expressed as a percent into a monthly
>> interest rate expressed as a decimal. It is worth noting that, should you
>> change the loan period expressed in P, you would /also/ have to change this
>> 1200 "magic number" appropriately (or is P a "loan period in years"? if so,
>> then I believe that your interest calculations are wrong.)
>>
>>
>
> The figure of 1200 will NEVER change. There will always be 12 months in
> a year and we will always have to divide by 100 to express percentage as
> decimals.

Imagine this is part of a bigger program, and the constant 1200 also
occurs elsewhere with a different meaning.

/That/ 1200 might need to change, but now you don't know which 1200s are
relevant.

On 12/26/21 4:30 PM, Manu Raju wrote:
> The figure of 1200 will NEVER change. There will always be 12 months in
> a year and we will always have to divide by 100 to express percentage as
> decimals.

Actually that is a BIG assumption, that assumes that the ONLY payment
schedule is monthly.

Some people take out loans with Semi-Monthly (or B-Weekly) payment
schedules to pay things off a bit faster it that is how they get paid.

You might even choose weekly, or some are paid annually or things in
between.

All these change the 1200 to something else, to something like 100 *
payments_per_year.

Also, due to how common other operations on interest rates are, it may
make more sense on a program scale to do the rate/100 early in the
program and internally store these rates as the actual rate in per unit,
instead of the artificail percent (that would also allow parts of the
code to use permill if that was desired (per mill is per 1000 instead of
percent which is per 100).

On Sun, 26 Dec 2021 21:30:00 +0000, Manu Raju wrote:

> On 26/12/2021 19:22, Lew Pitcher wrote:
>>
>>
>> Your use of 1200 is confusing, unless you already know that it facilitates the
>> conversion of a yearly interest rate expressed as a percent into a monthly
>> interest rate expressed as a decimal. It is worth noting that, should you
>> change the loan period expressed in P, you would /also/ have to change this
>> 1200 "magic number" appropriately (or is P a "loan period in years"? if so,
>> then I believe that your interest calculations are wrong.)
>>
>>
>
> The figure of 1200 will NEVER change. There will always be 12 months in
> a year and we will always have to divide by 100 to express percentage as
> decimals.

30 years ago, when I bought my house, I took out a mortgage. The bank offered
me options to pay in monthly installments, or bi-weekly installments. The bi-weekly
installment option offered a lower individual payment, but at a higher frequency.

So, /yes/, the number of installments per cycle /may/ change.

As for 1200 being an appropriate figure, I disagree. Your 1200 represents /two/
distinct conversion factors. Speaking from a purely "design" point of view, you
never want constants to represent more than one thing.

In this case, your 1200 represents
a) the conversion factor that alters values expressed as a percent into values
expressed as a decimal, and
b) the conversion factor that alters values expressed as a year into values
expressed as a number of months.

While it may be convenient for /you/ to consolidate those two conversion factors
into one constant, that consolidation /is not/ obvious, and /can/ lead to issues
if one or the other of those two conversions change.

Remember, you are writing code to be /readable/. The computer doesn't care; it
doesn't know C from COBOL or Brainfuck: it only knows the ones and zeros that
represent it's internal language. What you write must be readable and comprehensible
to other programmers.

[snip]

--
Lew Pitcher
"In Skills, We Trust"

One last thought....

On Sat, 25 Dec 2021 01:00:00 +0000, Manu Raju wrote:

[snip]
>>   float payBack = (P * r / 1200 * pow(1 + r / 1200, n)) / (pow((1 + r / 1200), n) - 1);
[snip]

You need some documentation, especially around the important but obscure
parts like the statement above.

While I've been out of the financial computing world for quite some time,
I still can recognize /parts/ of this statement as relating to compound
interest calculations, but the /exact/ calculation escapes me.

A comment within your code, describing the sort of calculation you make
here, along with a reference to it's source, would go a long way to
making the program readable.

When you come back to this code next year, or when your teacher
evaluates the code, such a comment would make the intent of this
calculation clearer (and perhaps even assist in debugging).

HTH
--
Lew Pitcher
"In Skills, We Trust"

Le 25/12/2021 à 06:44, Andrey Tarasevich a écrit :
> On 12/24/2021 5:00 PM, Manu Raju wrote:
>>>
>>> #include <stdio.h>
>>> #include <stdlib.h>
>>> #include <math.h>
>>>
>>> int main()
>>> {
>>>    float P = 100000; // Loan Amount
>>>    float r = 7.5; // Advertised Interest Rate
>>>    int n = 12; // Loan Period
>>>    float payBack = (P * r / 1200 * pow(1 + r / 1200, n)) / (pow((1 +
>>> r / 1200), n) - 1);
>>>    float Opening = P; // Opening Balance
>>>    float closing = 0;  // Closing Balance
>>>    float interest = 0;
>>>    float Total = 0;
>>>    float repaid = 0;
>>>
>>>    printf("\nMonthly payment is: %.2f\n", payBack);
>>>
>>>      printf("%10s %14s %13s %10s %14s %12s\n", "Month", "Beginning",
>>> "Interest", "Total", "Repayment", "Balance");
>>>
>>>      for (int i = 1; i <= n; i++)
>>>      {
>>>          for (int j = 0; j <= n; j++)
>>>          {
>>>              interest = Opening * r / 1200;
>>>              Total = Opening + interest;
>>>              repaid = payBack;
>>>              closing = Total - payBack;
>>>          }
>>>          printf("%10d %14.0f %13.0f %10.0f %14.0f %12.0f\n", i,
>>> Opening, interest, Total, repaid, closing);
>>>          Opening = closing;
>>>      }
>>>      return 0;
>>> }
>
> Certainly.
>
> 1. int main(void)
>
> 2. Stop using `float` for local variables. "Default" floating-point type
> in C is `double`. Everything else is used only if you have a good reason
> to do that. In this case you don't.
>
> 3. Stop using "regular" floating point types for representing monetary
> quantities. They are not good for that purpose.
>
> 4. It appears that you are actually trying to use `float` to represent
> _integer_ quantities (judging by your `printf`). Why?
>
> 5. Stop using `pow` for calculating integer powers. You don't really
> need `<math.h>` here.
>
> 6. Stop piling up all variable declarations at the beginning of the
> function. Declare variables as locally as possible.
>
> 7. Stop using dummy initializers for your variables. It is better to
> leave them uninitialized than initialize them to dummy zeros. This point
> is actually connected to the previous one: once you start declaring
> variables as locally as possible, you'll normally have a meaningful
> initializers for them at the point of declaration.
>
> 8. What's going on with capitalization in your variables names?
> `Opening`, `closing`, `interest`, `Total`? Is this a convention of some
> sort?
>
> 9. "Magical constants"? What on Earth is `1200`?
>
> 10. Repetitive subexpressions, like `1 + r / 1200` (some explicit, some
> slightly obfuscated) are probably a matter of style.... But anyway: DRY
> - do not repeat yourself.

All good points!

On 29/12/2021 16:52, Guillaume wrote:
> Le 25/12/2021 à 06:44, Andrey Tarasevich a écrit :

>> 1. int main(void)
>>
>> 2. Stop using `float` for local variables. "Default" floating-point
>> type in C is `double`. Everything else is used only if you have a good
>> reason to do that. In this case you don't.
>>
>> 3. Stop using "regular" floating point types for representing monetary
>> quantities. They are not good for that purpose.
>>
>> 4. It appears that you are actually trying to use `float` to represent
>> _integer_ quantities (judging by your `printf`). Why?
>>
>> 5. Stop using `pow` for calculating integer powers. You don't really
>> need `<math.h>` here.
>>
>> 6. Stop piling up all variable declarations at the beginning of the
>> function. Declare variables as locally as possible.
>>
>> 7. Stop using dummy initializers for your variables. It is better to
>> leave them uninitialized than initialize them to dummy zeros. This
>> point is actually connected to the previous one: once you start
>> declaring variables as locally as possible, you'll normally have a
>> meaningful initializers for them at the point of declaration.
>>
>> 8. What's going on with capitalization in your variables names?
>> `Opening`, `closing`, `interest`, `Total`? Is this a convention of
>> some sort?
>>
>> 9. "Magical constants"? What on Earth is `1200`?
>>
>> 10. Repetitive subexpressions, like `1 + r / 1200` (some explicit,
>> some slightly obfuscated) are probably a matter of style.... But
>> anyway: DRY - do not repeat yourself.
>
> All good points!
>

All?

2) Nothing wrong with using 'float' when it's appropropriate. Many
libraries eg. OpenGL make extensive use of float.

It's not obvious that C's /default/ float type is 'double', nor that
'float' is not the default float type, despite the name!

However, for this application, float is not quite accurate enough.

3) Double is perfectly suitable for representing monetary amounts,
especially in a toy program or for personal use. (I've used it for
accounts within a small business.)

But what exactly would be a practical alternative here? To import a
decimal float library, or somehow work with int64 whole cents? (Good
luck with interest calculations with that.)

4) Doesn't make sense. The quantities have to be floating point, but are
simply being printed with zero decimal places, as whole dollars or whatever.

5) I can't see an issue in using pow() to do pow(float,int); the result
will not be exact anyway. What is the alternate, to invent a local
powint(float,int) routine? Which will probably contain a loop. Or change
the logic for an accumulative product. pow() is simpler!

6) I just don't agree with this at all. I like all the cluttery
declarations out of the way of the logic, and in one place for quick
reference. Then you also know there are no multiple, incompatible
instances of any local identifier.

7) I think initialisers are a good idea. Some languages will ensure such
locals are set to a known starting value, like 0 or 0.0 for static
types; presumably they think that is a benefit.

Ones like (1) I agree with, but I also think it's a waste of time
pointing it out, as the practice is so widespread.

Because compilers [not mine!] have long routinely accepted () parameter
lists without any warnings that args passed to those functions are
completely unchecked for number or types, most seem to assume that they
mean /no/ parameters.

In this example program, it means that the code could call main(10,
20.0, "three") without comment. But then it could still call it legally
as main() if the (void) was added.

On 12/29/2021 9:49 AM, Bart wrote:
> On 29/12/2021 16:52, Guillaume wrote:
>> Le 25/12/2021 à 06:44, Andrey Tarasevich a écrit :
>
>
>>> 1. int main(void)
>>>
>>> 2. Stop using `float` for local variables. "Default" floating-point
>>> type in C is `double`. Everything else is used only if you have a
>>> good reason to do that. In this case you don't.
>>>
>>> 3. Stop using "regular" floating point types for representing
>>> monetary quantities. They are not good for that purpose.
>>>
>>> 4. It appears that you are actually trying to use `float` to
>>> represent _integer_ quantities (judging by your `printf`). Why?
>>>
>>> 5. Stop using `pow` for calculating integer powers. You don't really
>>> need `<math.h>` here.
>>>
>>> 6. Stop piling up all variable declarations at the beginning of the
>>> function. Declare variables as locally as possible.
>>>
>>> 7. Stop using dummy initializers for your variables. It is better to
>>> leave them uninitialized than initialize them to dummy zeros. This
>>> point is actually connected to the previous one: once you start
>>> declaring variables as locally as possible, you'll normally have a
>>> meaningful initializers for them at the point of declaration.
>>>
>>> 8. What's going on with capitalization in your variables names?
>>> `Opening`, `closing`, `interest`, `Total`? Is this a convention of
>>> some sort?
>>>
>>> 9. "Magical constants"? What on Earth is `1200`?
>>>
>>> 10. Repetitive subexpressions, like `1 + r / 1200` (some explicit,
>>> some slightly obfuscated) are probably a matter of style.... But
>>> anyway: DRY - do not repeat yourself.
>>
>> All good points!
>>
>
> 2) Nothing wrong with using 'float' when it's appropropriate. Many
> libraries eg. OpenGL make extensive use of float.

That's just emphasizes my the point. The main purpose of "small" types,
like `float`, `short`, char as plain integer, bit-fields etc. is to save
memory in quantitatively massive data structures.

That's exactly what OpenGL is intended to work with: massive amounts of
geometric data. That's why it opts for `float` Everything else is just a
consequence of that.

> It's not obvious that C's /default/ float type is 'double', nor that
> 'float' is not the default float type, despite the name!

It doesn't have to be obvious. That's why I state it explicitly.

> 6) I just don't agree with this at all. I like all the cluttery
> declarations out of the way of the logic,

Declarations are never cluttery, unless you make a deliberate effort to
make them that.

> and in one place for quick reference.

Piling up all variable declarations in one place makes for much slower
reference: first, one has has to find the pile, then one has to sift
through the pile.

Local declarations are always instantly visible, making for much quicker
reference. Basically, with local declarations the matter of "reference"
is virtually non-existent: the required knowledge is almost always
naturally and intuitively present within the field of view.

The popular counter-argument stating that "functions have to be small
with small number of variables" is nothing else that a fake advice whose
only purpose is to serve as an emergency brace for the cracking and
crumbling bad practice of piling up variable declarations.

> Then you also know there are no multiple, incompatible
> instances of any local identifier.

This is a classic "solution looking for a problem": a solution for a
problem that does not really exist in the first place.

> 7) I think initialisers are a good idea. Some languages will ensure such
> locals are set to a known starting value, like 0 or 0.0 for static
> types; presumably they think that is a benefit.

It definitely has a benefit: it works as a bootstrapping point for
static/dynamic initialization. I.e. gives you a reliable anchoring
point: something that is guaranteed to be there "even before the
programs starts", without you having to worry about the initialization
and associated ordering issues. No other reason.

And this, of course, does not apply outside of static initialization
contexts. The only thing you achieve by using dummy initializers is
defeat checks performed by static/dynamic analysis tools.

--
Best regards,
Andrey Tarasevich

Bart <bc@freeuk.com> writes:
[...]
> 3) Double is perfectly suitable for representing monetary amounts,
> especially in a toy program or for personal use. (I've used it for
> accounts within a small business.)

In a toy program, sure -- and I'd say *only* in a toy program.

Using floating-point for money risks, at best, rare off-by-one errors,
such as a computation yielding a result one cent off from the correct
value. I believe that would be considered unacceptable in any
real-world financial application.

> But what exactly would be a practical alternative here? To import a
> decimal float library, or somehow work with int64 whole cents? (Good
> luck with interest calculations with that.)

If you only need to do calculations that yield whole numbers of cents,
then yes, you can use a wide integer (long long or uint64_t, for
example, or define your own type "in64" if you insist for some reason)
with a scaling factor of 100. If you need to do interest calculations
in the real world (not in a toy program), you need to find out the exact
rules for those calculations and implement them.

[...]

> 5) I can't see an issue in using pow() to do pow(float,int); the
> result will not be exact anyway. What is the alternate, to invent a
> local powint(float,int) routine? Which will probably contain a
> loop. Or change the logic for an accumulative product. pow() is
> simpler!

Integer exponentiation can be done exactly (assuming no overflow).
pow() can suffer floating-point errors. Whether pow() is acceptable
depends on the application and the financial rules governing it.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 29/12/2021 22:37, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> 3) Double is perfectly suitable for representing monetary amounts,
>> especially in a toy program or for personal use. (I've used it for
>> accounts within a small business.)
>
> In a toy program, sure -- and I'd say *only* in a toy program.
>
> Using floating-point for money risks, at best, rare off-by-one errors,
> such as a computation yielding a result one cent off from the correct
> value. I believe that would be considered unacceptable in any
> real-world financial application.

Real-world doesn't need to mean dealing with trillions of dollars to the
exact cent.

Most businesses work with amounts far smaller. Then I believe the
precision of float64 is enough to emulate the needed rounding methods.

(But I didn't even bother with that. My app anyway had to work with
multliple parallel currencies so if an amount was correct to the nearest
cent on one, it couldn't also be correct in another. But the environment
was also fairly informal.)

>> But what exactly would be a practical alternative here? To import a
>> decimal float library, or somehow work with int64 whole cents? (Good
>> luck with interest calculations with that.)
>
> If you only need to do calculations that yield whole numbers of cents,
> then yes, you can use a wide integer (long long or uint64_t, for
> example, or define your own type "in64" if you insist for some reason)
> with a scaling factor of 100. If you need to do interest calculations
> in the real world (not in a toy program), you need to find out the exact
> rules for those calculations and implement them.

I wouldn't know where to start to apply an interest rate specified to
multiple decimals, to an integer amount, to yield an integer result.

> [...]
>
>> 5) I can't see an issue in using pow() to do pow(float,int); the
>> result will not be exact anyway. What is the alternate, to invent a
>> local powint(float,int) routine? Which will probably contain a
>> loop. Or change the logic for an accumulative product. pow() is
>> simpler!
>
> Integer exponentiation can be done exactly (assuming no overflow).
> pow() can suffer floating-point errors. Whether pow() is acceptable
> depends on the application and the financial rules governing it.

This is integer exponentation of floating point values. The choice is
between repeated multiplications, or calling pow().

The latter is likely done with logs and exp() which can introduce
errors, but if I calculate 3% compound interest monthly over about 80
years, then the results of:

1.03 * 1.03 * ... // 1000 times

and:

pow(1.03, 1000)

differ only in the 16th significant digit.

Bart <bc@freeuk.com> writes:
>On 29/12/2021 22:37, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> 3) Double is perfectly suitable for representing monetary amounts,
>>> especially in a toy program or for personal use. (I've used it for
>>> accounts within a small business.)
>>
>> In a toy program, sure -- and I'd say *only* in a toy program.
>>
>> Using floating-point for money risks, at best, rare off-by-one errors,
>> such as a computation yielding a result one cent off from the correct
>> value. I believe that would be considered unacceptable in any
>> real-world financial application.
>
>Real-world doesn't need to mean dealing with trillions of dollars to the
>exact cent.

Real-world still uses COBOL for these type of applications.

>
>Most businesses work with amounts far smaller. Then I believe the
>precision of float64 is enough to emulate the needed rounding methods.

Why bother with the error-prone "needed rounding methods". Use uint64_t
and denominate in mills.

If your domain requires larger numbers, widen it to 128 bits.

Bart <bc@freeuk.com> writes:
> On 29/12/2021 22:37, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> 3) Double is perfectly suitable for representing monetary amounts,
>>> especially in a toy program or for personal use. (I've used it for
>>> accounts within a small business.)
>> In a toy program, sure -- and I'd say *only* in a toy program.
>> Using floating-point for money risks, at best, rare off-by-one
>> errors,
>> such as a computation yielding a result one cent off from the correct
>> value. I believe that would be considered unacceptable in any
>> real-world financial application.
>
> Real-world doesn't need to mean dealing with trillions of dollars to
> the exact cent.

But it can mean dealing with thousands of dollars to the exact cent --
and if you get a result of $1234.565001 and round it to $1234.57, when
the rules call for a result of $1234.56, that could be a serious problem.

> Most businesses work with amounts far smaller. Then I believe the
> precision of float64 is enough to emulate the needed rounding methods.

Working with smaller amounts just means that errors like this are rarer,
not that they don't happen.

> (But I didn't even bother with that. My app anyway had to work with
> multliple parallel currencies so if an amount was correct to the
> nearest cent on one, it couldn't also be correct in another. But the
> environment was also fairly informal.)

If "fairly informal" means you don't need results accurate to the cent,
then floating-point might be good enough. But financial institutions
can't afford that.

>>> But what exactly would be a practical alternative here? To import a
>>> decimal float library, or somehow work with int64 whole cents? (Good
>>> luck with interest calculations with that.)
>> If you only need to do calculations that yield whole numbers of
>> cents,
>> then yes, you can use a wide integer (long long or uint64_t, for
>> example, or define your own type "in64" if you insist for some reason)
>> with a scaling factor of 100. If you need to do interest calculations
>> in the real world (not in a toy program), you need to find out the exact
>> rules for those calculations and implement them.
>
> I wouldn't know where to start to apply an interest rate specified to
> multiple decimals, to an integer amount, to yield an integer result.

Neither would I. My understanding is that there are precisely stated
rules that tell you exactly what results a given computation must
produce, for example when computing compound interest. If you're going
to be writing real-world software, where satisfying those rules is a
requirement, you *must* learn those rules first. (I haven't done so and
probably won't.)

>> [...]
>>
>>> 5) I can't see an issue in using pow() to do pow(float,int); the
>>> result will not be exact anyway. What is the alternate, to invent a
>>> local powint(float,int) routine? Which will probably contain a
>>> loop. Or change the logic for an accumulative product. pow() is
>>> simpler!
>> Integer exponentiation can be done exactly (assuming no overflow).
>> pow() can suffer floating-point errors. Whether pow() is acceptable
>> depends on the application and the financial rules governing it.
>
> This is integer exponentation of floating point values. The choice is
> between repeated multiplications, or calling pow().
>
> The latter is likely done with logs and exp() which can introduce
> errors, but if I calculate 3% compound interest monthly over about 80
> years, then the results of:
>
> 1.03 * 1.03 * ... // 1000 times
>
> and:
>
> pow(1.03, 1000)
>
> differ only in the 16th significant digit.

And if that difference in the 16th significant digit happens to
give you a result that's off by one cent after rounding, that's
a problem -- unless your environment is "fairly informal" and you
don't mind sometimes being off by a cent.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

scott@slp53.sl.home (Scott Lurndal) writes:
> Bart <bc@freeuk.com> writes:
>>On 29/12/2021 22:37, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>>> [...]
>>>> 3) Double is perfectly suitable for representing monetary amounts,
>>>> especially in a toy program or for personal use. (I've used it for
>>>> accounts within a small business.)
>>>
>>> In a toy program, sure -- and I'd say *only* in a toy program.
>>>
>>> Using floating-point for money risks, at best, rare off-by-one errors,
>>> such as a computation yielding a result one cent off from the correct
>>> value. I believe that would be considered unacceptable in any
>>> real-world financial application.
>>
>>Real-world doesn't need to mean dealing with trillions of dollars to the
>>exact cent.
>
> Real-world still uses COBOL for these type of applications.
>
>>Most businesses work with amounts far smaller. Then I believe the
>>precision of float64 is enough to emulate the needed rounding methods.
>
> Why bother with the error-prone "needed rounding methods". Use uint64_t
> and denominate in mills.
>
> If your domain requires larger numbers, widen it to 128 bits.

Compound interest calculations can give intermediate results that are
not a whole number of cents or even mills, and those results must be
rounded to the nearest cent at some specified point using specified
rules. (And no, I don't know what those rules are.)

Using large integers representing cents or mills is find if all
you're doing is adding and subtracting.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 2021-12-29, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> 3) Double is perfectly suitable for representing monetary amounts,
>> especially in a toy program or for personal use. (I've used it for
>> accounts within a small business.)
>
> In a toy program, sure -- and I'd say *only* in a toy program.
>
> Using floating-point for money risks, at best, rare off-by-one errors,
> such as a computation yielding a result one cent off from the correct
> value. I believe that would be considered unacceptable in any
> real-world financial application.

The fear is not well-founded.

Let's for a moment set aside astronomical monetary figures, and say
we are just doing accounting for some ordinary business.

Suppose we use the representation that 1.0 == $1.00 USD.

A one-cent error in some ordinary amount like $15,123,13 is gapingly
huge. It's in the 9th digit out of an available 15.

If that were a problem, floating-point would be entirely unsuitable
for engineering and science.

(Side note: consider that people use Microsoft Excel for real financial
work, and go with those numbers.

https://en.wikipedia.org/wiki/Numeric_precision_in_Microsoft_Excel )

The double type can recored 15 decimal digits of precision.
We can store the amount $9,999,999,999,999.99 in a double and
get all of it back. Say, that to be safe against truncation
errors, we scale that back by two orders of magnitude. That
gives us $99,999,999,999.9999 being exactly representable:
99 billion dollars down to a hundredth of a cent. If the
accounting we are doing runs in the cents, we are fine.

What we have to watch out for is the accumulation of errors. For
instance, we cannot just blindly sum an arbitrary long column of
figures, such as the transactions in a long-running account. After every
calculation, we should fastidiously round the result to the nearest
penny. The calculation will already be vastly closer to that
penny, than to any other penny: we are talking about a very tiny
movement.

You can probably get away with letting error accumulate over many
calculations, without any risk that the approximation will jump to the
wrong penny. The safest thing is probably to nip it in the bud:
"snap" the result of every calculation to the "penny grid".

Ideally, every amount recoreded into the double-based ledger
should be that type's closest approximation of the intended
dollars-and-cents amount.

There are some additional issues in that when percentages or other
fractional values are calculated, the accounting system may be governed
by special rules about rounding: when a fractional result lands halfway
between two pennies, which one does it go to?

But this applies regardless of whether we use scaled integers or doubles
for the base amounts, and the requirements could be met with
careful double-based arithmetic.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

On 2021-12-29, Scott Lurndal <scott@slp53.sl.home> wrote:
> Bart <bc@freeuk.com> writes:
>>On 29/12/2021 22:37, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>>> [...]
>>>> 3) Double is perfectly suitable for representing monetary amounts,
>>>> especially in a toy program or for personal use. (I've used it for
>>>> accounts within a small business.)
>>>
>>> In a toy program, sure -- and I'd say *only* in a toy program.
>>>
>>> Using floating-point for money risks, at best, rare off-by-one errors,
>>> such as a computation yielding a result one cent off from the correct
>>> value. I believe that would be considered unacceptable in any
>>> real-world financial application.
>>
>>Real-world doesn't need to mean dealing with trillions of dollars to the
>>exact cent.
>
> Real-world still uses COBOL for these type of applications.
>
>>
>>Most businesses work with amounts far smaller. Then I believe the
>>precision of float64 is enough to emulate the needed rounding methods.
>
> Why bother with the error-prone "needed rounding methods". Use uint64_t
> and denominate in mills.

This common intution is incorrect. Financial systems sometimews need to
calculate fractional amounts, like a 15.03% tax or whatever.

And in those situations, you may be required to implement the required
rounding rules: what to do when some fractional result lands halfway
between two pennies: which one does it go to.

You cannot get away from rounding issues just because you used an
integer representation for mills or penies.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

On 2021-12-30, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Bart <bc@freeuk.com> writes:
>> On 29/12/2021 22:37, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>>> [...]
>>>> 3) Double is perfectly suitable for representing monetary amounts,
>>>> especially in a toy program or for personal use. (I've used it for
>>>> accounts within a small business.)
>>> In a toy program, sure -- and I'd say *only* in a toy program.
>>> Using floating-point for money risks, at best, rare off-by-one
>>> errors,
>>> such as a computation yielding a result one cent off from the correct
>>> value. I believe that would be considered unacceptable in any
>>> real-world financial application.
>>
>> Real-world doesn't need to mean dealing with trillions of dollars to
>> the exact cent.
>
> But it can mean dealing with thousands of dollars to the exact cent --
> and if you get a result of $1234.565001 and round it to $1234.57, when

You cannot get a result of $1234.565... by only additive and subtractive
transactions, such as recording expenses in a ledger whose
denomination is pennies!

(Not unless you neglected to take care of cumulative truncation error
and let that error freely accumulate for a vast number of transactions.
But let's say everything was done right up to the point this $1234.565001
showed up.)

The way you got that half penny in there: 0.56 + 0.005001 is that
you performed a fractional calculation, like calculating a percentage
due to tax or interest or dividend or whatever.

If you calculate a fractional quantity, you must deal with the rounding,
right there and then, based on the applicable requirements.
(Whether or not you're recording monetary amounts using integers!)

For instance, let's suppose that 1234.565001 is the calculation of the
new account balance due to interest earned. The previous balance was
1232.19. Being recorded in the ledger, that fiture is exact. (Or, if we
use doubles, it is a vastly accurate approximation of 1232.19).

We calculated some interest and came up with 1234.565001. But we cannot
record that; the account is to the penny. So what do we do? We apply
some rounding rule, like Banker's Rounding.

If the result were exactly 1234.565, then according ot Banker's
Rounding, we would round down to 1234.56, because 6 is an even digit.
A 5 following an odd digit would go up.

This kind of thing you must handle even if the inputs amounts (other
than the percentage rate) are integers, and so are the outputs.

In the accounting system I wrote for my self-employment activities,
I used integers representing pennies, but fractionals are calculated
with the help of floating-point. I'm not required to deal with precise,d
decimal-based rounding rules, so what I did is this: the fractional
result (measuring pennies) is calculated in double-precision floating
point. Then this cents amount is subject to the C library round()
function to get it to the closest integer (i.e. cent), and then that is
converted to the integer-based monetary type.

I'm confident I could replace that integer-based monetary type with
floating-point and get all the same results (that would be fairly easily
checked, because the system calculates everything from scratch
from the recrded transaction log, every time it is run; my real data
could be converted to a giant regression test case.)

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

On 30/12/2021 00:09, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:

>> Real-world doesn't need to mean dealing with trillions of dollars to
>> the exact cent.
>
> But it can mean dealing with thousands of dollars to the exact cent --
> and if you get a result of $1234.565001 and round it to $1234.57, when
> the rules call for a result of $1234.56, that could be a serious problem.

With floating point, that result could as easily be just under 1234.565
as just over. If the requirements really are that binary floating point
must have exactly identical results, down to the least significant bit,
even for intermediates so that rounding will always give the same
results too, then that's what you have to do.

But I don't believe the OP's program is in that class. (This is one of a
category of exercises, like hashes, prngs, and reading a line of input
of arbitrary length, where apparently nothing less that a perfect,
industrial-strength professional solution will do.)

>> Most businesses work with amounts far smaller. Then I believe the
>> precision of float64 is enough to emulate the needed rounding methods.
>
> Working with smaller amounts just means that errors like this are rarer,
> not that they don't happen.
>
>> (But I didn't even bother with that. My app anyway had to work with
>> multliple parallel currencies so if an amount was correct to the
>> nearest cent on one, it couldn't also be correct in another. But the
>> environment was also fairly informal.)
>
> If "fairly informal" means you don't need results accurate to the cent,
> then floating-point might be good enough. But financial institutions
> can't afford that.

You can easily get results to the nearest cent. The problem can be when
rounding errors or rounding methods result in discrepancies between
different approaches, or between different programs and languages.

I just don't think this is a programming issue, more one of requirements
and specification.

>> I wouldn't know where to start to apply an interest rate specified to
>> multiple decimals, to an integer amount, to yield an integer result.
>
> Neither would I. My understanding is that there are precisely stated
> rules that tell you exactly what results a given computation must
> produce, for example when computing compound interest. If you're going
> to be writing real-world software, where satisfying those rules is a
> requirement, you *must* learn those rules first. (I haven't done so and
> probably won't.)

Again with real-world. Is this a corner shop or is it Lloyds Bank? Or
someone working out figures for their tax return? Or doing a personal
budget?

(In my country, tax returns only need figures in whole pounds, and don't
need to be that exact. So long as you are not deliberately
misrepresenting by significant amounts, it doesn't matter if they are a
pound either way.)

So, what do you think the OP should do?

Remember this is floating point which is generally not exact: 1.00625
(the factor needed for 7.5% annual interest applied monthly) can't be
represented precisely IEEE754. Using long integers for this isn't a
magic bullet, since you still have to multiply by 1.00625.

As it turns out, I do have a clue how it's done: you multiply by 100625
and divide by 100000.

However, int64 or even int128 don't have enough range to multiply by
100625 N times before dividing by 100000 N times. You have to do the
divide at each step. Which means deciding what to do about the remainder
at each step (especially if negative numbers are involved).

It's back to specifications.

Kaz Kylheku <480-992-1380@kylheku.com> writes:
> On 2021-12-30, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
[...]
>> But it can mean dealing with thousands of dollars to the exact cent --
>> and if you get a result of $1234.565001 and round it to $1234.57, when
>
> You cannot get a result of $1234.565... by only additive and subtractive
> transactions, such as recording expenses in a ledger whose
> denomination is pennies!

I didn't say otherwise.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 12/29/21 2:33 PM, Andrey Tarasevich wrote:
> On 12/29/2021 9:49 AM, Bart wrote:
....
>> It's not obvious that C's /default/ float type is 'double', nor that
>> 'float' is not the default float type, despite the name!
>
> It doesn't have to be obvious. That's why I state it explicitly.

Stating it explicitly is not as good as providing relevant citations.

That was certainly true in K&R C, where the usual arithmetic conversions
always caused float operands to be converted to double, and the default
argument promotions caused float arguments to be promoted to double.
However, in C90 the usual arithmetic conversions were changed so that
floating-point operands were never converted to a higher precision
unless the other operand had a higher precision.
In C90, none of the standard library functions took a float or long
double argument, but that changed in C99 - all of the math.h functions
now come in three different forms: one suffixed with 'f' that takes
float arguments and/or returns float values, one with no suffix for
double, and on suffixed with 'l' for long double.
C90 also introduced function prototypes. When calling a function with a
prototype declaration in scope (which is now the normal case), the
default argument promotions occur only for the variable parts of
variadic functions. That's the only sense in which "double is the
default" survived past C99.

I'd say that, since C99, it's far from obvious that double is the
default precision, and I'd say that the reason it's not obvious is
because it's no longer true.

On 12/29/2021 7:45 PM, James Kuyper wrote:
>
> I'd say that, since C99, it's far from obvious that double is the
> default precision, and I'd say that the reason it's not obvious is
> because it's no longer true.

A rather obvious fact that an unsuffixed `0.0` is a `double` still
grants a significant degree of defaultness (sic) to `double`.

--
Best regards,
Andrey Tarasevich

On 30/12/2021 09:35, Andrey Tarasevich wrote:
> On 12/29/2021 7:45 PM, James Kuyper wrote:
>>
>> I'd say that, since C99, it's far from obvious that double is the
>> default precision, and I'd say that the reason it's not obvious is
>> because it's no longer true.
>
> A rather obvious fact that an unsuffixed `0.0` is a `double` still
> grants a significant degree of defaultness (sic) to `double`.
>

If you call a function for which there is no prototype (I think it is
insane that non-prototype declarations are still allowed in C, even C18,
but that's a side point) then any arguments of type "float" are promoted
to "double". The same applies to arguments to a function with a
variable number of arguments (in the ellipsis part).

That adds to the "double is default" argument (though I agree with James
that it is much less the default in C99 than it was in C90).

On Thursday, 30 December 2021 at 01:06:35 UTC, Bart wrote:
>
> (In my country, tax returns only need figures in whole pounds, and don't
> need to be that exact. So long as you are not deliberately
> misrepresenting by significant amounts, it doesn't matter if they are a
> pound either way.)
>
In the UK, the Inland Revenue doesn't care about small amounts of money.

But, if you write a cheque to Inland Revenue, the amount the bank calculates
you have in your account needs to match the amount the program calculates
you have in your account to the exact penny. Not because accountants care
about one penny, but because any discrepancy, however small, could indicate
some more serious mis-accounting.

On 30/12/2021 00:34, Kaz Kylheku wrote:
> On 2021-12-29, Scott Lurndal <scott@slp53.sl.home> wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 29/12/2021 22:37, Keith Thompson wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>> [...]
>>>>> 3) Double is perfectly suitable for representing monetary amounts,
>>>>> especially in a toy program or for personal use. (I've used it for
>>>>> accounts within a small business.)
>>>>
>>>> In a toy program, sure -- and I'd say *only* in a toy program.
>>>>
>>>> Using floating-point for money risks, at best, rare off-by-one errors,
>>>> such as a computation yielding a result one cent off from the correct
>>>> value. I believe that would be considered unacceptable in any
>>>> real-world financial application.
>>>
>>> Real-world doesn't need to mean dealing with trillions of dollars to the
>>> exact cent.
>>
>> Real-world still uses COBOL for these type of applications.
>>
>>>
>>> Most businesses work with amounts far smaller. Then I believe the
>>> precision of float64 is enough to emulate the needed rounding methods.
>>
>> Why bother with the error-prone "needed rounding methods". Use uint64_t
>> and denominate in mills.
>
> This common intution is incorrect. Financial systems sometimews need to
> calculate fractional amounts, like a 15.03% tax or whatever.
>
> And in those situations, you may be required to implement the required
> rounding rules: what to do when some fractional result lands halfway
> between two pennies: which one does it go to.
>
> You cannot get away from rounding issues just because you used an
> integer representation for mills or penies.

The problem isn't the recommended rounding method, it's repeatability.

With floating point, an intermediate result might end in .4999999993 or
in .5000000007. If the rule is that up to exactly 0.5 rounds down, and
anything beyond rounds up, then it can go either way.

With integer divide, the results should be much more consistent: a
remainder will either be 4999999993 or 5000000007 or whatever, always.

On 12/30/2021 2:06 AM, Bart wrote:
> On 30/12/2021 00:09, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>
>>> Real-world doesn't need to mean dealing with trillions of dollars to
>>> the exact cent.
>>
>> But it can mean dealing with thousands of dollars to the exact cent --
>> and if you get a result of $1234.565001 and round it to $1234.57, when
>> the rules call for a result of $1234.56, that could be a serious problem.
>
> With floating point, that result could as easily be just under 1234.565
> as just over. If the requirements really are that binary floating point
> must have exactly identical results, down to the least significant bit,
> even for intermediates so that rounding will always give the same
> results too, then that's what you have to do.

Yes, and that's why standard floating point is not suitable for accurate
accounting.

IEEE 754 floating point types are designed for applications where its is
OK to assume that all values are approximated, e.g. measurements of
physical quantities. In this kind of environment the goal is to have
lots of decimal digits and huge scale of representation, some
predictable estimate of the propagation of rounding errors, and
calculation efficiency.
The price of not being able to represent exactly the value 1% (i.e.
0.01) is acceptable, even if this value is so common, as long as the
goals above are achieved.

The financial world has different requirements: they want exact results
whenever possible, and rounding errors, when impossible to avoid, are
thoroughly regulated.
This is because balancing the books down to the exact cent is important
to those guys.
In order to achieve this, they are willing to pay some price in terms of
representable numbers: the whole world uses monetary amounts quantified
down to the cent (2 decimal digits). In a similar fashion, conversion
ratios like currency exchange rates are conventionally expressed in a
fixed amount of significant digits (I think it's 6 or 7 digits), and the
same is likely to hold for interest rates as well. There's some upper
limit to the largest monetary amount to handle (e.g. the global wealth),
and so on.
Finally, calculations need not be super fast: a monetary transaction
involves much less computation than, say, modeling a magnetic field.

All in all, it's no surprise that the financial world uses different
data types than floating point, like e.g. the Decimal type.