stevehopwoodforex.com
https://www.stevehopwoodforex.com/phpBB3/
Print view

An object oriented language for Empty4
https://www.stevehopwoodforex.com/phpBB3/viewtopic.php?t=1393		 Page 4 of 8
Author:  roger-write [ Wed Jan 23, 2013 12:42 pm ]
Post subject:  Re: An object oriented language for Empty4
banzak wrote:
Hi Roger,
so I will start to collect all your posts here an start a manual, I will send you the draft when I'm finished.

Another question: How is the performance eg. in backtests, cause with my latest ea a backtest take me with 90% tick-data about 4 hours for a year.

Regards,
Banzak
Sound great, about the manual. As for performance, basically oq creates raw mql, so it's not bypassing that bottleneck. However, there are other ways around this. One of the class modules I plan to create is something called a TurboTick module. If tied in properly with the details of your code, it will be smart enough to throw out meaningless ticks and vastly turbocharge the performance of backtesting. I've done this sort of thing before and it can boost slow EA's by an order of magnitude when backtesting.
Author:  banzak [ Wed Jan 23, 2013 1:09 pm ]
Post subject:  Re: An object oriented language for Empty4
roger-write wrote: Sound great, about the manual. As for performance, basically oq creates raw mql, so it's not bypassing that bottleneck. However, there are other ways around this. One of the class modules I plan to create is something called a TurboTick module. If tied in properly with the details of your code, it will be smart enough to throw out meaningless ticks and vastly turbocharge the performance of backtesting. I've done this sort of thing before and it can boost slow EA's by an order of magnitude when backtesting.
Ok, then i will start with the manual and to build my ea and come back to you if I need some help. :)

Regards,
Banzak
Author:  roger-write [ Wed Jan 23, 2013 1:39 pm ]
Post subject:  Re: An object oriented language for Empty4
banzak wrote: Ok, then i will start with the manual and to build my ea and come back to you if I need some help. :)

Regards,
Banzak
Sounds good. One thing to keep in mind, you can take your existing .mq4 code right now, and add it to the modules list in the oq build file and it should build your project correctly, whether you ever create a class or not. That would be my suggestion as a first step. Then you can begin to play with creating a class here or there for your project and start to get the feel of it.

Also, a quick side note about troubleshooting error messages you receive from oq. They are either errors that oq is giving you, such as class reference not found, etc. Or they could be errors generated by the Empty4 compiler. These laters ones might be a little obscure and you have to figure out why they occurred. Sometimes it's obvious and sometimes not. If you run into anything you can't figure out, post it here and I'll see if I can help.

Thank you for offering to pull together the info for a manual. That will really help.
Author:  roger-write [ Wed Jan 23, 2013 10:38 pm ]
Post subject:  Re: An object oriented language for Empty4
oq has been updated to v0.96 in the first post with the following changes:

- Managed to reduce the footprint of subclass bindings by a bit

- Added a class name/kind registrar so you can get the class name from the kind or vice versa

- Added support for subclassing a constructor for morphing purposes talked about a couple of posts back. More on this soon.
Author:  roger-write [ Thu Jan 24, 2013 11:17 am ]
Post subject:  Re: An object oriented language for Empty4
A class name is obviously the name of the class, but this name exists as a string within the context of the Empty4 program you are creating. Under standard mql this wouldn't be the case. What I mean is, if you created a function by the name of GetSignal, you couldn't have the user specify a string called "GetSignal" and find your function, could you? But in oq, you can have the user specify the name of a class, and your code can find that class. Well, it can at least find the class kind. A class kind is a unique integer number representing the specific class. If you look at the mql source that oq produces, you will see a bunch of defines at the very beginning that look like this: #define CLASS_MyClass 5.

So ObjectQuotes has a class registry that you can access at any time in your code to get the class name as a string (given the class kind number), or to get the class kind (given the class name). Oq doesn't ask much of the coder to make it go, but in order to make use of this registry, the one thing you will have to do somewhere at the beginning of your code, is make the following call:

Code: Select all

  RegisterClasses();
That's it! Once you have done that, you have access to 2 registry functions as follows:

Code: Select all

  int kind = classkind("MyClass");

  string name = classname(CLASS_MyClass);
Obviously the first returns the kind from the name and the second returns the name from the kind. Incidentally, if you ever want to find out what kind the instance of an object is, you can look at the class property, which is present for all classes containing instance properties or methods. Here's an example of internally using the kind value:

Code: Select all

    if( @class == CLASS_Color )
        <do something>;
Here's an example using it from a static method in the same class:

Code: Select all

    if( :class[id] == CLASS_Color )
        <do something>;
An finally, an example of accessing an object's kind from outside:

Code: Select all

    if( Data:class[id] == CLASS_Color )
        <do something>;
So the question is, why do we need this registry? Why would we ever want to, for example, find a class's kind given its name? In the next post I'll give you a very good reason as we dive into morphing.
Author:  roger-write [ Thu Jan 24, 2013 11:49 am ]
Post subject:  Re: An object oriented language for Empty4
In standard OOP, you don't subclass/inherit constructor methods. But since I'm creating oq, I might as well have it do what I want, right? We don't have to get all puritanical about it. :lol: The language is there to serve the coder, not the other way around.

As long as the superclass constructor and all its subclass constructors have the same argument list, I'd like to be able to call the superclass constructor with the class kind and have it return to me the kind of object I requested. Certainly not all the time, but sometimes. Oq allows you to do this, but you have to specifically tell it that's what you want. Consider the following:

Code: Select all

class MyClass
{
    New(int args)
    {
        <create the object>
    }
}
This is a normal constructor. If you create a subclass of MyClass and define its own New constructor, these New methods will be independent from one another (standard OOP). Now consider the following:

Code: Select all

class MyClass
{
    morph New(int args)
    {
        <create the object>
    }
}
Notice the word morph before the name of the constructor. This directs oq that you will be calling the superclass method with a class kind and that it should use the subclass constructor for the specified kind. So here's what the call might look like:

Code: Select all

    int id = MyClass:New(CLASS_WeirdSubclass, args);
In this example, the call to the superclass New will result in creating a subclass object of WeirdSubclass instead of MyClass. This will work correctly as long as:

A) The argument list is identical (normally, constructors want different args, but the way around this is to pass an array of args or perhaps an argument object).

B) The CLASS_<name> being passed to the constructor is a decendent of the superclass (but it doesn't strictly have to be a direct decendent).
Author:  roger-write [ Thu Jan 24, 2013 12:11 pm ]
Post subject:  Re: An object oriented language for Empty4
If you can bear with one more post about morphing, we should be ale to put this all together into something incredibly powerful and useful. Consider the following:

Code: Select all

extern string SelectTradeManager = "ScaleOutTrader";

int TraderID;

int init()
{
    RegisterClasses();

    int kind = classkind(SelectTradeManager);
    if( kind==(-1) )
        { Print("Trade manager not found: ", SelectTradeManager); return(0); }
    TraderID = Trader:New(kind);
}
By structuring things this way, you can come back and create additional trade managers, instantly plug them into your oq project and they will just work. All a user of this EA would have to do would be to specify the class name of the new trade manager as part of the EA input values and the EA instantly uses the new trader instead of the old one. The possibilities are endless: ScaleInTrader, RecoveryTrader, GridTrader, PyramidTrader, StingyTrader, BetTheFarmTrader, HedgeIfWeFailTrader, fill in the blank...

I've just given you one example of how to apply this kind of template approach to coding. What about signals? Could you design an EA using this approach where you can plug in any signal your heart desires? How about money management styles, or any number of other things that would make your EA's extremely adaptable for trying different ideas, and having access to all ideas you've ever tried at your fingertips without creating a software maintenance nightmare?

Well, I think it's pretty cool anyway....
Author:  roger-write [ Mon Jan 28, 2013 1:06 pm ]
Post subject:  Re: An object oriented language for Empty4
If you ever choose to use oq, often times you will create a static class, where all properties and methods are defined as static. For example, lets say you want to create a bunch of time functions that do more than the standard Empty4 time functions. Maybe you want it to return true if you are in the London session or something. Rather than just creating the functions normally you could create a static class to handle all the time functions.

Code: Select all

class Time
{
    static bool InLondonSession()
    {
        <do something>
    }

    static int MarketOpenHour()
    {
        <do something>
    }

    ...
}
It's just a way of grouping related functions. But when creating a class intended for object creation, there are a few standard practices you should abide by. For example, the root class should have a class initializer static method, which clears out all objects of that class and any of its subclasses. This would only get called one time upon startup. I usually call this Init, but you can call it whatever you want.

Additionally, there should be one or more constructors and something to delete the object. Here is an example of what I consider the bare minimum when creating a root class intended for objects (IE non-static):

Code: Select all

class Signal
{
    static void Init()
    {
        @size();
    }

    New(int arg)
    {
        int ID = @new();
        <fill out the object>
        return(ID);
    }

    void Delete()
    {
        <do anything needed to take down object>
        @del();
    }
}
Any subclasses created from Signal won't need their own Init function. They will require their own constructor (in this case New), and may or may not require their own Delete, depending on whether there are additional things that need to be cleaned up for that particular subclass.
Author:  Dozer [ Sat Feb 02, 2013 5:03 pm ]
Post subject:  Re: An object oriented language for Empty4
Hi Roger,

Thanks for taking the time to write up these posts and explain your development process. It's quite an ambitious project!

I do most of my trading and programming in NinjaTrader and C# which is a great trading platform. I dread when I need to slog through MQL when using Empty4 for certain brokers. Adapting OO for Empty4 is pretty cool.... :D

I haven't had too much time to play around with your system, but I've been very interested in reading what you are doing.

Thanks,
Dozer
Author:  roger-write [ Mon Feb 04, 2013 3:02 pm ]
Post subject:  Re: An object oriented language for Empty4
Dozer wrote:Hi Roger,

Thanks for taking the time to write up these posts and explain your development process. It's quite an ambitious project!

I do most of my trading and programming in NinjaTrader and C# which is a great trading platform. I dread when I need to slog through MQL when using Empty4 for certain brokers. Adapting OO for Empty4 is pretty cool.... :D

I haven't had too much time to play around with your system, but I've been very interested in reading what you are doing.

Thanks,
Dozer
Thanks for the post and encouragement. I realize I haven't posted much on this thread over the past week. I'm still around and using oq, but I really haven't had to make any changes as it works pretty well right now. I'm used to using languages like c++ and c# and I agree that going to mql is a pain. At least when trying to do something more complex beyond simple indicators and straight forward EA's.

This project grew out of how I had begun to adapt to coding in mql. I ended up finding myself trying to create reusable modules and would use zero length global arrays ('[]') to hold an instance of one of the module's "objects". I found myself coding the same bloody functions over and over to, for example, do the maintenance work: resize all the globals, find a slot to use, create a new one and delete an old one, etc. Plus, it was a royal pain having to prefix everything concerning the module with the module name. It made the code too bulky/wordy.

So, the thought finally occurred to me, "Hey, what if I wrote a pre-parser to act like I'm coding in a real OOP language and then have it write out the awful, flat mql code I'd been manually doing for so long? ObjectQuotes was born.

Now that I've been using it and had the opportunity to refine it during January, a few really kind of cool things have emerged that I didn't even expect, like morphing, templating modules such that you can do plug-and-play type stuff. It's rather fascinating to an o'l geek like me. :lol:

If I ever get to the point of being able to make a living from this, I would absolutely love to turn the next generation of ObjectQuotes into a real, full-on parsed OOP language without having to use decorators like '@' and ':'. The output could actually be either crappy flat mql, or some other trading language. This would provide a sort of universal trading language that would potentially be used with any trading platform. But this would require a concerted full time effort (6 to 9 months?) that I simply can't do at the moment.

If anyone out there has any connections to individuals or companies in the industry that would see enough value in something like this to sponsor an open source project like this, I would love to discuss it.

In the meantime, I've been using oq myself and it's working well. It's way way better than what I was doing before. If anyone here ever gets around to giving it a try, let me know if you have any questions or run into anything.
All times are UTC Page 4 of 8

Powered by phpBB® Forum Software © phpBB Limited