Decimal missing or in wrong place on prices

[shortandlong]

None of my prices for CME futures contracts have any decimal places in them. The scaling is off by a factor of 100x up to 100000x.

For example, my eSignal 7.2 quote window shows:

EC M3 as 106030, it should be 1.0603
JY M3 as 8471, it should be .8471

ND M3 as 107500, it should be 1075.00
NQ M3 as 107550, it should be 1075.50

SP M3 as 85770, it should be 857.70
ES M3 as 85775, it should be 857.75

Is there a way to adjust this?

Brad

[JayF]

Hello Brad,

There are a few reasons we display our futures data this way. One is that we have always displayed it in this fashion. Long time futures traders are very accustomed to seeing data without decimals. On the floor of most futures exchanges data is also displayed in this fashion, and most newspapers continue this tradition.

Secondly, this is the way the data is sent to us from the exchange. We haven't had much demand to change the data to a decimal format, and based on the high cost associated with going through every future and future option to properly format it is difficult to justify.

We would like to hear your (and others) comments on this though, so please feel free to voice them.

[shortandlong]

A quick sampling shows the following display futures prices with decimals:

- NY Times
- Investors Business Daily
- CME future exchange home web page, http://www.cme.com
- My 1996 Omega Research trading software

Your statement that data is sent this way from the exchange is misleading. Along with the data, exchanges generally send a multiplier or format specifier. I know, I've written data feeds. Even if they don't, they publish the data format for each contract.

In general, I find no place in eSignal to configure contract specific information like this.

However, it looks like you DO keep contract specific information somewhere, because Advanced Charts seem to know about the different session times for each contract.

Brad

[ACM]

FWIW this is how the contracts appear on my CME Globex terminal.



As far as I can tell, eSignal disseminates prices in the same format transmitted by the CME and used by them on their own trading platform (ie GLwin).
Alex

[shortandlong]

Being a futures trader for the last 10 years I DO have an understanding of the prices.

It's just a matter of quick recognizability. The eye recognizes numbers with decimal places quicker.

If my bank statement was in cents, not dollars, I'd still be able to understand it. But, I'd much prefer having the decimal point, that's all. For example, a ten thousand dollar amount is harder to read as 1000000.

Note that the June Eurocurrency in the screen capture you posted clearly has the decimal point in the wrong place. Does this mean I don't understand the price and can't place a limit order with my broker, or interpret a fill. Of course not.

Anyway, I was just asking. I'm able to get along fine without the decimal point or even if it's in the wrong place. But it would be nice if were otherwise...

Brad

[shortandlong]

Decimals in Futures Prices - A Wider Perspective

If you look at your total customer base and your position in the financial market space, the perspective on adding a decimal point to your futures prices takes on a different light.

First, it's my understanding that futures trade entry systems don't use decimal points because it takes valuable time to enter the decimal point, and it serves no useful purpose for such systems. As a long-time futures trader, during trade entry I don't want to waste time entering the decimal point. The trade entry systems I've used don't use decimal points.

However, although I don't want to have to enter a decimal point during TRADE ENTRY, as a futures trader, I prefer the decimal point in a PRICE DISPLAY. It's easier and faster to recognize the prices.

That said, eSignal's primary business is price reporting and distribution, NOT trade entry!

Futures traders are not the only users of your futures price data. Your average market watcher or stock trader also watches futures prices. However, a non-futures trader who just wants to know what other markets are doing does NOT want to see prices such as:

Gold 3304
Crude Oil 2740
Unlead Gasoline 8760

They do NOT want to see pre-market opening futures stock indices as

Nasdaq +50
S&P 500 +60

...when the values are really up 0.50 and 0.60. To the average non-futures trader these price are, well, not displayed correctly.

Also, individual eSignal users don't just look at the prices, prices are also used computationally inside spreadsheets, for example. All your futures prices have to be normalized before they can be used.

With the addition of your inexpensive delayed futures offering, more of your non-futures customers will be subscribing to futures data.

And then there's your institutional customers that subscribe to your TurboFeed product - web sites, TV stations, etc. ALL of them must NORMALIZE your futures data before they can display it! They're not going to display the 'raw' format with no decimal point. The NY Times, Investors Business Daily, and Barrons display futures prices with the decimal point, along with CNBC TV. The only major media hold-out I found was the WSJ, and even they use decimal points for some of their prices - which one's seems arbitrary.

And then there's pricing support for backoffice systems: P&L, risk exposure, brokerage statements, etc. Again, these users must adjust all your futures prices.

Offer a competitive advantage and give your customers futures prices that are ready, out of the box, to be displayed on web pages and TV, ready for calculations, whether via a spreadsheet or a backoffice profit & loss, brokerage or portfolio statement.

Add a setting in the TurboFeed DataManager to distribute futures prices with decimals. Obviously, this would be table-driven, with settings for each futures contract. (The decimal should NOT be add by the frontend eSignal client, since doing so would mean spreadsheets and applications that connect directly to TurboFeed would still see the 'raw', non-decimal futures prices.)

Just my 0.02 dollars worth...

Brad