You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Will Stranathan <ws...@hotmail.com> on 2003/06/10 14:55:07 UTC
[math]? financial functions?
Has there been any discussion about the possibility of adding some work to
Commons somewhere for common financial functions? I don't know if this
necessarily falls in the scope of the Math project, or if I would need to
submit a proposal, or if there is any general interest in this.
Some of the functionality that I'm thinking about is things like:
- Number of periods to bring an annuity to a target value (or pay off a loan
- i.e., NPER)
- Calculation of interest and principal for current payment
- Amortization schedules
- Minimum payment amount calculations, given an interest rate, principal,
desired payoff date, etc.
Let me know if there's enough interest for me to put together a proposal (or
if this need is already met elsewhere).
Thanks,
Will Stranathan
_________________________________________________________________
Add photos to your messages with MSN 8. Get 2 months FREE*.
http://join.msn.com/?page=features/featuredemail
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] financial functions?
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
+1
i'm pretty sure that we don't have the committers at the moment (unless
some others step up) to push forward both maths and a sandbox financials
component. also, it seems likely that the communities will (at least
initially) be almost identical. at some stage a decision will be required
but it should be easier to make this once the development is more mature.
- robert
On Wednesday, June 11, 2003, at 09:47 PM, Tim O'Brien wrote:
> I don't think we have the carrying capacity for that right now. I'm
> proposing that someone put a simple class with some financial
> calculations in
> contrib/econ/src/java/org/apache/commons/math/area/econ/EconUtil.java
>
> 1. "econ" can be viewed as a dependent "module" to commons-math.
> 2. "econ" can be deployed as a separate component jar commons-math-econ
> - remember J2ME devices might only want to use some core Stat routine.
> 3. "econ" will definitely have separate xdocs and user guide
> 4. Once a community has developed around "econ" it can go flourish
> independently.
>
> Essentially, commons-math needs to focus on promotion with a limited
> scope. After promotion we'll see what happens.
>
> On Wed, 2003-06-11 at 15:38, J.Pietschmann wrote:
>> O'brien, Tim wrote:
>>> Alternatively, application areas should be separate modules entirely
>>
>> This could invite people to propose a jakarta-commons-sandbox-financial
>> module...
>>
>> J.Pietschmann
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] financial functions?
Posted by Tim O'Brien <to...@discursive.com>.
I don't think we have the carrying capacity for that right now. I'm
proposing that someone put a simple class with some financial
calculations in
contrib/econ/src/java/org/apache/commons/math/area/econ/EconUtil.java
1. "econ" can be viewed as a dependent "module" to commons-math.
2. "econ" can be deployed as a separate component jar commons-math-econ
- remember J2ME devices might only want to use some core Stat routine.
3. "econ" will definitely have separate xdocs and user guide
4. Once a community has developed around "econ" it can go flourish
independently.
Essentially, commons-math needs to focus on promotion with a limited
scope. After promotion we'll see what happens.
On Wed, 2003-06-11 at 15:38, J.Pietschmann wrote:
> O'brien, Tim wrote:
> > Alternatively, application areas should be separate modules entirely
>
> This could invite people to propose a jakarta-commons-sandbox-financial
> module...
>
> J.Pietschmann
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] financial functions?
Posted by "J.Pietschmann" <j3...@yahoo.de>.
O'brien, Tim wrote:
> Alternatively, application areas should be separate modules entirely
This could invite people to propose a jakarta-commons-sandbox-financial
module...
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] financial functions?
Posted by Phil Steitz <st...@yahoo.com>.
--- "O'brien, Tim" <to...@transolutions.net> wrote:
> Sorry, I've been away for a few days, I'm back.
Will, I think this code
> would be really valuable (I'd like to use it myself), we should add it
> to a contrib source tree...
>
> On Tue, 2003-06-10 at 08:24, Phil Steitz wrote:
> > Al Chou wrote:
> > > --- Will Stranathan <ws...@hotmail.com> wrote:
> > >>Has there been any discussion about the possibility of adding some work
> to
> > >>Commons somewhere for common financial functions?
>
> +1 on the idea of having these classes available for use, +1 on
> *temporarily* adding this to commons-math, but -1 to adding them to
> MathUtils (this code should be stored in a separate contrib source
> tree). Basic Financial utilities would add desired functionality, but
> in the "long term" - specific areas of application should not be a part
> of commons-math. I'm not saying this will never be the case, read on...
>
> Alternatively, application areas should be separate modules entirely
> (right now, within a separate contrib directory) - we don't want to
> create a monolithic collection of code (or a monolithic community of
> developers), but in the short-term I can see that adding these limited
> utilities would encourage active community participation. In other
> words, +1 for this if and only if we promise to keep these things
> limited to very simple applications/algorithms.
>
> I'd rather not see us start to get into too much specialization (not
> that I'm not interested) - IMO commons-math is similar to
> commons-digester. Commons Digester provides a basic mechanism for
> executing a set of rules, these rules are triggered by the structure of
> an XML file. Because commons-digester remains focused on a very limited
> set of goals, it is a utility which can be used for a wide range of
> applications - from marshalling/unmarshalling to/from XML, to a basic
> MathML engine, One could even write some sort of programming language
> using Digester..... The point is that Digester is a very generic piece
> of code. Likewise with the Linux kernel. Strength through simplicity.
>
> We should define the limits of the project and resist the urge to exceed
> those boundaries. This will lead to more nimble and focused
> communities, and it will reduce risk. I've been following the
> discussions surrounding the Struts 1.1 RC2 release, and I think that it
> might be wise to draw bold boundaries around a project. Commons-math is
> X, and if anything falls outside of X we can add it as a contrib, but I
> don't want to open up a Pandora's Box on a sandbox component that hasn't
> made it through the promotion process yet. Also, if a package in
> contrib isn't passing 100% of the tests, it isn't a blocker for a
> release, AND we could distribute those classes separately (think ant.jar
> and optional.jar in Apache Ant).
>
> If someone starts offering Apache utilities for Financial calculations,
> then why not start adding code for: Radioactive Decay, Monte Carlo
> simulations, Utilities for the calculation of gambling odds, Circuit
> simulation, Aerodynamics, Optimization algorithms for the layout of a
> Printed Circuit Board, Quantum Physics, Calculations performed in
> Maritime Navigation, etc....
>
> The goal is to release a simple, focused commons-math - get something
> through promotion, and either at promotion time or afterwards a
> conversation should be started about future direction. I think we've
> got a good amount of community-building to get through first. Add the
> code to a "contrib" source tree.
>
>
Well, I can't really argue with the "focus" argument above, since I have been
repeating the same thing from the beginning. The problem in this specific case
is that what could naturally "belong" in MathUtils is a set of simple functions
for dealing with solving equations involving exponential growth and decay
models. The vast majority of practical applications of this stuff would be to
financial calulations and it would be most convenient for the users not to have
to know that exponentials were involved at all. So...if we were to add the
"pure" math stuff to MathUtils, it would not be used much, since as Al has
pointed out, there's not much going on beyond exp(), pow(), log(), etc. What
would be really interesting/useful is the actual financial applications, but I
now agree with you that this is starting down a slippery slope to add them to
the commons-math package itself. Therefore, I am
+1 for adding simple financial computations to contrib and following the idea
that you have outlined above for adding "applications" modules via contrib.
+1 for descoping "exponential growth and decay models" from initial
commons-math release.
P.S.: struts 1.1 RC2 did ship after all ;-) What caused the most pain at the
end was actually commons dependencies (esp. dbcp -- eventually abandoned -- and
Martin Cooper having to handle FileUploader all by himself), not struts scope,
IMHO. But your main point is well taken. We need to keep defining and
maintaining boundaries.
Phil
__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[math] financial functions?
Posted by "O'brien, Tim" <to...@transolutions.net>.
Sorry, I've been away for a few days, I'm back. Will, I think this code
would be really valuable (I'd like to use it myself), we should add it
to a contrib source tree...
On Tue, 2003-06-10 at 08:24, Phil Steitz wrote:
> Al Chou wrote:
> > --- Will Stranathan <ws...@hotmail.com> wrote:
> >>Has there been any discussion about the possibility of adding some work to
> >>Commons somewhere for common financial functions?
+1 on the idea of having these classes available for use, +1 on
*temporarily* adding this to commons-math, but -1 to adding them to
MathUtils (this code should be stored in a separate contrib source
tree). Basic Financial utilities would add desired functionality, but
in the "long term" - specific areas of application should not be a part
of commons-math. I'm not saying this will never be the case, read on...
Alternatively, application areas should be separate modules entirely
(right now, within a separate contrib directory) - we don't want to
create a monolithic collection of code (or a monolithic community of
developers), but in the short-term I can see that adding these limited
utilities would encourage active community participation. In other
words, +1 for this if and only if we promise to keep these things
limited to very simple applications/algorithms.
I'd rather not see us start to get into too much specialization (not
that I'm not interested) - IMO commons-math is similar to
commons-digester. Commons Digester provides a basic mechanism for
executing a set of rules, these rules are triggered by the structure of
an XML file. Because commons-digester remains focused on a very limited
set of goals, it is a utility which can be used for a wide range of
applications - from marshalling/unmarshalling to/from XML, to a basic
MathML engine, One could even write some sort of programming language
using Digester..... The point is that Digester is a very generic piece
of code. Likewise with the Linux kernel. Strength through simplicity.
We should define the limits of the project and resist the urge to exceed
those boundaries. This will lead to more nimble and focused
communities, and it will reduce risk. I've been following the
discussions surrounding the Struts 1.1 RC2 release, and I think that it
might be wise to draw bold boundaries around a project. Commons-math is
X, and if anything falls outside of X we can add it as a contrib, but I
don't want to open up a Pandora's Box on a sandbox component that hasn't
made it through the promotion process yet. Also, if a package in
contrib isn't passing 100% of the tests, it isn't a blocker for a
release, AND we could distribute those classes separately (think ant.jar
and optional.jar in Apache Ant).
If someone starts offering Apache utilities for Financial calculations,
then why not start adding code for: Radioactive Decay, Monte Carlo
simulations, Utilities for the calculation of gambling odds, Circuit
simulation, Aerodynamics, Optimization algorithms for the layout of a
Printed Circuit Board, Quantum Physics, Calculations performed in
Maritime Navigation, etc....
The goal is to release a simple, focused commons-math - get something
through promotion, and either at promotion time or afterwards a
conversation should be started about future direction. I think we've
got a good amount of community-building to get through first. Add the
code to a "contrib" source tree.
> >>Some of the functionality that I'm thinking about is things like:
> >>- Number of periods to bring an annuity to a target value (or pay off a loan
> >>- i.e., NPER)
> >>- Calculation of interest and principal for current payment
> >>- Amortization schedules
> >>- Minimum payment amount calculations, given an interest rate, principal,
> >>desired payoff date, etc.
> >>
> >>Let me know if there's enough interest for me to put together a proposal (or
> >>if this need is already met elsewhere).
> > Sounds like a good idea to me, I'd say go ahead with the proposal.
>
> I agree. Or just submit patches to MathUtils and we can discuss
> splitting things out as necessary down the road.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math]? financial functions?
Posted by Phil Steitz <ph...@steitz.com>.
Al Chou wrote:
> --- Will Stranathan <ws...@hotmail.com> wrote:
>
>>Has there been any discussion about the possibility of adding some work to
>>Commons somewhere for common financial functions? I don't know if this
>>necessarily falls in the scope of the Math project, or if I would need to
>>submit a proposal, or if there is any general interest in this.
>>
>>Some of the functionality that I'm thinking about is things like:
>>- Number of periods to bring an annuity to a target value (or pay off a loan
>>- i.e., NPER)
>>- Calculation of interest and principal for current payment
>>- Amortization schedules
>>- Minimum payment amount calculations, given an interest rate, principal,
>>desired payoff date, etc.
>>
>>Let me know if there's enough interest for me to put together a proposal (or
>>if this need is already met elsewhere).
>
>
> Sounds like a good idea to me, I'd say go ahead with the proposal.
I agree. Or just submit patches to MathUtils and we can discuss
splitting things out as necessary down the road.
>
> Friday I came across a derivation of amortization that I had printed out a
> couple of years ago, and I just looked for a little Ruby script I had written
> at that time to compute amortization schedules (the << operator/method of a
> Ruby Array is equivalent to the add method of a Java ArrayList or Vector; I
> could have written the following using the push() method to make it read more
> like Java):
>
> principal = 10000 # whatever the principal amount is
> rate = 7.5 # as an annual percentage
> num_periods = 30 * 12 # total number of payment periods
>
> rate /= 100.0 # To convert percent to a real number.
> rate /= 12.0 # To convert annual rate to monthly rate.
>
> payment_amount = principal * rate * ( 1.0 / ( ( 1.0 + rate )**num_periods - 1.0
> ) + 1.0 )
>
> payment_interest_portion = Array.new
> payment_principal_portion = Array.new
> sum_payment_principal_portions = 0
>
> payment_interest_portion[0] = 0
> payment_principal_portion[0] = 0
>
> 1.upto( num_periods ) { |i|
> sum_payment_principal_portions += payment_principal_portion[i - 1]
>
> payment_interest_portion << rate * ( principal -
> sum_payment_principal_portions )
>
> payment_principal_portion << payment_amount - payment_interest_portion[i]
> }
>
> If I remember correctly, the above code was written directly from the formulas
> in the derivation and not ported from existing code, but I'll check, and if so,
> I'm willing to contribute it to commons-math.
>
>
> Al
>
> =====
> Albert Davidson Chou
>
> Get answers to Mac questions at http://www.Mac-Mgrs.org/ .
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
> http://calendar.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math]? financial functions?
Posted by Al Chou <ho...@yahoo.com>.
--- Will Stranathan <ws...@hotmail.com> wrote:
> Has there been any discussion about the possibility of adding some work to
> Commons somewhere for common financial functions? I don't know if this
> necessarily falls in the scope of the Math project, or if I would need to
> submit a proposal, or if there is any general interest in this.
>
> Some of the functionality that I'm thinking about is things like:
> - Number of periods to bring an annuity to a target value (or pay off a loan
> - i.e., NPER)
> - Calculation of interest and principal for current payment
> - Amortization schedules
> - Minimum payment amount calculations, given an interest rate, principal,
> desired payoff date, etc.
>
> Let me know if there's enough interest for me to put together a proposal (or
> if this need is already met elsewhere).
Sounds like a good idea to me, I'd say go ahead with the proposal.
Friday I came across a derivation of amortization that I had printed out a
couple of years ago, and I just looked for a little Ruby script I had written
at that time to compute amortization schedules (the << operator/method of a
Ruby Array is equivalent to the add method of a Java ArrayList or Vector; I
could have written the following using the push() method to make it read more
like Java):
principal = 10000 # whatever the principal amount is
rate = 7.5 # as an annual percentage
num_periods = 30 * 12 # total number of payment periods
rate /= 100.0 # To convert percent to a real number.
rate /= 12.0 # To convert annual rate to monthly rate.
payment_amount = principal * rate * ( 1.0 / ( ( 1.0 + rate )**num_periods - 1.0
) + 1.0 )
payment_interest_portion = Array.new
payment_principal_portion = Array.new
sum_payment_principal_portions = 0
payment_interest_portion[0] = 0
payment_principal_portion[0] = 0
1.upto( num_periods ) { |i|
sum_payment_principal_portions += payment_principal_portion[i - 1]
payment_interest_portion << rate * ( principal -
sum_payment_principal_portions )
payment_principal_portion << payment_amount - payment_interest_portion[i]
}
If I remember correctly, the above code was written directly from the formulas
in the derivation and not ported from existing code, but I'll check, and if so,
I'm willing to contribute it to commons-math.
Al
=====
Albert Davidson Chou
Get answers to Mac questions at http://www.Mac-Mgrs.org/ .
__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org