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

Add decimal_price field to API's, re-implement real_price #1575

Closed
theoreticalbts opened this issue Sep 15, 2017 · 2 comments · Fixed by #3514
Closed

Add decimal_price field to API's, re-implement real_price #1575

theoreticalbts opened this issue Sep 15, 2017 · 2 comments · Fixed by #3514

Comments

@theoreticalbts
Copy link
Contributor

@theoreticalbts theoreticalbts commented Sep 15, 2017

So if we implement tick pricing rules #1573, a price will always have a divisor that is a power of 10. Decimal prices are currently implemented approximately, for the real_price field, using floating-point double computations.

Let's implement them exactly using integer arithmetic and string processing. Here are the requirements:

  • Remove real_price for now as part of #1571
  • Refactor asset internals #1549
  • Implement Tick Pricing Rules #1573
  • Implement decimal_price field which is a decimal value stored as a string
  • decimal_price should be exact for TPR prices, approximate with a ? character appended for non-TPR prices
  • Implement real_price field by using some standard library or Boost function to convert string decimal_price field to double
  • (Optional) Create plumbing to send real_price as a string value to the JSON output code, so the conversion to double and precision loss never happens [1].

[1] In order for this to actually be useful, a client parser would need to be sufficiently flexible to read real_price as a string and convert it to some non-floating-point type. This is fairly easy to do in Python, in fact the standard library docs provide an example (simply import decimal and then specify parse_float=decimal.Decimal).

This is an "optional" requirement for the following reasons:

  • We should still supply it as a string in the JSON to support client libraries that aren't as flexible as Python
  • Precisely defining and building this plumbing is non-trivial
@mkochanowicz

This comment has been minimized.

Copy link
Contributor

@mkochanowicz mkochanowicz commented Oct 25, 2017

@theoreticalbts - just for sure: you mean real_price field of order, right?

@mac128k mac128k added this to Backlog (not prioritized) in Smart Media Tokens (SMTs) Sep 4, 2018
@sgerbino sgerbino assigned sgerbino and unassigned sgerbino Nov 15, 2018
@mvandeberg mvandeberg added the BLOCKED label Nov 16, 2018
@mvandeberg

This comment has been minimized.

Copy link
Contributor

@mvandeberg mvandeberg commented Nov 16, 2018

Blocked by #1573

@mvandeberg mvandeberg removed the BLOCKED label Sep 4, 2019
sgerbino added a commit that referenced this issue Sep 18, 2019
… associated tests, modifications of get_order_book for SMT support
sgerbino added a commit that referenced this issue Sep 18, 2019
@sgerbino sgerbino self-assigned this Sep 19, 2019
sgerbino added a commit that referenced this issue Sep 20, 2019
…revent the order book from iterating off the edge of the pairing
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Smart Media Tokens (SMTs)
Backlog (not prioritized)
6 participants
You can’t perform that action at this time.