On Fri, Jan 23, 2015 at 2:42 PM, Antoine Pitrou
I can't understand why a "non-maths person" would want to write one implementation of that - apart from recreation or educational purposes, that is.
I'll give you a real life example. I never thought of myself as a "maths person," so I guess that makes me a "non-maths person." I am a software engineer. I leave the math to people with PhDs in mathematics, statistics, and engineering. In my day job at a trading firm, I work on automated trading systems. Most models do all their internal calculations using floating point math. At some point though, the desired order prices calculated by the model's indicators need to be converted to actual prices acceptable to the exchange. Floating point numbers being what they are, a computed value will almost never correspond to a valid order price. If your computed price is very close to, but not exactly on a tick boundary and you're not careful, you might erroneously price your order too aggressively or too passively. In these situations you need to recognize when the floating point value you have is within some small tolerance equal to a price on an exact tick boundary. Furthermore, these comparisons need to take into account the different tick sizes of different contracts, The CME's Yen/USD futures contract (6Y) has a tick size (minimum change between two valid prices) of $.000001 while their Euro/USD futures contract (6E) has a tick size of $.0001. In my world, this is done in Python, though the problem arises independent of the language used. It also has nothing to do with the relative sophistication of the math used internal to the model. It is more-or-less just a case of format conversion on output. Skip