|
PureBytes Links
Trading Reference Links
|
Yes there are people calling for millisecond timestamps.
See this:
http://www.amibroker.com/feedback/view_bug.php?bug_id=1691
It specifically talks about milisecond resolution of timestamps
"It would be very useful to be able to display this in milliseconds [...]"
As to the feature you are talking about - I know what you are after.
But if you have any chart that takes 500ms
(for example), sooner or later this chart will need to be refreshed and all
other (quicker) charts will still need to wait for this "complex" chart to complete
once it gets control over GDI system-wide lock unless completely parallel rendering is implemented
and possible in the operating system-layer (i.e. in Windows 7).
Best regards,
Tomasz Janeczko
amibroker.com
----- Original Message -----
From: "Julian" <juliangoodsell@xxxxxxxxxxxx>
To: <amibroker@xxxxxxxxxxxxxxx>
Sent: Tuesday, July 14, 2009 4:46 PM
Subject: [amibroker] Re: Per Chart Refresh Rates
> Hi Tomasz,
>
> I don't know if something has been missed in translation, but I don't think anyone is actually calling for sub-second timestamps?
> Some are calling for 1 second timestamps because eSignal supports this.
>
> What I've been on about is sub-second chart refreshes, nothing to do with timestamps, so you might have mixed the two as they
> occurred in the same thread.
>
> For all the verbosity of the last two threads, they ended up formulating into the feedback center request #1795 which I'm glad
> you're looking into.
>
> The other point I raised, which hasn't been addressed yet, was about sub-second chart refreshes which came down to the fact that
> you can specify a refresh interval of 0 in the preferences, but requestTimedRefresh is limited to a 1 second resolution. This has
> real world implications in that it is difficult to use this per tick update feature in practice.
>
> Your help file says:
> "New in 4.90: To enable 'every tick' chart refresh in Professional Edition, go to Tools->Preferences, Intraday tab and enter ZERO
> (0) into "Intraday chart refresh interval" field. (note Standard Edition won't allow to do that).
> Once you enter zero, AmiBroker will refresh all charts with every new trade arriving provided that the formulas you use execute
> fast enough. If not, it will dynamically adjust refresh rate to maintain maximum possible refresh rate without consuming more than
> 50% of CPU (on average). So for example if your charts take 0.2 sec to execute AmiBroker will refresh them on average 2.5 times
> per second."
>
> This feature is great, but unless you can remove certain charts from this high speed refresh update, it's difficult to achieve. I
> may have one fast chart that I want, and is capable of being updated at per tick speed, but if I have 6 other charts that combined
> take 500ms or one second to refresh, then per tick updates are not possible.
> The ability to specify 0 via requestTimedRefresh(0), would mean I could choose 1 chart to update that quickly, and could specify
> slower refresh rates for the other 6 charts.
> I hope I've explained that clearly, and if I'm just missing something obvious, then please let me know.
>
> Thanks,
> Julian.
>
>
>
> --- In amibroker@xxxxxxxxxxxxxxx, "Tomasz Janeczko" <groups@xxx> wrote:
>>
>> Hello,
>>
>> > As far as I'm concerned, as long as we have a one second resolution. I'm happy enough.
>> > But if Tomasz is going to the trouble to re-structuring the database, why not build in some margin for future growth?
>> Sub-second resolution is not just restructuring database - it is a breaking change for entire API because timestamp with
>> milisecond
>> resolution AND scope of 1900-2155 would need to be 64-bit, that means adding support 64 data type to *ALL* afl functions
>> effectivelly
>> doubling the code (since polymorphic versions of all functions must be added) changing the way custom fixed-size allocators and
>> many
>> other details also the AmiVar structure is no longer 8 bytes
>> and that means *ALL* indicator plugins written upto date (including 3rd party that I don't have sources for) need (at least)
>> recompile.
>> Of course all data plugins need rewrite, but that's obvious. Essentially it means flipping all lines of code (millions) upside
>> down.
>>
>> I know it is my problem only but I just wanted to show that it is not just lack of "caring" as some may suggested.
>>
>> Best regards,
>> Tomasz Janeczko
>> amibroker.com
>> ----- Original Message -----
>> From: "Paul Ho" <paul.tsho@xxx>
>> To: <amibroker@xxxxxxxxxxxxxxx>
>> Sent: Tuesday, July 14, 2009 3:00 PM
>> Subject: [amibroker] Re: Per Chart Refresh Rates
>>
>>
>> > Guys
>> > There are two suggestions that should concern participants of this thread, if you're interested in changing the resolution of
>> > timestamp to sub 5 seconds. please take a look at suggestion 1691 :
>> > http://www.amibroker.com/feedback/view_bug.php?bug_id=1691&start_at=0 . Another one which could also be of interest is about
>> > float
>> > point volume. #636 http://www.amibroker.com/feedback/view_bug.php?bug_id=636 .
>> >
>> > As far as I'm concerned, as long as we have a one second resolution. I'm happy enough. But if Tomasz is going to the trouble to
>> > re-structuring the database, why not build in some margin for future growth?
>> >
>> > If you guys wants what we've talked about not gone emptied handed. take a few minute to have a look these 2 suggestions.
>> >
>> > Paul.
>> >
>> >
>> > --- In amibroker@xxxxxxxxxxxxxxx, "Tomasz Janeczko" <groups@> wrote:
>> >>
>> >> Hello,
>> >>
>> >> My post was solely to point out that
>> >> the Feedback Center (FC) http://www.amibroker.com/feedback/
>> >> is the only place to make suggestions. Other means will be simply ignored
>> >> because of the inefficiency. Only FC offers required organisation
>> >> and is compatible with development environment.
>> >> I simply can not afford reading through tons of talk
>> >> to locate one line in which someone wants something implemented.
>> >> That is a waste of time I was mentioning.
>> >> So please feel free to discuss, but don't expect me to note of your suggestions
>> >> spread in the middle of 10 page talk. Use the feedback center
>> >> or support channel to make any requests.
>> >>
>> >> And to people talking about adding sub-second resolution to timestamp:
>> >> you are simply forgetting one fact.
>> >> No supported DATA SOURCE offers resolution higher than 1 second.
>> >> They are all down to 1 second AT BEST. Not so rare are tick data with only 1-minute resolution (IQFeed until recently was such
>> >> example).
>> >> There is simply no sub-second data available.
>> >>
>> >> Why would one add a feature when there is no data available ?
>> >>
>> >> Please point out to single data vendor (for retail clients) that offers subsecond timestamps
>> >> and offers backfill with subsecond timestamps.
>> >>
>> >> I don't know of any.
>> >>
>> >> Best regards,
>> >> Tomasz Janeczko
>> >> amibroker.com
>> >> ----- Original Message -----
>> >> From: "Julian" <juliangoodsell@>
>> >> To: <amibroker@xxxxxxxxxxxxxxx>
>> >> Sent: Tuesday, July 14, 2009 12:18 PM
>> >> Subject: [amibroker] Re: Per Chart Refresh Rates
>> >>
>> >>
>> >> > Ouch! What a killjoy. :)
>> >> >
>> >> > That's fair enough from your point of view Tomasz, but this is a user forum, and the mulling over of ideas whether ignorant,
>> >> > uneducated or completely missing the point is all fair game.
>> >> >
>> >> > I'm well aware of the limited (probably zero) impact of these forum posts in relation to your actual development of AB, but
>> >> > posting them gets a lot of ideas out and solves a lot of problems in itself. I've answered heaps of my own questions, just
>> >> > by
>> >> > writing posts, many of which I never need to end up sending, and which in hindsight were foolish. Of course there's always
>> >> > some
>> >> > that get through the filter. :)
>> >> >
>> >> > There are innumerable posts on this forum from beginners and non programmers that I think are stupid, but I don't bother
>> >> > writing
>> >> > to let them know!
>> >> >
>> >> > So my advice is to stick to development and leave the forum nonsense to us. :)
>> >> >
>> >> > Tongue in cheek,
>> >> > Jules.
>> >> >
>> >> > --- In amibroker@xxxxxxxxxxxxxxx, "Tomasz Janeczko" <groups@> wrote:
>> >> >>
>> >> >> Hello,
>> >> >>
>> >> >> I am sorry to say this but this thread is just waste of time.
>> >> >> You may discuss things to death yet it has zero result in terms of program itself.
>> >> >> Naive views/opinions/beliefs from most participants of this thread are pretty much do not have any impact on development of
>> >> >> AmiBroker
>> >> >> simply because development plans are made many years ahead and features you are discussing now were planned 3 years ago
>> >> >> long
>> >> >> before
>> >> >> you knew AmiBroker exists. Moreover they are on the Feedback Center for years already (if somebody bother to check already
>> >> >> submitted things).
>> >> >> In contrast to cheap forum talk, the program development does not occur overnight. If you think that you will
>> >> >> talk for a month about some feature and it will arrive just because you talked a lot you are wrong.
>> >> >> There are zillions of things (half of them are not technical at all) that decide when and what way given thing is
>> >> >> implemented
>> >> >> and you are not aware of 90% of them.
>> >> >> So my advice is to stick to trading and leave the development to me.
>> >> >>
>> >> >> Best regards,
>> >> >> Tomasz Janeczko
>> >> >> amibroker.com
>> >> >> ----- Original Message -----
>> >> >> From: "brian_z111" <brian_z111@>
>> >> >> To: <amibroker@xxxxxxxxxxxxxxx>
>> >> >> Sent: Tuesday, July 14, 2009 5:12 AM
>> >> >> Subject: [amibroker] Re: Per Chart Refresh Rates
>> >> >>
>> >> >>
>> >> >> > The intention of the mother thread,"Data and PlugIn Speed", was to focus on AB's RT Performance, as opposed to its
>> >> >> > capabilities
>> >> >> > as
>> >> >> > a Backtesting Engine.
>> >> >> >
>> >> >> > For me this was an educational post and IMO the discussion has progressed nicely, across threads, with contrasting
>> >> >> > emphasis
>> >> >> > on
>> >> >> > speculative ideas, on one hand, and hard-nosed critique, accompanied by factual observations, on the other ... it is
>> >> >> > quite
>> >> >> > OK
>> >> >> > with
>> >> >> > me if others see the topics in a different way. or pursue other objectives/sub-objectives within them.
>> >> >> >
>> >> >> > To me it was always just a discussion, and not intended to be specifically critical of AB, or Tomasz, while at the
>> >> >> > sametime
>> >> >> > being
>> >> >> > pertinent enough to have value.
>> >> >> >
>> >> >> > IMO opinion using the forum as a sounding board, which provides users with the opportunity to sound off, pool our factual
>> >> >> > evidence
>> >> >> > and make critical assessents, prior to filing formal suggestions, is the best model for introducing progressive ideas
>> >> >> > that
>> >> >> > we
>> >> >> > have.
>> >> >> >
>> >> >> > (As a rule of thumb, we need to sound off on them several times before they start to sound reasonable to the majority).
>> >> >> >
>> >> >> > Keep in mind that only a fraction of the discussion will end up as a formal suggestion and that only a small % of filed
>> >> >> > suggestions will ever be implemented (especially in their original format).
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > Re RT Performance versus Backtesting Performance:
>> >> >> >
>> >> >> > Irrespective of what AB's BT can, or can not, do, the reality is, that for one reason or another, many of us do use it as
>> >> >> > dual
>> >> >> > software i.e. we do use AB as both a BT and trading platform software.
>> >> >> >
>> >> >> > Note that Janhaus said that he does not, and will not, use AB for high frequency trading, however, his objectives and
>> >> >> > situation
>> >> >> > (budget/ skills/hardware) are most likely unique compared to the AB user norm.
>> >> >> >
>> >> >> >
>> >> >> > From the discussion, so far, it seems that RT users:
>> >> >> >
>> >> >> > - want a trading platform type window with different behaviour to the other windows
>> >> >> > - use a dedicated machine for RT trading (or close all other programs while RT trading)
>> >> >> > - if they want to run extras, while running AB in RT mode the preference would be for additional monitors (go MS, go!)
>> >> >> > - use of machines with MCP's is standard (number of cores vary!) ... multicore is now standard for midrange off the shelf
>> >> >> > desktops?
>> >> >> > - they are prepared to buy machines, use OS etc that are particularly suited to AB use
>> >> >> > - consider that CPU useage is a critical issue ... consequently they want control over GDI workflow and CPU workflow
>> >> >> > - they are well informed about performance issues and typically limit indicator code and symbols traded as a trade off to
>> >> >> > gain
>> >> >> > CPU
>> >> >> > time to drive their 'trading platform' processes.
>> >> >> > - they are well informed about and want control over the amount of data processed i.e. they want execution flow control
>> >> >> > - they don't want to have to reference AA ... this is seen as being irrelavent when RT trading (either they are correct
>> >> >> > or
>> >> >> > some
>> >> >> > intense education is required to change this view).
>> >> >> >
>> >> >> >
>> >> >> > Speculating further, without any social or practical constraints in place (in order to learn some more or perhaps unearth
>> >> >> > some
>> >> >> > new
>> >> >> > issues or possibilities):
>> >> >> >
>> >> >> > - spread trading is the most extreme trading that we could consider (one person in this forum has already indicated that
>> >> >> > this
>> >> >> > is a
>> >> >> > strategy they are following, albeit not with AB as the software)
>> >> >> > - bid/ask and tick arrival can be considered micro-events, compared to compressed data e.g sec or minute bars etc.
>> >> >> > - microevents are dynamic, in time, and therefore need to be handled dynamically (indicators might need to be dynamic and
>> >> >> > not
>> >> >> > use
>> >> >> > any lookback data at all?)
>> >> >> > - it isn't practical for me (at this stage) because MarketMarkets play the spread without any frictional costs and they
>> >> >> > are
>> >> >> > sitting on top of the markets with highspeed gear (compared to myself only)
>> >> >> > - it might not ever be practical for the majority of traders to trade microevents OR trade them via AB .... however, like
>> >> >> > AB/Tomasz, I want to gather some evidence from real world testing, to find out for myself, and not rely on others beliefs
>> >> >> > about
>> >> >> > whether it is viable or not.
>> >> >> >
>> >> >> >
>> >> >> > Hypothetically to BT bid/ask scenarios:
>> >> >> >
>> >> >> > - bid/ask data without volume at the bid ask is of lessor value therefore to Backtest some bid/ask indicators I will need
>> >> >> > a
>> >> >> > BT
>> >> >> > with fields/functions that accommodate bid/ask and volume at the bid/ask at the least (full market depth history would be
>> >> >> > required
>> >> >> > to fully test all possible strategies)
>> >> >> > - possibly historical bid/ask data could be collected, by my software, when I am not actively enaged in RT trading OR
>> >> >> > perhaps I
>> >> >> > could buy some historical data OR alternatively I could rely on live paper trading, using only a small number of recent
>> >> >> > bid/asks
>> >> >> > etc and then only save the tradeSeries/calculated indicators for historical reference
>> >> >> > - in any case, leaving aside the issues of collecting/managing the extreme amount of bid/ask data generated in a single
>> >> >> > days
>> >> >> > trading and assuming that testing has been managed somehow and that I have a valid bid/ask system I want to implement.
>> >> >> >
>> >> >> > (Perhaps that aspect requires a separate thread).
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > Hypothetically for RT spread type trading:
>> >> >> >
>> >> >> > - I would need the arrival of the a new bid/ask to be an actionable event ... down to the time limits of processing etc
>> >> >> > where
>> >> >> > execution would revert to minimum ontime basis if the number of bid/asks that arrive exceeds processing capabilities i.e.
>> >> >> > automatically execution of the bid/ask calcs would have to resort to a time absis in extreme high volume?
>> >> >> >
>> >> >> > - I would not want to see every 'behind the scene' bid/ask calc (is it likely that the MarketMakers, who set the spread,
>> >> >> > are
>> >> >> > visually looking at every incoming bid/ask OR would they algorithmically make/take the bid/asks and only PHYSICALLY watch
>> >> >> > a
>> >> >> > summary of the process instead?) .... I assume that in order to play this game I could physically look at every event
>> >> >> > when
>> >> >> > looking
>> >> >> > at historical data in the BT but that for RT trading I would have to handover to my faster AT computer when in trading
>> >> >> > mode.
>> >> >> >
>> >> >> > - so, I would elect to AT the high frequency bid/ask indicators and only render actual trades entered, or orders placed
>> >> >> > etc,
>> >> >> > in
>> >> >> > a
>> >> >> > window that needs to be refreshed i.e. I would only physically watch timed reports on my key performance indicators
>> >> >> > /trouble
>> >> >> > shooting status etc.
>> >> >> >
>> >> >> >
>> >> >> > Hypothetically .....what would I require of my software to be able to trade the spread:
>> >> >> >
>> >> >> >
>> >> >> > (... thinking as a layperson ... first pass/draft version only)
>> >> >> >
>> >> >> >
>> >> >> > - everything would have to be optimized to extreme levels to achieve this extreme performance
>> >> >> > - I would need finer control of what constitutes an event e.g. arrival of a bid/ask or a tick is far more important than
>> >> >> > user
>> >> >> > action e.g scrolling, so new bid/ask or tick quotes would need to be recorded as an actionable event in the fastest
>> >> >> > possible
>> >> >> > way
>> >> >> > - I would need bid/ask calculations threaded out (almost certainly to another core?) and worked in the background (no
>> >> >> > visual
>> >> >> > reporting of most of this)
>> >> >> > - I would need a 'trading platform' type window, or windows, to provide me with the absolute bare min of updated reports
>> >> >> > from
>> >> >> > the
>> >> >> > algorithmic trading that is going on in the background
>> >> >> >
>> >> >> > (I would need the training and mindset to go with this style of trading .... it is just like the difference in flying a
>> >> >> > high
>> >> >> > performance aircraft, with only virtual feedback available, and flying a hobby aircraft by looking out the window).
>> >> >> >
>> >> >> > - I would have to forgo 'historical saving' of bid/ask data .. even data used on the fly might have to be progressively
>> >> >> > dumped
>> >> >> > as
>> >> >> > new data comes in (challenging to find ways to keep it all for the session if we want to do what if checks at the end of
>> >> >> > the
>> >> >> > day
>> >> >> > ... unless of course MCP somehow 'saves the day' in this regard).
>> >> >> >
>> >> >> > - I would need control over when a particular window refreshes and what drives the refresh e.g. refresh actions would
>> >> >> > need
>> >> >> > to
>> >> >> > be
>> >> >> > parameter driven .... by default all parameters would be included (as in AB at present) but the user would elect what
>> >> >> > refresh
>> >> >> > actions to turn off for any particular chart (all turned off,except for slow timed refresh would == something similar to
>> >> >> > commentary? ... it would just give us a, say, 10 sec update on the score == W/L, PayOffratio, open trades, net gain
>> >> >> > etc)......
>> >> >> > in
>> >> >> > effect, a window with most actions/events disabled would function just like a static graphic (the keypoint is that users
>> >> >> > should
>> >> >> > be
>> >> >> > able to define this, or graduations of it, for themselves).
>> >> >> >
>> >> >> > - I would need fine grain/extreme control over how much data to process at any time/for any event.
>> >> >> >
>> >> >> >
>> >> >> > Realistically:
>> >> >> >
>> >> >> > - can AB achieve this?
>> >> >> > - is it desireable for AB to achieve this?
>> >> >> > - should AB keep its focus on being a cutting edge BackTesting engine, with some secondary RT charting that is only
>> >> >> > intended
>> >> >> > to
>> >> >> > supplement design and testing efforts, and leave RT high frequency trading to other software?
>> >> >> > - at the least, shouldn't AB allow us to somehow create an extreme event database and do our testing within AB ... and do
>> >> >> > this
>> >> >> > with off the shelf features, so that it is accessable to all?
>> >> >> > - perhaps thinking about how AB could hyptothetically trade microevents, in RT, will lead to some realisitic options that
>> >> >> > will
>> >> >> > end
>> >> >> > up being implemented by AB, for use at subsecond timeframes (not necessarily bid/ask trading).
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > KEYWORDS
>> >> >> >
>> >> >> > OPTIMAL RT PERFORMANCE
>> >> >> >
>> >> >> > --- In amibroker@xxxxxxxxxxxxxxx, "brian_z111" <brian_z111@> wrote:
>> >> >> >>
>> >> >> >> > I just believe you'll get better support for what you're asking >within the realm of tick by tick trading.
>> >> >> >>
>> >> >> >> I agree that the issue is best considered in the context of bid/ask OR tick trading ... hypothetically considering those
>> >> >> >> propositions is where we can learn the most about where we are, where we would like to go and whether, or not, we can
>> >> >> >> realisitically expect to get to any of those places (more on this in another post).
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> > May be Tomasz will implement it as it is for you, best of luck.
>> >> >> >>
>> >> >> >> IMO the arguments put forward by Julian, and supported by Dennis and Yofa, are compelling i.e.
>> >> >> >>
>> >> >> >> it is not an issue of scaling up, via application of new MS GDI features but rather one of taking the load off the GDI
>> >> >> >> by
>> >> >> >> removing unnecessary graphic rendering from the queue (some people seemed to mis-read Julians suggestion and kept going
>> >> >> >> back
>> >> >> >> to
>> >> >> >> the GDI multithreading argument ... bottlenecking at the GDI is the argument that makes Julians case, rather than breaks
>> >> >> >> it!)
>> >> >> >>
>> >> >> >> The second compelling argument, made by the proactive group, is that threading out background tasks, calculations etc
>> >> >> >> from
>> >> >> >> graphic rendering tasks can lead to RT improvement.
>> >> >> >>
>> >> >> >> I accept this generic argument (in fact I naively guessed at it myself a way back at the MultiCoreProcessing
>> >> >> >> discussions)
>> >> >> >> ....
>> >> >> >> what I am not sure about is how it could apply in specific cases e.g. on a particular machine, where machines can have
>> >> >> >> different
>> >> >> >> OS and cores OR within AB in general, where the priority of subtasks could be user defined.
>> >> >> >>
>> >> >> >> Against this you posted the third most telling point of the discussion so far (in the top three points somewhere) when
>> >> >> >> you
>> >> >> >> highlighted the fact that AB only stamps bars down to a resolution of 5 secs ... I agree all RT performance theorising
>> >> >> >> etc
>> >> >> >> stops
>> >> >> >> at that point, like a car hitting a 10ft thick concrete wall.
>> >> >> >>
>> >> >> >> At the end of the day, only Tomasz can make structural changes while we are left with the power to chose from the cards
>> >> >> >> we
>> >> >> >> are
>> >> >> >> holding in our hands.
>> >> >> >>
>> >> >> >> >BTW with a few lines of C/C++ using windows timer you can implement >your own suppressedrefresh function which will do
>> >> >> >> >exactly
>> >> >> >> >what you >want.
>> >> >> >>
>> >> >> >> Sounds like an idea worthy of further investigation.
>> >> >> >> Probably a bridge to far for me at this stage ... maybe in a year or two.
>> >> >> >> In the meantime the discussion on how to bring this to the people, via AB features, is a good one.
>> >> >> >>
>> >> >> >> Thanks for your good pragmatic contributions.
>> >> >> >>
>> >> >> >> --- In amibroker@xxxxxxxxxxxxxxx, "Paul Ho" <paul.tsho@> wrote:
>> >> >> >> >
>> >> >> >> > I just believe you'll get better support for what you're asking within the realm of tick by tick trading. May be
>> >> >> >> > Tomasz
>> >> >> >> > will
>> >> >> >> > implement it as it is for you, best of luck. BTW with a few lines of C/C++ using windows timer you can implement your
>> >> >> >> > own
>> >> >> >> > suppressedrefresh function which will do exactly what you want.
>> >> >> >> >
>> >> >> >> > --- In amibroker@xxxxxxxxxxxxxxx, "Julian" <juliangoodsell@> wrote:
>> >> >> >> > >
>> >> >> >> > > Yes, I partially agree with you Paul,
>> >> >> >> > >
>> >> >> >> > > however just because some traders might see a feature as unnecessary and can't see a use for it, doesn't make it so
>> >> >> >> > > or
>> >> >> >> > > mean
>> >> >> >> > > there isn't one. GetRTData and automatic trade entries are an example where sub-second updates could be useful.
>> >> >> >> > >
>> >> >> >> > > The fact that Tomasz has actually implemented a per tick update option means it must have been useful to some,
>> >> >> >> > > unless
>> >> >> >> > > he
>> >> >> >> > > did
>> >> >> >> > > it for fun. :) The problem is simply that this resolution is not available via requestTimedRefresh.
>> >> >> >> > >
>> >> >> >> > > Whether this feature is only useful to a minority of traders or not, it's such a simple (supposedly) fix, for a
>> >> >> >> > > feature
>> >> >> >> > > that
>> >> >> >> > > is already supported, but is hindered in practice.
>> >> >> >> > >
>> >> >> >> > > Regards,
>> >> >> >> > > Julian.
>> >> >> >> > >
>> >> >> >> > > --- In amibroker@xxxxxxxxxxxxxxx, "Paul Ho" <paul.tsho@> wrote:
>> >> >> >> > > >
>> >> >> >> > > > As long as the restiction on the resolution of timestamping of price data is set at 5 sec. There is no point in
>> >> >> >> > > > trying
>> >> >> >> > > > to
>> >> >> >> > > > RT trade at tick level. As the requirement of unique time stamp is waived in storing tick data. tick database
>> >> >> >> > > > often
>> >> >> >> > > > gets
>> >> >> >> > > > corrupted, ie., later db records can have older time stamp. And together without knowing the exact timing of these
>> >> >> >> > > > ticks
>> >> >> >> > > > coming in. I dont believe there is anyone who is willing to trade with REAL MONEY at tick level.
>> >> >> >> > > > From a practical standpoint, I have never found this refresh rate striction difficult to live with. A resolution
>> >> >> >> > > > of 1
>> >> >> >> > > > second is plenty fast enough for me, even for trading futures.
>> >> >> >> > > > I think Tomasz is thinking about rehashing the underlining db structure. Along with changing Volume to a floating
>> >> >> >> > > > point
>> >> >> >> > > > number. if he would consider expanding his PackDate to more than 4 bytes. He can then have a timestamp resolution
>> >> >> >> > > > of
>> >> >> >> > > > a
>> >> >> >> > > > fraction of a second. Then any request to enhance tick trading would make more sense. In the meantime. there isnt
>> >> >> >> > > > much
>> >> >> >> > > > point in trying to get a faster refresh rate than 1 second IMHO.
>> >> >> >> > > >
>> >> >> >> > > > amibroker@xxxxxxxxxxxxxxx, "Julian" <juliangoodsell@> wrote:
>> >> >> >> > > > >
>> >> >> >> > > > > Yes Paul,
>> >> >> >> > > > >
>> >> >> >> > > > > the crux is that requestTimedRefresh only has a 1 second resolution, whereas in the preferences you can set it
>> >> >> >> > > > > to 0
>> >> >> >> > > > > for
>> >> >> >> > > > > per tick updates, or as fast as your charts permit.
>> >> >> >> > > > >
>> >> >> >> > > > > What I'm requesting only applies to the instance where you have it set to 0 in the preferences.
>> >> >> >> > > > >
>> >> >> >> > > > > Regards,
>> >> >> >> > > > > Julian.
>> >> >> >> > > > >
>> >> >> >> > > > > --- In amibroker@xxxxxxxxxxxxxxx, "Paul Ho" <paul.tsho@> wrote:
>> >> >> >> > > > > >
>> >> >> >> > > > > > Julian
>> >> >> >> > > > > > It does, but only if the refresh time interval is >= 10 seconds as well.
>> >> >> >> > > > > > I do that all the time with my RT trading. I have trading logic that is updated every 1 sec, and querying and
>> >> >> >> > > > > > displaying of my positions as a separate chart, updating every 10 seconds.
>> >> >> >> > > > > > If you put now() in your chart title, you can see how often your chart is being refreshed.
>> >> >> >> > > > > >
>> >> >> >> > > > > > --- In amibroker@xxxxxxxxxxxxxxx, "Julian" <juliangoodsell@> wrote:
>> >> >> >> > > > > > >
>> >> >> >> > > > > > > Paul,
>> >> >> >> > > > > > >
>> >> >> >> > > > > > > the problem with requestTimedRefresh is that it doesn't remove that chart from the standard update queue.
>> >> >> >> > > > > > > If I specify requestTimedRefresh(10), that chart is still going to be updated along with every other chart
>> >> >> >> > > > > > > on
>> >> >> >> > > > > > > every
>> >> >> >> > > > > > > standard refresh, perhaps once a second, which is a waste of cpu time.
>> >> >> >> > > > > > >
>> >> >> >> > > > > > > What I want is for that chart to only update every 10 seconds so that other charts can be updated more
>> >> >> >> > > > > > > quickly.
>> >> >> >> > > > > > >
>> >> >> >> > > > > > > Regards,
>> >> >> >> > > > > > > Julian.
>> >> >> >> > > > > > >
>> >> >> >> > > > > > > --- In amibroker@xxxxxxxxxxxxxxx, "Paul Ho" <paul.tsho@> wrote:
>> >> >> >> > > > > > > >
>> >> >> >> > > > > > > > I'm not sure what you're trying to do.
>> >> >> >> > > > > > > > It is already possible to specify how often to update charts individually. The refresh rate in preference
>> >> >> >> > > > > > > > set
>> >> >> >> > > > > > > > the
>> >> >> >> > > > > > > > slowest rate and the default refresh rate. Individual chart can be refreshed at a rate set by
>> >> >> >> > > > > > > > requestTimedrefresh(). the only difference between what you want (I guess ?) and what AB is doing seems to
>> >> >> >> > > > > > > > be
>> >> >> >> > > > > > > > one
>> >> >> >> > > > > > > > of the following
>> >> >> >> > > > > > > > 1. requestedtimedrefresh does not guarantee refresh rate
>> >> >> >> > > > > > > > 2. not possible to refresh more frequently than 1 second.
>> >> >> >> > > > > > > >
>> >> >> >> > > > > > > > Traditionally, A tick is defined as a minimum move in price that is possible in an instrument. In AB, I
>> >> >> >> > > > > > > > gather a
>> >> >> >> > > > > > > > tick is both defined as a course of sale as well as a 5 seconds interval,ie. 12 ticks a minute. So I'm not
>> >> >> >> > > > > > > > sure
>> >> >> >> > > > > > > > what you mean by rendering every tick. But if you want to render you charts for every new course of sale,
>> >> >> >> > > > > > > > then
>> >> >> >> > > > > > > > it
>> >> >> >> > > > > > > > is more possible. Is that what you want?
>> >> >> >> > > > > > > >
>> >> >> >> > > > > > > > --- In amibroker@xxxxxxxxxxxxxxx, "Julian" <juliangoodsell@> wrote:
>> >> >> >> > > > > > > > >
>> >> >> >> > > > > > > > > Hi Tomasz,
>> >> >> >> > > > > > > > >
>> >> >> >> > > > > > > > > just to be clear from my side, as this thread has veered off course a little, I'm NOT suggesting running
>> >> >> >> > > > > > > > > afl
>> >> >> >> > > > > > > > > scripts without a render, or threading out the afl processing from the GDI rendering.
>> >> >> >> > > > > > > > > I'm NOT suggesting any changes to the current architecture.
>> >> >> >> > > > > > > > >
>> >> >> >> > > > > > > > > I'm asking for the ability to set refresh rates per chart, for which the functionality already seems to
>> >> >> >> > > > > > > > > be
>> >> >> >> > > > > > > > > there.
>> >> >> >> > > > > > > > > Running indicator calculations without rendering is a waste of cpu time, and so is rendering charts that
>> >> >> >> > > > > > > > > don't
>> >> >> >> > > > > > > > > need to be.
>> >> >> >> > > > > > > > > If I have a chart that only needs to be updated every minute, there's no point in AB trying to render it
>> >> >> >> > > > > > > > > on
>> >> >> >> > > > > > > > > every
>> >> >> >> > > > > > > > > tick update.
>> >> >> >> > > > > > > > >
>> >> >> >> > > > > > > > > Allowing us to specify at what intervals we want individual charts to update, would save countless
>> >> >> >> > > > > > > > > wasted
>> >> >> >> > > > > > > > > cpu
>> >> >> >> > > > > > > > > time.
>> >> >> >> > > > > > > > >
>> >> >> >> > > > > > > > > Regards,
>> >> >> >> > > > > > > > > Julian.
>> >> >> >> > > > > > > > >
>> >> >> >> > > > > > > > > --- In amibroker@xxxxxxxxxxxxxxx, "Tomasz Janeczko" <groups@> wrote:
>> >> >> >> > > > > > > > > >
>> >> >> >> > > > > > > > > > Hello,
>> >> >> >> > > > > > > > > >
>> >> >> >> > > > > > > > > > There is no sense in doing indicator calculation when this calculation
>> >> >> >> > > > > > > > > > does not lead to actual rendering. That would be waste of CPU.
>> >> >> >> > > > > > > > > > The purpose of doing indicator calculation is to actually display it (refresh it).
>> >> >> >> > > > > > > > > > Indicators formulas are here to display something.
>> >> >> >> > > > > > > > > >
>> >> >> >> > > > > > > > > > If you want code that does not display anything, you should run it as
>> >> >> >> > > > > > > > > > automatic-analysis (scan/exploration) code.
>> >> >> >> > > > > > > > > >
>> >> >> >> > > > > > > > > > Also AFL formula execution is often much faster than final GDI output,
>> >> >> >> > > > > > > > > > therefore even if AFL formula was executed in parallel, it would still
>> >> >> >> > > > > > > > > > face GDI contention because of Windows GDI system-wide lock.
>> >> >> >> > > > > > > > > >
>> >> >> >> > > > > > > > > > Only on Windows 7 this system-wide GDI lock is removed and only
>> >> >> >> > > > > > > > > > there you could see graphic performance scaling
>> >> >> >> > > > > > > > > >
>> >> >> >> > > > > > > > > > Again, read the entire article:
>> >> >> >> > > > > > > > > > http://blogs.msdn.com/e7/archive/2009/04/25/engineering-windows-7-for-graphics-performance.aspx
>> >> >> >> > > > > > > > > >
>> >> >> >> > > > > > > > > > Especially figure 4 GDI Concurrency and Scalability
>> >> >> >> > > > > > > > > > - as you can see in any pre-Win7 systems, GDI does not scale *at all*
>> >> >> >> > > > > > > > > > with adding threads.
>> >> >> >> > > > > > > > > >
>> >> >> >> > > > > > > > > > I can ensure you that I have actually *timed* many scenarios
>> >> >> >> > > > > > > > > > and what I say is based on actual measurement and not on somebody's "belief".
>> >> >> >> > > > > > > > > > That was one of the reasons I did not use GDI+ ("improvement" suggested by somebody on this list)
>> >> >> >> > > > > > > > > > because real-world test revealed that it is 6 times slower than normal GDI.
>> >> >> >> > > > > > > > > > Microsoft admitted that by the way in their recent demonstration on PDC (prof. dev. conference).
>> >> >> >> > > > > > > > > >
>> >> >> >> > > > > > > > > > So, all decisions regarding development of AmiBroker are not based on beliefs but on
>> >> >> >> > > > > > > > > > hard code profiling evidence.
>> >> >> >> > > > > > > > > >
>> >> >> >> > > > > > > > > > Best regards,
>> >> >> >> > > > > > > > > > Tomasz Janeczko
>> >> >> >> > > > > > > > > > amibroker.com
>> >> >> >> > > > > > > > > > ----- Original Message -----
>> >> >> >> > > > > > > > > > From: "Yofa" <jtoth100@>
>> >> >> >> > > > > > > > > > To: <amibroker@xxxxxxxxxxxxxxx>
>> >> >> >> > > > > > > > > > Sent: Sunday, July 12, 2009 9:47 PM
>> >> >> >> > > > > > > > > > Subject: Re: [amibroker] Per Chart Refresh Rates
>> >> >> >> > > > > > > > > >
>> >> >> >> > > > > > > > > >
>> >> >> >> > > > > > > > > > > Hi Thomas,
>> >> >> >> > > > > > > > > > >
>> >> >> >> > > > > > > > > > >> Tomasz wrote in the "Data And PlugIn Speed" thread
>> >> >> >> > > > > > > > > > >>I may add that the concept of independent rendering from multiple threads
>> >> >> >> > > > > > > > > > >>although attractive from first look, it inevitably hits the wall of GDI
>> >> >> >> > > > > > > > > > >>which in all current versions of Windows has
>> >> >> >> > > > > > > > > > >> single system-wide exclusive global lock, which means that only ONE thread
>> >> >> >> > > > > > > > > > >> can actually render at one time. This means that adding threads does not
>> >> >> >> > > > > > > > > > >> give you better performance.
>> >> >> >> > > > > > > > > > >
>> >> >> >> > > > > > > > > > >>The truth is that all current releases of Windows are not particularly
>> >> >> >> > > > > > > > > > >>suited for multi-core/multi-CPU
>> >> >> >> > > > > > > > > > >>but good news is that Microsoft apparently have given these limitations
>> >> >> >> > > > > > > > > > >>some thought and
>> >> >> >> > > > > > > > > > >>many of them are removed in Windows 7.
>> >> >> >> > > > > > > > > > >
>> >> >> >> > > > > > > > > > > That is true for rendering only! (Apps main thread is allowed to write the
>> >> >> >> > > > > > > > > > > GDI device. So rendering is limited to a single thread.)
>> >> >> >> > > > > > > > > > >
>> >> >> >> > > > > > > > > > > But indicator calculation (and trading logic) could get executed by any
>> >> >> >> > > > > > > > > > > threads. Am I right? So doing the calculation on a background thread than
>> >> >> >> > > > > > > > > > > doing chart painting with the "main" thread would increase processor usage
>> >> >> >> > > > > > > > > > > and increase chart refresh reate? (I guess we all have dual and quad core
>> >> >> >> > > > > > > > > > > CPUs...)
>> >> >> >> > > > > > > > > > >
>> >> >> >> > > > > > > > > > > How about separating "calculation refresh rate" and "chart refresh rate"? So
>> >> >> >> > > > > > > > > > > I could request my panel to execute 3 times per sec without chart repaint
>> >> >> >> > > > > > > > > > > (this could be executed by any threads) and refresh visible chart in every
>> >> >> >> > > > > > > > > > > 3rd sec (this requires rendering, so calculation is done by a background
>> >> >> >> > > > > > > > > > > thread, and painting is done by main thread))?
>> >> >> >> > > > > > > > > > >
>> >> >> >> > > > > > > > > > > Any thoughts?
>> >> >> >> > > > > > > > > > >
>> >> >> >> > > > > > > > > > > Regards,
>> >> >> >> > > > > > > > > > >
>> >> >> >> > > > > > > > > > > Y
>> >> >> >> > > > > > > > > > >
>> >> >> >> > > > > > > > > > > (I know it is not doable in a day work, but I guess all short
>> >> >> >> > > > > > > > > > > term/daytraders are having trouble bacause of refresh limitations.)
>> >> >> >> > > > > > > > > > >
>> >> >> >> > > > > > > > > > >
>> >> >> >> > > > > > > > > > > --------------------------------------------------
>> >> >> >> > > > > > > > > > > From: "Julian" <juliangoodsell@>
>> >> >> >> > > > > > > > > > > Sent: Sunday, July 12, 2009 8:14 PM
>> >> >> >> > > > > > > > > > > To: <amibroker@xxxxxxxxxxxxxxx>
>> >> >> >> > > > > > > > > > > Subject: [amibroker] Per Chart Refresh Rates
>> >> >> >> > > > > > > > > > >
>> >> >> >> > > > > > > > > > >> Hi Tomasz, I thought I'd start a new thread on this topic as I think it's
>> >> >> >> > > > > > > > > > >> an interesting one.
>> >> >> >> > > > > > > > > > >>
>> >> >> >> > > > > > > > > > >> Tomasz wrote in the "Data And PlugIn Speed" thread
>> >> >> >> > > > > > > > > > >>> I may add that the concept of independent rendering from multiple threads
>> >> >> >> > > > > > > > > > >>> although attractive from first look, it inevitably hits the wall of GDI
>> >> >> >> > > > > > > > > > >>> which in all current versions of Windows has
>> >> >> >> > > > > > > > > > >> single system-wide exclusive global lock, which means that only ONE thread
>> >> >> >> > > > > > > > > > >> can actually render at one time. This means that adding threads does not
>> >> >> >> > > > > > > > > > >> give you better performance.
>> >> >> >> > > > > > > > > > >>
>> >> >> >> > > > > > > > > > >> In response to that Tomasz,
>> >> >> >> > > > > > > > > > >> you're referring to performance on the basis of multiple charts being
>> >> >> >> > > > > > > > > > >> rendered per refresh update.
>> >> >> >> > > > > > > > > > >> E.g. If you have ten charts on screen, and they take a total of 2 seconds
>> >> >> >> > > > > > > > > > >> to render, then there's little performance gain to be had by threading
>> >> >> >> > > > > > > > > > >> them because of the GDI lock. That is fine and I get that.
>> >> >> >> > > > > > > > > > >>
>> >> >> >> > > > > > > > > > >> But what I'm referring to is the ability to control which charts render
>> >> >> >> > > > > > > > > > >> when, so that all ten don't have to be updated every refresh.
>> >> >> >> > > > > > > > > > >> The problem is that in real time mode with the refresh interval set to 0
>> >> >> >> > > > > > > > > > >> in the preferences, if I have a tick chart that only takes 10ms to update,
>> >> >> >> > > > > > > > > > >> it's still only going to be rendered every 2 seconds because that's how
>> >> >> >> > > > > > > > > > >> long the other nine charts take to render, even though I don't need them
>> >> >> >> > > > > > > > > > >> to be updated multiple times per second, but maybe only once every 5
>> >> >> >> > > > > > > > > > >> seconds or even every minute.
>> >> >> >> > > > > > > > > > >>
>> >> >> >> > > > > > > > > > >> If we could set refresh rates per chart, then you could have time critical
>> >> >> >> > > > > > > > > > >> tick charts update as fast as possible, and longer timeframe or more time
>> >> >> >> > > > > > > > > > >> expensive/less critical charts only update every 5 seconds or even longer.
>> >> >> >> > > > > > > > > > >>
>> >> >> >> > > > > > > > > > >> By staggering chart updates, traders would have much greater control over
>> >> >> >> > > > > > > > > > >> performance and not waste so much processing power updating charts that
>> >> >> >> > > > > > > > > > >> don't need to be. This would trounce any other kind of performance
>> >> >> >> > > > > > > > > > >> improvement that could be gained by optimizing the rendering engine
>> >> >> >> > > > > > > > > > >> itself, and would require no threading or any real change to the current
>> >> >> >> > > > > > > > > > >> architecture that I can see.
>> >> >> >> > > > > > > > > > >>
>> >> >> >> > > > > > > > > > >> Moreover, it appears this functionality is already in AB, but just that
>> >> >> >> > > > > > > > > > >> there's no way for the user to control it.
>> >> >> >> > > > > > > > > > >> The requestTimedRefresh() function enables you to update only the chart it
>> >> >> >> > > > > > > > > > >> is applied to, so they can obviously be rendered independently of each
>> >> >> >> > > > > > > > > > >> other.
>> >> >> >> > > > > > > > > > >>
>> >> >> >> > > > > > > > > > >> The problem though is that it is not enforceable. If I specify a refresh
>> >> >> >> > > > > > > > > > >> interval of 1 in the preferences, and then requestTimedRefresh(10) on a
>> >> >> >> > > > > > > > > > >> chart, that chart still gets updated every second along with all the
>> >> >> >> > > > > > > > > > >> others, and then once more after ten seconds.
>> >> >> >> > > > > > > > > > >>
>> >> >> >> > > > > > > > > > >> Giving the option to make requestTimedRefresh() enforceable would be one
>> >> >> >> > > > > > > > > > >> way of enabling this functionality. Perhaps add an enforceable parameter
>> >> >> >> > > > > > > > > > >> to the function like:
>> >> >> >> > > > > > > > > > >> requestTimedRefresh(10, onlyvisible=True, enforceable=false).
>> >> >> >> > > > > > > > > > >> Then if I specify requestTimedRefresh(10, true, true), that chart should
>> >> >> >> > > > > > > > > > >> only update every 10 seconds, irrespective of what I've set in the
>> >> >> >> > > > > > > > > > >> preferences.
>> >> >> >> > > > > > > > > > >>
>> >> >> >> > > > > > > > > > >> Would this be as easy to implement as I think it is? If so, I think the
>> >> >> >> > > > > > > > > > >> benefits would be rather large.
>> >> >> >> > > > > > > > > > >>
>> >> >> >> > > > > > > > > > >> Jules.
>> >> >> >> > > > > > > > > > >>
>> >> >> >> > > > > > > > > > >>
>> >> >> >> > > > > > > > > > >>
>> >> >> >> > > > > > > > > > >> ------------------------------------
>> >> >> >> > > > > > > > > > >>
>> >> >> >> > > > > > > > > > >> **** 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
>> >
>> >
>> >
>>
>
>
>
>
> ------------------------------------
>
> **** 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/
|