These are chat archives for rust-lang/rust

21st
Jan 2018
Patrick Elsen
@xfbs
Jan 21 2018 18:40
What's the state on named arguments in Crystal again?
Denis Lisov
@tanriol
Jan 21 2018 18:41
@xfbs Did you mean some other channel?
Patrick Elsen
@xfbs
Jan 21 2018 18:42
@tanriol Oh whoops yes I did, sorry
Daniel Bischof
@dbischof90
Jan 21 2018 20:51
Hey guys!
Someone up for a little programming problem?
Patrick Elsen
@xfbs
Jan 21 2018 20:52
Of course. What do you got in store?
Daniel Bischof
@dbischof90
Jan 21 2018 20:52
I'm fighting with a recursive method and have trouble with ownership there
Really shouldn't be complicated
Patrick Elsen
@xfbs
Jan 21 2018 20:54
Let's see if I can help a fellow Darmstadtian out :)
Daniel Bischof
@dbischof90
Jan 21 2018 20:54
Lot of code, I know, just a copy-paste of the scratchbook
No shit, what? :D
Patrick Elsen
@xfbs
Jan 21 2018 20:55
Yeah that's a lotta cote, I'll see if I can reduce it a little. And yup, live from the Martinsviertel
Daniel Bischof
@dbischof90
Jan 21 2018 20:55
Hehe, used to live at Riegerplatz
But graduated in Nov '16, live in FFM now ;)
I'm a beginner in Rust, as you might see, so there are a lot of rough edges there
Be as critical as you can. I want this execute_and_resolve method to be solved first - conceptually that should really be possible to be boiled down to some allocation and these three match statements. But to access head_order_peek in the second match I had to include book_head into the second match now and since then I have the feeling it's going downwards
Patrick Elsen
@xfbs
Jan 21 2018 20:59
Hmm, I'm digging in, but it's a lotta code
Daniel Bischof
@dbischof90
Jan 21 2018 20:59
It's essentially just this one method, the rest is just there fore reference
If there are no error messages left for that method, I am more than happy :D
Patrick Elsen
@xfbs
Jan 21 2018 21:06
Hmm it's hard, rustc isn't gonna let you call a &mut self method on an object while you have &mut references in scope..
Daniel Bischof
@dbischof90
Jan 21 2018 21:07
.... yes.
There is the possiblity to write this as a trait and have the OrderBook being a long/short variant
That feels a little bit like a hammer for a needle
Patrick Elsen
@xfbs
Jan 21 2018 21:10
I don't think that's necessary per se, but it might uglify the code a little to get it to work. But I'm guessing at some point you'll probably want to refactor it anyways.. so should be cool
Denis Lisov
@tanriol
Jan 21 2018 21:11
Maybe refactor it from recursion to a loop?
Daniel Bischof
@dbischof90
Jan 21 2018 21:17
I'm generally not a friend of break statements where they don't have to be. And this should be solvable without...
Although, I'm not sure how performant such a recursive function is anyways.
Patrick Elsen
@xfbs
Jan 21 2018 21:22
Hm, I think performance shouldn't be an issue, it boils down to the same code
Daniel Bischof
@dbischof90
Jan 21 2018 21:23
Besides, the stop-orders make the whole thing a little bit ugly in a loop
Alexandre Bury
@gyscos
Jan 21 2018 21:25
What you can do is instead make a method that doesn't take &mut self, but each required variable, so they will be borrowed separately
Daniel Bischof
@dbischof90
Jan 21 2018 21:27
So a function call with ' book_to_resolve ' and ' order_heap ' separately?
Wouldn't that create the same problem in the recursive call?
Alexandre Bury
@gyscos
Jan 21 2018 21:27
Or sell_orders and buy_orders
Daniel Bischof
@dbischof90
Jan 21 2018 21:32
Recursion might be a weakness of Rust :/
Alexandre Bury
@gyscos
Jan 21 2018 21:32
Hmm the problem is that you have a reference to the peeked value
So if the nested call modifies the heap, this reference may become invalid
Denis Lisov
@tanriol
Jan 21 2018 21:34
@gyscos Is there a reference at the moment of the call? I don't see any yet...
Alexandre Bury
@gyscos
Jan 21 2018 21:34
triggered_order_peek
comes from book_head
which comes from book_to_resolve.peek_mut()
Daniel Bischof
@dbischof90
Jan 21 2018 21:35
I mean this is a completely valid concern
Denis Lisov
@tanriol
Jan 21 2018 21:35
It gives the same error (one of three) if the whole branch with triggered_order_peek is commented out
Alexandre Bury
@gyscos
Jan 21 2018 21:36
On the other branch, it's head_order_peek
which comes from the same book_head
Denis Lisov
@tanriol
Jan 21 2018 21:36
And which should be consumed by PeekMut::pop, no?
Alexandre Bury
@gyscos
Jan 21 2018 21:37
Right now the borrowing doesn't stop there
Might be a case for NLL, not sure
Denis Lisov
@tanriol
Jan 21 2018 21:37
It does not stop there with NLL, at least in the current nightly.
Daniel Bischof
@dbischof90
Jan 21 2018 21:39
Would the situation be better if the triggered_order_peek was popped of first, resolved through the recursive call and then the function call would resume?
Alexandre Bury
@gyscos
Jan 21 2018 21:40
Possibly, it's hard to see exactly what it would be like?
Daniel Bischof
@dbischof90
Jan 21 2018 21:45
I see
I just realize, with that code change I made a couple of days ago - currently book_head doesn't have to be mutable anymore for the first match block
I had more logic in the first match statement before
That is going to make the code ugly but one could scope the first match statement somehow
Ah no, shit, it has to
F*ing stop orders.
Okay so I refactored it a little to just kinda split the beast in half
Denis Lisov
@tanriol
Jan 21 2018 21:54
@xfbs I'd guess that a method called get_quantitative_relation that modifies self is highly unintuitive :-(
Patrick Elsen
@xfbs
Jan 21 2018 21:55
Well yeah, it's not an intuitive name, but eh it computes the value of quantitative_relation so that's kinda the best I could come up with
Denis Lisov
@tanriol
Jan 21 2018 22:00
@dbischof90 Nitpicking: I'd suggest not buy: bool, but a proper enum
Daniel Bischof
@dbischof90
Jan 21 2018 22:00
Really?
But there's just two possibilities
I had the feeling that an enum would be overkill there
@xfbs That's a good new perspective
Daniel Bischof
@dbischof90
Jan 21 2018 22:06
I have the feeling we are close boys
Denis Lisov
@tanriol
Jan 21 2018 22:11
I have the feeling you've got some logic problems too. Or at least I don't understand why you don't use the stop/limit values at all.
Daniel Bischof
@dbischof90
Jan 21 2018 22:15
Market mechanics basically. the stop values are there for ordering purposes, as you see once they appear at the top of the order book, they turn into regular market orders or limit orders, so let's focus on these first. Market orders are written on a certain volume and consume an ordered order book until they are exhausted. So a buy market order over X units would execute all orders on the stack until the order or the book is exhausted. The price of the transaction is then given by the price of the order in the book - in the case of a limit order that would be the limit price
This resembles a very primitive stock market
If the trade_to_resolve, the order I want to resolve, hits a limit order, it buys as much as possible from it and continues. If it's a stop order (haven't implemented the Ord traits for these yet), they get triggered, turn into a market order or limit order and consume the book by themselves. When they are dealt, the normal order continues. I am very much aware of the problem at this point and that's fully right of Rust to complain here
If there's no order to fulfill, take the rest of the order and place it on the other heap if it is NOT a market order.
I'm not sure about the behaviour there, so I just left that case empty for now.
Daniel Bischof
@dbischof90
Jan 21 2018 22:20
The sole purpose of the stop price is to act as the primary key to sort by.
If you push a limit order through the book, it will, just as a market order, consume the order book until it's exhausted, the limit price is hit or the book is empty.
Patrick Elsen
@xfbs
Jan 21 2018 22:22
Why don't you describe (as in, write in terms of an algorithm) exactly what the execute_and_resolve() function is expected to do, maybe someone here can re-implement it from scratch in a way that it works?
Daniel Bischof
@dbischof90
Jan 21 2018 22:23
Most of these tricks and whistles are pretty much definable by when an order is actually 'larger' than another. That is defined differently for most types
Yeah, maybe I have a thought error.
I could ask the guys at work
We don't use Rust but well, we operate a stock exchange. :D
Steve Klabnik
@steveklabnik
Jan 21 2018 22:25
:)
i saw the NYSE put out a job with "rust experience helpful"
Daniel Bischof
@dbischof90
Jan 21 2018 22:26
I can understand why
Steve Klabnik
@steveklabnik
Jan 21 2018 22:26
i've given at least one talk at a quant firm
Daniel Bischof
@dbischof90
Jan 21 2018 22:26
Really? Which?
Steve Klabnik
@steveklabnik
Jan 21 2018 22:26
i am not sure if i can say so i'd better not. they don't currently use rust but have an internal study group
(I live in NYC so it's easy for me to swing by places)
Daniel Bischof
@dbischof90
Jan 21 2018 22:27
,I see
I'm a quant at Deutsche Börse in Frankfurt, but we do the research part mainly. Rust got me curious for these things
Steve Klabnik
@steveklabnik
Jan 21 2018 22:28
cool cool, i like frankfurt :)
Daniel Bischof
@dbischof90
Jan 21 2018 22:28
Surprisingly many people say that lately :D
And it's indeed not that bad, yes
Oh wait
Steve
I see we talked in the IRC group already :D
Steve Klabnik
@steveklabnik
Jan 21 2018 22:30
we did :)
Daniel Bischof
@dbischof90
Jan 21 2018 22:30
I'm freistil there
I think I'll scrap the method and rethink this whole thing again.
Steve Klabnik
@steveklabnik
Jan 21 2018 22:31
i do have one breif question
about how you wrote this
did you write a ton of code and then try to get it compiling? or did you write a little, compile, write some more, compile
Daniel Bischof
@dbischof90
Jan 21 2018 22:32
Mostly by keyboard, but go ahead
Steve Klabnik
@steveklabnik
Jan 21 2018 22:32
i personally find that incremental is a great way to go, because then you know exactly at what stage things stopped working
Daniel Bischof
@dbischof90
Jan 21 2018 22:33
Yeah, mainly in small steps. It's my first project in rust with more than 15 LOC.
So started with a Order trait first, played with heaps and vecs and now wanted to implement an orderbook
And that's not easy to deconstruct in smaller pieces
Steve Klabnik
@steveklabnik
Jan 21 2018 22:35
i gotta run
good luck :)
Denis Lisov
@tanriol
Jan 21 2018 22:35
@dbischof90 By the way, can (a modification of) your code be used to report a rustc bug?
Daniel Bischof
@dbischof90
Jan 21 2018 22:35
cheers
@tanriol
You gotta laugh but I think someone actually asked me that about a week ago with an older version
Why, what's the matter?
Denis Lisov
@tanriol
Jan 21 2018 22:37
Well, I tried to make the nightly compiler explain the borrow error with -Znll-dump-cause and it paniced :-)
Daniel Bischof
@dbischof90
Jan 21 2018 22:37
Hm. :D
Well, go ahead then
Denis Lisov
@tanriol
Jan 21 2018 23:23
Done. Going back to our orders :-) I'm not sure it's a good idea to keep them all in the same pair of heaps at all.
Daniel Bischof
@dbischof90
Jan 21 2018 23:24
Thought about that as well already
But an order is an order is an order.
That's the problem
Denis Lisov
@tanriol
Jan 21 2018 23:27
I'd, for example, keep the inactive orders (Stop and StopLimit that haven't yet seen the stop level) in a separate heap ordered by the stop level...
Daniel Bischof
@dbischof90
Jan 21 2018 23:28
If I have a buy stop limit order that could in theory be filled at least partially now, I have to fill it now and then put the rest as the correct order on the stack...
Hm. Wouldn't that bring problems to the order?
So for two limit orders A and B as well as for Stop Limit orders C and D with A > B and C> D we can have A > B > C > D as well as A > C > B > D in theory
Meaning that keeping them on separated heaps might loose the order.
I might think too mathematically about this
It would reduce the problem, yes. Not solve, but reduce
Daniel Bischof
@dbischof90
Jan 21 2018 23:34
It would also lead to more and more control variables
So check value a first, which is the last traded price, if that's lower than the highest price on the inactive heap, we have to execute, etc
If this ownership thing gets resolved somehow, then we can pretty much define any type of order as long as we can describe the relationship to other orders
That's what made this so attractive as an approach
Denis Lisov
@tanriol
Jan 21 2018 23:40
If you have "Sell (limit 110)", "Sell (limit 90)" and "Sell (limit 100, stop 120)", what's the correct order?
Daniel Bischof
@dbischof90
Jan 21 2018 23:50
Hehe, Sell (limit 110) > Sell (limit 90). Once the price drops below 120, the order turns into a limit order with 100, which goes through the buy stack first in the moment of activation and the rest will be set on the sell-pile with the others. The ordering here should be Sell(stop 120) > Sell(limit 110) > Sell(90) and after activation should be sorted as limit order between the last two
Hm
So with stop(120) > stop (100) and limit(110) > limit(90) could be a possible book. We have no possibility to know about the state of the other book unless we take a look - meaning that for every order-pop, we have to take a look onto the other order book and have to keep track of both. Possible, but will be slow I think..
If we assume stop orders have priority, which they should have I guess.
I'll call it a night. 1am here and work awaits tomorrow :D
Daniel Bischof
@dbischof90
Jan 21 2018 23:55
Keep thinking about it, I'll be back!
Denis Lisov
@tanriol
Jan 21 2018 23:57
Going to sleep, good luck :-)