Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

QUESTION:Where does 10800 come from? #3

Open
locosoft1986 opened this issue May 5, 2018 · 2 comments
Open

QUESTION:Where does 10800 come from? #3

locosoft1986 opened this issue May 5, 2018 · 2 comments

Comments

@locosoft1986
Copy link

I saw your post on your blog post "Maintaining an Order Book on the Blockchain (Part 1)
". But I dont understand where does the magic number 10800 comes from?
There are two paragraphs I dont understand in the post:

Let’s start by limiting our prices to the 12 orders of magnitude from 0.000001 to 1000000.

and

If we were to write down all the prices possible under these rules, we’d find there are 10800 different prices, starting with 0.00000100, 0.00000101, 0.0000102, and with 1.22, 1.23, 1.24 near the middle, and finally ending 997000, 998000, 999000.

Since the price range is from 0.000001 to 1000000 and 1 bit for 1 increment of this value, it should be 9999999999999 bits.

And I have also checked the code, it seems like it splits the price into three parts:
1.how many zeros behind or before the number between 1 and 999.
2. the actual price value 1~999.
3. direction, buy or sell

Please en-light me, thank you

@kieranelby
Copy link
Contributor

Hi Jeremy,

Thanks for your question!

Sadly ubitok.io never really took off, despite efforts to reduce gas costs, it was still too unattractive to market makers to have to pay "gas" to place/cancel orders, compared to other DEXs like EtherDelta/Forkdelta/IDEX where placing orders is free.

But I think the technique we used to represent prices compactly was rather neat, so I'll try to explain it a bit better, unless you've ever looked at how floating point numbers - https://en.wikipedia.org/wiki/Floating-point_arithmetic - are stored it's not very obvious.

Normally when people talk about "orders of magnitude" -https://en.wikipedia.org/wiki/Order_of_magnitude - they are talking about a scale that goes up in tens - 1, 10, 100, 1000, 10000 etc. And below one it goes down in tens - 0.1, 0.01, 0.001, etc.

(Numbers that aren't exactly on the scale - like 7 say - are considered to belong to the one below. So 7 belongs with 1. And 539 would belong with 100.)

Often we're interested in how many different orders of magnitude we can handle.

For example, a baggage weighing scales at an airport might only handle two orders of magnitude - 1s and 10s.

Or if I had a voltmeter that could measure voltages accurately from 0.01 volts to 999 volts, that would cover five orders of magnitude - 0.01, 0.1, 1, 10, 100.

So when I said:

limit our prices to the 12 orders of magnitude from 0.000001 to 1000000

I mean we're going to handle prices in the following twelve ranges:

 1st)       0.000001 to       0.000010
 2nd)       0.000010 to       0.000100
 3rd)       0.000100 to       0.001000
 4th)       0.001000 to       0.010000
 5th)       0.010000 to       0.100000
 6th)       0.100000 to       1.000000
 7th)       1.000000 to      10.000000
 8th)      10.000000 to     100.000000
 9th)     100.000000 to    1000.000000
10th)    1000.000000 to   10000.000000
11th)   10000.000000 to  100000.000000
12th)  100000.000000 to 1000000.000000

Next, I said:

let’s restrict ourselves to three significant figures

By three significant figures we meant that apart from leading/trailing zeroes we can't have more than three digits.

e.g. for my 0.100000 to 1.000000 range, I'm allowed to have 0.123 but not 0.1234 or 0.1239999.
e.g. for my 100-1000 range, I'm allowed to have 123 but not 123.4.

This means within each order of magnitude there's at most 1000 different prices if we only have three digits to play with - 000, 001, 002 ,..., 998, 999.

But yes, I skipped over a bit how this leads to the rather magical 10,800. Surely 12 orders of magnitude times 1000 different prices for each is 12,000?

But we don't actually need to use all 1000 prices in each range.

e.g. for my 0.100000 to 1.000000 range, I won't use anything below 0.100, so really the only digit combinations needed are 100, 101, 102, 103, ... , 998, 999. Which is 900 combinations, not 1000, to cover 0.100, 0.101, 0.102, 0.999.

The same would work for the 1000-10000 range, the prices would start at 1000 and go up in 10s - 1000, 1010, 1020, ..., 9980, 9990 is only 900 different prices. (We don't need 001, 002, 003 because they would have been covered by the previous order of magnitude - the 100-1000 range).

And 12 ranges with 900 prices in each range = 900 * 12 = 10,800.

So it is true that with just the numbers 1 to 10,800 we can represent all the prices from 0.000001 to 999000 (provided we can live with just three significant figures - not the same as 3 decimal places).

And therefore with the numbers 1 to 21600 we can represent all the possible prices and directions (buy/sell).

Hope this helps!
Kieran

@locosoft1986
Copy link
Author

locosoft1986 commented May 6, 2018

Wow, thank you for the explanation. Now its clear to me for the magic number 10800 :) It's a great algorithm.

it was still too unattractive to market makers to have to pay "gas" to place/cancel orders, compared to other DEXs like

Please correct me if I misunderstand:
When users place order it will cost gas to execute the order management part of the on-chain code, The ForkDelta's solution to me seems like a semi-decentralized application. It seems that it use contract events to drive the python backend and record those orders in the database to draw the chart. And also it record orders in their smart contracts' storage. So the ForkDelta does not support market orders.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants