Quote from: new overcomer on November 29, 2012, 06:34:59 PM

@Aido: Do you want me to just push code fixes as bugs on the tracker and you can push them into the repository?

For the time being this may be a good way to track suggestions that require code change. After discussion in this thread, a specific targeted task can be put in the issues page of github. It's just a suggestion to do it this way so, yea or nay?
Or a new forum can be created as suggested by new overcomer.

Quote from: new overcomer on November 29, 2012, 06:44:07 PM

so you're saying all the market connection and data streaming is coming from a different project?

Yes, I think rather than re-inventing the wheel the original developer choose to use XChange so as to get IsisATP up and running a lot faster. If the XChange project no longer suits our purpose I suppose it could be forked on github and our own requirements implemented. However, looking at the planned milestones for XChange project, the developers plan to expand the code for other exchanges:

https://github.com/timmolter/XChange/wiki/Milestones

And as mentioned previously, one of the developers is going to investigate adding code for testing and reconnecting socketIO connections which is currently an issue for IsisATP:

https://github.com/timmolter/XChange/issues/6

Just to recap on a few things and explain some of the changes I made to the original.

The most fundamental change was to switch from a polling to streaming ticker. The reason I decided to use a streaming ticker was so that it would react faster to the market. Now, when a tick is received it triggers an arbitrage thread and a trend observer thread. Each making a decision on whether to trade or not. Another upshot of this was I found that the original IsisATP was using 100% of my CPU. By changing how the threads were launched I could use the thread.join() Java method rather than the thread.yield() method of the original which apparently can have negative effects on a Linux system.

I also made some changes to the learning functionality. Originally it learned for 1 hour and cleared out any ticks older than that time. So trade decisions were based on an hour of ticks that were polled every 1 minute. The learning time was hardcoded.

Now it learns for at least 16 streamed ticks and keeps data for 2 hours. So depending on how many ticks it received in that two hours it will have more data for a 'popular' currency like dollars. By coincidence, I think this change may make it a bit easier to implement some of the SMA functionality mentioned in the previous few posts. We'll see....

I think the first step is to make these values configurable from the preferences file (or the registry for you Windows fanboys!

).

I think maybe we should concentrate on core functionality and algorithms first before getting fancy with GUIs and the like. I'm an old-school command line type person anyway and always favour function over form.