DTC Protocol Discussion Forum
- DTC Protocol Discussion Forum |
- Search Board |
- Control Panel |
- View My Posts / Threads |
- Direct Messages
Date/Time: Fri, 29 Nov 2024 16:37:09 +0000
market depth volume precision
View Count: 4237
| [2015-09-18 21:16:17] |
| vbmithr - Posts: 204 |
|
I see that in the bitcoin data service, you display the volumes in the depth window using floating point number. On my DTC server, volumes in the depth window are rounded to an integer. Why is that the case ? Is there a way that I can also display floating point numbers in the depth window ? |
| [2015-09-20 01:45:35] |
| |
|
In Sierra Chart this is controlled through Global Settings >> Symbol Settings >> Additional >> Volume Display Format for the selected Symbol. The actual setting to use depends upon what multiplier was applied to the original floating-point volume number. There is no place in DTC to control this because it is a subject which needs to be discussed. There is one thread where you talked about making the quantity value in a DTC integer Order message to also be an integer but the problem is we cannot just simply do that. There has to be a specification written and followed which defines how that integer is converted to a floating-point number in the same way there is a specification like this for price values. The whole idea behind using integers in a market data feed is for compactness and/or accuracy. If the price and quantity/volume data is originally as integers and needs to remain as integers, you might as well just put those integers into doubles. There should not be any precision issue most likely, and not an accuracy problem either because it is only holding an integer. |
| [2015-09-20 09:58:57] |
| vbmithr - Posts: 204 |
|
There is one thread where you talked about making the quantity value in a DTC integer Order message to also be an integer but the problem is we cannot just simply do that. There has to be a specification written and followed which defines how that integer is converted to a floating-point number in the same way there is a specification like this for price values.
Yes, but these always need to be a specifiation written and followed sowewhere. Buying 1.23 of something or 123443 of something has only a meaning when there is a specification of what this quantity means. Maybe in the first case you implicitely it is some currency, say USD, and that it a number of USDs. But you still follow an "implicit" specification. So yes this specification must be written somewhere, could be in security definition actually :) The whole idea behind using integers in a market data feed is for compactness and/or accuracy. If the price and quantity/volume data is originally as integers and needs to remain as integers, you might as well just put those integers into doubles. There should not be any precision issue most likely, and not an accuracy problem either because it is only holding an integer.
It is clear that most of the times, the denomination of quantity/price are precise enough, but still, exact quantities should not be represented by doubles, there is no reason really to do this. If I follow you, the only reason why you want to use doubles is because of the implicit convention that the "dot" is placed after the canonical amount of currency (when it's in USD, 12.23 means 12$ and 23 cents), but then, you can just as well adopt a global convention like in bitcoin (1e-8 is the smallest amount of currency) and express all prices like this. Apart from "FIX uses float for prices" I don't see much a reason to use them. |
| [2015-09-26 01:50:05] |
| |
|
The DTC Protocol already supports the use of integers for prices. There still needs to be some work done to support 64-bit integers and that will come. What we need to develop is a clear specification for the conversion of a floating-point volume/quantity to an integer and an integer volume/quantity to a floating-point value. So we need to add the necessary multiplier and divisor members for volumes/quantities to the security definition. Date Time Of Last Edit: 2015-09-26 01:50:54
|
| [2015-09-26 08:59:03] |
| vbmithr - Posts: 204 |
|
So we need to add the necessary multiplier and divisor members for volumes/quantities to the security definition.
Yes, this looks fine indeed. In my opinion, price and quantities should be expressed as integers, and there should be a divisor to convert them to floating point. I fail to see where you would need a divisor _and_ a multiplier since it seems to me that divisor = 1 / multiplier. |
| [2015-09-27 09:40:30] |
| |
|
Yes, there only needs to be one value and it can be used both as a multiplier or divider depending upon which direction the conversion is.
|
| [2015-09-28 01:07:19] |
| |
|
There is one thread where you talked about making the quantity value in a DTC integer Order message to also be an integer
We can see in the DTC integer new Order messages that the quantities are already integers. So we think you were probably referring to another DTC message. Date Time Of Last Edit: 2015-09-28 01:53:16
|
| [2015-09-28 01:52:51] |
| |
|
Here is the initial specification about the discussion in this thread : http://dtcprotocol.org/index.php?page=doc/doc_DTCMessageDocumentation.php#IntegerTradingMessages Date Time Of Last Edit: 2015-09-28 01:53:31
|
| [2015-09-28 04:49:17] |
| |
|
Some things at the about floating-point volume/quantity values as integers. All of the DTC header files have not yet been updated to support this. The Sierra Chart test client has a technique to support floating-point volume/quantity values for market data. But it has no support for floating-point quantity values for trading. Therefore, given the number 100.55, it needs to be sent as an integer of 10055 for market data with a divisor of 100. For trading, Sierra Chart would send this through as 1005500 as a quantity value for a new order. Date Time Of Last Edit: 2015-09-28 04:50:51
|
To post a message in this thread, you need to log in with your Sierra Chart account: