Traders' Roundtable

I'm glad you like the forum.

If you have Excel, I'd practice using its macro language called VBA (Visual Basic for Application). The Visual Basic application VB 6 is a bit of overkill, unless you already have it.

The base language is actually pretty simple as far as languages go.

The easiest way to learn code is to have examples and then change a few lines at a time to see the effect of the changes. You'll have the full source code to VeriTrader's systems so they'll provide a good starting point.

I've read so much about the limitations traders eventually experience when using the products currently on the market.

I intend to make VeriTrader the one product that proves the exception to this rule. You'll have to make your own judgement once it comes.

I think you'll find you won't need to learn C++, and if you feel a need to after getting VeriTrader, please speak up.

Hi Forum Mgmnt,

I too voted that they all stink, but not so much for reasons related to specific language syntax, but as a result of design decisions made to appeal to the largest market possible. While there is nothing wrong with having a larger market, I haven't been able to understand why the ones written with the more modern languages (which probably excuses TR) must necessarily have such an object "disoriented" design. I believe for maximum system design flexibility, the software object model needs to be relatively flat. By that I mean that the system designer must be able to access individual objects from anywhere within the system logic. This would allow the entry logic to talk to the risk manager or risk manager to talk to portfolio manager etc. and would solve many design problems.

Wealth Lab probably comes closest, but (at least in 2.0) there is still a sharp divide between money management code and trade entry/exit logic and communication is confined mostly as in TR to a limited number of "user variables". I say this as a TS 4.0 user, a Metastock user, a TR user and a Wealth Lab user. Judging by your design you've solved most of this already.

David

p.s. 40 seems like a good age to start another career - like cracking the trading software market wide open. Happy belated birthday.

David,

Thanks for the comments.

I think I know what you are suggesting, but I want to be sure that I don't miss something.

Is the ability to get information about money managment values from your trade entry logic the sort of thing you refer to?

Can you give me a couple of specific examples of something you can't do with the other products that you want to be able to do?

Thanks,

c.f.

P.S. Hmm.... cracking open the trading software market.... hmmm.... that's an interesting idea. I should look into that.

Forum Mgmnt wrote:Can you give me a couple of specific examples of something you can't do with the other products that you want to be able

I think that the entry/exit module should interact dynamically with the position sizing module. If a program figures out all entries and exits first, and only then determines position sizes for all trades, then it is very difficult to code rules which change entry/exit rules because of money management issues, e.g.:

If the current drawdown of the whole portfolio exceeds 10%, then change the entry from a 10-day channel breakout to a 20-day channel breakout.

Regards,
TK

another example:

I am currently using Wealth-lab. But as has been said: an object oriented approach is most flexible. As many I never programmed in that way, yet.
Anyway: Keep on going c.f.. Your projects sounds very interesting and congrats for the great website.

fliesch

1) Filter simultaneous day signals for all markets prior to sizing based on trend strength

2) assign risk percent differently based on type of trade
i.e. 1st unit, strong trend late trend addon, etc.

3) scale out or adjust stop daily based on aggregrate potfolio risk

BondTrader, DrHendricks,

You will have enough information and flexibility to do all the things you outline.

- Forum Mgmnt

Veritrader appears to be interesting.

First, thanks for the great site. Though I seem to have gotten ‘flamed’ as a ‘newbie’ for my unwillingness to post any test results...Perhaps I might give the new 2.0 a try. What's the price tag, what is the ETA, and can I get a pre-order invoice for this so I can pay for it with B-Trade Soft$?

viewtopic.php?t=856&highlight=

viewtopic.php?t=860

I happen to agree with verec, maybe because we both think in Java (?). The libraries and constructs make a HUGE difference for usuability. So I will second what he mentions, and add a few bits ...

Other extremely important aspects are orthogonality, composition, and cannonical form. By orthogonality I mean that tasks, functions, and objects are discrete, sufficiently complete and don't overlap or have side-effects. By composition I mean functions and objects can be combined, like f(x), g(x) -> f(g(x). By cannonical form I mean that combinations are simple and consistent across a wide variety of types.

Composition makes a qualitative difference between TradeStation and Metastock. For instance, EasyLanguage lets you pass a function to a function, but MetaStock does not. That makes writing adaptive indicators difficult in MetaStock, but a snap in EasyLanguage. In EL we simply replace "length" with a function that returns a bounded interval range.

Imagine if this were also true with regard to OHLC quotes. Any quote function could be substituted for actual quotes, and all quote functions could be used on any data series. This includes quote transforms (synthetic data bars), or time compression, or types of quote data (tick, time, volume, range). This is WAY beyond EL, but is a snap when following the same composition and orthogonality rules mentioned.

So, what if the idea is extended portfolios, money management, and other aspects in the trading system? Any function can become a filter atop money management, or the equity curve. Conversely, the function that filters equity curve has the same cannonical form as other functions. This makes the language, libraries and environment consistent, easy to learn, and easy to apply.

I've used these principles in my own trading engine, so I know they are possible to achieve.

The suggestion to ride atop an existing language like C# or Java is an appealing one. I certainly didn't want to invent a new language for trading, and chose to do this. However, the trade-off is always what is possible within the constructs of the language vs. what feels natural in terms of composition. In this regard, widely used OOP languages like C# and Java fall short. Structured language fall even shorter. I'd offer that a natural feel of expression might be more accessible coded in Python, Ruby, or Groovy. Of course, these don't have the wide appeal of more common languages.

It's difficult to strike a good nice balance between ease of use, cannonical composition, and the required language syntax and constructs. One thing that can ease the job of the trader/programmer is using inversion of control (IOC) ... or plug in modules. I think this makes it easier for an end user to extend the system small chunks at a time.

Anyway, just my $0.02. I think these concepts would make an awesome addition to VeriTrader.

Cheers,

Kevin

What do you like about the trading system specific languages you use?
What don't you like?

Any suggestions as we work on the language for VeriTrader 2.0?
c.f.

P.S. If you answer none of the above in the poll, please post your two or three most hated "features".

Hello c.f.

A language script is difficult to learn, and you cannot always understand your logical / language failures. I've been a programmer.

I think you should have pre-programmed area's were you could fill in conditions for the different aspects of a trading system, like you did it in veritrader 1. Every system has an equal structure: entry, how much to risk, stops, exit, etc....

And then I think what is very important is a lot of examples, which a user can "copy and paste, and edit". This will improve his learning curve.

I use fibonacci trader, it is very simple to program a system, it prevents you from programming very difficult code, but sometimes you want to go a little further and you cannot do anything. Missing examples are also a problem. Metastock has a better interface, but is somewhat more complex, tradestation gives more freedom and is more difficult, esignal is completely script oriented and is very hard to learn.

It would be no problem at all, if you knew before that what you want to build is exactly the system, but you don't know.

So what i don't like is:

-scripts
-missing (many) examples

I hope you can do something with it.

Erwin