Live data from Hacker News

Finance sites erroneously show Amazon, Apple, other stocks crashing

marketwatch.com

81–90 of 98 posts

Re: Finance sites erroneously show Amazon, Apple, other stocks crashing

#81
post #13
post #6

Earlier quoted context omitted.

Stock tracking websites don't need to be perfect, just need to be better than the humans they replaced. Faster, free, and less errors doesn't mean they must be error free. Self driving cars just need to be better than humans, and given the number of teens and senior citizens on the road...

Statistically that's true but realistically I wouldn't want to use a self-driving car that's only a little better than the average driver. It's one thing to have a friend that's a bad driver and another thing to ride in their car.

Elon Musk said that he is aiming for his self-driving cars to be 10x safer than the average driver (without LIDAR btw).

Re: Finance sites erroneously show Amazon, Apple, other stocks crashing

#82
post #52

One nice thing about SEC-regulated markets - unlike the various cryptocurrency markets - is that it's possible for trades to be rolled back if they are "clearly erroneous". That isn't perfect - if the data is only a little off, it might not be possible to get a trade rolled back - but it tends to limit how much havoc is called. https://www.sec.gov/news/press/2009/2009-215.htm (My understanding is that trades can also…

Why can't majority participants in a crypto currency agree to roll back?

Anyone could roll forward all the transactions again, so you need to do more than just roll back. You need to declare the transactions invalid somehow.

And unless every participant is in on it, you will end up with two cryptocurrencies afterwards. Holdings won't match on both chains. Find an exchange that is not running the same chain as you and spend a transaction that is valid on his chain but not the other, and by transferring out other cryptos you could empty their wallet.

Re: Finance sites erroneously show Amazon, Apple, other stocks crashing

#83
post #52

Earlier quoted context omitted.

Why can't majority participants in a crypto currency agree to roll back?

The majority of participants do not in a crypto-currency. Only the majority of the hashing power.

Hashing power can not roll back transactions. Hashing power alone can not change rules embedded in the software.

Proof of work is used to order transactions in the global ledger to avoid the double spending problem.

Re: Finance sites erroneously show Amazon, Apple, other stocks crashing

#84
post #7

I've actually seen a number of times where Google Finance has a daily low that was never reached or a high that wasn't shown on the graph (sometimes many percentage points away). It's also notoriously bad when there's a gap up or down, and will sometimes cut out various parts of the graph. But still, seems to be one of the better ones out there, as I still use it. Just don't treat it as authority. Another interesting…

Google Finance does not even have a working price plotter, that's pretty awful in a basic way.

Of all of google's services Finance is the worst, it seems to be supported by cheap contractors in Elbonia. I mean Flash charts??? Sometimes stocks that were removed remain in the lists for months. The stock screener seems to be a student take home test where the student failed.

Re: Finance sites erroneously show Amazon, Apple, other stocks crashing

#85
post #58

Earlier quoted context omitted.

Unless you cashed out.

It takes 3 days for trades to settle, so you can't really cash out quickly. Google "T+3" for more details.

Not in cryptoland. The guy who bought ETH at $0.1 could have sent the ETH out of the exchange minutes later.

Re: Finance sites erroneously show Amazon, Apple, other stocks crashing

#86
post #75

Earlier quoted context omitted.

Using production systems to run tests... What could go wrong?

It's actually considered best practice in various categories of technology to run tests on the production systems. https://en.wikipedia.org/wiki/Built-in_self-test

I agree that there are a class of problems that you simply will not find on canary environments, but most of the places I have been will run their smoke suite independent of the actual service. A problem of this type, e.g. core to your SLA/SLO, shouldn't be tested on the live production deployment. An alternative would be creating a dummy ticker and playing fake data, but even that is dangerous on a live exchange.

Re: Finance sites erroneously show Amazon, Apple, other stocks crashing

#88
post #7

I've actually seen a number of times where Google Finance has a daily low that was never reached or a high that wasn't shown on the graph (sometimes many percentage points away). It's also notoriously bad when there's a gap up or down, and will sometimes cut out various parts of the graph. But still, seems to be one of the better ones out there, as I still use it. Just don't treat it as authority. Another interesting…

Google Finance does not even have a working price plotter, that's pretty awful in a basic way.

What is a price plotter?

Re: Finance sites erroneously show Amazon, Apple, other stocks crashing

#89

Earlier quoted context omitted.

Isn't that sort of what happened in the "flash crash"? Or was it purely market-makers and algorithms working their way down to 0? Big regulated markets now have circuit breakers to prevent this, unfortunately.

But the idea is that you put a buy option at the low price. Ie, you say "I would like to buy 1 million microsoft stock, at the price of 1 cent". The flash crash was cause by stop-loss orders. IE, if the price gets low, then sell. Instead of price gets low, then buy.

That is not at all what options are.

Re: Finance sites erroneously show Amazon, Apple, other stocks crashing

#90

Earlier quoted context omitted.

It's actually considered best practice in various categories of technology to run tests on the production systems. https://en.wikipedia.org/wiki/Built-in_self-test

When done intentionally. I've seen lots of tests 'escape' their environment for a bunch of reasons (tests got sent to production with a deploy, human was on the wrong machine and ran a manual test command etc etc). It's almost impossible not to screw up at some point, I try to focus on minimising the small mistakes (airline pilots have commented that it's not the first problem that kills you it's the second one).

That's why artificially differentiated steps are critical. If the "deploy to test" procedure looks exactly like the "deploy to prod" procedure, except with different servers, then you're asking for human error.

Ensure the test deploy procedure will always fail if run against prod targets when half-asleep. Whether it's something like requiring a different config setting or a reload or an account switch. Anything that breaks the process-as-usual.

Post reply on HN