开云体育

Ah, that's very interesting! ?I'm on Mac OS X so it seems I can't use the Linux utilities you are referring to.

Ben, thanks for pointing out. The comments you referred to seem to interchangeably refer to TWS and IBGateway. Is it possible to somehow run the same download "as" IBGateway, or are you just talking about both at the same time? Or do you actually mean IBGateway, most of the time, when you refer to TWS?

Thanks, it was indeed that simple.

It could be spelling.? This is from the API docs:
whatToShow String
Determines the nature of data being extracted. Valid values include:

• TRADES
• MIDPOINT
• BID
• ASK
• BID_ASK
• HISTORICAL_VOLATILITY
• OPTION_IMPLIED_VOLATILITY

At 07:37 AM 12/5/2015, you wrote:

...seems to be gone. I kept checking the download page for a standalone version of IB Gateway (Mac OS X) that would correspond to TWS "latest" version 954.2 (or newer), but there was only an older one from March 2015.

FWIW:

?

I have enjoyed this sort of thing "forever" -- even back to The Journal Of Mathematical Psychology -- which was the vehicle by which Kahneman, Tversky, et.al. got their stuff published in the early/mid 80s. Finding such an official-sounding word like "Quorum sensing" re-assures me that, if I won The Lottery and funded my own fun-for-thinking Institution, "Quorum sensing" might be in the title. (Or at least on somebody's door, right?)

In the meantime, you can bet your bippy that those who sample word-flow from Twitter, StockTwits, etc. have just these sorts of frameworks in place. (I want my own! Ha-HA!)

No, you don’t need to use the expiry field.



It works just fine with secType=”FUT”, exchange=”ECBOT”, and localSymbol=”ZB DEC 15”.



The only difficulty is that different exchanges have different local symbol formats. For Globex, Nymex and many other futures exchanges the ‘short’ format that you’ve always used (eg CLF6, ESZ5, 6EH6) is correct, but for ECBOT, DTB (and possibly others) the SSSS MMM YY format is required, eg ZC DEC 16, FDAX DEC 15.



The trick with this ‘long’ format is to ensure that there are 5 characters before the first month character, padding with spaces if need be. So for a two character symbol like ZC, you need three spaces after it, for a four character symbol like FDAX you need one space after it.



What’s even trickier is that what you put in the SSSS part is not necessarily the plain symbol. For example, the Euro STOXX50 contracts at DTB have a symbol of ESTX50, but in the local symbol you have to use FESX, thus ESTX50 with an expiry date of 201512 has a local symbol of FESX DEC 15. Simlarly for DAX you use FDAX in the local symbol (eg FDAC DEC 15), and for GBL you use FGBL (eg FGBL DEC 15).



Simple, huh?...



By the way, the long format is arguably much more logical, because it’s immune to changes of decade. For example I have historical data stored back to 2003, so I need contract definitions in my database for the ESZ5 in both 2005 and 2015. But I use the local name as a key to access the data, so I’ve had to change all the old ones to put the decade in as part of the local symbol: thus the ESZ5 for Dec 2005 is now called ESZ05 in my database. Whereas FDAX DEC 05 and FDAX DEC 15 are perfectly clear (I probably won’t care when we wrap round to the next century!).



Richard





From: TWSAPI@... [mailto:TWSAPI@...]
Sent: 03 December 2015 02:02
To: TWSAPI@...
Subject: Re: [TWS API] Re: ECBOT historical data





Thanks to those who responded. I have it working now.



To summarize, the trick for the ECBOT contracts is to specify the expiry in the Contracts object. For stocks, forex and all other futures, I have never used this field. I have left it "" and I have always used just the localSymbol field, e.g. CLF6. For some reason IB chose to make the localSymbol difficult for this exchange as one of the responders pointed out.



I have watched this forum for a long time and am amazed that I am the only one who has had this problem. I guess when everyone else started programming this interface that they started using the expiry field at the outset.



Phil







On Wednesday, December 2, 2015 12:48 PM, "fantasy football fantasyfootball672@... [TWSAPI]" <TWSAPI@...> wrote:





Phil,



It's a very annoying system for the "Local Symbol" with 3 embedded spaces:



For instance, Corn for December is: "ZC DEC 15"















[Non-text portions of this message have been removed]

endDateTime="20151201 17:59:59 EST" durationStr="10 D" barSizeSetting="1 min" whatToShow="TRADES" formatDate="1"><reqContract symbol="ZN" secType="FUT" expiry="201603" exchange="ECBOT" includeExpired="1" multiplier="1000"

or better w expiry="20160321"? (useful with weekly futures like VIX).

Interesting. There is certainly a lot of interest in crowd consensus in all sorts of areas, from election forecasting to classifying galaxies.



The galaxy classification case is fairly straightforward, because you have to be at least interested in the subject to make the sustained effort required (not hard, but there’s no point in just doing a few), and the potential reward is having your name associated with an unusual and previously unrecognized astrophysical phenomenon, so there is a small incentive – though probably most people do it out of a desire to contribute to ‘citizen science’.



The election forecasting scenario is trickier. We all know that standard ‘who are you going to vote for’ polls taken on the street are often (usually?) way off, but I read an article in Scientific American a couple of years ago about a study where participants were invited to predict, if I remember correctly, the winner of the last US Presidential election, and they stood to gain financially if they were right – not a huge amount, but just enough to make it interesting: the result was startlingly accurate, not just in who won but also the proportion of votes.



As you suggest, it’s not obvious why a crowd should possess this sort of group forecasting ability. I certainly wouldn’t make a decision to buy or sell a future based on the votes cast in your little website, even if there were some incentive for the voters. They may very well get the answer right, but I’d also need to know that the market isn’t going to move past my stop loss point before reaching the forecast target. So maybe to get any practically useful information from a crowd you actually need their view on several interrelated points, and perhaps the error bars on each forecast would accumulate such that there is no net advantage.



Anyway, back to your app. I think the big problem with the link you posted is that it shouts ‘malware trap’. If I had not known that you actually wrote your post (because I recognise your style), I would never have clicked on the link and I would have immediately deleted the post from the archive (I’ve had to do this a number of times recently, the most recent just this morning – and since they always seem to originate from the same member, his membership has now been cancelled!).



I think it also needs statements such as ‘this could be your poll’, and ‘click here to learn about Flashvote, an app that enables you to run your own polls similar to this one’ (though obviously with a bit of marketing panache which I’m sadly lacking!). Perhaps also a variety of different sample polls, to show off its capabilities: I think this would give more assurance that this site is for real.



Richard











From: TWSAPI@... [mailto:TWSAPI@...]
Sent: 02 December 2015 02:15
To: TWSAPI@...
Subject: Re: [TWS API] OT: An app I've been working on





Ben,



Yes, tracking of members would allow a vetting of correctness and the application of a weighting algorithm for answers. Agreed.



And here we get into the broader premise: is there any true information to be found in the consensus of a crowd?



Estimize certainly thinks so. Stocktwits too. SeekingAlpha? Yeah, they think that there exists weight in numbers. But is there? Really?



And can you trust it? Would you? And if not, how do you incentivize the participants to drive their opinions into the honesty half of the dial?



If each member had a stake in the outcome, wouldn't each member then want to ensure that their vote was as accurate and influential as possible?



A system like that, tough to build. And tougher still to harden the process and the system so that the information was worthy of trust.



What's needed is a kibbutz of sorts, where the group is self policing and all members dedicated to the same ends.



That's the ideal at least.



Thanks for sharing your opinions.



MM





On Tue, Dec 1, 2015 at 5:19 PM, Ben Alex ben.alex@... <mailto:ben.alex@...> [TWSAPI] <TWSAPI@... <mailto:TWSAPI@...> > wrote:





On Wed, Dec 2, 2015 at 10:33 AM, MarketMole marketmole@... <mailto:marketmole@...> [TWSAPI] <TWSAPI@... <mailto:TWSAPI@...> > wrote:

There's no attribution and no risk involved so gaming the votes would be an issue. Don't know a way around that except for private votes (which it will handle).



Maybe you could fetch the device's hardware address (Android API info <> ) and then track how often a voter was correct and then weight accordingly.

The example asked users to select an expected index value by a certain date. As you know this is something that's routinely modelled via quantitative and machine learning techniques, particularly given you can statistically test the quality of such models via historical data (yet there's no equivalent historical vote data AFAIK). Or is that question not really the sort of data the app intends to collect, or is the app intended for a totally different purpose (eg maybe to engage users in quasi paper CFD trading and then on-ramp them to another destination like a broker, news provider etc)?














[Non-text portions of this message have been removed]