|
PureBytes Links
Trading Reference Links
|
Dans un courrier daté du 07/02/99 08:53:03 Heure d8iver Pari3 Madrid,
lwright@xxxxxxxxxx a écrit :
> n Sat, 6 Feb 1999 Orphelin@xxxxxxx wrote:
>
> > > Why not an ASCII option for studies? Much more convenient for
*traders*
> > > (as oppposed to solution providers), and no size problems at all.
Same
> as
> > > they had before.
> > >
> > I think thay removed the ASCII format to avoid errors when transferring
>
> What errors? I *still* have ASCII code, in good shape, from the old
> System Writer days, not to mention some ASCII code from old 8080's,
> transferred from 8 inch disks. Tell me about errors....
>
As the code was readable, some users tried to copy only the ASC file directly
to TS directory .
Of course , this produced a major erroe when running TS.
This is impossible with Ela files.
> > also to protect the SC functions from being used and modified without TS
>
> Aaahhhh - the *real* reason comes out, after all -- make it proprietary
> and more difficult for users...
TS = 2399.40 $
SC = 395.00$
Do you see a difference between two numbers above ?
( )Yes
( )No
( ) What means difference?
>
> > > Don't you think it would be nice for *traders* to have a save-as-ASCII
> > > option?
> >
> > Yes and no
> > You can always export to a text edior
>
> Export? -- how? Don't you mean copy and paste, copy and paste, copy and
> paste, copy and paste, one at a time until you get fed up.
>
> *Really* ugly if you have a lot of studies. With the studies from the net,
> etc, I have a library of hundreds.
>
> If they were ASCII, one could do some very nice things. For example, I
> have about 4 Gigs of reference material, in > 20,000 files. If I'm
> looking for, say, "close stop", I can find ALL instances of that phrase in
> the 4 Gigs in only a few seconds, and scan through them very easily. If I
> come upon the code I need, I can easily copy & paste it. *Very* fast, but
> NOT with those awful .ela files.
>
See above.
> Let's bring back ASCII...
>
> > > Why not say how to access an omz? Other data providers say what the
> > > format is, and some even have sample code to access it. Would it not
> be
> > > nice to be able to do this?
> > >
> > They provide some useful information to access the data with their Server
> > API.
>
> Does this mean I can add contracts and data, reset expired contracts,
> add/import data to expired contracts, edit bad ticks with a Access/VB "bad
> tick finder", etc?
Probably, but not with Access ( see further).
>
> > OMZ format changes every major version, so it's not designed to be a
> standard.
>
> Hey - just post the new format on the Omega web site. No problem...
>
I'm a TradeStation user, not the product designer.
> > > For fast storage, of course not, but it would be nice to be able to
> import
> > > ASCII ticks, would it not? And isn't ASCII *the* leader in overall
> > > compatibility?
> >
> > Yes, we need that. An not only for ticks.
>
> Glad you agree...
>
> > You can add new sympbol to the universe ( at your own risks)
>
> This is not the problem...
>
> > scanning bad ticks can be done with the server and the API.
>
> This *is* the problem:
>
> Does this mean I can add contracts and data, reset expired contracts,
> add/import data to expired contracts, edit bad ticks with a Access/VB "bad
> tick finder", etc?
>
> Can I do these with the server and the API?
>
Yes, but not directly with Access or VB
You need to use a C compiler with the API.
Access reads the symbol universe, not the OMZ f or DAT files.
The bad ticks can be modified by developping an application with the API
server, and also import export from ASCII could be considered, at you own
risks.
I know that Bob Brickey has been able to do this ,and we were also
considering this 3 years ago.
Due to the frequent DAT format change and the possibility of an automated tick
filter in a next TS release, we gave up with this development.
PO
|