|
PureBytes Links
Trading Reference Links
|
I received a private email on this subject.
>From a software engineer -
" the use of array processing is extremely quick .........infinitesimally so ....especially with today's processors (It is a fundamental weapon of design of the software engineer .... especially when the data is so related in terms of price points at particular intervals). Secondly ...... in a RT mode, all sorts of events may occur and change this position .... So really, in a short answer, it is simply easiest to reprocess the array that dynamically change it, and the processing penalty is virtually non-existant".
I seldom answer private emails so to set the record straight:
I accept that AB's default behaviour (bulk array re-processing in chart refresh) and the subsequent explanation given by Tomasz is correct for practical purposes.
For me it was a philosphical investigation and also the search for exceptions (sometimes it is necessary to do the exceptional to get where we want to go and to do this requires an understanding of what we are doing) ... confirmation by others that they do sometimes apply exceptions to the rule confirmed my hypothesis.
Anyway .. it is all Tomahtoes and Tomaytoes!
One persons event is another persons shortened array i.e. it all depends on the context ... a shortened array may be AB's version of an event and StatusAction might be AB's version of event programming.
--- In amibroker@xxxxxxxxxxxxxxx, "brian_z111" <brian_z111@xxx> wrote:
>
> Thankyou very much Jules.
>
> You guys really put the icing on the cake for me now.
>
>
> --- In amibroker@xxxxxxxxxxxxxxx, "Julian" <juliangoodsell@> wrote:
> >
> > Hi Brian,
> >
> > > If BarIndex() > BarCount - 10
> > > {
> > > Do something
> > > }
> >
> > barIndexes = BarIndex();
> > lastBarIndex = StaticVarGet("LastBarIndex");
> > for (bar = barcount-1; bar>=0; bar--){
> > barIndex = barIndexes[bar];
> > if (barIndex <= lastBarIndex)
> > break;
> >
> > // Do Something
> > }
> > StaticVarSet("LastBarIndex", barIndexes[barcount-1]);
> >
> > There is nothing wrong with this technique, but it depends what you want to do.
> > For eg. I create tick volume profiles. It would be slow and unnecessary to process every tick for the day (thousands) to create a profile, so I just process the most recent data, maybe 10-100 ticks, and update static vars from which the profiles are rendered.
> > For historical profiles, I export this data once to file and then read it in in real time which is massively quicker than processing tens of thousands of ticks on the fly. This enables me to display tick based volume profiles for months of data and on any timeframe chart in realtime.
> >
> > However this accumulation of data can't be used, and is often not necessary for lots of other things that rely on full price arrays. Quick AFL gets around most performance issues anyway, but at the tick level, you're dealing with a lot of data for multiple days.
> >
> >
> > Janhausd,
> >
> > in respect of an event driven model, I can see how this would be useful for various information gathering, Time & Sales particularly, but it would have to be disconnected from the rendering phase. I.e. You'd have to be able to run scripts on events, separate from the scripts that render charts as it's impossible to render them that quickly.
> >
> > You could have chart scripts which only refresh every second or so and non-chart event based scripts which could be processed in a separate thread.
> >
> > Performance wise though, I don't see any real difference between an event model and backwards cycling an array as shown above. If anything, I imagine an event based model triggered for every bit of data coming in, could cause a backlog of processing under heavy traffic, and hamstring your cpu until the data eases up.
> >
> > It's all tomaytoes/tomahtoes anyway as there are many ways data can be processed. :)
> >
> > Jules.
> >
> > --- In amibroker@xxxxxxxxxxxxxxx, "janhausd" <janhaus.dresden@> wrote:
> > >
> > > Heya Brian,
> > >
> > > I'd have to say that from my point of view, I'm more comfortable with an OO, event-driven method of writing code vs AFL, and this is how I code my trading systems after testing with Amibroker. I would venture to guess that most real-time trading systems are indeed event-driven, esp the ones very concerned with speed but of course nobody is going to use Amibroker for high-frequency trading, so that's comparing apples to oranges.
> > >
> > > For testing purposes Amibroker's performance is blindingly fast that even though the entire AFL is looped over from head to toe and despite the frequent reprocessing of entire arrays per AFL loop, it is still faster than any other package I've tested, so I can't complain about the performance.
> > >
> > > Regarding what you mentioned, I am inclined to think that breaking the 5-second barrier in Ami is not too difficult for Tomas other than replacing some existing data structures and modifying the rest of the code to play nice. However, in one of his posts he mentioned that he just doesn't think there are enough people out there who use 1s data or millisecond data, whereas we've endeavored to show otherwise :) Frankly I think the hard part is showing that there is enough customer demand for such a feature, hehe.
> > >
> > > Anyhow, I would guess that transitioning from the current AFL to an event-driven scripting model (for us users) would likely never be done, but opening up its access and functionality to sub-1s data should be within reach.
> > >
> > > --- In amibroker@xxxxxxxxxxxxxxx, "brian_z111" <brian_z111@> wrote:
> > > >
> > > > Hi Janhaus,
> > > >
> > > > >On my end, since Amibroker ......is greatly limited in any <5second >timeframe
> > > >
> > > >
> > > > We have had some good discussion on this issue.
> > > > I got a lot out it and I am nearly there but I haven't quite nailed the understanding 100%.
> > > >
> > > >
> > > > Where I have some doubts is over the idea that array processing is always the optimum method at the processing edge (whitespace that becomes current data).
> > > >
> > > > Obviously my naive computer skills color my perceptions but I can't help wondering if an event driven model would actually be better in some instances ..... say, if the arrival of a new bid/ask is an event and we want to recognize that and do some quick calc that triggers an AT (AT being capable of responding at < 0.1 sec even if I can't see the bid/ask).
> > > >
> > > > I am a bit behind on my reading and I haven't checked the discussion between Tomasz and Dennis that went on around this issue == Dennis's tests.
> > > >
> > > > My mental 'test tells me that an array can be infinite (the markets go on forever), so that however clever array processing is the processor can only file the array stuff through in single file, albeit several single files if it is threaded and that there must be a point where the size of the array means that it takes longer to process than it would to process one piece of data if a single event happens (a new price arises).
> > > >
> > > > The other thing I haven't figured out yet is if I have a gazillion bars but I just use the following sort of thing:
> > > >
> > > > If BarIndex() > BarCount - 10
> > > > {
> > > > Do something
> > > > }
> > > >
> > > > Surely this is faster than Doing Something on a gazillion bars?
> > > > If not why not? ( I haven't got around to physically testing this ... it is hard to get me out of my mental lab and into the real one).
> > > >
> > > > Anyway, I'm not expecting you to answer those questions but do you have a short list of what AB needs to move beyond the 5 sec barrier?
> > > >
> > > > (So far, I like Dennis's idea of a separate core handling a fast chart and Herman's idea of a virtual pane ... delineated in code by sections ... with the panes running at different bar requirements.
> > > > For myself I would probably like these panes to be either virtual or displayed but I am nowhere near the level of understanding that Herman has on this stuff).
> > > >
> > > > Of course I leave it to Tomasz to worry about the how, the whatifs and the 'if at alls' but I still like to speculate).
> > > >
> > > > --- In amibroker@xxxxxxxxxxxxxxx, "janhausd" <janhaus.dresden@> wrote:
> > > > >
> > > > > Hi Tomasz,
> > > > >
> > > > > I wholeheartedly second (or third) this recommendation to enable bid/ask! While you're at it, if there can be a couple of custom fields definable other than OHLCVOI, that'd be great too, but bid/ask would be most helpful. Please leave any performance or hardware considerations to the user, since some of us have great need for this feature, and some people have sufficient processing power or time on their hands not to be concerned about the processing limitations. On my end, since Amibroker does not support market depth and is greatly limited in any <5second timeframe, I had to write my own programs to process such data, but I would greatly prefer this feature being available in Amibroker natively.
> > > > >
> > > > >
> > > > > --- In amibroker@xxxxxxxxxxxxxxx, "Julian" <juliangoodsell@> wrote:
> > > > > >
> > > > > > Hi Tomasz, that would be fantastic!
> > > > > >
> > > > > > Perhaps just have a preference setting enabling you to switch logging on or off for Time & Sales, along with the option of whether you want bid/ask, trades, or both? Using trades only would only require one record per tick. As long as the record included data on whether the trade was executed at the bid or offer.
> > > > > >
> > > > > > I use an eSignal tick database already but it's the Time & Sales data (bid/ask/trade/volume) I'm after that would really complete the picture. It's frustrating knowing the data is there but not being able to access it.
> > > > > >
> > > > > > Access to this data would enable the ability to categorize trades into buyers or sellers. The ridiculously large chart below by IOAMT is an example of this:
> > > > > > http://www.tradingeducationexchange.com/products/images/ioamt/intraday.png
> > > > > >
> > > > > > I figured you would mention the file size aspect but it's not really an issue for various reasons, which in the end all boil down to just one reason. So long as it is technically feasible to do on your end, then traders on the client end will find ways to use that data within the limitations of their software and hardware.
> > > > > > As a programmer, there is simply nothing on the client that can't be done, so long as the data is there.
> > > > > >
> > > > > > Traders already are limited to the number of charts they can display on screen per refresh interval required. I.e. you can't display 100 charts at once every second. Time & Sales data is no different. You'll be limited to how many symbols you can process by the limitations of your hardware.
> > > > > >
> > > > > > Sincerely wishing that you'll please implement this feature. :)
> > > > > > Regards,
> > > > > > Julian.
> > > > > >
> > > > > > --- In amibroker@xxxxxxxxxxxxxxx, "Tomasz Janeczko" <groups@> wrote:
> > > > > > >
> > > > > > > Hello,
> > > > > > >
> > > > > > > If you mean trades tick-by-tick - it is available. Configure your database so base time interval is set to "Tick"
> > > > > > > and normal Close array will give each trade (tick).
> > > > > > >
> > > > > > > If you mean bid / ask - I could do that, but since there are way more bid/asks than trades, the resulting file could
> > > > > > > be easily 50MB per day per symbol. Just imagine one month of data for 100 symbols. That would be 125GB.
> > > > > > > Processing such huge files in real-time (note that for 100 symbols that can be peaks of 10000 new bid/asks per second)
> > > > > > > is not feasible with ordinary desktop computer.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Best regards,
> > > > > > > Tomasz Janeczko
> > > > > > > amibroker.com
> > > > > > > ----- Original Message -----
> > > > > > > From: "Julian" <juliangoodsell@>
> > > > > > > To: <amibroker@xxxxxxxxxxxxxxx>
> > > > > > > Sent: Wednesday, July 08, 2009 12:19 PM
> > > > > > > Subject: [amibroker] Re: Data And PlugIn Speed
> > > > > > >
> > > > > > >
> > > > > > > > Tomasz,
> > > > > > > >
> > > > > > > > is it too much trouble for you to log the Time & Sales data to file as it comes in? This would at least enable us to read that
> > > > > > > > data and construct charts based on the info, as it's not possible to accurately gather this data through chart scripts.
> > > > > > > >
> > > > > > > > I tried for a while using GetRTData so I could track trades hitting the bid vs ask, but the fact that I can't get this info for
> > > > > > > > every tick makes the data invalid. If Time & Sales was logged (ala eSignals file format for saving replay data), I could then
> > > > > > > > process that file to strip all the data I needed from it.
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Julian.
> > > > > > > >
> > > > > > > > --- In amibroker@xxxxxxxxxxxxxxx, Dennis Brown <see3d@> wrote:
> > > > > > > >>
> > > > > > > >> Brian,
> > > > > > > >>
> > > > > > > >> You asked:
> > > > > > > >> > ...is there any way to know when a quote (tick) has arrived other
> > > > > > > >> > than Status("redrawaction")? ... this seems to be a generic trigger
> > > > > > > >> > so we can't separate new quote from the other possible causes of
> > > > > > > >> > actioned refresh.
> > > > > > > >>
> > > > > > > >> Of course there is. There may be a simpler method, but you could save
> > > > > > > >> the Time Stamp and Volume of the last bar in a static variable at the
> > > > > > > >> end of each pass (Time Stamps have to be set to start of bar), then on
> > > > > > > >> the next pass check to see if the Time Stamp or Volume has changed.
> > > > > > > >> If they are the same, then the refresh is for some other reason than a
> > > > > > > >> new quote. Just checking the Time Stamp will indicate a new bar. If
> > > > > > > >> the bar has not changed, then the Volume is checked for additional
> > > > > > > >> trades. The OHLC may not be any different even though more trades
> > > > > > > >> have been made. What you check is based on what you need to know for
> > > > > > > >> your algorithm.
> > > > > > > >>
> > > > > > > >> BR,
> > > > > > > >> Dennis
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> On Jul 5, 2009, at 7:10 PM, brian_z111 wrote:
> > > > > > > >>
> > > > > > > >> >> If you go to the data provider's sites, they tell you exactly what
> > > > > > > >> >> they provide and archive.
> > > > > > > >> >
> > > > > > > >> > Thanks for your summary.
> > > > > > > >> > You have saved me a lot of research time.
> > > > > > > >> > In fact your answer is about all of the info I need really (perhaps
> > > > > > > >> > I will check the detail on my provider eSignal).
> > > > > > > >> >
> > > > > > > >> >> BTW: The backtests (on historical intraday data) can show good
> > > > > > > >> >> >trading performance that is not
> > > > > > > >> >> duplicated in realtime.
> > > > > > > >> >
> > > > > > > >> > Yes, I made a mental note of that point when Herman brought it to
> > > > > > > >> > our attention earlier on (I missed a lot of the other discussion on
> > > > > > > >> > RT performance though because I was focused elsewhere).
> > > > > > > >> >
> > > > > > > >> >> For very high speed
> > > > > > > >> >> trading Herman has many more caveats in the UKB.
> > > > > > > >> >
> > > > > > > >> > Yes, I can see what he is on about now.
> > > > > > > >> > He has made a pretty decent contribution to the AB community and
> > > > > > > >> > even the general trading community.
> > > > > > > >> > I doubt if there is a better AT training ground anywhere.
> > > > > > > >> >
> > > > > > > >> > Of course I will go and read it ... lots of code tends to scare me
> > > > > > > >> > off but the UKB format is the best support for the code that we have
> > > > > > > >> > (outside of Howard's books .. go Howard go!)
> > > > > > > >> >
> > > > > > > >> >> RequestTimedRefresh ....has two other useful modes that are not
> > > > > > > >> >> >time based. The 0.1 second refresh minimum time can only be
> > > > > > > >> >> >achieved when refreshes are triggered by new quotes (ticks) in the
> > > > > > > >> >> >data stream at a rate equal or less than 0.1 sec.
> > > > > > > >> >
> > > > > > > >> > That is the final piece of the jigsaw puzzle that I was looking for.
> > > > > > > >> > I noticed that Herman talks about executing when new quotes are
> > > > > > > >> > received ... is there any way to know when a quote (tick) has
> > > > > > > >> > arrived other than Status("redrawaction")? ... this seems to be a
> > > > > > > >> > generic trigger so we can't separate new quote from the other
> > > > > > > >> > possible causes of actioned refresh.
> > > > > > > >> >
> > > > > > > >> > My first impression is that progammatically creating panes with
> > > > > > > >> > functions to specify different refresh the individual panes would be
> > > > > > > >> > on the short wishlist of RT high performance traders, or not?
> > > > > > > >> >
> > > > > > > >> > I noticed that a lot of your posts are educational.
> > > > > > > >> > Thanks once again to you and Herman for your efforts to educate
> > > > > > > >> > others (there were some good contributions from others in the posts
> > > > > > > >> > I read to).
> > > > > > > >> >
> > > > > > > >> > Correction to my previous post:
> > > > > > > >> >
> > > > > > > >> > It seems that the best way to go is to work with an amount of data
> > > > > > > >> > that fits into the cache (I think that is for all symbols in the
> > > > > > > >> > database).
> > > > > > > >> > So, it follows that the best case is to only save new data that
> > > > > > > >> > arrives in memory at the end of the session.
> > > > > > > >> > This could vary though ... perhaps AB does this on time OR it would
> > > > > > > >> > be forced to do this if data starts to overflow the cache (the
> > > > > > > >> > unknown factor there is how AB differentiates new data in memory
> > > > > > > >> > from the data that we loaded into the cache from the disc. Most
> > > > > > > >> > likely it marks start of the new data in some way ... I don't think
> > > > > > > >> > the optimum method would be to save all the data in memory by
> > > > > > > >> > default i.e. overwrite the data that we loaded in the first place).
> > > > > > > >> >
> > > > > > > >> > --- In amibroker@xxxxxxxxxxxxxxx, Dennis Brown <see3d@> wrote:
> > > > > > > >> >>
> > > > > > > >> >> Brian,
> > > > > > > >> >>
> > > > > > > >> >> If you go to the data provider's sites, they tell you exactly what
> > > > > > > >> >> they provide and archive. In general a RT data provider will keep a
> > > > > > > >> >> number of days of tick history. From those they compress into one
> > > > > > > >> >> minute bars that they keep for many months or a few years. From
> > > > > > > >> >> those, they compress into daily bars that they keep for many years or
> > > > > > > >> >> decades. They will provide historical downloads based on one of
> > > > > > > >> >> these
> > > > > > > >> >> saved formats. Some also compress ticks into volume bars of various
> > > > > > > >> >> denominations for certain tickers that they archive like minute bars.
> > > > > > > >> >> They just have these few historical formats and everything else has
> > > > > > > >> >> to
> > > > > > > >> >> be aggregated from these, either by the server, or the client. WIth
> > > > > > > >> >> storage becoming less expensive, the tendency is to keep larger
> > > > > > > >> >> historical archives.
> > > > > > > >> >>
> > > > > > > >> >> It is possible that for efficiency, they might choose to cache other
> > > > > > > >> >> tick derived timeframes like 5 second, etc., so they don't have to
> > > > > > > >> >> duplicate the computations on every request. However, that is
> > > > > > > >> >> internal and may or may not take place based on their internal
> > > > > > > >> >> engineering designs, and it may change at any time. They also scrub
> > > > > > > >> >> their databases for bad ticks during the day and also at night. This
> > > > > > > >> >> obviously means that the data you get served for a historical
> > > > > > > >> >> backfill
> > > > > > > >> >> will not match the data that actually occurred in real time.
> > > > > > > >> >>
> > > > > > > >> >> BTW: The backtests can show good trading performance that is not
> > > > > > > >> >> duplicated in realtime. This is a possible indication of an over
> > > > > > > >> >> optimized algorithm. I try to avoid such algorithms in practice.
> > > > > > > >> >> The
> > > > > > > >> >> way you find out is to run the algorithm in realtime for a day, then
> > > > > > > >> >> backfill over the day's data the next day and see if the performance
> > > > > > > >> >> changes significantly. I learned this lesson early on the hard way.
> > > > > > > >> >> This was actually a major driver for me to trade only the ES futures
> > > > > > > >> >> -- the data feeds are very high quality with very few errors, so my
> > > > > > > >> >> backtests match the realtme trading performance. For very high speed
> > > > > > > >> >> trading Herman has many more caveats in the UKB.
> > > > > > > >> >>
> > > > > > > >> >> RequestTimedRefresh can only specify down to 1 second in 1 second
> > > > > > > >> >> increments. It also has two other useful modes that are not time
> > > > > > > >> >> based. The 0.1 second refresh minimum time can only be achieved when
> > > > > > > >> >> refreshes are triggered by new quotes (ticks) in the data stream at a
> > > > > > > >> >> rate equal or less than 0.1 sec. To have timed refreshes at 0.1
> > > > > > > >> >> second increments is only something that has been requested at this
> > > > > > > >> >> point.
> > > > > > > >> >>
> > > > > > > >> >> BR,
> > > > > > > >> >> Dennis
> > > > > > > >> >>
> > > > > > > >> >> On Jul 5, 2009, at 5:14 AM, brian_z111 wrote:
> > > > > > > >> >>
> > > > > > > >> >>>> since their server is, say tick based, when we use it at a
> > > > > > > >> >>>>> different timeframe
> > > > > > > >> >>>> (as the base timeframe in AB) then AB must compress ticks, on the
> > > > > > > >> >>>>> fly in memory
> > > > > > > >> >>>> UNLESS they keep different timeframes on different servers, or
> > > > > > > >> >>>>> sections of
> > > > > > > >> >>>> servers, but that doesn't seem likely.
> > > > > > > >> >>>
> > > > > > > >> >>> Actually, now that I think about it the most likely scenario appears
> > > > > > > >> >>> to be that the providers compress their tick data according to our
> > > > > > > >> >>> needs (AB communicates with them via the plugin and 'tells' the
> > > > > > > >> >>> provider what timeframe we want to use).
> > > > > > > >> >>>
> > > > > > > >> >>> --- In amibroker@xxxxxxxxxxxxxxx, "brian_z111" <brian_z111@> wrote:
> > > > > > > >> >>>>
> > > > > > > >> >>>> Tomasz,
> > > > > > > >> >>>>
> > > > > > > >> >>>> Thanks.
> > > > > > > >> >>>>
> > > > > > > >> >>>> I am starting to understand now because I have read a few of the
> > > > > > > >> >>>> posts on refresh etc (thanks to Herman/Dennis .. who seem to be the
> > > > > > > >> >>>> leaders on this, and others plus, of course, your good replies,
> > > > > > > >> >>>> here and there).
> > > > > > > >> >>>>
> > > > > > > >> >>>> I seem to have moved on to AFL 201, without even noticing.
> > > > > > > >> >>>>
> > > > > > > >> >>>> I don't understand why you did not tell me this stuff in the
> > > > > > > >> >>>> manual... I could have learnt it years ago instead of suffering it
> > > > > > > >> >>>> out in silence.
> > > > > > > >> >>>> I had to access posts to find it out ... it took me a few hours ..
> > > > > > > >> >>>> will I remember what I read, or do I have to archive the posts ..
> > > > > > > >> >>>> maybe try to find them again if I forget (more precious time
> > > > > > > >> >>>> gone) ... * how many users have to do this per year?
> > > > > > > >> >>>>
> > > > > > > >> >>>> In general I agree with your philosophies and approach ... I give
> > > > > > > >> >>>> AB a tick for QuickAFL and setting the default to 0.1 sec refresh
> > > > > > > >> >>>> with > 0.1 chart redraw required. This is practical and logical and
> > > > > > > >> >>>> a very good yardstick for non-programmers. Most long term users
> > > > > > > >> >>>> will want to go further though ... even the non-progamming group
> > > > > > > >> >>>> will start asking questions eventually.
> > > > > > > >> >>>>
> > > > > > > >> >>>> I don't agree with all of your answers though ... some are
> > > > > > > >> >>>> questionable ... not technically questionable but in terms of your
> > > > > > > >> >>>> objectives, yes questionable .... but at this stage I haven't made
> > > > > > > >> >>>> a final decision:
> > > > > > > >> >>>>
> > > > > > > >> >>>>
> > > > > > > >> >>>> I don't need this stuff myself, not at the moment, but I have to go
> > > > > > > >> >>>> along with any investigation into the power of the logic.
> > > > > > > >> >>>>
> > > > > > > >> >>>>
> > > > > > > >> >>>> (The Holy Grail for my style is to make 1000%PA, in consecutive
> > > > > > > >> >>>> years, and only need a little bit of code in an AB chart OR maybe
> > > > > > > >> >>>> no AB at all ... except that AT is permissable because it is only a
> > > > > > > >> >>>> tool to ease the administrative burden).
> > > > > > > >> >>>>
> > > > > > > >> >>>> For this discussion I referenced the following posts:
> > > > > > > >> >>>>
> > > > > > > >> >>>> http://finance.groups.yahoo.com/group/amibroker/message/137507
> > > > > > > >> >>>> http://finance.groups.yahoo.com/group/amibroker/message/122464
> > > > > > > >> >>>> http://finance.groups.yahoo.com/group/amibroker/message/109672
> > > > > > > >> >>>> http://finance.groups.yahoo.com/group/amibroker/message/125914
> > > > > > > >> >>>> http://finance.groups.yahoo.com/group/amibroker/message/136087
> > > > > > > >> >>>> http://finance.groups.yahoo.com/group/amibroker/message/135943
> > > > > > > >> >>>>
> > > > > > > >> >>>>
> > > > > > > >> >>>>
> > > > > > > >> >>>> KEYWORDS
> > > > > > > >> >>>>
> > > > > > > >> >>>> OPTIMAL RT PERFORMANCE
> > > > > > > >> >>>>
> > > > > > > >> >>>>
> > > > > > > >> >>>>
> > > > > > > >> >>>> OT Commentary:
> > > > > > > >> >>>>
> > > > > > > >> >>>> Don't worry, Tomasz.
> > > > > > > >> >>>>
> > > > > > > >> >>>> Even if you wrote an explanation of the zillion of things that make
> > > > > > > >> >>>> AB work there are too many nice things to do with my life to sit
> > > > > > > >> >>>> down and read them all.
> > > > > > > >> >>>>
> > > > > > > >> >>>> I think that, in general, people only want to know, and need to
> > > > > > > >> >>>> know the basics of the core processes.
> > > > > > > >> >>>>
> > > > > > > >> >>>> You could easily add a chapter, on this subject, to the manual and
> > > > > > > >> >>>> add a flowchart or two (BTW the 'flowchart' for Database
> > > > > > > >> >>>> Management, in the manual, is too basic (junior school level).
> > > > > > > >> >>>> Do you realize the power that flowcharts have, to convey
> > > > > > > >> >>>> information?
> > > > > > > >> >>>> In the mining industry I have seen examples where all of the core
> > > > > > > >> >>>> information in a 1000 page manual was contained, in detail, in 20
> > > > > > > >> >>>> drafted charts ... a whole processing plant, covering 100's of
> > > > > > > >> >>>> hectares, summarized in around 100 - 200 charts (I could tell you
> > > > > > > >> >>>> exactly what was going on in any section of the plant without
> > > > > > > >> >>>> leaving my office).
> > > > > > > >> >>>>
> > > > > > > >> >>>>
> > > > > > > >> >>>> Re data collection:
> > > > > > > >> >>>>
> > > > > > > >> >>>> I was thinking about this yesterday, in the back of my mind.
> > > > > > > >> >>>> It is amazing how, after you formalize a question the answer starts
> > > > > > > >> >>>> to form in your mind, all by itself.
> > > > > > > >> >>>>
> > > > > > > >> >>>> I came to the following speculative construction in my imagination
> > > > > > > >> >>>> (that is the picture in my head for laypeople) ... the picture is
> > > > > > > >> >>>> constructed by relying on what is the most likely or at least a
> > > > > > > >> >>>> feasible way that soemthing could be done:
> > > > > > > >> >>>>
> > > > > > > >> >>>> - streaming data can be collected passively ... I imagine it is
> > > > > > > >> >>>> like water, in a tap, that is under pressure, and if we tap into it
> > > > > > > >> >>>> then it will flow to us (don't know how it would work technically).
> > > > > > > >> >>>> I imagaine that providers would use this method as it would be an
> > > > > > > >> >>>> efficient way to get the data to many users (it requires less
> > > > > > > >> >>>> activity on their servers?)
> > > > > > > >> >>>>
> > > > > > > >> >>>> - in AB, data collection is managed by the program ..... the
> > > > > > > >> >>>> plugins are relatively dumb (they just have the docking protocols
> > > > > > > >> >>>> etc?)
> > > > > > > >> >>>>
> > > > > > > >> >>>> - routines to manage each plugin are included in AB, and are
> > > > > > > >> >>>> activated when we install the plugin OR when we install the plugin
> > > > > > > >> >>>> it adds a little bit of plugin control code to AB so AB can
> > > > > > > >> >>>> interact with it
> > > > > > > >> >>>>
> > > > > > > >> >>>> - IQ, for example, is streaming data, and the data flows from their
> > > > > > > >> >>>> server into our on board cache, when we are connected via the
> > > > > > > >> >>>> plugin
> > > > > > > >> >>>>
> > > > > > > >> >>>> - ticks go into the on board memory in the order they arrive (park
> > > > > > > >> >>>> them on the end of the queue for each symbol)
> > > > > > > >> >>>>
> > > > > > > >> >>>> - tick history in memory is rendered as Time&sales
> > > > > > > >> >>>>
> > > > > > > >> >>>> - tick history is only rendered for the QuoteWindow and charts
> > > > > > > >> >>>> according to refresh rates, so while tick history is there (for
> > > > > > > >> >>>> Time and Sales and historical work) we don't see it in RT work.
> > > > > > > >> >>>>
> > > > > > > >> >>>> - Tools > Preferences > Intraday > Realtime Chart Refresh interval
> > > > > > > >> >>>> (sec) is the default for chart and QuoteWindow refresh/
> > > > > > > >> >>>>
> > > > > > > >> >>>> - RequestTimedRefresh over-rides the preference setting for charts
> > > > > > > >> >>>> (not sure about QuoteWindow ... I guess not).... it accepts any
> > > > > > > >> >>>> input but in practice it is limited to 0.1 sec by AB
> > > > > > > >> >>>>
> > > > > > > >> >>>> - newly arrived tick data, in the onboard cache, is only saved to
> > > > > > > >> >>>> the historical database, on the disc, when we hit save OR when we
> > > > > > > >> >>>> exit the database/session (only if autosave is set in our
> > > > > > > >> >>>> preferences?)
> > > > > > > >> >>>>
> > > > > > > >> >>>>
> > > > > > > >> >>>> - IQ, for example, is a streaming RT tick provider ... each new
> > > > > > > >> >>>> tick must pulse to us but at the same time go to their historical
> > > > > > > >> >>>> database so that we can download historical (backfill) by sending a
> > > > > > > >> >>>> request to their server
> > > > > > > >> >>>>
> > > > > > > >> >>>> - since their server is, say tick based, when we use it at a
> > > > > > > >> >>>> different timeframe (as the base timeframe in AB) then AB must
> > > > > > > >> >>>> compress ticks, on the fly in memory UNLESS they keep different
> > > > > > > >> >>>> timeframes on different servers, or sections of servers, but that
> > > > > > > >> >>>> doesn't seem likely.
> > > > > > > >> >>>>
> > > > > > > >> >>>> - after hours, when traffic is light, AB changes over to the
> > > > > > > >> >>>> default of 'polling' the server once every sec (like requesting a
> > > > > > > >> >>>> backfill of historical data).
> > > > > > > >> >>>>
> > > > > > > >> >>>> Of course, this could all be wrong ... it is only speculation.
> > > > > > > >> >>>>
> > > > > > > >> >>>> We only speculate, in an effort to gain understanding, in the
> > > > > > > >> >>>> absence of truth (we are all driven towards achieving
> > > > > > > >> >>>> understanding, or meaning, fo the world around us, or our current
> > > > > > > >> >>>> environment. This is hardcoded into humans).
> > > > > > > >> >>>>
> > > > > > > >> >>>>
> > > > > > > >> >>>> Why do I want to know this stuff?
> > > > > > > >> >>>>
> > > > > > > >> >>>> - so that I can use AB in better ways (if I understand the design
> > > > > > > >> >>>> limits I will know how far I can push it in any one direction).
> > > > > > > >> >>>> - and so that I don't have to ask stupid questions in the forum
> > > > > > > >> >>>> - because quite a few experienced AB users are sometime confused
> > > > > > > >> >>>> by/
> > > > > > > >> >>>> interested in this subject
> > > > > > > >> >>>>
> > > > > > > >> >>>> for example:
> > > > > > > >> >>>>
> > > > > > > >> >>>> in 3-4 years of owning AB I have never used PerformanceCounter, or
> > > > > > > >> >>>> debug or CodeProfile and check etc ... not once, because you didn't
> > > > > > > >> >>>> put it in pictures in the manual. In the first years, because of my
> > > > > > > >> >>>> computing inexperience, I couldn't absorb this info, by the 'no
> > > > > > > >> >>>> hand holding here' method because there was too much other stuff to
> > > > > > > >> >>>> learn ... my brain couldn't cope with that kind of workload i.e.
> > > > > > > >> >>>> you have answered questions on Refresh before but I didn't follow
> > > > > > > >> >>>> the answers because I didn't realize the significance (you need
> > > > > > > >> >>>> your specs to find your specs) ... on the other hand if your write
> > > > > > > >> >>>> about it in the Help maual then I know that it must be significant
> > > > > > > >> >>>> so then I will pay more attention e.g. if you don't write about
> > > > > > > >> >>>> Code Profile and Check then I guess that it is not a significant
> > > > > > > >> >>>> part of AB.
> > > > > > > >> >>>>
> > > > > > > >> >>>> Why do I ask these questions here?
> > > > > > > >> >>>>
> > > > > > > >> >>>> - because it would be very selfish, and an inefficient use of AB
> > > > > > > >> >>>> time (== bad karma!) if I emailed support and kept the answers to
> > > > > > > >> >>>> myself.
> > > > > > > >> >>>> - because I am a NewAgeGuy (not a sensitive one though) I am
> > > > > > > >> >>>> committed to my ethical imperatives ..... group effort and sharing,
> > > > > > > >> >>>> transparent communication and full disclosure/availability of
> > > > > > > >> >>>> information.
> > > > > > > >> >>>>
> > > > > > > >> >>>>
> > > > > > > >> >>>> I do notice your admonitions, and guidance, in this forum, not to
> > > > > > > >> >>>> do certain things in AB e.g. I saw your post advising that total
> > > > > > > >> >>>> execution (redraw time) should be under 0.1 sec and this fits
> > > > > > > >> >>>> nicely with your default time of 0.1 sec for refresh.
> > > > > > > >> >>>> I really appreciate your guidance in these areas.
> > > > > > > >> >>>> I have learnt a lot about the IT side of trading, from you ...
> > > > > > > >> >>>> taking not of the things you put in and left out of AB and also the
> > > > > > > >> >>>> forum discussions.
> > > > > > > >> >>>> I should have archived some of your answers but once again that is
> > > > > > > >> >>>> additional work to compile my own private Help manual.
> > > > > > > >> >>>>
> > > > > > > >> >>>>
> > > > > > > >> >>>> FTR
> > > > > > > >> >>>>
> > > > > > > >> >>>> why do you only give your answers informally, via the forum,
> > > > > > > >> >>>> instead of compending them somewhere, for the benefit of newcomers
> > > > > > > >> >>>> and for reference ... why do youkeep on answering the same
> > > > > > > >> >>>> questions in the forum ... over and over again?
> > > > > > > >> >>>>
> > > > > > > >> >>>> Do you ever feel the urge to answer these questions once and for
> > > > > > > >> >>>> all and then the users can move on?
> > > > > > > >> >>>>
> > > > > > > >> >>>>
> > > > > > > >> >>>>
> > > > > > > >> >>>>
> > > > > > > >> >>>>
> > > > > > > >> >>>>
> > > > > > > >> >>>>
> > > > > > > >> >>>>
> > > > > > > >> >>>>
> > > > > > > >> >>>> --- In amibroker@xxxxxxxxxxxxxxx, Tomasz Janeczko <groups@> wrote:
> > > > > > > >> >>>>>
> > > > > > > >> >>>>> Hello,
> > > > > > > >> >>>>>
> > > > > > > >> >>>>> Chart refresh is independent from data collection.
> > > > > > > >> >>>>> It means that plugin can collect even 1000 updates (ticks) per
> > > > > > > >> >>>>> second
> > > > > > > >> >>>>> per symbol,
> > > > > > > >> >>>>> while chart will refresh 10 times per second.
> > > > > > > >> >>>>>
> > > > > > > >> >>>>> If that happens, during 0.1 sec you will see 100 new ticks arrived
> > > > > > > >> >>>>> and
> > > > > > > >> >>>>> displayed
> > > > > > > >> >>>>> on chart.
> > > > > > > >> >>>>>
> > > > > > > >> >>>>> It does not make sense to update chart more often than about 10
> > > > > > > >> >>>>> times
> > > > > > > >> >>>>> per second
> > > > > > > >> >>>>> because human perception is limited to that rate.
> > > > > > > >> >>>>>
> > > > > > > >> >>>>> Best regards,
> > > > > > > >> >>>>> Tomasz Janeczko
> > > > > > > >> >>>>> amibroker.com
> > > > > > > >> >>>>>
> > > > > > > >> >>>>> brian_z111 wrote:
> > > > > > > >> >>>>>> Going by what Tomasz said:
> > > > > > > >> >>>>>>
> > > > > > > >> >>>>>> Plugins do send updates if certain market is closed because
> > > > > > > >> >>>>>> a) if you open AmiBroker on sunday, you still want to see most
> > > > > > > >> >>>>>> recent quote,
> > > > > > > >> >>>>>> without waiting till Monday.
> > > > > > > >> >>>>>> b) plugins not only send updates on quotes but also on some other
> > > > > > > >> >>>>>> info that is
> > > > > > > >> >>>>>> not related to market activity
> > > > > > > >> >>>>>> c) there can be corrections sent later
> > > > > > > >> >>>>>> d) other markets may be open
> > > > > > > >> >>>>>> e) the bacfill may be in progress, etc.
> > > > > > > >> >>>>>>
> > > > > > > >> >>>>>> For the reasons above, most plugins sent "general update" every
> > > > > > > >> >>>>>> second.
> > > > > > > >> >>>>>>
> > > > > > > >> >>>>>> AND "real-time data refresh (can be as often as every tick, but
> > > > > > > >> >>>>>> not more often
> > > > > > > >> >>>>>> than 10 times per second)"
> > > > > > > >> >>>>>>
> > > > > > > >> >>>>>> For IQ RT data:
> > > > > > > >> >>>>>>
> > > > > > > >> >>>>>> - when the market is quiet we are receiving general updates, in
> > > > > > > >> >>>>>> our charts, every sec and when the market is busy we are
> > > > > > > >> >>>>>> receiving updates every 1/10th sec, at best i.e. if watching a
> > > > > > > >> >>>>>> fast market and we have no programmatical or preferences set to
> > > > > > > >> >>>>>> refresh AND we don't touch our mouse).
> > > > > > > >> >>>>>>
> > > > > > > >> >>>>>> This seems to indicate that our data is polling the IQ server for
> > > > > > > >> >>>>>> a timeslice of historical tick downloads.
> > > > > > > >> >>>>>>
> > > > > > > >> >>>>>> Presumably our quote database and the T&S window is the same ...
> > > > > > > >> >>>>>> unless the plugin is a 'two in one' i.e. it does it one way for
> > > > > > > >> >>>>>> charts and another way for T&S or quote database.
> > > > > > > >> >>>>>>
> > > > > > > >> >>>>>>
> > > > > > > >> >>>>>> --- In amibroker@xxxxxxxxxxxxxxx, "brian_z111" <brian_z111@>
> > > > > > > >> >>>>>> wrote:
> > > > > > > >> >>>>>>
> > > > > > > >> >>>>>>> RT speed (trading in charts) seems to be limited,at the core, by
> > > > > > > >> >>>>>>> data speed.
> > > > > > > >> >>>>>>>
> > > > > > > >> >>>>>>> There are some things I don't understand about data and the way
> > > > > > > >> >>>>>>> we collect it, via our plugins.
> > > > > > > >> >>>>>>>
> > > > > > > >> >>>>>>> I am referencing info from a previous discussion:
> > > > > > > >> >>>>>>>
> > > > > > > >> >>>>>>> http://finance.groups.yahoo.com/group/amibroker/message/136651
> > > > > > > >> >>>>>>>
> > > > > > > >> >>>>>>> I understand that these are hard questions to answer so if I get
> > > > > > > >> >>>>>>> no answer I will send the question to support.
> > > > > > > >> >>>>>>>
> > > > > > > >> >>>>>>> Assuming that for speed work, true tick data is the best (not 1
> > > > > > > >> >>>>>>> -5 sec snapshot like some data providers).
> > > > > > > >> >>>>>>>
> > > > > > > >> >>>>>>>
> > > > > > > >> >>>>>>> Assuming that the plugins are not all the same ... they are
> > > > > > > >> >>>>>>> matched to the data type.
> > > > > > > >> >>>>>>>
> > > > > > > >> >>>>>>> Is it possible for software to be a passive receiver of RT data
> > > > > > > >> >>>>>>> i.e. the provider 'sends' out the ticks, like a pulse, and we
> > > > > > > >> >>>>>>> just hook up our pipe (via the plugin) and the data streams into
> > > > > > > >> >>>>>>> our software (is that what is called streamed data?)
> > > > > > > >> >>>>>>>
> > > > > > > >> >>>>>>> If so, would they 'pulse' every tick but not supply historical
> > > > > > > >> >>>>>>> ticks live?
> > > > > > > >> >>>>>>>
> > > > > > > >> >>>>>>> Opposed to 'streaming' data I imagine that the provider could
> > > > > > > >> >>>>>>> just give us access to the historical ticks (with RT update) and
> > > > > > > >> >>>>>>> we have to proactively get the data i.e. our plugin would
> > > > > > > >> >>>>>>> initiate a download of the last few ticks or secs of tick data.
> > > > > > > >> >>>>>>>
> > > > > > > >> >>>>>>> I am a bit confused about this.
> > > > > > > >> >>>>>>>
> > > > > > > >> >>>>>>> Using IQFeed as the example:
> > > > > > > >> >>>>>>>
> > > > > > > >> >>>>>>> - it appears that our IQ plugin 'polls' the IQ server OR holds
> > > > > > > >> >>>>>>> the streaming data for a while and then sends it to us in
> > > > > > > >> >>>>>>> packets.
> > > > > > > >> >>>>>>>
> > > > > > > >> >>>>>>> Tomasz said that
> > > > > > > >> >>>>>>>
> > > > > > > >> >>>>>>> "real-time data refresh (can be as often as every tick, but not
> > > > > > > >> >>>>>>> more often
> > > > > > > >> >>>>>>> than 10 times per second)"
> > > > > > > >> >>>>>>>
> > > > > > > >> >>>>>>> but in a test, Conrad Joach (using IQ RT data) with refresh in
> > > > > > > >> >>>>>>> the preferences set to zero, found that the plugin was updating
> > > > > > > >> >>>>>>> to AB every second (this is plugin initiated activity ...
> > > > > > > >> >>>>>>> completely independent of refresh settings and not requested
> > > > > > > >> >>>>>>> refresh in the AFL formula).
> > > > > > > >> >>>>>>>
> > > > > > > >> >>>>>>> Is the IQ plugin streaming every tick OR polling every 10 secs
> > > > > > > >> >>>>>>> OR polling every 1 sec Or something else?
> > > > > > > >> >>>>>>>
> > > > > > > >> >>>>>>> To make things even more confusing Tomasz also said that
> > > > > > > >> >>>>>>>
> > > > > > > >> >>>>>>> "On MSFT you can easily have more than 200 new ticks per second.
> > > > > > > >> >>>>>>> Use Time&Sales window to display actual ticks."
> > > > > > > >> >>>>>>>
> > > > > > > >> >>>>>>>
> > > > > > > >> >>>>>>> If MSFT has > 200 ticks per second does that mean we can never
> > > > > > > >> >>>>>>> see true RT tick by tick charts because our plugin only updates,
> > > > > > > >> >>>>>>> at best 1 per sec or 1 per 10 sec (not sure which is correct).
> > > > > > > >> >>>>>>>
> > > > > > > >> >>>>>>> Also, how can we see ticks for say, MSFT, in the Time&sales
> > > > > > > >> >>>>>>> window (I don't use it so I am not sure if we can or not).....
> > > > > > > >> >>>>>>> are we really only seeing historical bites in the T&S window OR
> > > > > > > >> >>>>>>> is the plugin somehow streaming ticks to the T&S window while
> > > > > > > >> >>>>>>> not streaming ticks to our charts?
> > > > > > > >> >>>>>>>
> > > > > > > >> >>>>>>>
> > > > > > > >> >>>>>>> (I am using Pro 5.20 on an XP machine)
> > > > > > > >> >>>>>>>
> > > > > > > >> >>>>>>>
> > > > > > > >> >>>>>>
> > > > > > > >> >>>>>>
> > > > > > > >> >>>>>>
> > > > > > > >> >>>>>>
> > > > > > > >> >>>>>> ------------------------------------
> > > > > > > >> >>>>>>
> > > > > > > >> >>>>>> **** IMPORTANT PLEASE READ ****
> > > > > > > >> >>>>>> This group is for the discussion between users only.
> > > > > > > >> >>>>>> This is *NOT* technical support channel.
> > > > > > > >> >>>>>>
> > > > > > > >> >>>>>> TO GET TECHNICAL SUPPORT send an e-mail directly to
> > > > > > > >> >>>>>> SUPPORT {at} amibroker.com
> > > > > > > >> >>>>>>
> > > > > > > >> >>>>>> TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at
> > > > > > > >> >>>>>> http://www.amibroker.com/feedback/
> > > > > > > >> >>>>>> (submissions sent via other channels won't be considered)
> > > > > > > >> >>>>>>
> > > > > > > >> >>>>>> For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
> > > > > > > >> >>>>>> http://www.amibroker.com/devlog/
> > > > > > > >> >>>>>>
> > > > > > > >> >>>>>> Yahoo! Groups Links
> > > > > > > >> >>>>>>
> > > > > > > >> >>>>>>
> > > > > > > >> >>>>>>
> > > > > > > >> >>>>>>
> > > > > > > >> >>>>>>
> > > > > > > >> >>>>>
> > > > > > > >> >>>>
> > > > > > > >> >>>
> > > > > > > >> >>>
> > > > > > > >> >>>
> > > > > > > >> >>>
> > > > > > > >> >>> ------------------------------------
> > > > > > > >> >>>
> > > > > > > >> >>> **** IMPORTANT PLEASE READ ****
> > > > > > > >> >>> This group is for the discussion between users only.
> > > > > > > >> >>> This is *NOT* technical support channel.
> > > > > > > >> >>>
> > > > > > > >> >>> TO GET TECHNICAL SUPPORT send an e-mail directly to
> > > > > > > >> >>> SUPPORT {at} amibroker.com
> > > > > > > >> >>>
> > > > > > > >> >>> TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at
> > > > > > > >> >>> http://www.amibroker.com/feedback/
> > > > > > > >> >>> (submissions sent via other channels won't be considered)
> > > > > > > >> >>>
> > > > > > > >> >>> For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
> > > > > > > >> >>> http://www.amibroker.com/devlog/
> > > > > > > >> >>>
> > > > > > > >> >>> Yahoo! Groups Links
> > > > > > > >> >>>
> > > > > > > >> >>>
> > > > > > > >> >>>
> > > > > > > >> >>
> > > > > > > >> >
> > > > > > > >> >
> > > > > > > >> >
> > > > > > > >> >
> > > > > > > >> > ------------------------------------
> > > > > > > >> >
> > > > > > > >> > **** IMPORTANT PLEASE READ ****
> > > > > > > >> > This group is for the discussion between users only.
> > > > > > > >> > This is *NOT* technical support channel.
> > > > > > > >> >
> > > > > > > >> > TO GET TECHNICAL SUPPORT send an e-mail directly to
> > > > > > > >> > SUPPORT {at} amibroker.com
> > > > > > > >> >
> > > > > > > >> > TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at
> > > > > > > >> > http://www.amibroker.com/feedback/
> > > > > > > >> > (submissions sent via other channels won't be considered)
> > > > > > > >> >
> > > > > > > >> > For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
> > > > > > > >> > http://www.amibroker.com/devlog/
> > > > > > > >> >
> > > > > > > >> > Yahoo! Groups Links
> > > > > > > >> >
> > > > > > > >> >
> > > > > > > >> >
> > > > > > > >>
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > ------------------------------------
> > > > > > > >
> > > > > > > > **** IMPORTANT PLEASE READ ****
> > > > > > > > This group is for the discussion between users only.
> > > > > > > > This is *NOT* technical support channel.
> > > > > > > >
> > > > > > > > TO GET TECHNICAL SUPPORT send an e-mail directly to
> > > > > > > > SUPPORT {at} amibroker.com
> > > > > > > >
> > > > > > > > TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at
> > > > > > > > http://www.amibroker.com/feedback/
> > > > > > > > (submissions sent via other channels won't be considered)
> > > > > > > >
> > > > > > > > For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
> > > > > > > > http://www.amibroker.com/devlog/
> > > > > > > >
> > > > > > > > Yahoo! Groups Links
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
------------------------------------
**** IMPORTANT PLEASE READ ****
This group is for the discussion between users only.
This is *NOT* technical support channel.
TO GET TECHNICAL SUPPORT send an e-mail directly to
SUPPORT {at} amibroker.com
TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at
http://www.amibroker.com/feedback/
(submissions sent via other channels won't be considered)
For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
http://www.amibroker.com/devlog/
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/amibroker/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/amibroker/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:amibroker-digest@xxxxxxxxxxxxxxx
mailto:amibroker-fullfeatured@xxxxxxxxxxxxxxx
<*> To unsubscribe from this group, send an email to:
amibroker-unsubscribe@xxxxxxxxxxxxxxx
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|
