As an aside: gawd, I hate their use of "patriot" that way, does anybody know the etymology of the word "patriot" with respect to this legislation? Whose idea was it to use "patriot" and why? It seems like the worst/most transparent type of label possible for such a group of laws that seek to strip away personal freedoms and rights to privacy.
I've always taken it as a principle that anything named by a government is the exact opposite of whatever adjectives appear in the name. Examples: (*) The People's Democratic Republic of China. None of the above! (*) The Patriot Act. (*) The No Child Left Behind Act. (*) The Job Creation Act (*) The United Nations (*) The Central Intelligence Agency
Dijjer (rhymes, apparently, with "fridge"-er) is a SourceForge project. It claims to be open source and free software, but I'll be darned if I can find any source code for it!
I will wait until the source is available before installing this one, thanks.
Moderators, please give this AC his due. The link leads to the opinions of an engineer who has actually done physical, psychological, and thought experiments about high-end (I refuse to say audiophile!) audio cabling.
As I understand it, the idea for EOF was not conceived by anyone at NeXT, but rather by Swiss Bank (now UBS). This was back in the mid-90s when the finance industry was NeXT's savior.
NeXT thought it was a great idea, ran with it, and created EOF. Which was better than Swiss Bank's implementation, but for which they also wanted a princely sum. Many rich customers went ahead and bought, but Swiss Bank, despite being among the richest of NeXT's clients, was so angry at being charged out the wazoo for what was essentially their own invention, stuck with their own implementation.
And, BTW, some institutions (Bank of America comes to mind) still employed developers coding in OpenStep (version 3.3 IIRC) until well after the year 2000!
I have previously ranted about the valuation of these options here on Slashdot. I realize that such is not in the Slashdot tradition, but rather than continuing to just rant, I actually spent some time this weekend to do something about the problem.
Since I am a quant, I created a model (released at my public website under the GPL) for pricing employee stock options properly. Or at least more properly than people are doing right now. Much as I dislike working in Excel and VB, I decided they were the way to reach the widest audience of accountants, so the model is in VB and I included an Excel spreadsheet.
Let's hope the accountants find this model and start using it. FASB 123 requests that they use Black-Scholes or a binomial variation. It's time they did it right!
Moderators, I realize it's late in the game for such a post, but I really hope this model or a similar one improves the accounting standards in this country...I could use a little love. Thanks!
Actually, I did put blackout periods in my model. However, they do not affect the option value as much as you might think (at least to extent that stock prices follow the Black-Scholes stochastic model).
The reason is fairly simple: the blackout periods turn an American-exercise option into a Bermudan-exercise option with relatively frequent decision times. Just a few decision dates manage to capture most of the value difference between European and American exercise.
To address your point about selling options on the market...the idea is generally sound, but does not entirely capture the asymmetry between ESO and market options. For example, a certain number of employees quit every year, relinquishing their options. This attrition (in the company's favor) should be modeled and estimated, though it obviously doesn't apply to other market participants.
Employees also should be expected to value options and the resulting stock less than the market as a consequence of their inability to hedge properly; they are not allowed to sell short, and often must hold stock resulting from option exercise for a year or so. Though their subjective valuation clearly has no direct bearing on what the firm's option valuation ought to be, it does affect their exercise decisions in a way that will reduce the option value indirectly. This too can be modeled. To see this, think about the following: if you had a one-year hold restriction on the resulting $20,010 stock, would you be willing to exercise your options that were (in total) only $10 in the money? You shouldn't be, as the $20,000 in the bank you could otherwise keep will have far less volatility.
Oh, I'm certainly not arguing that expensing should not happen. I simply wish they would have gotten the specification correct, right from the start. Proper valuation is now going to require another fight.
The Black-Scholes formula itself has narrow application: namely to vanilla options with European exercise. I believe you are referring to the Black-Scholes stochastic model, which of course has wider applicability. My solution was actually a solution of the Black-Scholes model with boundary conditions germane to ESO.
The features and restrictions found in ESO do not require a model other than Black-Scholes, but they do generally introduce path-dependence (even early exercise implies path-dependence), and thus make the formula inapplicable even if the model itself remains valid.
Path-dependence nearly always requires approximate solutions to the Black-Scholes SDE. One can argue whether these approximations themselves are models or not. For example, the binomial model is indeed a model, though in the high N limit it converges to the same thing as analytic solutions. However a trinomial tree is not a model, as it fails to eliminate arbitrage. Nevertheless it is perfectly functional as a technique for obtaining approximate solutions to the PDE, and converges to the continuous limit faster than binomial trees do.
Speaking of models, one could actually argue with justice that the Black-Scholes model is not particularly well suited to ESO due to the long maturities involved, and that some sort of stochastic volatility model is called for. Unfortunately, such models are a real pain to parameterize in a way everyone agrees on.
[I was a quant working at a major bank until leaving this year]
Putting a value on those options is itself a matter of some contention. Basically, employee stock options (ESO) nearly always have a strike K bigger than the current stock price S when they are granted. The value of the option lies in the fact that it is reasonably likely that at some later date, K>S.
So, a foolish measure of value would be intrinsic value: i.e. MAX(0, S-K). There is a formula called the Black-Scholes formula used for pricing options with only one allowable exercise date, and no other special features. That formula is quite inappropriate for pricing ESO, since ESO come with lots of other quirks, including vesting periods, stock holding periods, employee attrition, and (not least) lengthy time intervals in which they are exercisable.
Of course, to accountants even the BS formula is exotic. Rather than using a proper model (hinted at in FASB 123 with the moniker "binomial model") to price the options, accountants prefer to use BS, and then "adjust" the results as they see fit to account for the various features. The results of this are better than just using intrinsic value of course, but not by much.
I developed a model for the bank to use in pricing its ESO. It was reasonably correct, in the sense that it used the traditional approach of a trinomial tree to model the stochastic process followed by the stock price, along with code to account for the various quirks of our options. It still had manipulable inputs, such as volatility, but at least accountants would have to have justified their values.
Of course, internal politics killed the model in favor of the BS formula, and arbitrary accountant's adjustments. If that's what happened in a major bank, with the generally stated goal to transparently publish numbers, and with guys like me around to develop models like that...well, how much are you going to be able to trust the option expenses published by other companies?
I hope that FASB fixes this, and deprecates the use of the BS formula in inappropriate contexts.
As the Maple guy points out, in Maple and Mathematica, it's just n!.
Note that in Mma (and this is probably also true of Maple) you also get reasonable results for noninteger arguments, e.g. Gamma(1+n) or
4! = 52.3428
which is a sign of a symbolic mathematics package rather than a programmer's package. Matlab takes the programming view of the factorial, but of course has the gamma function available for this who want it.
I don't really have a point about Haskell itself here. It looks reasonable to work with, but I'm not sure why in a mathematical context one would choose it over Octave, Python, Mma, Maple, or Matlab.
Yeah, I tried that, using the ISBN or some other number on one of my CDs. It worked OK (the two or three times I needed that password) until I switched to MP3s and archived my CDs in a different city. The next time I needed that password, I was screwed.
In retrospect, perhaps I could have found another copy online or at a store. But the moral is the same: it's easy to forget you are treating a book or CD or whatever as a password reference too, and woe betide anyone who loses their passord reference material!
[I was a quant working at a major bank until leaving this year]
Putting a value on those options is itself a matter of some contention. Basically, employee stock options (ESO) nearly always have a strike K bigger than the current stock price S when they are granted. The value of the option lies in the fact that it is reasonably likely that at some later date, K>S.
So, a foolish measure of value would be intrinsic value: i.e. MAX(0, S-K). There is a formula called the Black-Scholes formula used for pricing options with only one allowable exercise date, and no other special features. That formula is quite inappropriate for pricing ESO, since ESO come with lots of other quirks, including vesting periods, stock holding periods, employee attrition, and (not least) lengthy time intervals in which they are exercisable.
Of course, to accountants even the BS formula is exotic. Rather than using a proper model (hinted at in FASB 123 with the moniker "binomial model") to price the options, accountants prefer to use BS, and then "adjust" the results as they see fit to account for the various features. The results of this are better than just using intrinsic value of course, but not by much.
I developed a model for the bank to use in pricing its ESO. It was reasonably correct, in the sense that it used the traditional approach of a trinomial tree to model the stochastic process followed by the stock price, along with code to account for the various quirks of our options. It still had manipulable inputs, such as volatility, but at least accountants would have to have justified their values.
Of course, internal politics killed the model in favor of the BS formula, and arbitrary accountant's adjustments. If that's what happened in a major bank, with the generally stated goal to transparently publish numbers, and with guys like me around to develop models like that...well, how much are you going to be able to trust the option expenses published by other companies?
I hope that FASB fixes this, and deprecates the use of the BS formula in inappropriate contexts.
any analyst with two brain cells to rub together can tell the difference between "earnings" and "fully diluted earnings"
True, but the only shares that go into the computation of outstanding fully diluted shares are ones that are in the money. Options are nearly always granted with a strike price greater than the current stock price. They have no intrinsic value (where I am using the technical meaning of the term), but rather just optionality value. You can look up the accounting rules for yourself.
As it stands, the only way to really find out about options granted is in footnotes to the K's and Q's. And even there reporting is spotty.
And, by the way, deciding what value to assign to the options is almost universally mishandled. I'll probably post about that elsewhere in this article.
(I was a quant at Bank One -- now JP Morgan -- and developed an ESO pricing model)
Try finding an all-in-one (print/fax/scan) that works if you happen to use Fast User Switching. It doesn't exist. (BTW I just RMA'd the latest offering from HP)
I wish the built-in fax played nicely with an answering machine!
It's worth noting that, at this point, Chicago's infamous South Side has improved in many ways. The best place to go for poverty and violence these days would be the Austin neighborhood, on the west side.
To satify your curiosity -- I work for a hedge fund now. Rather than modeling exotic derivatives or making fancy portfolio risk measurements, I'll be attempting to come up with trading strategies.
Models remain involved so I guess you might still call me a quant. But there will be a lot less variety, and the mathematics will be even more trivial.
[Disclaimer: Until recently I was a quant, and among other things was responsible for the coding quality of Bank One's quantitative libraries. I am no longer there, and do not speak for JPMorgan, who now owns the business.]
There are two main considerations you have with respect to libraries of numerical routines: (1) Having access to quick, accurate, and reliable numerical analytic routines such as singular value decompositions, FFTs, and optimizers. (2) Having convenient and standard ways within your organization of defining vectors and matrices, as well as simple operations (e.g. dot products) on them.
To address the first problem, I think you have to look first to the quality of the numerical routines you plan to use. Paying attention to their native language or available interfaces is foolish. Would you really trust a 5-year-old SVD written in Java over something from LAPACK or NAG? I sure wouldn't, and I would never guarantee a model calibration based on it!
Thus, your numerical analytic routines will come in some hoary library, and you will have to interface to it as best you can. In many cases you could use JNI or, if that makes you nervous, have the Java portion communicate with the library wrapped in a separate process using sockets or something. But the point is, quality is more important than interface here.
The other issue is standardization of vector and matrix encapsulations etc. Here I am less opinionated, but my thoughts are roughly as follows: there are probably lots of vector/matrix implementations out there, some of which must be good. You might as well just choose one with an API and implementation you are impressed with...it's not as though you will be expecting it to do your numerical math. Sure you won't get operator overloading (if you're in Java) but having done financial mathematics in C, C++ and MatLab, I can say with a fair degree of certainty that you will use overloading far less often than you might think.
You now have a convenient standard for manipulating objects, and a quality library. Write the glue and you're done.
Oh, and for those people recommending MatLab/Octave/Mathematica etc., let me just say that most of us in finance know about them and many use them for prototyping. Python, and (ugh) VB too. But ultimately one is often asked to create a library that gets handed off to internal developers for use in one or more custom apps, which are then distributed to anywhere from 5 to a couple hundred users, and run on portfolios of thousands of securities. Even if, say, your MatLab routine didn't need licensing for each workstation and took just a couple milliseconds to run, you're still looking at perceptible delays before the user sees results.
Modern financial applications are one of those few remaining arenas in which computers are Not Yet Fast Enough.
You don't need to follow -- they remain
on
Steel Bolt Hacking
·
· Score: 1
I've made picks from the bristles, and have some comments:
(1) You don't need to follow the sweeper. It's not like anything *else* comes by to sweep away the bristles! Just walk along the edge looking for them. (2) The bristles are hard to perceive at first; it's something about what your mind is trained to see. It may take 30 mins to find your first one. 5 minutes for your second. Then you'll see them all over! An interesting side effect is, after your mind is trained, you can't *help* but see them all over. Your friends will think you are weird for constantly stopping and picking them up. (3) The bristles make excellent torsion wrenches, but IMO are not sufficiently broad to carve down into picks suitable for some of the longer reaches necessary in door locks (if you have a short pin behind a long one). They're fine for push-up-and-release though. (4) Usually the bristles have, at most, surface rust. Use sandpaper to clean them up.
Wearing contact lenses and glasses carry their own risks, which (depending on your behavior) might actually make Lasik-corrected eyes less risky for you.
I found that when wearing soft lenses, I was often too lazy to take them out when sleeping. That carries a nontrivial risk of serious infection. I went to wearing glasses more often, but then since I get around by bicycle, I found myself riding often with my normal glasses on. Normal glasses are lousy eye protection, as the good-looking thin lenses are far more susceptible to shattering than polycarbonate cycling shields.
Now theoretically I could have changed my behavior to mitigate those risks. And believe me, before Lasik, I tried. But the fact was that I lacked the willpower or whatever, and so I believe getting Lasik was the less risky option for me.
That said, pay close attention to the posts explaining poor night vision in terms of expanded irises. The point is, the wider the "lens" carved by the laser, the deeper into your cornea it must protrude. When your irises expand beyond lens width due to darkness, you start to get blurring and halos. This isn't horribly complicated, but appears to be sufficiently complicated that the doctors never bother explaining it.
Your doctor must choose a balance between the darkness threshold at which your night vision begins to suffer, and the amount of cornea he/she is willing to burn away.
Hold on, it's not like the BMW glovebox interface. They appear to expect the iPod to be mounted near your dashboard -- say with a bracket that clips onto your A/C vents.
I agree with you about the "cassette" receptacle, though. It would be much neater. Perhaps they went with this design because it is less dependent on iPod form factors...future iPods may be smaller, wider, whatever, and the system will presumably continue to work with them.
Slashdot Mirror
do it on the cheap for a college student? I don't have access to acid or anything else like that.
I thought all college students had access to acid. And alcohol. And lots more means of permanent destruction besides!
As an aside: gawd, I hate their use of "patriot" that way, does anybody know the etymology of the word "patriot" with respect to this legislation? Whose idea was it to use "patriot" and why? It seems like the worst/most transparent type of label possible for such a group of laws that seek to strip away personal freedoms and rights to privacy.
I've always taken it as a principle that anything named by a government is the exact opposite of whatever adjectives appear in the name. Examples:
(*) The People's Democratic Republic of China. None of the above!
(*) The Patriot Act.
(*) The No Child Left Behind Act.
(*) The Job Creation Act
(*) The United Nations
(*) The Central Intelligence Agency
the list goes on and on.
on the project page.
The little bit of code I perused looks good.
Dijjer (rhymes, apparently, with "fridge"-er) is a SourceForge project. It claims to be open source and free software, but I'll be darned if I can find any source code for it!
I will wait until the source is available before installing this one, thanks.
Moderators, please give this AC his due. The link leads to the opinions of an engineer who has actually done physical, psychological, and thought experiments about high-end (I refuse to say audiophile!) audio cabling.
As I understand it, the idea for EOF was not conceived by anyone at NeXT, but rather by Swiss Bank (now UBS). This was back in the mid-90s when the finance industry was NeXT's savior.
NeXT thought it was a great idea, ran with it, and created EOF. Which was better than Swiss Bank's implementation, but for which they also wanted a princely sum. Many rich customers went ahead and bought, but Swiss Bank, despite being among the richest of NeXT's clients, was so angry at being charged out the wazoo for what was essentially their own invention, stuck with their own implementation.
And, BTW, some institutions (Bank of America comes to mind) still employed developers coding in OpenStep (version 3.3 IIRC) until well after the year 2000!
I have previously ranted about the valuation of these options here on Slashdot. I realize that such is not in the Slashdot tradition, but rather than continuing to just rant, I actually spent some time this weekend to do something about the problem.
Since I am a quant, I created a model (released at my public website under the GPL) for pricing employee stock options properly. Or at least more properly than people are doing right now. Much as I dislike working in Excel and VB, I decided they were the way to reach the widest audience of accountants, so the model is in VB and I included an Excel spreadsheet.
Let's hope the accountants find this model and start using it. FASB 123 requests that they use Black-Scholes or a binomial variation. It's time they did it right!
Moderators, I realize it's late in the game for such a post, but I really hope this model or a similar one improves the accounting standards in this country...I could use a little love. Thanks!
Actually, I did put blackout periods in my model. However, they do not affect the option value as much as you might think (at least to extent that stock prices follow the Black-Scholes stochastic model).
The reason is fairly simple: the blackout periods turn an American-exercise option into a Bermudan-exercise option with relatively frequent decision times. Just a few decision dates manage to capture most of the value difference between European and American exercise.
To address your point about selling options on the market...the idea is generally sound, but does not entirely capture the asymmetry between ESO and market options. For example, a certain number of employees quit every year, relinquishing their options. This attrition (in the company's favor) should be modeled and estimated, though it obviously doesn't apply to other market participants.
Employees also should be expected to value options and the resulting stock less than the market as a consequence of their inability to hedge properly; they are not allowed to sell short, and often must hold stock resulting from option exercise for a year or so. Though their subjective valuation clearly has no direct bearing on what the firm's option valuation ought to be, it does affect their exercise decisions in a way that will reduce the option value indirectly. This too can be modeled. To see this, think about the following: if you had a one-year hold restriction on the resulting $20,010 stock, would you be willing to exercise your options that were (in total) only $10 in the money? You shouldn't be, as the $20,000 in the bank you could otherwise keep will have far less volatility.
Oh, I'm certainly not arguing that expensing should not happen. I simply wish they would have gotten the specification correct, right from the start. Proper valuation is now going to require another fight.
The Black-Scholes formula itself has narrow application: namely to vanilla options with European exercise. I believe you are referring to the Black-Scholes stochastic model, which of course has wider applicability. My solution was actually a solution of the Black-Scholes model with boundary conditions germane to ESO.
The features and restrictions found in ESO do not require a model other than Black-Scholes, but they do generally introduce path-dependence (even early exercise implies path-dependence), and thus make the formula inapplicable even if the model itself remains valid.
Path-dependence nearly always requires approximate solutions to the Black-Scholes SDE. One can argue whether these approximations themselves are models or not. For example, the binomial model is indeed a model, though in the high N limit it converges to the same thing as analytic solutions. However a trinomial tree is not a model, as it fails to eliminate arbitrage. Nevertheless it is perfectly functional as a technique for obtaining approximate solutions to the PDE, and converges to the continuous limit faster than binomial trees do.
Speaking of models, one could actually argue with justice that the Black-Scholes model is not particularly well suited to ESO due to the long maturities involved, and that some sort of stochastic volatility model is called for. Unfortunately, such models are a real pain to parameterize in a way everyone agrees on.
[I was a quant working at a major bank until leaving this year]
Putting a value on those options is itself a matter of some contention. Basically, employee stock options (ESO) nearly always have a strike K bigger than the current stock price S when they are granted. The value of the option lies in the fact that it is reasonably likely that at some later date, K>S.
So, a foolish measure of value would be intrinsic value: i.e. MAX(0, S-K). There is a formula called the Black-Scholes formula used for pricing options with only one allowable exercise date, and no other special features. That formula is quite inappropriate for pricing ESO, since ESO come with lots of other quirks, including vesting periods, stock holding periods, employee attrition, and (not least) lengthy time intervals in which they are exercisable.
Of course, to accountants even the BS formula is exotic. Rather than using a proper model (hinted at in FASB 123 with the moniker "binomial model") to price the options, accountants prefer to use BS, and then "adjust" the results as they see fit to account for the various features. The results of this are better than just using intrinsic value of course, but not by much.
I developed a model for the bank to use in pricing its ESO. It was reasonably correct, in the sense that it used the traditional approach of a trinomial tree to model the stochastic process followed by the stock price, along with code to account for the various quirks of our options. It still had manipulable inputs, such as volatility, but at least accountants would have to have justified their values.
Of course, internal politics killed the model in favor of the BS formula, and arbitrary accountant's adjustments. If that's what happened in a major bank, with the generally stated goal to transparently publish numbers, and with guys like me around to develop models like that...well, how much are you going to be able to trust the option expenses published by other companies?
I hope that FASB fixes this, and deprecates the use of the BS formula in inappropriate contexts.
As the Maple guy points out, in Maple and Mathematica, it's just n! .
Note that in Mma (and this is probably also true of Maple) you also get reasonable results for noninteger arguments, e.g. Gamma(1+n) or
4! = 52.3428
which is a sign of a symbolic mathematics package rather than a programmer's package. Matlab takes the programming view of the factorial, but of course has the gamma function available for this who want it.
I don't really have a point about Haskell itself here. It looks reasonable to work with, but I'm not sure why in a mathematical context one would choose it over Octave, Python, Mma, Maple, or Matlab.
Yeah, I tried that, using the ISBN or some other number on one of my CDs. It worked OK (the two or three times I needed that password) until I switched to MP3s and archived my CDs in a different city. The next time I needed that password, I was screwed.
In retrospect, perhaps I could have found another copy online or at a store. But the moral is the same: it's easy to forget you are treating a book or CD or whatever as a password reference too, and woe betide anyone who loses their passord reference material!
Yeah, both devices process in parallel.
[I was a quant working at a major bank until leaving this year]
Putting a value on those options is itself a matter of some contention. Basically, employee stock options (ESO) nearly always have a strike K bigger than the current stock price S when they are granted. The value of the option lies in the fact that it is reasonably likely that at some later date, K>S.
So, a foolish measure of value would be intrinsic value: i.e. MAX(0, S-K). There is a formula called the Black-Scholes formula used for pricing options with only one allowable exercise date, and no other special features. That formula is quite inappropriate for pricing ESO, since ESO come with lots of other quirks, including vesting periods, stock holding periods, employee attrition, and (not least) lengthy time intervals in which they are exercisable.
Of course, to accountants even the BS formula is exotic. Rather than using a proper model (hinted at in FASB 123 with the moniker "binomial model") to price the options, accountants prefer to use BS, and then "adjust" the results as they see fit to account for the various features. The results of this are better than just using intrinsic value of course, but not by much.
I developed a model for the bank to use in pricing its ESO. It was reasonably correct, in the sense that it used the traditional approach of a trinomial tree to model the stochastic process followed by the stock price, along with code to account for the various quirks of our options. It still had manipulable inputs, such as volatility, but at least accountants would have to have justified their values.
Of course, internal politics killed the model in favor of the BS formula, and arbitrary accountant's adjustments. If that's what happened in a major bank, with the generally stated goal to transparently publish numbers, and with guys like me around to develop models like that...well, how much are you going to be able to trust the option expenses published by other companies?
I hope that FASB fixes this, and deprecates the use of the BS formula in inappropriate contexts.
any analyst with two brain cells to rub together can tell the difference between "earnings" and "fully diluted earnings"
True, but the only shares that go into the computation of outstanding fully diluted shares are ones that are in the money. Options are nearly always granted with a strike price greater than the current stock price. They have no intrinsic value (where I am using the technical meaning of the term), but rather just optionality value. You can look up the accounting rules for yourself.
As it stands, the only way to really find out about options granted is in footnotes to the K's and Q's. And even there reporting is spotty.
And, by the way, deciding what value to assign to the options is almost universally mishandled. I'll probably post about that elsewhere in this article.
(I was a quant at Bank One -- now JP Morgan -- and developed an ESO pricing model)
Try finding an all-in-one (print/fax/scan) that works if you happen to use Fast User Switching. It doesn't exist. (BTW I just RMA'd the latest offering from HP)
I wish the built-in fax played nicely with an answering machine!
It's worth noting that, at this point, Chicago's infamous South Side has improved in many ways. The best place to go for poverty and violence these days would be the Austin neighborhood, on the west side.
To satify your curiosity -- I work for a hedge fund now. Rather than modeling exotic derivatives or making fancy portfolio risk measurements, I'll be attempting to come up with trading strategies.
Models remain involved so I guess you might still call me a quant. But there will be a lot less variety, and the mathematics will be even more trivial.
[Disclaimer: Until recently I was a quant, and among other things was responsible for the coding quality of Bank One's quantitative libraries. I am no longer there, and do not speak for JPMorgan, who now owns the business.]
There are two main considerations you have with respect to libraries of numerical routines:
(1) Having access to quick, accurate, and reliable numerical analytic routines such as singular value decompositions, FFTs, and optimizers.
(2) Having convenient and standard ways within your organization of defining vectors and matrices, as well as simple operations (e.g. dot products) on them.
To address the first problem, I think you have to look first to the quality of the numerical routines you plan to use. Paying attention to their native language or available interfaces is foolish. Would you really trust a 5-year-old SVD written in Java over something from LAPACK or NAG? I sure wouldn't, and I would never guarantee a model calibration based on it!
Thus, your numerical analytic routines will come in some hoary library, and you will have to interface to it as best you can. In many cases you could use JNI or, if that makes you nervous, have the Java portion communicate with the library wrapped in a separate process using sockets or something. But the point is, quality is more important than interface here.
The other issue is standardization of vector and matrix encapsulations etc. Here I am less opinionated, but my thoughts are roughly as follows: there are probably lots of vector/matrix implementations out there, some of which must be good. You might as well just choose one with an API and implementation you are impressed with...it's not as though you will be expecting it to do your numerical math. Sure you won't get operator overloading (if you're in Java) but having done financial mathematics in C, C++ and MatLab, I can say with a fair degree of certainty that you will use overloading far less often than you might think.
You now have a convenient standard for manipulating objects, and a quality library. Write the glue and you're done.
Oh, and for those people recommending MatLab/Octave/Mathematica etc., let me just say that most of us in finance know about them and many use them for prototyping. Python, and (ugh) VB too. But ultimately one is often asked to create a library that gets handed off to internal developers for use in one or more custom apps, which are then distributed to anywhere from 5 to a couple hundred users, and run on portfolios of thousands of securities. Even if, say, your MatLab routine didn't need licensing for each workstation and took just a couple milliseconds to run, you're still looking at perceptible delays before the user sees results.
Modern financial applications are one of those few remaining arenas in which computers are Not Yet Fast Enough.
I've made picks from the bristles, and have some comments:
(1) You don't need to follow the sweeper. It's not like anything *else* comes by to sweep away the bristles! Just walk along the edge looking for them.
(2) The bristles are hard to perceive at first; it's something about what your mind is trained to see. It may take 30 mins to find your first one. 5 minutes for your second. Then you'll see them all over! An interesting side effect is, after your mind is trained, you can't *help* but see them all over. Your friends will think you are weird for constantly stopping and picking them up.
(3) The bristles make excellent torsion wrenches, but IMO are not sufficiently broad to carve down into picks suitable for some of the longer reaches necessary in door locks (if you have a short pin behind a long one). They're fine for push-up-and-release though.
(4) Usually the bristles have, at most, surface rust. Use sandpaper to clean them up.
Perhaps the parent poster was thinking of tiny tricycle racing.
Wearing contact lenses and glasses carry their own risks, which (depending on your behavior) might actually make Lasik-corrected eyes less risky for you.
I found that when wearing soft lenses, I was often too lazy to take them out when sleeping. That carries a nontrivial risk of serious infection. I went to wearing glasses more often, but then since I get around by bicycle, I found myself riding often with my normal glasses on. Normal glasses are lousy eye protection, as the good-looking thin lenses are far more susceptible to shattering than polycarbonate cycling shields.
Now theoretically I could have changed my behavior to mitigate those risks. And believe me, before Lasik, I tried. But the fact was that I lacked the willpower or whatever, and so I believe getting Lasik was the less risky option for me.
That said, pay close attention to the posts explaining poor night vision in terms of expanded irises. The point is, the wider the "lens" carved by the laser, the deeper into your cornea it must protrude. When your irises expand beyond lens width due to darkness, you start to get blurring and halos. This isn't horribly complicated, but appears to be sufficiently complicated that the doctors never bother explaining it.
Your doctor must choose a balance between the darkness threshold at which your night vision begins to suffer, and the amount of cornea he/she is willing to burn away.
Hold on, it's not like the BMW glovebox interface. They appear to expect the iPod to be mounted near your dashboard -- say with a bracket that clips onto your A/C vents.
I agree with you about the "cassette" receptacle, though. It would be much neater. Perhaps they went with this design because it is less dependent on iPod form factors...future iPods may be smaller, wider, whatever, and the system will presumably continue to work with them.
Volumes (in cubic centimeters)
iPod mini: 59
Walkman HD: 77
iPod: 100
Pretty good for a 20GB unit, though! I'll probably stick with iPod for myself.