Re: Simple Question?

SaTriGuy wrote: > 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.) 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? I am sorry to be a royal pain in the ass, but what I am really trying to do is to get Informix or someone to justify to me that UDO greatly enhances the functionality over *commodity* databases. -Mikey