Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Can’t afford Bloomberg Terminal? No prob, I built the next best thing

github.com

Post reply on HN
Print view View original

301–310 of 314 posts

Re: Show HN: Can’t afford Bloomberg Terminal? No prob, I built the next best thing

#301

Post by z2 »

throwawaysea wrote: post #118
z2 wrote: post #63

Earlier quoted context omitted.

Interestingly enough, as someone with both Bloomberg terminal and FactSet subscriptions, I still don't have real-time market data for most asset classes and securities. Those are actually add-on costs that I don't need for my research (I'm not a trader). The value for me (again not a trader) comes from having 25 years of robust fundamental and market data along with powerful portfolio analysis tools and models.

I guess I’m not very familiar with these offerings. I was really asking “how do I acquire a real time feed to plug into this open source software”. But it sounds like it’s not valuable to have that in practice?

I guess it depends on what you want to use the data for. There are plenty reasonably priced APIs for streaming the latest closing price once a second for, say, up to 5 stocks at a time. That's much more manageable than, say, streaming all 100,000 global stock and their transactions, bids, asks, closing prices, outstanding orders across multiple stock exchanges per stock, and 3-dimensional options data (strike price, expiration date, type). This may approach (but still be a few orders of magnitude less than) particle collider levels of data.

Re: Show HN: Can’t afford Bloomberg Terminal? No prob, I built the next best thing

#303

Post by Hnrobert42 »

pc86 wrote: post #224
Hnrobert42 wrote: post #206

Is it just me, or is the feel of the comment on this post different than other HN posts? There are a lot more snarky jokes. A little more combative. It feels like why I stopped reading Reddit. I hope it doesn’t metastasize to posts on other topics.

> Please don't post comments saying that HN is turning into Reddit. It's a semi-noob[0] illusion[1], as[2] old[3] as[4] the[5] hills.[6] [7] [0] https://news.ycombinator.com/item?id=926703 [1] https://news.ycombinator.com/item?id=633099 [2] https://news.ycombinator.com/item?id=582513 [3] https://news.ycombinator.com/item?id=289254 [4] https://news.ycombinator.com/item?id=253657 [5] https://news.ycombinator.com/item?i…

You missed the point of my post entirely. I said that the comments on this one post felt like Reddit. Specifically I noted that feels different from HN.

Re: Show HN: Can’t afford Bloomberg Terminal? No prob, I built the next best thing

#304

Post by aryc19 »

kolinko wrote: post #101
aryc19 wrote: post #35

Earlier quoted context omitted.

It looks promising. I was going to create an account to try it but then I stopped. Their privacy policy states I would have to send an email to delete my account data. Why do people make it harder to remove an account when the sign up process so easy?

I have the same process on my site. The reason is that it is such a risky operation that you want to have a human in the middle as a safeguard from accidental deletion. Account cancellations and so on are automatic of course, but anything that can’t be rolled back requires human input.

It guess it's not hard to put a deletion timer and send warning emails before actual deletion. Not every service out there requires you to send an email to delete your account.

Re: Show HN: Can’t afford Bloomberg Terminal? No prob, I built the next best thing

#305

Post by eclat »

berkes wrote: post #138
TheAdamist wrote: post #49

Should probably rewrite it in rust, to solve the markets memory leaks, otherwise everything will keep going up.

I know you are joking. But asides from the securities offered by the typing system and borrow checker, Rust (and Go; and maybe others to some extend) have going for them is that the compiled binary is "OOTB". I'm on ubuntu, and it seems all python tooling is there to start running Gamestonks Terminal. But more often then not, getting a Python, Nodejs or Ruby project running requires a lot of fiddling, insider-informa…

ASDF requires nearly the same amount of effort for every language

Re: Show HN: Can’t afford Bloomberg Terminal? No prob, I built the next best thing

#306

Post by Grustaf »

ghgdynb1 wrote: post #293
minikites wrote: post #230

Earlier quoted context omitted.

Hacker News is Reddit with a thesaurus. This is only an insult to Hacker News if you think Reddit is bad, but they clearly share the same dynamic brought on by the perverse incentives of the "karma" system and individually threaded comments. Classic discussion forum interfaces (e.g. vBulletin or phpBB) allow for much richer and calmer communication.

I think “Reddit but smarter” is a legitimate point of differentiation. I gave up Reddit for HN because despite all the issues you probably have in mind, the average quality of interaction and information is marginally better here.

Alternatively, reddit but nerdier and less fun. Granted I've only seen wallstreetbets which might not be entirely representative...

Re: Show HN: Can’t afford Bloomberg Terminal? No prob, I built the next best thing

#307

Post by nwallin »

29athrowaway wrote: post #271
bidirectional wrote: post #217

Earlier quoted context omitted.

I can't see any reason to use fixed point numbers here, seems like floating point would be perfectly sufficient.

Floating point numbers are inadequate to manipulate accounts representing currency, and for finance at a large. https://stackoverflow.com/questions/3730019/why-not-use-doub...

You're cargo culting. Floating point numbers are perfectly fine for financial modeling and forecasting. If your goal is to figure out what stocks to buy/sell, it doesn't matter if your software calculates the P/E ratio as 19.232738273816 but the actual value is 19.232738273817. It doesn't even matter if you calculate it as 19.23 but the actual value is 19.22.

When you're storing balances or transacting payments between institutions, you need to emulate a specific set of operations, part of which includes using fixed point numbers. It is not sufficient to just use fixed point, you also need the correct number of digits (AFAIK it's 4 digits with US currency) you need the correct rounding mode, etc.

Every few years someone comes along with a big new idea to rewrite the aging dinosaur COBOL code that runs the financial world in something modern. It never works. Nobody wants to go through the old COBOL code to figure out exactly what the code does, they take a greenfield approach with a description of what the UI is and an incomplete spec of the operations that need to happen. And then when it comes time to test the system, they get balances and numbers that are wrong. Because the only thing they know is "we need to use fixed point" but never bother to understand the actual full scope of how basic financial arithmetic is unique, and different from "normal" arithmetic.

Re: Show HN: Can’t afford Bloomberg Terminal? No prob, I built the next best thing

#308

Post by 29athrowaway »

nwallin wrote: post #307
29athrowaway wrote: post #271

Earlier quoted context omitted.

Floating point numbers are inadequate to manipulate accounts representing currency, and for finance at a large. https://stackoverflow.com/questions/3730019/why-not-use-doub...

You're cargo culting. Floating point numbers are perfectly fine for financial modeling and forecasting. If your goal is to figure out what stocks to buy/sell, it doesn't matter if your software calculates the P/E ratio as 19.232738273816 but the actual value is 19.232738273817. It doesn't even matter if you calculate it as 19.23 but the actual value is 19.22. When you're storing balances or transacting payments betwe…

The problem gets compounded as you chain more operations together. Financial calculations often involve long sequences of operations and that is where you can see the true effect of what I am mentioning.

With numbers that are large enough, a 1% or 0.1% difference means a lot of money. And if you have an automated system making decisions based on those numbers that can translate into financial ruin, legal problems, etc.

Leave the ad hominem aside, btw, noone wants to hear about it.

Re: Show HN: Can’t afford Bloomberg Terminal? No prob, I built the next best thing

#309

Post by dan-robertson »

29athrowaway wrote: post #308
nwallin wrote: post #307

Earlier quoted context omitted.

You're cargo culting. Floating point numbers are perfectly fine for financial modeling and forecasting. If your goal is to figure out what stocks to buy/sell, it doesn't matter if your software calculates the P/E ratio as 19.232738273816 but the actual value is 19.232738273817. It doesn't even matter if you calculate it as 19.23 but the actual value is 19.22. When you're storing balances or transacting payments betwe…

The problem gets compounded as you chain more operations together. Financial calculations often involve long sequences of operations and that is where you can see the true effect of what I am mentioning. With numbers that are large enough, a 1% or 0.1% difference means a lot of money. And if you have an automated system making decisions based on those numbers that can translate into financial ruin, legal problems, et…

Fixed point numbers have finite precision. As soon as you multiply two fixed point numbers you risk losing precision unless you use more space for your result. You can’t fix your “long chain of calculation” by making it fixed point as you’ll still be rounding things (unless it happens that all your numbers need 54-63 bits of precision and you were wasting bits on the exponent)

Apart from in accounting, the two problems with floats are nonassociativity and speed, neither of which are particularly relevant here.

The risk of losing money does not look like subtle floating point rounding errors. It looks like someone fucking up a formula in excel or the model being wrong or the model being right but risk not being hedged.plenty of people in finance will add percentages as x + y instead of doing (1-(1+x)*(1+y)) because it’s simpler (this works fine because log(1+x) is approximately x when it’s small, and it can obviously be made better by taking the log earlier but plenty of percentage inputs to a model may be rough guesses anyway (who cares if you write 5% or log(5%)))

Re: Show HN: Can’t afford Bloomberg Terminal? No prob, I built the next best thing

#310

Post by coolgeek »

nwallin wrote: post #307
29athrowaway wrote: post #271

Earlier quoted context omitted.

Floating point numbers are inadequate to manipulate accounts representing currency, and for finance at a large. https://stackoverflow.com/questions/3730019/why-not-use-doub...

You're cargo culting. Floating point numbers are perfectly fine for financial modeling and forecasting. If your goal is to figure out what stocks to buy/sell, it doesn't matter if your software calculates the P/E ratio as 19.232738273816 but the actual value is 19.232738273817. It doesn't even matter if you calculate it as 19.23 but the actual value is 19.22. When you're storing balances or transacting payments betwe…

> Nobody wants to go through the old COBOL code to figure out exactly what the code does, they take a greenfield approach with a description of what the UI is and an incomplete spec of the operations that need to happen.

The only way to improve on this description would be to note that the contract rate for each of the persons involved in this endeavor would be in the $485/hour range (of which, the labor provider might get $50). And then to note the 12 layers of management sign-off/approval on top of that - billed separately.

Post reply on HN