Monte-Carlo probability calculator in Golang

[bln]

Hi,

Anyone have to know where to find a Monte-carlo probability calculator code in Go?

I'm looking for something like this: https://www.optionstrategist.com/calculators/probability

Guess this is simple Monte-carlo using random input?

I need the code for a risk management tool I would like to build to montor the risk of open positions. The tool will be used to monitor risk for directional trades (current price vs stop loss) as well as Cash-Secured Puts or Covered-Call positions.

 

[nooby_mcnoob]

Why on earth would you do this in Go? That is the worst language in history. I suppose you think goroutines will allow you to do N paths concurrently but quite honestly, a threadpool in C++ is sufficient and uses a less stupid language.

With that out of the way, it's easy enough to write yourself. I would just do this.

 

[Simples]

Why on earth would you do this in Go? That is the worst language in history. I suppose you think goroutines will allow you to do N paths concurrently but quite honestly, a threadpool in C++ is sufficient and uses a less stupid language.

With that out of the way, it's easy enough to write yourself. I would just do this.

Have you learnt and used Golang? I'm using it for out of office projects, and more people at work are starting to use it too. Once you understand the various design choices, Golang stands out as a well thought-out language, although still a niche compiled language between C and interpreters. If what you require is alot of convoluted complexity while coding, Golang with its "Go Way" won't fit nicely though, as the language promotes more verbose solutions with less dependencies (own your own code!). Although you can inject behaviour and configuration into methods in Golang, simplest over time is just write out what you need, even copy & paste whenever suitable. You'll probably want to choose simpler solutions than SOAP, XML, et. al., so may require some thinking-time in order to stay away from bloat and Bad Design Patterns.

I agree it is probably best to program yourself, in whatever language works best for you. The important bits are what functionality you actually need, not the platform.

If what you need should be optimized by GPU, maybe Python with some libs are better suited to get a quick solution or MVP? You may not need or even want to hand-code the calculations if solvable by GPU in parallell. If GPU is out of scope for a quick preview, don't be afraid to make something that you can safely eject into recycle bin at any time (though we all know you probably won't! ).

Most important for me personally: I'm more happy when coding in Golang!

 

[nooby_mcnoob]

I'm not an expert, but I did not find anything useful or novel besides goroutines. There are many ways to implement scalable code and goroutines are one. Most new languages these days are geared towards consolidating common patterns so that the users don't need to re-learn them but the languages may not survive any shifts.

C++ with its renewed competition between compilers and regular releases is likely to outlast golang.

 

[Simples]

I'm not an expert, but I did not find anything useful or novel besides goroutines. There are many ways to implement scalable code and goroutines are one. Most new languages these days are geared towards consolidating common patterns so that the users don't need to re-learn them but the languages may not survive any shifts.

C++ with its renewed competition between compilers and regular releases is likely to outlast golang.

I've never even used goroutines. Although channels are novel use in a modern programming language, it may simplify stuff you need to handle concurrently (not in parallell!), it's not everything regarding distributed programming. For most use cases there's no need though.

What intrigues me with Golang is exactly the lack of novelty, although goroutines and interfaces, how they're used to simplify are novel uses of these old concepts. That you can focus on coding, just the code, if you want. Later, you can sprinkle OO, interfaces, concurrency and such imperative paradigms on top. When it compiles, faster and with less/no dependencies than most other compilers, your program usually is logically built so also runs OK. Makes it easier to refactor. Very rarely I discover quirks, mostly for deeply nested data structures and references.

One caveat is that you should make simple solutions with golang, not complex ones. It's perfect for the microservice and polyglot mindset, although not perfect for everything. It's an evolving stable language, the developers committed to making Golang stable backwards-compatible. So optimized for deployments and code to last too. Expect less new features for each major version! Entire specification and bundled tooling are just some pages that can be read and (almost) understood in a sitting.

There's an entirely different mindset worth exploring at least.

 

[nooby_mcnoob]

Yes you are right that golang solves a lot of deployment issues. For that alone, it would be worth learning. However, my preference leans towards Rust in this regard.

 

[tommcginnis]

...But the OP is not going to get to a fair Monte Carlo framework, without passing through a Black Scholes Merton pdf anyway. Why not stop there and work a probability distribution on an ATR, and be done? If you work in "infinite" number of Monte Carlo runs, you end up there anyway.

(FWIW and all, this seems like going three sides around a rectangle, when a single side would do.)

 

[nooby_mcnoob]

@tommcginnis how would you come up with said distribution?

 

[Simples]

...But the OP is not going to get to a fair Monte Carlo framework, without passing through a Black Scholes Merton pdf anyway. Why not stop there and work a probability distribution on an ATR, and be done? If you work in "infinite" number of Monte Carlo runs, you end up there anyway.

(FWIW and all, this seems like going three sides around a rectangle, when a single side would do.)

Often, complicated minds must travel complicated paths, in order to arrive at the simplest of solutions

 

[tommcginnis]

Okay, so as not to veer too far from the OP, let's examine that probability modeler on Larry McMillan's site: https://www.optionstrategist.com/calculators/probability
Is there anything there that is different from an inverted "Expected Move" calculation? No.
It's got a market price, a strike price, a DTE space, and a vol space. So, no different than an Expected Move from ye ol' BSM framework: you've got delta, theta, vega covered (and poor ol' rho is still left dangling in the wind, as pretty much everybody has done...).

Any need for (or use of) Monte Carlo in here? Nope. In fact, there *can't*be* (despite the verbage above the inputs, "Calculate stock market probabilities with this easy to use Monte Carlo simulation program"), because there is no mention of any number (fixed or user-input) of trials. "Hello!"

But the OP (I surmise) wants something broader than just options anyway -- maybe shorts & longs and then puts & calls to support those underlying positions? Regardless, the same inputs for the "calculator" fill the bill: it's still BSM-derived Expected Move time.

As for a probability distribution? Well of course, you still have one at work in that volatility number you have for the spreadsheet inputs: Gaussian Normal in a returns world, logNormal in a market price world. [In my own experience, I mapped out strikes on either side of the market, coded in the Expected Move, as well as stoplight colors at the strikes from |.25| down to |.15| red, from |.15| to |.10| yellow, and from |10| to |.05| green. And outside of all that? a stoplight color round-up based on a Gaussian/Normal, just to contrast with the IV-driven deltas.]

So, how to 'come up with said distribution'? I dunno! I coded Normal because it was symmetric, and allowed me a precise framework to view skew. Over longer term analyses (6-24 months), a logNormal might be more supportable, theory-wise. Pareto -- I've seen that sort of shape *way* too often to ignore, but in shorter-term option spreads, it's simply not been needed. My favorite to *think* about is Weibull -- with four parameters -- with which you can mimic Gauss, Pareto, and logNormal.

At any rate, if this were about *portfolio* management, I would insure that each underlying had its own supported distribution -- maybe based on its short-term IV?? -- and use those proffered distributions as lenses on the individual underlyings and their outlook. I mean, even as an index trader, I would never dream of using S&P VIX on the RUT, right? Ewwwww.

Thems me thoughts.