 




<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Financial Calculations in RPG</title>
	<atom:link href="http://itknowledgeexchange.techtarget.com/itanswers/financial-calculations-in-rpg/feed/" rel="self" type="application/rss+xml" />
	<link>http://itknowledgeexchange.techtarget.com/itanswers/financial-calculations-in-rpg/</link>
	<description></description>
	<lastBuildDate>Tue, 21 May 2013 18:28:49 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	
	<item>
		<title>By: solutions1</title>
		<link>http://itknowledgeexchange.techtarget.com/itanswers/financial-calculations-in-rpg/#comment-44032</link>
		<dc:creator>solutions1</dc:creator>
		<pubDate>Sat, 24 Sep 2005 22:23:22 +0000</pubDate>
		<guid isPermaLink="false">#comment-44032</guid>
		<description><![CDATA[Let me see if I can add something to this discussion.

In the &quot;olden days,&quot;  people did lookups of cost of money factors from pre-computed tables, and those tables were based on interest rate and number of periods. For example, one could look up the present worth of a future amount factor for an interest rate of 10% per year and twenty period in such a table and get the value  .148644. They then multiplied the selected factor times the specific monetary amount in question ? for example, multiplying that factor times a future amount of $2,000 yield a present worth of $297.29.

You are in effect bringing back the &quot;olden days&quot; by creating your own executables, and mimicking those steps will get you to where you want to go without losing precision.

For a given transaction or case, first you must access (or compute) the appropriate values for &quot;interest&quot; (cost of money). You also need to compute the number of periods, and the two need to be expressed in the same units of time. For example, if you expect a payment in September, 2025 and you deal in annual interest rates, your software or some built-in calendaring function would need to compute the number of years (20). If your rates are in months or days or whatever, you would of course compute time in those units. Note that sealing in small units of time, like days, makes it essential that you preserve precision.

Once you have i and n, you plug them into the appropriate formula to produce the appropriate factor. For example, as shown below, an interest rate of 10% per annum and a payment that won&#039;t be received for 20 years will result in a present worth factor of .148643628. As long as you can do floating point arithmetic and you retain enough precision for your business purpose, the formulas should present little problem. This factor in effect is the present worth of  1 unit of money at 10% over 20 years.

Once you have computed the factor, you multiply the factor times the number of dollars in the particular transaction ? e.g., in this case multiply .148643626 times $2,000 to produce the present worth amount of $297.29. You can blend the two steps together (as I presume Microsoft does inside Excel), but particularly for debugging and auditing you want to be sure you do not inadvertently lose precision, so computing (and perhaps logging) the factor separately isolates the opportunity for error and also enables you to cross-check against some &quot;olden days&quot; book that includes cost of money tables. Those same books (e.g., Engineering Economy by Gerald W. Smith) include the formulas themselves.

Below I have pasted in pieces of an Excel spreadsheet that does the computation exactly as described above and without using built-in Excel cost of money formulas. I named the input cells &quot;i&quot; and &quot;n,&quot; and the column labeled &quot;Formula&quot; is the Excel equation that I wrote to compute the factor (I left out the Excel = to force this display; on my spreadsheet the operative formula with the Excel = is within the column headed &quot;formula&quot; ).

As I think is apparent, writing code in almost any programming language to compute cost of money factors is pretty trivial. Most of the work will be in serving up and manipulating the input data and saving and publishing the outputs.

I do not know if you are doing this because of Sarbanes-Oxley or other compliance issues, but there are many other situations where people are being forced to give up the &quot;black box&quot; solutions (and very good ones) built into MS Office and elsewhere, taking those people back to &quot;olden days.&quot; If you are a high compliance line of work (e.g., consumer lending), make sure your selection of formulas and exact implementation match regulatory requirements because truncation in intermediate results could get up into compliance trouble - (e.g., the car or mortgage payment is overstated by a penny), .

									Fulton Wilcox						Colts Neck Solutions LCC

present worth of a future sum (10% interest, 20 years)
Formula	       factor	     amount   Equals
1/((1+i)^n) 0.148643628	  $2,000.00   $297.29

annuity from a present sum (10% interest, 20 years)	

Formula                      factor        amount   equals		
(i*((1+i)^n))/(((1+i)^n)-1) 0.117459625 $10,000.00 $1,175
						
]]></description>
		<content:encoded><![CDATA[<p>Let me see if I can add something to this discussion.</p>
<p>In the &#8220;olden days,&#8221;  people did lookups of cost of money factors from pre-computed tables, and those tables were based on interest rate and number of periods. For example, one could look up the present worth of a future amount factor for an interest rate of 10% per year and twenty period in such a table and get the value  .148644. They then multiplied the selected factor times the specific monetary amount in question ? for example, multiplying that factor times a future amount of $2,000 yield a present worth of $297.29.</p>
<p>You are in effect bringing back the &#8220;olden days&#8221; by creating your own executables, and mimicking those steps will get you to where you want to go without losing precision.</p>
<p>For a given transaction or case, first you must access (or compute) the appropriate values for &#8220;interest&#8221; (cost of money). You also need to compute the number of periods, and the two need to be expressed in the same units of time. For example, if you expect a payment in September, 2025 and you deal in annual interest rates, your software or some built-in calendaring function would need to compute the number of years (20). If your rates are in months or days or whatever, you would of course compute time in those units. Note that sealing in small units of time, like days, makes it essential that you preserve precision.</p>
<p>Once you have i and n, you plug them into the appropriate formula to produce the appropriate factor. For example, as shown below, an interest rate of 10% per annum and a payment that won&#8217;t be received for 20 years will result in a present worth factor of .148643628. As long as you can do floating point arithmetic and you retain enough precision for your business purpose, the formulas should present little problem. This factor in effect is the present worth of  1 unit of money at 10% over 20 years.</p>
<p>Once you have computed the factor, you multiply the factor times the number of dollars in the particular transaction ? e.g., in this case multiply .148643626 times $2,000 to produce the present worth amount of $297.29. You can blend the two steps together (as I presume Microsoft does inside Excel), but particularly for debugging and auditing you want to be sure you do not inadvertently lose precision, so computing (and perhaps logging) the factor separately isolates the opportunity for error and also enables you to cross-check against some &#8220;olden days&#8221; book that includes cost of money tables. Those same books (e.g., Engineering Economy by Gerald W. Smith) include the formulas themselves.</p>
<p>Below I have pasted in pieces of an Excel spreadsheet that does the computation exactly as described above and without using built-in Excel cost of money formulas. I named the input cells &#8220;i&#8221; and &#8220;n,&#8221; and the column labeled &#8220;Formula&#8221; is the Excel equation that I wrote to compute the factor (I left out the Excel = to force this display; on my spreadsheet the operative formula with the Excel = is within the column headed &#8220;formula&#8221; ).</p>
<p>As I think is apparent, writing code in almost any programming language to compute cost of money factors is pretty trivial. Most of the work will be in serving up and manipulating the input data and saving and publishing the outputs.</p>
<p>I do not know if you are doing this because of Sarbanes-Oxley or other compliance issues, but there are many other situations where people are being forced to give up the &#8220;black box&#8221; solutions (and very good ones) built into MS Office and elsewhere, taking those people back to &#8220;olden days.&#8221; If you are a high compliance line of work (e.g., consumer lending), make sure your selection of formulas and exact implementation match regulatory requirements because truncation in intermediate results could get up into compliance trouble &#8211; (e.g., the car or mortgage payment is overstated by a penny), .</p>
<p>									Fulton Wilcox						Colts Neck Solutions LCC</p>
<p>present worth of a future sum (10% interest, 20 years)<br />
Formula	       factor	     amount   Equals<br />
1/((1+i)^n) 0.148643628	  $2,000.00   $297.29</p>
<p>annuity from a present sum (10% interest, 20 years)	</p>
<p>Formula                      factor        amount   equals<br />
(i*((1+i)^n))/(((1+i)^n)-1) 0.117459625 $10,000.00 $1,175</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Performance optimized by W3 Total Cache. Learn more: http://www.w3-edge.com/wordpress-plugins/

Page Caching using memcached
Database Caching 6/9 queries in 0.092 seconds using memcached
Object Caching 268/271 objects using memcached

Served from: itknowledgeexchange.techtarget.com @ 2013-05-21 19:22:50 -->