Re: Simple Question?

>> With financial data, the concept of date does not follow the calander date. >> For instance options generally we commonly refer to March options, but what >we >> really mean are the options that expire on the friday of the third week of >> March. Also in studying the life of that option, we are not so much >concerned >> about the number of days until the expiration date, but the number of >trading >> days. >> > >Uhmm no. A date is a date.The problems with financial instruments is that >they are >merely contracts. >You can easily and trivially create a database of all the option call dates >by >market/country/product. >Then when you have a March call date, you know the expiration date of march >for >that >product and you enter that date into the instrument. Voila now do you date >calculations. >But then again there is another term known as day basis. >What you could be thinking of is Day Basis or Bond Basis. >During calculations based on the bond basis, you apply a different formulas >for dates based on the type of instrument. For example some instruments pay >out >over a 30/360. >This means that they assume 30 days a month and 360 days a year. Sometimes >you >assume that >there are 365 days in a year. (No concept of leap years.) Others deal with >realtime >dates including >leap years. > > >> We could have a whole series of functions to calculate these differences, >but >> that would require the programmer to constantly be aware to call the >funtions. >> >> It would be much easier to simply state TRADING_DAYS = EXPIRATION_DATE - >TODAY. >> By defining expiration_date as a type, this could automatically happen. >> >> > >No because this doesn't really work.Going back to the derivatives example, >you have >a swap. (You have two instruments both >which you and the other party are exchanging payments. You make his payments >he >makes yours. Either fixed/float or float/float tagged to different indexs. >[COFI vs >LIBOR] >or [OFF (USD) vs YEN] (Hedging FX) [OK so I'm making it simple] >The problem is that if the payment schedule falls on a holiday, you either >pay >early >or later depending on the country and the holiday. The problem is that if you >make >a late payment, you pay a penalty. Now on a 50 Million Dollar SWAP that you >have a >lump >sum payment at maturity, and you miss the payment by a day, you are talking >mucho >bucks. >(And it does happen!) Its not really a calculation per say but a set of >agreed upon >rules which >may change based on the type of instruments. > >Really the solution is fairly trivial. And doesn't require UDO or anything >outside >of >your programming language, some defined rules and look up table for the >holidays >by country code and dates. (When dealing with FX) > >Now even in your example, the date calculation could be done via a shared >library >routine. >In OO terms, there are two different ways of considering this. It all depends >on >how you >design the object hierarchy and classes. > >In either case, because you can have different instrument types, you can have >different *expiration dates*. Options vs Leaps, or Callable or non-callable >bonds. >Or if you deal in American vs European options then you have different >calculations. >(Now consider that you may have several applications each with a different >concept >of >*expiration date* so with datablade technology, how do you handle that?) > > >Sorry but the *datablade* technology does not make a compelling argument for >a >paradigm shift. I can't justify the addional expense of the UDO in this >instance. >(Try again.) I'm afraid that you missed on the essence of my earlier response. All things can be done using the existing tools and paradigms. They could also be done with assembler code/machine language. But that's not the purpose of why any object oriented environment is used. The main reason for any OO environment is to enable the designer to expand the methods and rules for simpler data types to cover any data type that the designer might envision. > >Even looking at a Mortgage banking application, I don't see how you could >justify >it? >Lets say we want to create a datawarehouse modeling the Pipeline. How does >UDO >make things better? > >Or lets look at modeling Interest Rate Risk. >I want to run one scenario using a standardized pre-payment table. >I want to run another scenario using a custom pre-payment table. >Now I want to model both future cashflows based on these assumptions >and the same generated interest rate path. > >How does UDO handle that? >Will it allow me to do database lookups dynamically on the fly based on an >Objects >parameters? > >Even still, what are the advantages over ESQL/C and ODS ? > >I realize that I am getting in to some serious issues that are pretty >specific to >the banking >industry. I notice that First Union is now a named customer, even though they >were >running Informix way back in '94 ;-) How did Informix sell them on UDO? >They are planning on using UDO right? > > Madison Pruet