output unparseable

I ran this, but I don't really understand the output

Creating new order...
[ID 0] time: 1401130499435
[ID 0] amount for sale: 20 Indiv2
[ID 0] amount desired: 10 Indiv1
[ID 0] unit price: 0.5 Indiv1/Indiv2
[ID 0] inverse unit price: 2.0 Indiv2/Indiv1
Creating new order...
[ID 1] time: 1401130499435
[ID 1] amount for sale: 12 Indiv1
[ID 1] amount desired: 17 Indiv2
[ID 1] unit price: 1.41666667 Indiv2/Indiv1
[ID 1] inverse unit price: 0.70588235 Indiv1/Indiv2
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Adding Order [ID 0] to the orderbook...
[ID 0] time: 1401130499435
[ID 0] amount for sale: 20 Indiv2
[ID 0] amount desired: 10 Indiv1
[ID 0] unit price: 0.5 Indiv1/Indiv2
[ID 0] inverse unit price: 2.0 Indiv2/Indiv1
Best match for Order [ID 0]:
None
Added Order [ID 0] to the orderbook.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Adding Order [ID 1] to the orderbook...
[ID 1] time: 1401130499435
[ID 1] amount for sale: 12 Indiv1
[ID 1] amount desired: 17 Indiv2
[ID 1] unit price: 1.41666667 Indiv2/Indiv1
[ID 1] inverse unit price: 0.70588235 Indiv1/Indiv2
Best match for Order [ID 1]:
[ID 0] time: 1401130499435
[ID 0] amount for sale: 20 Indiv2
[ID 0] amount desired: 10 Indiv1
[ID 0] unit price: 0.5 Indiv1/Indiv2
[ID 0] inverse unit price: 2.0 Indiv2/Indiv1
9 Indiv1 traded for 17 Indiv2 at 0.52941176 Indiv1/Indiv2.
Order [ID 0] filled partially and will be replaced.
Removed Order [ID 0].
Order [ID 1] filled completely.
Creating new order...
[ID 2] time: 1401130499435
[ID 2] amount for sale: 2 Indiv2
[ID 2] amount desired: 1 Indiv1
[ID 2] unit price: 0.5 Indiv1/Indiv2
[ID 2] inverse unit price: 2.0 Indiv2/Indiv1
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Adding Order [ID 2] to the orderbook...
[ID 2] time: 1401130499435
[ID 2] amount for sale: 2 Indiv2
[ID 2] amount desired: 1 Indiv1
[ID 2] unit price: 0.5 Indiv1/Indiv2
[ID 2] inverse unit price: 2.0 Indiv2/Indiv1
Best match for Order [ID 2]:
None
Added Order [ID 2] to the orderbook.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Open Orders:
[ID 2] time: 1401130499435
[ID 2] amount for sale: 2 Indiv2
[ID 2] amount desired: 1 Indiv1
[ID 2] unit price: 0.5 Indiv1/Indiv2
[ID 2] inverse unit price: 2.0 Indiv2/Indiv1

huh?

[dexX7]

Agreed, the output is neither readable by a machine nor by a human at the moment. The process is like this:

• Add order A
• Try to find a match
• No match found, add to the orderbook
• Add order B
• Try to find a match
• Match found, execute
• The new order filled partially and a new order with updated amounts is created
• The old order filled completely
• And the process repeats with this updated order

I think it would be best to assign "trade ids" and a mechanism to query the state of a trade. What happend in short:

• A created: 20 Indiv2 for 10 Indiv1
• B created: 12 Indiv1 for 17 Indiv2
• A filled partially: 17 Indiv2 for 9 Indiv1 (1 Indiv1 remaining)
• B filled completely: 9 Indiv1 for 17 Indiv1 (0 Indiv2 remaining)

Okay, this makes sense now. It also looks like there are some things implied with this:

Before A and B are added and assigned IDs, there seems to be a staging/prep area where we can see all of their data, this might just be for simulation sake, and if so, disregard.

"9 Indiv1 traded for 17 Indiv2 at 0.52941176 Indiv1/Indiv2."

I'm curious about why this might be OK, since this is less than the offer creator (ID 1) originally asked for, is 'amount desired' a soft value? it could be used to clear out the books at higher values than desired. (stop buy order) Maybe this just needs to be explained to me

[dexX7]

Yes, this is for the sake of simulation, but I'm on it to transform it to something useful.

We have a very interesting discussion over at OmniLayer/spec#170 about the matching itself.

You may start here, if you want to skip the beginning: OmniLayer/spec#170 (comment)

In general: it's probably best to see the orders as "buy orders" where "unit price" is the "limit".

9 for 17 is a special case due to the rounding and actually he could get 18 for 9 for the same total price (see other thread), but that aside:

• ID 1 wants 17 and offers 12. He receives his desired 17, but only pays 9, so this is in his favor.
• ID 0 is happy too, because he wanted 10 and was willing to pay 20. He received 9 for 17 which is also in his favor.
• Nevertheless he still wants 1 more, so a new order is created (ID 2: want: 1, give: 2)

[Bitoy]

A created: 20 Indiv2 for 10 Indiv1 = .5
B created: 12 Indiv1 for 17 Indiv2 = .7058

Match found. .5 < .7058
Roundup(Genmin(17,20) * .5 ) = 8.5 = 9 indiv1

B gives 9 indiv1 gets 17 indiv2 change 3 indiv1 (tx for B is closed completely filled)
A gives 17 indiv2 gets 9 indiv1 remaining is 3 indiv2 1 indiv1

X=1 indiv1 / .5 = 2 indiv2
Compute indiv2 Change for A = 3 - x = 1 indiv2

A change of 1 indiv2 must the given to A In order for the original .5 unit price to be maintained.

A updated offer: 2 Indiv2 for 1 Indiv1 = .5

The order matching makes sense, I'll follow the other thread to see where this is going, DexX, what exactly are your plans, quote, "to transform it to something useful" ?

interested in contributing

[dexX7]

Nice! I added a new branch:

https://github.com/dexX7/simple-order-matching/tree/event-based

Probably the best, if you run the whole thing and take a look into the code, to see what I meant with "something more useful/usable". :)