<?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 Modeling Discipline &#8211; Never Use Magic Numbers</title>
	<atom:link href="http://www.financialmodelingguide.com/modeling-discipline/magic-numbers/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.financialmodelingguide.com/modeling-discipline/magic-numbers/</link>
	<description>Free online resource for financial modeling advice, tips and tricks</description>
	<lastBuildDate>Tue, 13 Jul 2010 17:29:24 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
	<item>
		<title>By: John Richter</title>
		<link>http://www.financialmodelingguide.com/modeling-discipline/magic-numbers/comment-page-1/#comment-5836</link>
		<dc:creator>John Richter</dc:creator>
		<pubDate>Wed, 07 Oct 2009 17:27:33 +0000</pubDate>
		<guid isPermaLink="false">http://www.financialmodelingguide.com/modeling-discipline/magic-numbers/#comment-5836</guid>
		<description>Hmmmm, well this advice can easily be debated by professionals who have been at this a long time.

First off, correct, no reasonable debate on avoiding commercially relevant &#039;magic numbers&#039; (technical name: embedded constants).

However, do not conflate requirement to make inputs explicit (good advice) with use of Excel Names -- the two have no bearing, and one certainly does not need Names to achieve the primary objective.  Using Names is very debatable, as there are legions of problems with them.  See http://www.fast-modeling.net/fast/Excel_Names

As well, to say there is &#039;one&#039; exception to embedded constants (the 1 in your example) may be a bit brave.  There are probably dozens of instances that would be seen as acceptable, and will vary under the circumstances.  Do I need &quot;Days in LIBOR year&quot; explicit, e.g. 360 or 365?  Yes, probably good idea.  However, &quot;Hours in Earth day&quot; = 24, so I can change to 40 or whatever when we move business to Mars?  Not obvious and the 24 will generally be easily recognized in the formula for what it is.

http://www.fast-modeling.net/fast/Formula_design:_Detailed_points

See Point No. 9 with Link to Financial Mechanics blog, &quot;Are hard-wired constants always bad?&quot;

All good stuff.  Keep up the good work,

John Richter
Financial Mechanics</description>
		<content:encoded><![CDATA[<p>Hmmmm, well this advice can easily be debated by professionals who have been at this a long time.</p>
<p>First off, correct, no reasonable debate on avoiding commercially relevant &#8216;magic numbers&#8217; (technical name: embedded constants).</p>
<p>However, do not conflate requirement to make inputs explicit (good advice) with use of Excel Names &#8212; the two have no bearing, and one certainly does not need Names to achieve the primary objective.  Using Names is very debatable, as there are legions of problems with them.  See <a href="http://www.fast-modeling.net/fast/Excel_Names" rel="nofollow">http://www.fast-modeling.net/fast/Excel_Names</a></p>
<p>As well, to say there is &#8216;one&#8217; exception to embedded constants (the 1 in your example) may be a bit brave.  There are probably dozens of instances that would be seen as acceptable, and will vary under the circumstances.  Do I need &#8220;Days in LIBOR year&#8221; explicit, e.g. 360 or 365?  Yes, probably good idea.  However, &#8220;Hours in Earth day&#8221; = 24, so I can change to 40 or whatever when we move business to Mars?  Not obvious and the 24 will generally be easily recognized in the formula for what it is.</p>
<p><a href="http://www.fast-modeling.net/fast/Formula_design:_Detailed_points" rel="nofollow">http://www.fast-modeling.net/fast/Formula_design:_Detailed_points</a></p>
<p>See Point No. 9 with Link to Financial Mechanics blog, &#8220;Are hard-wired constants always bad?&#8221;</p>
<p>All good stuff.  Keep up the good work,</p>
<p>John Richter<br />
Financial Mechanics</p>
]]></content:encoded>
	</item>
</channel>
</rss>
