APL - Using APLX's embedded CandleStick graphics

Author

Using APLX's embedded CandleStick graphics

aleph0

2006-10-23, 7:55 am

1. Does anyone have any experience using the nice CandleStick charts
from MicroAPL's APLX ?
2. Does anyone have any experience in - or code for - hooking in
Real-Time data-feeds into APLX or Dyalog APL ?
3. .. maybe with some examples concerning setting up the interface to
the external feed from within APL ?

Thx in advance !

aleph0

2006-12-05, 6:56 pm

aleph0 wrote:
> 1. Does anyone have any experience using the nice CandleStick charts
> from MicroAPL's APLX ?
> 2. Does anyone have any experience in - or code for - hooking in
> Real-Time data-feeds into APLX or Dyalog APL ?
> 3. .. maybe with some examples concerning setting up the interface to
> the external feed from within APL ?
>
> Thx in advance !

Must I assume that nobody has ever done this ?
Pity !

microapl@microapl.demon.co.uk

2006-12-06, 3:57 am

aleph0 wrote:
>
> Must I assume that nobody has ever done this ?
> Pity !

Yes, we and our clients do have experience with real-time financial
data feeds - however, it's hard to generalise as a lot depends on the
particular feed you want to use, and what you want to do with it.
Contact us at MicroAPL and we'll try to help.

Richard Nabavi
MicroAPL

Marv

2006-12-11, 6:59 pm

microapl@microapl.demon.co.uk wrote:
> aleph0 wrote:
>
> Yes, we and our clients do have experience with real-time financial
> data feeds - however, it's hard to generalise as a lot depends on the
> particular feed you want to use, and what you want to do with it.
> Contact us at MicroAPL and we'll try to help.
>
> Richard Nabavi
> MicroAPL

I'm interested in what's possible in APLX graphics for 2 types of
realtime
streams; financial data and realtime audio. Especially interested in
48khz
audio. I suspect others here might be interested in realtime stream
handling
too, so could you discuss it a bit here?

Thanks,
Marv Smoak

aleph0

2006-12-11, 6:59 pm

My first questions would be:

a) do RTFeed providers (usually) charge extra for allowing one to
hook-in to their feed ?
b) for which RTF-providers have APL hook-ins already been done
c) could someone publish some code as a demo ?

TIA

microapl@microapl.demon.co.uk

2006-12-11, 6:59 pm

OK, I'll try to give a brief overview on the questions raised:.

Marv wrote:
> I'm interested in what's possible in APLX graphics for 2 types of
> realtime
> streams; financial data and realtime audio. Especially interested in
> 48khz
> audio.

aleph0 wrote:
>
> a) do RTFeed providers (usually) charge extra for allowing one to
> hook-in to their feed ?
> b) for which RTF-providers have APL hook-ins already been done
> c) could someone publish some code as a demo ?
>

There are two separate issues here: getting the real-time data into
APL, and how to display real-time data graphically.

On the first point, most providers will have some way of getting the
data into Excel, and that will usually be via a COM interface.
(High-end systems, used on investment bank trading desks, will
typically use more sophisticated and more efficient interfaces, but I
guess we're not talking about that here). If you can get the data into
Excel, you can almost certainly use the same feed to get the data
directly into APLX (you shouldn't normally need Excel itself, just the
documentation on the COM interface). Although the details vary, the
basic mechanism is that you subscribe to a particular set of data, you
specify exactly what you are interested in (stock price of company
XXX), and a COM event will trigger when new data is available.
Alternatively, you might poll the data feed at regular intervals.
Either way it's just a few []WI commands to get the data by reading
properties or calling methods of the COM object which provides the
feed.

As to whether you'll be charged separately for this, some systems may
be totally closed, but I think that most will let you get at the raw
data as part of the package - you'd have to check the commercial terms
on what you are allowed to do with the particular feed.

The other point is to ask whether you really do need real-time data. A
real-time feed giving trading data on heavily-traded stocks will
generate vast amounts of data - many price quotes per second, and more
than a desktop system and ordinary internet links could handle. Often
when people say 'real-time' data they are referring to something much
less onerous than this - for example, bid-offer prices every five
minutes for 100 stocks. That would be much more manageable, and could
be done by polling for the updated information at regular intervals.
You may even be able to get this kind of information from a
free-of-charge website, using the []WI HTTPClient and parsing the HTML
page you get back . However, these free feeds are likely to be not
quite up to date (typically 15 minutes delay for stock-market data) -
which is OK for analysis purposes, but not for short-term trading.

On the question of graphing the data, it depends on whether you want
the graph to update in real-time, or whether you just want to display a
graph of historic prices (where 'historic' in this context might be
only a few hours). For the latter case, you can use the APLX built-in
charts very easily - in the simplest case, just give it the data and
set the graph type, and it will do everything for you. More
realistically, you'd probably want to set the scale and perhaps overlay
some statistical trend lines or comparisons with an index. The
SAMPLESCHART workspace in the APLX installation (or the APLX demo
download) shows how to do this, including a sample for
High-Low-Open-Close and Candlestick graphs for a stock price.

For updating in real time, the trick is to set the time-axis scale in
advance, so that as extra data comes in, it is drawn at the end of the
current graph rather than redrawing the existing data. Depending on
the frequency with which new data comes in, you can reset the scale
every few minutes so that the data effectively scrolls. If I get a
chance over the next few days, I'll try to put a sample on our website.

Richard Nabavi
MicroAPL

aleph0

2006-12-11, 6:59 pm

Thanks Richard for your infos.

<< A real-time feed giving trading data on heavily-traded stocks will
generate vast amounts of data - many price quotes per second, and more
than a desktop system and ordinary internet links could handle. >>

I thoroughly recommend trying MedVed's RT QuoteTracker.
It's written in Java AFAIK and is free !
http://www.quotetracker.com/

I have ca. 30 RTFeed stocks under observation running ca. 5 to 10
intraday RT-graphs with many sophisticated indicators/calculations etc.
- with no problem at all !

( BTW : I'm interesting in the APLX Charting tools for being able to
hook-in the RTFeed and doing my own RT-graphs on for example MoneyFlow
- but my own method of MF, rather than Chaikin for example. )

If the above mentioned Java tool can handle this with no problem, I
cannot imagine that APLX would hae any problem with this either !

<< That would be much more manageable, and could be done by polling for
the updated information at regular intervals. >>

Are you saying that "polling" rather than an Event-driven solution is
the way ?
... I can't imagine that an Event-driven solution is not possible ?
TIA

microapl@microapl.demon.co.uk

2006-12-11, 6:59 pm

aleph0 wrote:
>
> I thoroughly recommend trying MedVed's RT QuoteTracker.
> It's written in Java AFAIK and is free !
> http://www.quotetracker.com/
>
>

OK, that's a nice application which does all the data collection for
you. It also has either a socket-based or HTTP-based interface for
getting the data into another application. See
http://www.quotetracker.com/help/qtserver.shtml

The HTTP interface is the easier to use, but either can be used direct
from APLX. I set up a mini-portfolio, which included UK stock Premier
Foods (ticker symbol PFD). It took two lines of APL to get the latest
price info into APL for this stock:

'HTTP' []WI 'New' 'HTTPClient'
'HTTP' []WI 'Get' 'http://127.0.0.1:16239/Req?GetLastQuote(PFD)'

(I've substituted [] for Quad). This returns a three-element nested
vector of errorcode, data type, and the data itself as text. The
interface looks as though it would give you everything you need.

If you use the socket interface, you can also get update events when
some new data comes in.

>
> Are you saying that "polling" rather than an Event-driven solution is
> the way ?
>

No, not necessarily. You can use whichever is more appropriate. But
bear in mind that something like QuoteTracker is itself polling to get
the data, as far as I can see.

Richard

phil chastney

2006-12-13, 4:08 pm

aleph0 wrote:
> My first questions would be:
>
> a) do RTFeed providers (usually) charge extra for allowing one to
> hook-in to their feed ?
> b) for which RTF-providers have APL hook-ins already been done
> c) could someone publish some code as a demo ?

FWIW, I have had a couple of experiences with Reuters feeds

one was in the US, in the 80s, when the Reuters rep told us we were only
allowed to use Reuters terminals -- so, presumably, the idea was that we
should watch these screens, write down the numbers of interest, and key
them into a PC on a separate network

I asked if we could connect a PC instead, via the serial port, and since
the rep didn't understand the question, I got a reply from tech support
saying a PC wouldn't be terminated properly

this seemed possible, so I put in a PC as a pass-through device, with a
Reuters terminal on the other side, being careful to ensure that all
signals were sent through in both directions, and it worked

another time, another place, another Reuters, we needed forward exchange
rates -- Reuters have traditionally shown litte knowledge or interest in
what data their customers want, what format, and how they want to be
able to use it, so TibCo filled the gap -- this was shortly after
Reuters took over TibCo, and the budget was not available to purchase
TibCo's super new interface (whose name completely eludes me), so I
picked up on the old software, and brought it out to an HTTP port on a
Unix box

accessing the HTTP port from APL, across the intranet, was a complete doddle

so, in summary, if you can bring the feed out to a port, hard or soft,
then (a) there is no need to trouble the data provider with details of
how you use it, and (b) it matters not what language you use to access
that port

mind you, forward FX rates are not that volatile, so maybe this approach
won't work for your application . . . /phil

Sponsored Links