231–240 of 264 posts
Earlier quoted context omitted.
Well, darn, there goes that. I'll have to re-examine it with C99 reference to assess it's accuracy.
I don't think it's quite that bad, but "for numeric programming" is a very important caveat here. As is "define higher-level".
Earlier quoted context omitted.
That's not how markets work. If an HFT firm saw your order resting, means that nobody wanted to trade with you at that price in the first place. If you cross the market then there is nothing the HTF firm can do. When it becomes aware of your order it will be too late. Of course the order you want to trade with might have disappeared while your order is in flight, but that would not be casually related to you sending…
You're forgetting that "the market" isn't one monolithic thing anymore, it's a number of independent exchanges. Your order goes out to all of them, and the HFT firm sees it on the nearest market then races (and beats!) your offer to all of the other markets. That's why they care about nanoseconds so much, they're racing the speed of light. That's why you get a tiny fraction of your bid filled and then everything else…
> Your order goes out to all of them, and the HFT firm sees it on the nearest market then races (and beats!) your offer to all of the other markets.
No, they have no idea or way to know if your order was big enough to even go to other markets; if they rush out ahead of you and you don't show up, they lose money. What they do is not risk free.
> That's why they care about nanoseconds so much, they're racing the speed of light.
Incorrect. They about latency because all traders have always cared about being first to get their orders in and this would matter whether HFT existed or not. They're not racing the speed of light, they're racing other traders and that would happen no matter the speed of the trading. It's not the speed that matters, it's being first that matters. Even if you outlawed HFT, being first would still matter except it'd be human traders seeing who could push buttons faster.
Earlier quoted context omitted.
What? None of that made any sense. The only way they can reduce liquidity is to stop trading, or buy it all up, neither of which is bad. > Remember, if a HFT extracts money that means the actual seller and actual buyer's price never meets which means the market is not doing accurate price discovery instead providing two prices separated by fractions of a second. Just no, that is not at all correct. HFT increases pric…
Liquidity means the price is stable not that trades will go through.* Stable prices prevent HFT traders from making money. Price accuracy is somewhat debatable. Many HFT traders may toss lot's of trades around at a price, but that does not mean you can buy or sell large numbers of shares at that price as they can easily just be trading relatively small number of shares back and forth. *Dramatic price swings are often…
No, liquidity means there's limit orders sitting on the market. That is quite literally all liquidity is.
> Stable prices prevent HFT traders from making money.
No they don't, stable prices are good for market makers as it reduces the risk of flipping the spread. You can sit there all day long without prices moving a lick and make bank buying at the bid and selling at the ask getting pad the spread for providing liquidity; this is what HFT's want to do. Directional movement, aka volatility, increases the risk for market makers, aka HFTs as it forces them to predict a direction and makes their trades more risky. Yes, some strategies work better with volatility, but market making is the least risky when price doesn't move at all because you're not making your money from the volatility but from the pocketing the spread over and over.
I know why I don't like C++ anymore, it's just no fun.Its slow to compile, the errors are like 6 lines long full of template and class hierarchy that makes it hard to understand what exactly happened, and then of course there's the common coding shortcut of declaring everything auto. (What type is this list? I don't know, it's auto all the way down.) Then there's the whole thing about making constructors, but leaving…
My personal rules for using auto. Only use it iff: 1. the actual type is clearly visible on the right hand side. auto f = make_widget(); // it's a widget auto i = 123; // it's an int auto x = vec3(1.0, 0.0, 0.0); // it's a vector 2. the actual type doesn't really matter so much or is complicated to type out. auto it = vec.begin(); // it's an iterator auto it = // some template expression 3. the actual type is not kno…
auto f = make_widget();
// is f of type widget or widget*?
auto i = 123;
// ok, I guess, but...
// int i = 123; is shorter and more clear.
auto x = vec3(1.0, 0.0, 0.0);
// this can be shorter and simpler.
// vec3 x(1.0, 0.0, 0.0);Earlier quoted context omitted.
That's not how markets work. If an HFT firm saw your order resting, means that nobody wanted to trade with you at that price in the first place. If you cross the market then there is nothing the HTF firm can do. When it becomes aware of your order it will be too late. Of course the order you want to trade with might have disappeared while your order is in flight, but that would not be casually related to you sending…
You're forgetting that "the market" isn't one monolithic thing anymore, it's a number of independent exchanges. Your order goes out to all of them, and the HFT firm sees it on the nearest market then races (and beats!) your offer to all of the other markets. That's why they care about nanoseconds so much, they're racing the speed of light. That's why you get a tiny fraction of your bid filled and then everything else…
What's likely happening in your example is a large trade in one exchange triggering adverse selection protection across all markets from multiple market makers.
Earlier quoted context omitted.
Liquidity means the price is stable not that trades will go through.* Stable prices prevent HFT traders from making money. Price accuracy is somewhat debatable. Many HFT traders may toss lot's of trades around at a price, but that does not mean you can buy or sell large numbers of shares at that price as they can easily just be trading relatively small number of shares back and forth. *Dramatic price swings are often…
> Liquidity means the price is stable not that trades will go through.* Stable prices prevent HFT traders from making money. No, liquidity means there's limit orders sitting on the market. That is quite literally all liquidity is. > Stable prices prevent HFT traders from making money. No they don't, stable prices are good for market makers as it reduces the risk of flipping the spread. You can sit there all day long…
If orders are going though at different prices that's volatility, even if it's just bid ask spread. Reducing bid - ask spread is how HFT traders are supposed to reduce volatility in the first place. Trade at 10.10, 10.00, 10.10 is price motion even if the trades where buy 10.10, sell 10.00 buy 10.00 because a party needs to sit on the other side of the transaction so all trades are both buy and sell transactions.
That said, you can model only one type of transaction and talk about say sell volatility.
Earlier quoted context omitted.
Obviously, full memory safety is not ensured if you ever move over to raw pointers. But if you're copying shared_ptrs around, the reference counting almost always ensures that the memory is valid. The idea is to rarely use references or raw-pointers unless you know you have to.
I'm not questioning how shared_ptr works. I'm claiming that using it as extensively as you describe is totally impractical, and no C++ code works this way.
Its mostly when interacting with legacy code (ie: MFC) where issues come up.
Earlier quoted context omitted.
> That's the compiler's business. I don't care one way or the other about its implementation details. Actually, you do- for at least several reasons. 1. If the runtime or compiler were to have problems with interdependencies. 2. If the compiled code that will actually be executed or the application or service itself across cores, processors, VMs, geography at runtime takes longer to run because of its compiler implem…
lmm's statement was clearly intended to be taken in the context of the statement he was replying to. While your points are valid in general, the fact that the functions will generally be composed into a single translation unit is not an argument against the benefits of making them small.
Earlier quoted context omitted.
I'm not questioning how shared_ptr works. I'm claiming that using it as extensively as you describe is totally impractical, and no C++ code works this way.
I've found the UWP Windows 10 API to be using shared_ptrs and stuff more often. A lot of things are done 'correctly'. Its mostly when interacting with legacy code (ie: MFC) where issues come up.
In my experience, the opposite of what the author claims is true: modern C++ leads to code that's easier to understand, performs better and is easier to maintain. As an example, replacing boost::bind with lambdas allowed the compiler to inline functor calls and avoided virtual function calls in a large code base I've been working with, improving performance. Move semantics also boosted performance. Designing APIs wit…