mirror of
https://github.com/Gnucash/gnucash.git
synced 2025-02-25 18:55:30 -06:00
Fix some typos
This commit is contained in:
parent
f4c6d65395
commit
67ab9e90d2
@ -1826,7 +1826,7 @@ def gnc_numeric_from_decimal(decimal_value):
|
||||
TEN = int(Decimal(0).radix()) # this is always 10
|
||||
numerator_place_value = 1
|
||||
# add each digit to the final value multiplied by the place value
|
||||
# from least significant to most sigificant
|
||||
# from least significant to most significant
|
||||
for i in range(len(digits)-1,-1,-1):
|
||||
numerator += digits[i] * numerator_place_value
|
||||
numerator_place_value *= TEN
|
||||
|
@ -66,7 +66,7 @@ def gnc_numeric_from_decimal(decimal_value):
|
||||
TEN = int(Decimal(0).radix()) # this is always 10
|
||||
numerator_place_value = 1
|
||||
# add each digit to the final value multiplied by the place value
|
||||
# from least significant to most sigificant
|
||||
# from least significant to most significant
|
||||
for i in range(len(digits)-1,-1,-1):
|
||||
numerator += digits[i] * numerator_place_value
|
||||
numerator_place_value *= TEN
|
||||
|
@ -8,7 +8,7 @@ id,company,name,addr1,addr2,addr3,addr4,phone,fax,email,notes,shipname,shipaddr1
|
||||
#company with the same ID will be UPDATED. This may not be what you want!
|
||||
000099,Average Company,Accounts Dept,50 Poor Avenue,,,,,,,,,,,,,,,
|
||||
,Academy,Academy,Some Street,,,,555-237-6959,,,,,,,,,,shipmail
|
||||
,company,name,addr1,addr2,addr3,addr4,phone,fax,emai,lnotes,shipname,shipaddr1,shipaddr2,shipaddr3,shipaddr4,shipphone,shipfax,shipemail
|
||||
,company,name,addr1,addr2,addr3,addr4,phone,fax,email,notes,shipname,shipaddr1,shipaddr2,shipaddr3,shipaddr4,shipphone,shipfax,shipemail
|
||||
,No Address Company,Accounts,,,,,,,,,,,,,,,,
|
||||
|
||||
#Just another example after a blank line
|
||||
|
Can't render this file because it has a wrong number of fields in line 2.
|
@ -103,7 +103,7 @@
|
||||
* interest only loan), or large enough to fully repay both the interest and
|
||||
* principal during the term of the loan (a fully amoritized loan). Many loans
|
||||
* fall somewhere between, with payments that do not fully cover repayment of
|
||||
* both the principal and interst. These loans require a larger final payment
|
||||
* both the principal and interest. These loans require a larger final payment
|
||||
* (balloon) to complete their amortization. Payments may occur at the
|
||||
* beginning or end of a payment period. If you and your friend had agreed on
|
||||
* monthly repayment of the $800 loan at 12% NAR compounded monthly, twelve
|
||||
@ -220,7 +220,7 @@
|
||||
* compounding Frequency, CF, is simply the number of times per
|
||||
* year, the monies in the financial transaction are compounded. In
|
||||
* the U.S., monies are usually compounded daily on bank deposits,
|
||||
* and monthly on loans. Somtimes Long term deposits are compounded
|
||||
* and monthly on loans. Sometimes Long term deposits are compounded
|
||||
* quarterly or weekly.
|
||||
*
|
||||
* The Payment Frequency, PF, is simply how often during a year
|
||||
@ -596,7 +596,7 @@
|
||||
* T[n] = -i*n*(PV + C) - i*C*n(n+1)/2
|
||||
* T[n] = -i*n*(PV + (C*(n - 1)/2))
|
||||
*
|
||||
* Note: substituing for C = -PV/N, in the equations for PV[n], I[n],
|
||||
* Note: substituting for C = -PV/N, in the equations for PV[n], I[n],
|
||||
* P[n], and T[n] would give the following equations:
|
||||
*
|
||||
* PV[n] = PV*(1 - n/N)
|
||||
@ -739,12 +739,12 @@
|
||||
* 1. The payment *, interest paid, principal paid and remaining PV
|
||||
* for each payment period are computed and displayed. At the end of
|
||||
* each year a summary is computed and displayed and the total
|
||||
* interest paid is diplayed at the end.
|
||||
* interest paid is displayed at the end.
|
||||
*
|
||||
* 2. A summary is computed and displayed for each year. The
|
||||
* interest paid during the year is computed and displayed as well
|
||||
* as the remaining balance at years end. The total interest paid
|
||||
* is diplayed at the end.
|
||||
* is displayed at the end.
|
||||
*
|
||||
* 3. An amortization schedule is computed for a common method of
|
||||
* advanced payment of principal is computed and displayed. In this
|
||||
@ -1016,7 +1016,7 @@
|
||||
* Example 6: Balloon Payment
|
||||
* On long term loans, small changes in the periodic payments can generate
|
||||
* large changes in the future value. If the monthly payment in example 5 is
|
||||
* rounded down to $1125, how much addtional (balloon) payment will be due
|
||||
* rounded down to $1125, how much additional (balloon) payment will be due
|
||||
* with the final regular payment.
|
||||
* <>pmt=-1125
|
||||
* -1,125
|
||||
@ -2034,7 +2034,7 @@ Amortization_Schedule (amort_sched_ptr amortsched)
|
||||
else
|
||||
{
|
||||
/* remaining pv less than advanced principal payment reduce
|
||||
* advanced pricipal payment to remaining pv and set
|
||||
* advanced principal payment to remaining pv and set
|
||||
* remaining pv to fv */
|
||||
adv_pmt = -pv;
|
||||
pv = fv;
|
||||
@ -2137,7 +2137,7 @@ Amortization_Schedule (amort_sched_ptr amortsched)
|
||||
case 'o':
|
||||
/* Constant payment to principal use constant payment equal to
|
||||
* original pv divided by number of periods. constant payment to
|
||||
* pricipal could be amount specified by user. */
|
||||
* principal could be amount specified by user. */
|
||||
amortsched->schedule.first_yr =
|
||||
amortyr = (amort_sched_yr_ptr) calloc (1, sizeof (amort_sched_yr));
|
||||
amortsched->total_periods = n;
|
||||
|
@ -455,7 +455,7 @@ the option '~a'."))
|
||||
#f #f #f #f)))
|
||||
|
||||
;; budget option
|
||||
;; TODO: need to double-check this proc (dates back to r11545 or eariler)
|
||||
;; TODO: need to double-check this proc (dates back to r11545 or earlier)
|
||||
;;
|
||||
;; Always takes/returns a budget
|
||||
;; Stores the GUID in the KVP
|
||||
|
@ -71,7 +71,7 @@ returned.
|
||||
|
||||
Simple/ad-hoc lazy evaluation works well when data dependencies are
|
||||
simple, but it breaks down when there are too many/circular
|
||||
relationships. It becomes all too easy to get trapped in inifinite
|
||||
relationships. It becomes all too easy to get trapped in infinite
|
||||
loops of corrections. The goal of moving to a formal constraint
|
||||
system is to introduce specific, well-defined sync points where
|
||||
constraint checking can be done, without incuring circular
|
||||
|
@ -176,7 +176,7 @@ static void qof_instance_class_init(QofInstanceClass *klass)
|
||||
"Object Last Update",
|
||||
"A pointer to the last time this object was "
|
||||
"updated. This value is present for use by "
|
||||
"backends and shouldnot be written by other "
|
||||
"backends and shouldn't be written by other "
|
||||
"code.",
|
||||
G_PARAM_READWRITE));
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user