Re: activequant-base and activequant-examples release 1.2 is out!

View: New views
14 Messages — Rating Filter:   Alert me  

Re: activequant-base and activequant-examples release 1.2 is out!

by Mike Kroutikov-2 :: Rate this Message:

| View Threaded | Show Only this Message

Temp build problems on AQ continuum server has been resolved.

Official release 1.2 is now out. No changes compared to 1.1, except temporary repository has been removed.

-Mike

On Sat, Sep 12, 2009 at 6:46 PM, Ulrich Staudinger <ustaudinger@...> wrote:
Cool ! Great job, am double checking already ...


On Sat, Sep 12, 2009 at 6:21 PM, Mike Kroutikov <pgmmpk@...> wrote:
Hi All,

Release 1.1 is out, Please see details at the link below:

http://activequant.org/news/show/17

-Mike

_______________________________________________
ccapi mailing list
ccapi@...
http://activestocks.de/cgi-bin/mailman/listinfo/ccapi




--
Ulrich B. Staudinger

_______________________________________________
ccapi mailing list
ccapi@...
http://activestocks.de/cgi-bin/mailman/listinfo/ccapi



_______________________________________________
ccapi mailing list
ccapi@...
http://activestocks.de/cgi-bin/mailman/listinfo/ccapi

Re: activequant-base and activequant-examples release 1.2 is out!

by Kirill Jacobson :: Rate this Message:

| View Threaded | Show Only this Message

Mike,

I am new to maven and have a question about building AQ from Eclipse. How does the project dependency works in Maven/Eclipse? I want to make changes to some classes (like YahooCandleSeriesSource) in the base project but debug from my example. Should I create an Eclipse project for the entire aq-base or for each sub-project separately? When I check out the entire base as an Eclipse project and enable maven's dependency management it builds nothing. The src/main/java folder stays empty with a tiny question mark. Checking "Process modules recursively" doesn't help. As for the aq-examples folder (single pom per project) everything works fine. How do you debug examples?

Also, would you recommend me working with the trunk or a point release? What is the purpose of the x.x-SNAPSHOT version? Is it "work in progress" towards the x.x release?

Thank you,
Kirill

Mike Kroutikov-2 wrote:
Temp build problems on AQ continuum server has been resolved.

Official release 1.2 is now out. No changes compared to 1.1, except
temporary repository has been removed.

-Mike

Re: activequant-base and activequant-examples release 1.2 is out!

by Bugzilla from ustaudinger@gmail.com :: Rate this Message:

| View Threaded | Show Only this Message



On Mon, Sep 14, 2009 at 5:21 AM, Kirill Jacobson <activequant.nabble@...> wrote:
Also, would you recommend me working with the trunk or a point release? What
is the purpose of the x.x-SNAPSHOT version? Is it "work in progress" towards
the x.x release?



If you want to work with the latest stable version, trunk is recommended. The snapshot versions are indeed releases on the way to the next x.x version and are usually build either nightly or after commit / on demand.

In principle, you can also work with the SNAPSHOT versions, but some interfaces or things might change in the future. Experience shows that the codebase doesn't change fundamentally at the moment. New features will be available only in the snapshot version.

I recommend that you take the snapshot version.

Cheers,
Ulrich
 


_______________________________________________
ccapi mailing list
ccapi@...
http://activestocks.de/cgi-bin/mailman/listinfo/ccapi

Re: activequant-base and activequant-examples release 1.2 is out!

by Mike Kroutikov-2 :: Rate this Message:

| View Threaded | Show Only this Message

Kirill,

Do not attempt to make an eclipse project out of a multi-module maven build - this level of eclipse/maven integration is not yet supported by eclipse plugins.

Instead, just checkout activequant-framework (or whatever submodule you intend to change, maybe activequant-adapter-simple). Eclipse is clever enough to short-circuit maven dependencies between eclipse project (they internally become eclipse dependencies and behave accordingly). My experience shows that this works very well (i.e. changes made to the dependency are immediately picked up by dependents). If anything does not work as it should - do "Locally Install Artefact" in maven menu for the dependency - this will force changes to become "visible" via maven dependency mechanism and guarantees that they are picked up by all dependents on the current machine (i.e. even different eclipse instance/workspace).

Which release to choose: if you plan to make patches, pls use SNAPSHOT - this is (relatively) stable "bleeding edge" code. If you just link against AQ module (i.e. use it as dependency in your project), then you may be better off by using release version.

At the moment, release and snapshot are very close. And we intend to keep them that way (i.e. release often), so the distinction is really blurred. Technically, there bullets should drive the decision:

1. using SNAPSHOT as dependency may make things slow, as maven checks if SNAPSHOT artefact is current on every compile (unless you use "offline" flag)
2. all new code goes to SNAPSHOT. Therefore, patches built on top of release will not be accepted, as they will require manual merging with SNAPSHOT code.

On Mon, Sep 14, 2009 at 7:10 AM, Ulrich Staudinger <ustaudinger@...> wrote:


On Mon, Sep 14, 2009 at 5:21 AM, Kirill Jacobson <activequant.nabble@...> wrote:
Also, would you recommend me working with the trunk or a point release? What
is the purpose of the x.x-SNAPSHOT version? Is it "work in progress" towards
the x.x release?



If you want to work with the latest stable version, trunk is recommended. The snapshot versions are indeed releases on the way to the next x.x version and are usually build either nightly or after commit / on demand.

In principle, you can also work with the SNAPSHOT versions, but some interfaces or things might change in the future. Experience shows that the codebase doesn't change fundamentally at the moment. New features will be available only in the snapshot version.

I recommend that you take the snapshot version.

Cheers,
Ulrich
 


_______________________________________________
ccapi mailing list
ccapi@...
http://activestocks.de/cgi-bin/mailman/listinfo/ccapi



_______________________________________________
ccapi mailing list
ccapi@...
http://activestocks.de/cgi-bin/mailman/listinfo/ccapi

Re: activequant-base and activequant-examples release 1.2 is out!

by Kirill Jacobson :: Rate this Message:

| View Threaded | Show Only this Message

Ulrich, do you know why examples/pom.xml in the trunk is marked as version 1.3-SNAPSHOT (as expected) but it depends on the base components version 1.2? I would expect it to depend on 1.3-SNAPSHOT.

I am trying configure Eclipse to debug base/trunk code from the examples/trunk project with no success :(

Thank you,
Kirill

Ulrich Staudinger-2 wrote:
On Mon, Sep 14, 2009 at 5:21 AM, Kirill Jacobson <
activequant.nabble@augnisoft.com> wrote:

> Also, would you recommend me working with the trunk or a point release?
> What
> is the purpose of the x.x-SNAPSHOT version? Is it "work in progress"
> towards
> the x.x release?
>
>

If you want to work with the latest stable version, trunk is recommended.
The snapshot versions are indeed releases on the way to the next x.x version
and are usually build either nightly or after commit / on demand.

In principle, you can also work with the SNAPSHOT versions, but some
interfaces or things might change in the future. Experience shows that the
codebase doesn't change fundamentally at the moment. New features will be
available only in the snapshot version.

I recommend that you take the snapshot version.

Cheers,
Ulrich

_______________________________________________
ccapi mailing list
ccapi@activestocks.de
http://activestocks.de/cgi-bin/mailman/listinfo/ccapi

Re: activequant-base and activequant-examples release 1.2 is out!

by Mike Kroutikov-2 :: Rate this Message:

| View Threaded | Show Only this Message

This question is to me, actually.

Why do you think it should depend on the snapshot version of product? Typical user will not need to update classes outside of examples. The benefit of release-level dependency here is (i) more stability, and (ii) faster builds. Also, it is easy to update dependency, if needed. 

Try this: checkout examples, enable maven project nature. This should compile/build with no problem.
If needed, change dependency version to 1.3-SNAPSHOT.

Please, be specific when you say "with no success", otherwise its hard to address it.

Cheers,
-Mike

On Mon, Sep 14, 2009 at 10:29 AM, Kirill Jacobson <activequant.nabble@...> wrote:

Ulrich, do you know why examples/pom.xml in the trunk is marked as version
1.3-SNAPSHOT (as expected) but it depends on the base components version
1.2? I would expect it to depend on 1.3-SNAPSHOT.

I am trying configure Eclipse to debug base/trunk code from the
examples/trunk project with no success :(

Thank you,
Kirill


Ulrich Staudinger-2 wrote:
>
> On Mon, Sep 14, 2009 at 5:21 AM, Kirill Jacobson <
> activequant.nabble@...> wrote:
>
>> Also, would you recommend me working with the trunk or a point release?
>> What
>> is the purpose of the x.x-SNAPSHOT version? Is it "work in progress"
>> towards
>> the x.x release?
>>
>>
>
> If you want to work with the latest stable version, trunk is recommended.
> The snapshot versions are indeed releases on the way to the next x.x
> version
> and are usually build either nightly or after commit / on demand.
>
> In principle, you can also work with the SNAPSHOT versions, but some
> interfaces or things might change in the future. Experience shows that the
> codebase doesn't change fundamentally at the moment. New features will be
> available only in the snapshot version.
>
> I recommend that you take the snapshot version.
>
> Cheers,
> Ulrich
>
> _______________________________________________
> ccapi mailing list
> ccapi@...
> http://activestocks.de/cgi-bin/mailman/listinfo/ccapi
>
>

--
View this message in context: http://www.nabble.com/Re%3A-activequant-base-and-activequant-examples-release-1.2-is-out%21-tp25429279p25436762.html
Sent from the ActiveQuant mailing list archive at Nabble.com.

_______________________________________________
ccapi mailing list
ccapi@...
http://activestocks.de/cgi-bin/mailman/listinfo/ccapi


_______________________________________________
ccapi mailing list
ccapi@...
http://activestocks.de/cgi-bin/mailman/listinfo/ccapi

Re: activequant-base and activequant-examples release 1.2 is out!

by Kirill Jacobson :: Rate this Message:

| View Threaded | Show Only this Message

Eventually dependencies for many core components will be switched to the snapshot. The question is should it be done up front, when a new version is branched out, or gradually one dependency at a time. You said that a snapshot slows the build and you prefer to postpone the update. As for me, who is a novice to maven, it is easier not have any 1.2 files in the local repository. Otherwise it is not clear who is using what and if the code compiles against the newly built jars. To make the things even more confusing I just discovered \opt\0.8-stable in the root of my C: drive and have no idea what it is used for.

I am sorry for my "with no success" comment. It was more of a status update. With your help I finally got things working in Eclipse. I am debugging a problem with the backtester when a market order is filled at the price that the stock had five days before. Would it be nice to do it in a real life :)

I made minor changes to the TimeStamp and YahooCandleSeriesSource classes and attached them for your review.TimeStamp.javaYahooCandleSeriesSource.java

Thank you,
Kirill

Mike Kroutikov-2 wrote:
This question is to me, actually.
Why do you think it should depend on the snapshot version of product?
Typical user will not need to update classes outside of examples. The
benefit of release-level dependency here is (i) more stability, and (ii)
faster builds. Also, it is easy to update dependency, if needed.

Try this: checkout examples, enable maven project nature. This should
compile/build with no problem.
If needed, change dependency version to 1.3-SNAPSHOT.

Please, be specific when you say "with no success", otherwise its hard to
address it.

Cheers,
-Mike

Re: activequant-base and activequant-examples release 1.2 is out!

by Mike Kroutikov-2 :: Rate this Message:

| View Threaded | Show Only this Message

Kirill,

\opt stuff: you apparently asked maven to "deploy" the app. No point in doing this locally. Deploy action is configured this way for the aq server. Just delete it :)

I do not get your comment that states "it is easier not have any 1.2 files in the local repository". Maven controls dependencies, not you. Existence of files in local repository does not hurt, and does not change anything - nothing gets included in the classpath unless dependency is directly or transitively derived from pom.xml. Be prepared to see a lot of stuff in your local m2 repo, with different versions - its normal. In eclipse, there is "maven dependency viewer", which is a nice tool to track actual dependency tree - check it out.

At this point I will vote against your suggested changes for the following reasons:

- you enhance somewhat TimeStamp.toString() output at the expense of introducing tight coupling between TimeStamp and TimeStampFormat. I prefer keeping TimeStamp simple and its toStirng() method consistent across timezones. Its very easy to use TimeStampFormat in the printing code (or use helpers).

- your yahoo source uses hardcoded 16:00 as close time. Arguably, this is better than 00:00. However, I would prefer a settable time instead (just in case some instruments are traded on different exchanges that have different close times). Another solution is to use a post-processing filter that adjusts time - this gives full control and the ability to set time depending on the instrument (and can be used with different sources)... Maybe not feasible for this simple source...

Btw, thanks for the suggestions. I do appreciate your efforts towards learning and using the aq, and especially your readiness to ask questions, debug, and share the code.

Cheers,
-Mike

On Mon, Sep 14, 2009 at 8:33 PM, Kirill Jacobson <activequant.nabble@...> wrote:

Eventually dependencies for many core components will be switched to the
snapshot. The question is should it be done up front, when a new version is
branched out, or gradually one dependency at a time. You said that a
snapshot slows the build and you prefer to postpone the update. As for me,
who is a novice to maven, it is easier not have any 1.2 files in the local
repository. Otherwise it is not clear who is using what and if the code
compiles against the newly built jars. To make the things even more
confusing I just discovered \opt\0.8-stable in the root of my C: drive and
have no idea what it is used for.

I am sorry for my "with no success" comment. It was more of a status update.
With your help I finally got things working in Eclipse. I am debugging a
problem with the backtester when a market order is filled at the price that
the stock had five days before. Would it be nice to do it in a real life :)

I made minor changes to the TimeStamp and YahooCandleSeriesSource classes
and attached them for your review.
http://www.nabble.com/file/p25445962/TimeStamp.java TimeStamp.java
http://www.nabble.com/file/p25445962/YahooCandleSeriesSource.java
YahooCandleSeriesSource.java

Thank you,
Kirill


Mike Kroutikov-2 wrote:
>
> This question is to me, actually.
> Why do you think it should depend on the snapshot version of product?
> Typical user will not need to update classes outside of examples. The
> benefit of release-level dependency here is (i) more stability, and (ii)
> faster builds. Also, it is easy to update dependency, if needed.
>
> Try this: checkout examples, enable maven project nature. This should
> compile/build with no problem.
> If needed, change dependency version to 1.3-SNAPSHOT.
>
> Please, be specific when you say "with no success", otherwise its hard to
> address it.
>
> Cheers,
> -Mike
>

--
View this message in context: http://www.nabble.com/Re%3A-activequant-base-and-activequant-examples-release-1.2-is-out%21-tp25429279p25445962.html
Sent from the ActiveQuant mailing list archive at Nabble.com.

_______________________________________________
ccapi mailing list
ccapi@...
http://activestocks.de/cgi-bin/mailman/listinfo/ccapi


_______________________________________________
ccapi mailing list
ccapi@...
http://activestocks.de/cgi-bin/mailman/listinfo/ccapi

Re: activequant-base and activequant-examples release 1.2 is out!

by Kirill Jacobson :: Rate this Message:

| View Threaded | Show Only this Message

Mike, thanks for the kind words and encouragement.

I am slowly but surely getting to the cause of the problem with the back tester. Now I wounder what is the right way to fix it. This is what happens. The back tester reads daily candles and at some point issues a market order to buy shares. To my surprise the order is filled not at the current price or the next day's price, but at some price in the past (the price on the first day of the series to be precise).

This is my understanding of what happens: an order is submitted, tracker is created, subscription is activated, candles are retrieved, trade indications are created and merged into the replay service, which reads them and distributes to subscribers. Unfortunately merge doesn't remove trade indications that happened prior (backtester time) to the most recent indication that has already been removed from the pump. Is this by design or is it a bug? I will investigate it further tomorrow.

Good night,
Kirill


Mike Kroutikov-2 wrote:
Kirill,

\opt stuff: you apparently asked maven to "deploy" the app. No point in
doing this locally. Deploy action is configured this way for the aq server.
Just delete it :)

I do not get your comment that states "it is easier not have any 1.2 files
in the local repository". Maven controls dependencies, not you. Existence of
files in local repository does not hurt, and does not change anything -
nothing gets included in the classpath unless dependency is directly or
transitively derived from pom.xml. Be prepared to see a lot of stuff in your
local m2 repo, with different versions - its normal. In eclipse, there is
"maven dependency viewer", which is a nice tool to track actual dependency
tree - check it out.

At this point I will vote against your suggested changes for the following
reasons:

- you enhance somewhat TimeStamp.toString() output at the expense of
introducing tight coupling between TimeStamp and TimeStampFormat. I prefer
keeping TimeStamp simple and its toStirng() method consistent across
timezones. Its very easy to use TimeStampFormat in the printing code (or use
helpers).

- your yahoo source uses hardcoded 16:00 as close time. Arguably, this is
better than 00:00. However, I would prefer a settable time instead (just in
case some instruments are traded on different exchanges that have different
close times). Another solution is to use a post-processing filter that
adjusts time - this gives full control and the ability to set time depending
on the instrument (and can be used with different sources)... Maybe not
feasible for this simple source...

Btw, thanks for the suggestions. I do appreciate your efforts towards
learning and using the aq, and especially your readiness to ask questions,
debug, and share the code.

Cheers,
-Mike

Re: activequant-base and activequant-examples release 1.2 is out!

by Mike Kroutikov-2 :: Rate this Message:

| View Threaded | Show Only this Message

Kirill, 

Re: backtester. Could you publish your complete code? My understanding is that backtester fires events strictly in ascending time order. What you describe suggests that backtester time jerks back at some point, which would be wrong.

Here is how its supposed to work:

TS subscribes for the feed. Since feed is simulated, subscription request is processed by backtester which triggers fetching of the historical data interval.
TS may decide to subscribe to another feed. Again, the request will pass thru backtester and will trigger fetching of historical data for this instrument, and adding it to the merge set.
TS may issue an order. With the paper broker this should trigger activation of corresponding subscription by the broker. Again, corresponding historical data series should be added to the merge set (if not already there).

Regards,
-Mike

On Tue, Sep 15, 2009 at 1:12 AM, Kirill Jacobson <activequant.nabble@...> wrote:

Mike, thanks for the kind words and encouragement.

I am slowly but surely getting to the cause of the problem with the back
tester. Now I wounder what is the right way to fix it. This is what happens.
The back tester reads daily candles and at some point issues a market order
to buy shares. To my surprise the order is filled not at the current price
or the next day's price, but at some price in the past (the price on the
first day of the series to be precise).

This is my understanding of what happens: an order is submitted, tracker is
created, subscription is activated, candles are retrieved, trade indications
are created and merged into the replay service, which reads them and
distributes to subscribers. Unfortunately merge doesn't remove trade
indications that happened prior (backtester time) to the most recent
indication that has already been removed from the pump. Is this by design or
is it a bug? I will investigate it further tomorrow.

Good night,
Kirill



Mike Kroutikov-2 wrote:
>
> Kirill,
>
> \opt stuff: you apparently asked maven to "deploy" the app. No point in
> doing this locally. Deploy action is configured this way for the aq
> server.
> Just delete it :)
>
> I do not get your comment that states "it is easier not have any 1.2 files
> in the local repository". Maven controls dependencies, not you. Existence
> of
> files in local repository does not hurt, and does not change anything -
> nothing gets included in the classpath unless dependency is directly or
> transitively derived from pom.xml. Be prepared to see a lot of stuff in
> your
> local m2 repo, with different versions - its normal. In eclipse, there is
> "maven dependency viewer", which is a nice tool to track actual dependency
> tree - check it out.
>
> At this point I will vote against your suggested changes for the following
> reasons:
>
> - you enhance somewhat TimeStamp.toString() output at the expense of
> introducing tight coupling between TimeStamp and TimeStampFormat. I prefer
> keeping TimeStamp simple and its toStirng() method consistent across
> timezones. Its very easy to use TimeStampFormat in the printing code (or
> use
> helpers).
>
> - your yahoo source uses hardcoded 16:00 as close time. Arguably, this is
> better than 00:00. However, I would prefer a settable time instead (just
> in
> case some instruments are traded on different exchanges that have
> different
> close times). Another solution is to use a post-processing filter that
> adjusts time - this gives full control and the ability to set time
> depending
> on the instrument (and can be used with different sources)... Maybe not
> feasible for this simple source...
>
> Btw, thanks for the suggestions. I do appreciate your efforts towards
> learning and using the aq, and especially your readiness to ask questions,
> debug, and share the code.
>
> Cheers,
> -Mike
>
>

--
View this message in context: http://www.nabble.com/Re%3A-activequant-base-and-activequant-examples-release-1.2-is-out%21-tp25429279p25447891.html
Sent from the ActiveQuant mailing list archive at Nabble.com.

_______________________________________________
ccapi mailing list
ccapi@...
http://activestocks.de/cgi-bin/mailman/listinfo/ccapi


_______________________________________________
ccapi mailing list
ccapi@...
http://activestocks.de/cgi-bin/mailman/listinfo/ccapi

Re: activequant-base and activequant-examples release 1.2 is out!

by Kirill Jacobson :: Rate this Message:

| View Threaded | Show Only this Message

Mike,

I attached my code and the output. It is based on the sample that you posted on 09/07 (www.nabble.com/BalanceBook--Account--OrderTracker--to25177571.html). To make it easier to debug I removed the charting code and reduced the time interval to four trading days.

-Kirill


public class MainBacktest {
        private final static TimeStamp start = format.parse("2004/08/19");
        private final static TimeStamp end   = format.parse("2004/08/24");
        static {
                TimeStamp.DEFAULT_FORMAT = new TimeStampFormat("MM/dd/yyyy HH:mm:ssZZZ");
        }
}

public class TradeSystemLogic {
        int candelCounter = 0;
        private void onCandle(Candle candle) {
               
                log.info("[evaluate] candle #" + candelCounter + ": " + candle);
                if (candelCounter++ != 1)
                        return;

                log.info("BUY @market");

                Order order = new Order();
                order.setInstrumentSpecification(spec);
                order.setOrderTimeStamp(new TimeStamp());
                order.setOrderSide(OrderSide.BUY);
                order.setOrderType(OrderType.MARKET);
                order.setQuantity(quantity);
                order.setOrderSide(OrderSide.BUY);
                position = positionService.openPosition(order);
        }
}


Mike Kroutikov-2 wrote:
Kirill,
Re: backtester. Could you publish your complete code? My understanding is
that backtester fires events strictly in ascending time order. What you
describe suggests that backtester time jerks back at some point, which would
be wrong.

Here is how its supposed to work:

TS subscribes for the feed. Since feed is simulated, subscription request is
processed by backtester which triggers fetching of the historical data
interval.
TS may decide to subscribe to another feed. Again, the request will pass
thru backtester and will trigger fetching of historical data for this
instrument, and adding it to the merge set.
TS may issue an order. With the paper broker this should trigger activation
of corresponding subscription by the broker. Again, corresponding historical
data series should be added to the merge set (if not already there).

Regards,
-Mike

On Tue, Sep 15, 2009 at 1:12 AM, Kirill Jacobson <
activequant.nabble@augnisoft.com> wrote:

>
> Mike, thanks for the kind words and encouragement.
>
> I am slowly but surely getting to the cause of the problem with the back
> tester. Now I wounder what is the right way to fix it. This is what
> happens.
> The back tester reads daily candles and at some point issues a market order
> to buy shares. To my surprise the order is filled not at the current price
> or the next day's price, but at some price in the past (the price on the
> first day of the series to be precise).
>
> This is my understanding of what happens: an order is submitted, tracker is
> created, subscription is activated, candles are retrieved, trade
> indications
> are created and merged into the replay service, which reads them and
> distributes to subscribers. Unfortunately merge doesn't remove trade
> indications that happened prior (backtester time) to the most recent
> indication that has already been removed from the pump. Is this by design
> or
> is it a bug? I will investigate it further tomorrow.
>
> Good night,
> Kirill
>
>
>
> Mike Kroutikov-2 wrote:
> >
> > Kirill,
> >
> > \opt stuff: you apparently asked maven to "deploy" the app. No point in
> > doing this locally. Deploy action is configured this way for the aq
> > server.
> > Just delete it :)
> >
> > I do not get your comment that states "it is easier not have any 1.2
> files
> > in the local repository". Maven controls dependencies, not you. Existence
> > of
> > files in local repository does not hurt, and does not change anything -
> > nothing gets included in the classpath unless dependency is directly or
> > transitively derived from pom.xml. Be prepared to see a lot of stuff in
> > your
> > local m2 repo, with different versions - its normal. In eclipse, there is
> > "maven dependency viewer", which is a nice tool to track actual
> dependency
> > tree - check it out.
> >
> > At this point I will vote against your suggested changes for the
> following
> > reasons:
> >
> > - you enhance somewhat TimeStamp.toString() output at the expense of
> > introducing tight coupling between TimeStamp and TimeStampFormat. I
> prefer
> > keeping TimeStamp simple and its toStirng() method consistent across
> > timezones. Its very easy to use TimeStampFormat in the printing code (or
> > use
> > helpers).
> >
> > - your yahoo source uses hardcoded 16:00 as close time. Arguably, this is
> > better than 00:00. However, I would prefer a settable time instead (just
> > in
> > case some instruments are traded on different exchanges that have
> > different
> > close times). Another solution is to use a post-processing filter that
> > adjusts time - this gives full control and the ability to set time
> > depending
> > on the instrument (and can be used with different sources)... Maybe not
> > feasible for this simple source...
> >
> > Btw, thanks for the suggestions. I do appreciate your efforts towards
> > learning and using the aq, and especially your readiness to ask
> questions,
> > debug, and share the code.
> >
> > Cheers,
> > -Mike
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Re%3A-activequant-base-and-activequant-examples-release-1.2-is-out%21-tp25429279p25447891.html
> Sent from the ActiveQuant mailing list archive at Nabble.com.
>
> _______________________________________________
> ccapi mailing list
> ccapi@activestocks.de
> http://activestocks.de/cgi-bin/mailman/listinfo/ccapi
>

_______________________________________________
ccapi mailing list
ccapi@activestocks.de
http://activestocks.de/cgi-bin/mailman/listinfo/ccapi
KirillsTest-2009-09-15.zipconsole.txt

Re: activequant-base and activequant-examples release 1.2 is out!

by Mike Kroutikov-2 :: Rate this Message:

| View Threaded | Show Only this Message

Indeed, its a bug in MarketDataReplayService, aka backtester.

It shows up when subscription of a different kind or instrument (comparing to the already running) is dynamically created. For example: subscribe for the GOOG candles and in the middle of backtester run subscribe for AAPL candles - and watch virtual backtester time to jump back. In your case PaperBroker was creating a dynamic subscription in response for the order request.

Workaround would be to create TradeIndication subscription in the Start method of trading system (for all traded instruments).

I submitted a fix that should take care of the problem. Please, test

Strange that we did not see this before. I suspect that all other configurations were using TradeIndication feeds and therefore were subscribing to it "statically" (i.e. in the Start method).

Regards,
-Mike

On Tue, Sep 15, 2009 at 9:50 AM, Kirill Jacobson <activequant.nabble@...> wrote:

Mike,

I attached my code and the output. It is based on the sample that you posted
on 09/07
(www.nabble.com/BalanceBook--Account--OrderTracker--to25177571.html). To
make it easier to debug I removed the charting code and reduced the time
interval to four trading days.

-Kirill


public class MainBacktest {
       private final static TimeStamp start = format.parse("2004/08/19");
       private final static TimeStamp end   = format.parse("2004/08/24");
       static {
               TimeStamp.DEFAULT_FORMAT = new TimeStampFormat("MM/dd/yyyy HH:mm:ssZZZ");
       }
}

public class TradeSystemLogic {
       int candelCounter = 0;
       private void onCandle(Candle candle) {

               log.info("[evaluate] candle #" + candelCounter + ": " + candle);
               if (candelCounter++ != 1)
                       return;

               log.info("BUY @market");

               Order order = new Order();
               order.setInstrumentSpecification(spec);
               order.setOrderTimeStamp(new TimeStamp());
               order.setOrderSide(OrderSide.BUY);
               order.setOrderType(OrderType.MARKET);
               order.setQuantity(quantity);
               order.setOrderSide(OrderSide.BUY);
               position = positionService.openPosition(order);
       }
}



Mike Kroutikov-2 wrote:
>
> Kirill,
> Re: backtester. Could you publish your complete code? My understanding is
> that backtester fires events strictly in ascending time order. What you
> describe suggests that backtester time jerks back at some point, which
> would
> be wrong.
>
> Here is how its supposed to work:
>
> TS subscribes for the feed. Since feed is simulated, subscription request
> is
> processed by backtester which triggers fetching of the historical data
> interval.
> TS may decide to subscribe to another feed. Again, the request will pass
> thru backtester and will trigger fetching of historical data for this
> instrument, and adding it to the merge set.
> TS may issue an order. With the paper broker this should trigger
> activation
> of corresponding subscription by the broker. Again, corresponding
> historical
> data series should be added to the merge set (if not already there).
>
> Regards,
> -Mike
>
> On Tue, Sep 15, 2009 at 1:12 AM, Kirill Jacobson <
> activequant.nabble@...> wrote:
>
>>
>> Mike, thanks for the kind words and encouragement.
>>
>> I am slowly but surely getting to the cause of the problem with the back
>> tester. Now I wounder what is the right way to fix it. This is what
>> happens.
>> The back tester reads daily candles and at some point issues a market
>> order
>> to buy shares. To my surprise the order is filled not at the current
>> price
>> or the next day's price, but at some price in the past (the price on the
>> first day of the series to be precise).
>>
>> This is my understanding of what happens: an order is submitted, tracker
>> is
>> created, subscription is activated, candles are retrieved, trade
>> indications
>> are created and merged into the replay service, which reads them and
>> distributes to subscribers. Unfortunately merge doesn't remove trade
>> indications that happened prior (backtester time) to the most recent
>> indication that has already been removed from the pump. Is this by design
>> or
>> is it a bug? I will investigate it further tomorrow.
>>
>> Good night,
>> Kirill
>>
>>
>>
>> Mike Kroutikov-2 wrote:
>> >
>> > Kirill,
>> >
>> > \opt stuff: you apparently asked maven to "deploy" the app. No point in
>> > doing this locally. Deploy action is configured this way for the aq
>> > server.
>> > Just delete it :)
>> >
>> > I do not get your comment that states "it is easier not have any 1.2
>> files
>> > in the local repository". Maven controls dependencies, not you.
>> Existence
>> > of
>> > files in local repository does not hurt, and does not change anything -
>> > nothing gets included in the classpath unless dependency is directly or
>> > transitively derived from pom.xml. Be prepared to see a lot of stuff in
>> > your
>> > local m2 repo, with different versions - its normal. In eclipse, there
>> is
>> > "maven dependency viewer", which is a nice tool to track actual
>> dependency
>> > tree - check it out.
>> >
>> > At this point I will vote against your suggested changes for the
>> following
>> > reasons:
>> >
>> > - you enhance somewhat TimeStamp.toString() output at the expense of
>> > introducing tight coupling between TimeStamp and TimeStampFormat. I
>> prefer
>> > keeping TimeStamp simple and its toStirng() method consistent across
>> > timezones. Its very easy to use TimeStampFormat in the printing code
>> (or
>> > use
>> > helpers).
>> >
>> > - your yahoo source uses hardcoded 16:00 as close time. Arguably, this
>> is
>> > better than 00:00. However, I would prefer a settable time instead
>> (just
>> > in
>> > case some instruments are traded on different exchanges that have
>> > different
>> > close times). Another solution is to use a post-processing filter that
>> > adjusts time - this gives full control and the ability to set time
>> > depending
>> > on the instrument (and can be used with different sources)... Maybe not
>> > feasible for this simple source...
>> >
>> > Btw, thanks for the suggestions. I do appreciate your efforts towards
>> > learning and using the aq, and especially your readiness to ask
>> questions,
>> > debug, and share the code.
>> >
>> > Cheers,
>> > -Mike
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Re%3A-activequant-base-and-activequant-examples-release-1.2-is-out%21-tp25429279p25447891.html
>> Sent from the ActiveQuant mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> ccapi mailing list
>> ccapi@...
>> http://activestocks.de/cgi-bin/mailman/listinfo/ccapi
>>
>
> _______________________________________________
> ccapi mailing list
> ccapi@...
> http://activestocks.de/cgi-bin/mailman/listinfo/ccapi
>
>
http://www.nabble.com/file/p25454418/KirillsTest-2009-09-15.zip
KirillsTest-2009-09-15.zip  http://www.nabble.com/file/p25454418/console.txt
console.txt
--
View this message in context: http://www.nabble.com/Re%3A-activequant-base-and-activequant-examples-release-1.2-is-out%21-tp25429279p25454418.html
Sent from the ActiveQuant mailing list archive at Nabble.com.

_______________________________________________
ccapi mailing list
ccapi@...
http://activestocks.de/cgi-bin/mailman/listinfo/ccapi


_______________________________________________
ccapi mailing list
ccapi@...
http://activestocks.de/cgi-bin/mailman/listinfo/ccapi

Re: activequant-base and activequant-examples release 1.2 is out!

by Mike Kroutikov-2 :: Rate this Message:

| View Threaded | Show Only this Message

Btw, I experienced problems making activequant-examples compile. Research showed that this was due to the duplicate repository id: "real" repository (with http:// url) has the same id as "local" repository (with file:/// url). I fixed this by removing file:// variant. I think this used to work just fine not long ago. Maybe maven engine get upgraded, donno. In any case, it should be smooth now - just use the 1.3-SNAPSHOT.

On Tue, Sep 15, 2009 at 8:14 PM, Mike Kroutikov <pgmmpk@...> wrote:
Indeed, its a bug in MarketDataReplayService, aka backtester.

It shows up when subscription of a different kind or instrument (comparing to the already running) is dynamically created. For example: subscribe for the GOOG candles and in the middle of backtester run subscribe for AAPL candles - and watch virtual backtester time to jump back. In your case PaperBroker was creating a dynamic subscription in response for the order request.

Workaround would be to create TradeIndication subscription in the Start method of trading system (for all traded instruments).

I submitted a fix that should take care of the problem. Please, test

Strange that we did not see this before. I suspect that all other configurations were using TradeIndication feeds and therefore were subscribing to it "statically" (i.e. in the Start method).

Regards,
-Mike


On Tue, Sep 15, 2009 at 9:50 AM, Kirill Jacobson <activequant.nabble@...> wrote:

Mike,

I attached my code and the output. It is based on the sample that you posted
on 09/07
(www.nabble.com/BalanceBook--Account--OrderTracker--to25177571.html). To
make it easier to debug I removed the charting code and reduced the time
interval to four trading days.

-Kirill


public class MainBacktest {
       private final static TimeStamp start = format.parse("2004/08/19");
       private final static TimeStamp end   = format.parse("2004/08/24");
       static {
               TimeStamp.DEFAULT_FORMAT = new TimeStampFormat("MM/dd/yyyy HH:mm:ssZZZ");
       }
}

public class TradeSystemLogic {
       int candelCounter = 0;
       private void onCandle(Candle candle) {

               log.info("[evaluate] candle #" + candelCounter + ": " + candle);
               if (candelCounter++ != 1)
                       return;

               log.info("BUY @market");

               Order order = new Order();
               order.setInstrumentSpecification(spec);
               order.setOrderTimeStamp(new TimeStamp());
               order.setOrderSide(OrderSide.BUY);
               order.setOrderType(OrderType.MARKET);
               order.setQuantity(quantity);
               order.setOrderSide(OrderSide.BUY);
               position = positionService.openPosition(order);
       }
}



Mike Kroutikov-2 wrote:
>
> Kirill,
> Re: backtester. Could you publish your complete code? My understanding is
> that backtester fires events strictly in ascending time order. What you
> describe suggests that backtester time jerks back at some point, which
> would
> be wrong.
>
> Here is how its supposed to work:
>
> TS subscribes for the feed. Since feed is simulated, subscription request
> is
> processed by backtester which triggers fetching of the historical data
> interval.
> TS may decide to subscribe to another feed. Again, the request will pass
> thru backtester and will trigger fetching of historical data for this
> instrument, and adding it to the merge set.
> TS may issue an order. With the paper broker this should trigger
> activation
> of corresponding subscription by the broker. Again, corresponding
> historical
> data series should be added to the merge set (if not already there).
>
> Regards,
> -Mike
>
> On Tue, Sep 15, 2009 at 1:12 AM, Kirill Jacobson <
> activequant.nabble@...> wrote:
>
>>
>> Mike, thanks for the kind words and encouragement.
>>
>> I am slowly but surely getting to the cause of the problem with the back
>> tester. Now I wounder what is the right way to fix it. This is what
>> happens.
>> The back tester reads daily candles and at some point issues a market
>> order
>> to buy shares. To my surprise the order is filled not at the current
>> price
>> or the next day's price, but at some price in the past (the price on the
>> first day of the series to be precise).
>>
>> This is my understanding of what happens: an order is submitted, tracker
>> is
>> created, subscription is activated, candles are retrieved, trade
>> indications
>> are created and merged into the replay service, which reads them and
>> distributes to subscribers. Unfortunately merge doesn't remove trade
>> indications that happened prior (backtester time) to the most recent
>> indication that has already been removed from the pump. Is this by design
>> or
>> is it a bug? I will investigate it further tomorrow.
>>
>> Good night,
>> Kirill
>>
>>
>>
>> Mike Kroutikov-2 wrote:
>> >
>> > Kirill,
>> >
>> > \opt stuff: you apparently asked maven to "deploy" the app. No point in
>> > doing this locally. Deploy action is configured this way for the aq
>> > server.
>> > Just delete it :)
>> >
>> > I do not get your comment that states "it is easier not have any 1.2
>> files
>> > in the local repository". Maven controls dependencies, not you.
>> Existence
>> > of
>> > files in local repository does not hurt, and does not change anything -
>> > nothing gets included in the classpath unless dependency is directly or
>> > transitively derived from pom.xml. Be prepared to see a lot of stuff in
>> > your
>> > local m2 repo, with different versions - its normal. In eclipse, there
>> is
>> > "maven dependency viewer", which is a nice tool to track actual
>> dependency
>> > tree - check it out.
>> >
>> > At this point I will vote against your suggested changes for the
>> following
>> > reasons:
>> >
>> > - you enhance somewhat TimeStamp.toString() output at the expense of
>> > introducing tight coupling between TimeStamp and TimeStampFormat. I
>> prefer
>> > keeping TimeStamp simple and its toStirng() method consistent across
>> > timezones. Its very easy to use TimeStampFormat in the printing code
>> (or
>> > use
>> > helpers).
>> >
>> > - your yahoo source uses hardcoded 16:00 as close time. Arguably, this
>> is
>> > better than 00:00. However, I would prefer a settable time instead
>> (just
>> > in
>> > case some instruments are traded on different exchanges that have
>> > different
>> > close times). Another solution is to use a post-processing filter that
>> > adjusts time - this gives full control and the ability to set time
>> > depending
>> > on the instrument (and can be used with different sources)... Maybe not
>> > feasible for this simple source...
>> >
>> > Btw, thanks for the suggestions. I do appreciate your efforts towards
>> > learning and using the aq, and especially your readiness to ask
>> questions,
>> > debug, and share the code.
>> >
>> > Cheers,
>> > -Mike
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Re%3A-activequant-base-and-activequant-examples-release-1.2-is-out%21-tp25429279p25447891.html
>> Sent from the ActiveQuant mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> ccapi mailing list
>> ccapi@...
>> http://activestocks.de/cgi-bin/mailman/listinfo/ccapi
>>
>
> _______________________________________________
> ccapi mailing list
> ccapi@...
> http://activestocks.de/cgi-bin/mailman/listinfo/ccapi
>
>
http://www.nabble.com/file/p25454418/KirillsTest-2009-09-15.zip
KirillsTest-2009-09-15.zip  http://www.nabble.com/file/p25454418/console.txt
console.txt
--
View this message in context: http://www.nabble.com/Re%3A-activequant-base-and-activequant-examples-release-1.2-is-out%21-tp25429279p25454418.html
Sent from the ActiveQuant mailing list archive at Nabble.com.

_______________________________________________
ccapi mailing list
ccapi@...
http://activestocks.de/cgi-bin/mailman/listinfo/ccapi



_______________________________________________
ccapi mailing list
ccapi@...
http://activestocks.de/cgi-bin/mailman/listinfo/ccapi

Re: activequant-base and activequant-examples release 1.2 is out!

by Kirill Jacobson :: Rate this Message:

| View Threaded | Show Only this Message

Mike, I have tested rev:460 and it works like a charm. Thank you, Kirill

Mike Kroutikov-2 wrote:
Indeed, its a bug in MarketDataReplayService, aka backtester.

It shows up when subscription of a different kind or instrument (comparing
to the already running) is dynamically created. For example: subscribe for
the GOOG candles and in the middle of backtester run subscribe for AAPL
candles - and watch virtual backtester time to jump back. In your case
PaperBroker was creating a dynamic subscription in response for the order
request.

Workaround would be to create TradeIndication subscription in the Start
method of trading system (for all traded instruments).

I submitted a fix that should take care of the problem. Please, test

Strange that we did not see this before. I suspect that all other
configurations were using TradeIndication feeds and therefore were
subscribing to it "statically" (i.e. in the Start method).

Regards,
-Mike