You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(32) |
Oct
(144) |
Nov
(14) |
Dec
(44) |
2002 |
Jan
(16) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
(65) |
Nov
(4) |
Dec
(30) |
2003 |
Jan
(84) |
Feb
(101) |
Mar
(58) |
Apr
(30) |
May
(138) |
Jun
(336) |
Jul
(36) |
Aug
(12) |
Sep
(8) |
Oct
(4) |
Nov
(12) |
Dec
(12) |
2004 |
Jan
(186) |
Feb
(274) |
Mar
(248) |
Apr
(18) |
May
(104) |
Jun
(48) |
Jul
(144) |
Aug
(98) |
Sep
(60) |
Oct
(72) |
Nov
(32) |
Dec
(130) |
2005 |
Jan
(84) |
Feb
(130) |
Mar
(50) |
Apr
(106) |
May
(240) |
Jun
(154) |
Jul
(66) |
Aug
(82) |
Sep
(36) |
Oct
(18) |
Nov
(14) |
Dec
(4) |
2006 |
Jan
(68) |
Feb
(2) |
Mar
(14) |
Apr
(6) |
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
(50) |
Dec
(4) |
2007 |
Jan
(14) |
Feb
(42) |
Mar
(70) |
Apr
(30) |
May
(8) |
Jun
|
Jul
(2) |
Aug
(2) |
Sep
|
Oct
(88) |
Nov
(168) |
Dec
(2) |
2008 |
Jan
(56) |
Feb
(372) |
Mar
(446) |
Apr
(112) |
May
(144) |
Jun
(94) |
Jul
(208) |
Aug
(90) |
Sep
(26) |
Oct
(10) |
Nov
(2) |
Dec
|
2009 |
Jan
|
Feb
(8) |
Mar
|
Apr
(46) |
May
(188) |
Jun
(120) |
Jul
(448) |
Aug
(202) |
Sep
(4) |
Oct
(72) |
Nov
(154) |
Dec
(2) |
2010 |
Jan
(58) |
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
(68) |
Aug
(24) |
Sep
|
Oct
|
Nov
|
Dec
(11) |
2011 |
Jan
(6) |
Feb
(11) |
Mar
(8) |
Apr
(10) |
May
(4) |
Jun
|
Jul
|
Aug
(8) |
Sep
|
Oct
(3) |
Nov
(2) |
Dec
|
2012 |
Jan
|
Feb
(13) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(31) |
Aug
(21) |
Sep
(2) |
Oct
(1) |
Nov
(29) |
Dec
(17) |
2013 |
Jan
(2) |
Feb
|
Mar
|
Apr
(25) |
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
(3) |
Oct
(4) |
Nov
(11) |
Dec
|
2016 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
From: r. a. s. <uw...@fl...> - 2023-09-06 17:33:24
|
gt'ers (and acr) here is my gt_bugs file -- have not updated it since Nov 27 2016 so that's how long ago i hacked on the gt code. note i'm not much of perl (or any) coder err software engineer, just a hacker and re-user of things i can understand. the gt_bugs file is distant past at top to most recent time at bottom and is really just a 'train-of-thought' log as issues were id'ed and noted. graphic.pl versus my hack chart.pl as of now (mid 2023) i don't use anything but chart.pl to generate chart images, and a bit of cron and small handful of shell (bash) scripts to coerce the various gconf files to work with the current calendar. update_graphs is one such script -- it basically hacks a boilerplate gconf file and arranges to run a number of symbols with chart.pl (or graphic.pl) on it. it uses other ras hacks and is definitely only gonna work on my system without substantial alteration as will any other hacks it uses. you're probably better off inventing your own version of this rather than try to understand-unravel and make my hack work for you. my largest issue with gt is being unable to count events (signals) within a system and test and alter these event counts based on elapsed time periods that are generally day-date fixed. if we could do that then 'programming' an ibd buy signal would be possible. it might be a trivial problem for a software engineer, but i've not been able to figure it out, but without a readily available source of security ohlcv data, since yahoo locked it down, i've lost substantial interest. plus, the current state-of-art of most brokerage accounts provide charting far more feature packed than gt offers, provided you have a more modern computer than i do. about the gt_bugs file i write about this events and day-date issue around line 145, but i don't see any notes on hacks in signals/ or indicators/ that i might have worked on -- if i re-discover such i'll send them off too. well -- seems these (such as they are) are already be included in the ras hack distribution* of gt -- see GT/Indicators/Generic/mymaxinperiod.pm, and various GT/Signals/Generic/*pm. be sure to either read to code for my commentary and also consider perldoc -t filename for clues ... i don't suggest these even are working perl modules. finally, i've also attached file 'ibd_canslim' and the tarball ibd_canslim.tar.gz which seems to be the final effort. i'm of recollection that about at this point it became clear that user defined variables were needed in gt to allow windowing over a range to time-periods along with fixed values for the time-frame of these variables. aloha ras attached: gt_bugs ibd_canslim ibd_canslim.tar.gz * ras hack distribution available to anyone by request |
From: Adam R. <ac....@li...> - 2023-08-25 01:25:34
|
Has anyone ever put together a formal grammar for GT system syntax? I am just starting to get to understanding it and think that a top down view of the syntax would be helpful. |
From: r. a. s. <uw...@fl...> - 2020-04-10 19:41:42
|
funky_one and other interested gt'ers geniustrader_status gt is not really active anymore. it works as it always has, but getting the needed market data is no longer freely available. basically gt requires security market data tuples of stohlcv data (eg security, timestamp, open, high, low, close, volume) for the duration of the timestamp period. gt DOES NOT provide a mechanism to fetch or to store this market data. gt does provide many flexible interfaces for any (most) local data access methods. the primary market data downloader (and database) was beancounter (also written in perl) (re Dirk Eddelbuettel <ed...@de...>) which primarily used yahoo. now beancounter is flexible enough to support alternative download sources, methods and database engines, but so far i've found no FREE way to get end-of-day market ohlcv data for many 1000s of symbols. that includes asking each of my 3 stockbrokers for an api-interface to download eod well after the market has closed. now unfortunately yahoo has embargoed getting the raw data as implemented by beancounter (multiple security symbols in single fetch). there are ways around this but it can only be done on a single symbol at a time. updating a few 1000 symbols on an individual basis is just too time-consuming methinks. i've got a beancounter integrated bash-perl hack that fetches just sp500 (^GSPC) but it is always for the previous day. should be simple, (well not likely) to extend it for multiple symbols ... but you might have better luck (a better stockbroker) or are willing to pay a nominal fee for the data. there are a good number of such providers and i'm more than willing to help you getting this to work with your choice of database (i recommend beancounter with your choice of db engine) and that database to work with gt. if you are still interested in gt and i'll arrange to get you the source tarballs. the ras hack version comes in 3 tarballs, one for user app scripts, one for gt code proper and the top-level dir with info and other stuff. this arrangement allows one to have different gt versions resident without interference. please note that beancounter is not distributed with gt, and the ras hack of it is of limited use unless you have my hardware and software environment or intend to do a lot of tweaking to make it compatible with your hardware and software. hopefully Dirk Eddelbuettel will allow me to distribute my hack of it (beancounter), but no one has asked me for it yet. last check of gz tarball sizes: scripts: about 1mb gtlib: about 3/4mb tld: about 3/4mb aloha ras |
From: Robert R. <the...@gm...> - 2019-11-16 16:17:13
|
I've been looking at what trading strategy software has been done in Perl and came across this project. A lot of good work has been put into it, but it seems development has stopped. As far as I can tell, the SVN repository was lost somewhere in early 2018. I managed to find these old sources on github: https://github.com/ecocode/GeniusTrader-CPAN https://www.openhub.net/p/GeniusTrader-CPAN Are there any more recent source repositories available somewhere? I'm working on getting this to build on Windows under more modern versions of Perl. Thanks. Robert |
From: Robert A. S. <uw...@fl...> - 2018-01-31 22:45:56
|
gt'ers somehow the recent changes to sourceforge have broken access to the geniustrader source code repository. until i can resolve that problem feel free to contact me, ras directly at acm dot org and i will email you a gz, bz2 or xz tarball of the code (please indicate preference). the size will be on the order of 2.5 Mbytes. sorry for the inconvenience, aloha ras |
From: Raphael H. <ra...@ou...> - 2018-01-31 11:55:54
|
Hello, Le mardi 30 janvier 2018, Jason Orr a écrit : > All links are broken and the svn has moved and I can't get the url to > work???? I don't really understand what happened. It looks like the "Browse SVN" button is just an external link that was pointing to svn.geniustrader.org and then somehow this was mapped back to sourceforge... and now it looks like the SVN repository from there is gone. I enabled the SVN tool on the Sourceforge project but it now points to a new empty repository (see "Code" link). Bjarne? ras? Do you have any idea? Do you have backups of the svn repository (with history)? Cheers, -- Raphaël Hertzog ◈ Writer/Consultant ◈ Debian Developer Discover the Debian Administrator's Handbook: → https://debian-handbook.info/get/ |
From: Jason O. <the...@gm...> - 2018-01-30 03:17:40
|
All links are broken and the svn has moved and I can't get the url to work???? |
From: Robert A. S. <uw...@fl...> - 2016-02-23 00:45:58
|
Mark McClellan wrote: > I've hacked GT::Graphics::Tools.pm to build a clean intra-day axis. > << big snip>> aloha mark and all interested gt'ers i'm a bit perplexed -- while i like the intraday time period axis example you provided i've been unable to duplicate something similar with my extremely limited bits of intraday data. i have some old FIAT 1min data from 2010 ( 05 jul to through 03 dec ). with a datafile /tmp/FIAT_2010-08-02_1MIN.txt with time periods from 2010-08-02 09:00:00 through 2010-08-02 20:29:00 and with the attached $HOME/.gt/options_textdb file (for my system tweak as needed for yours) linked to $HOME/.gt/options and using the GT svn revision 718 *prior* to the submitted patch and the following graphic.pl command line: ./graphic.pl \ --file /usr/local/src/genius_trader/svn_repo/Scripts/mcclellan_intraday_patch.gconf \ --timeframe 1min \ --opt 'DB::timeframes_available=1min,30min,hour,day,week,month,year' \ --opt 'DB::text::fields::datetime=5' \ --opt 'DB::text::fields::open=0' \ --opt 'DB::text::fields::high=1' \ --opt 'DB::text::fields::low=2' \ --opt 'DB::text::fields::close=3' \ --opt 'DB::text::fields::volume=4' \ --opt 'DB::text::header_lines=0' \ --opt 'DB::text::directory=/tmp/' \ --opt 'DB::text::file_extension=_2010-08-02_9-16.txt' \ --opt 'DB::text::marker=\t' \ --opt 'DB::text::order=0' \ --opt 'DB::text::format=0' \ --out ./mcclellan_intraday_fiat_1min_prepatch.png \ FIAT i was able to generate the attached graphic.pl chart: (mcclellan_intraday_fiat_1min_prepatch.png). notice the time period axis labels are limited to two 15:00 and 16:00. this is incorrect, since the time period data should start at 09:00, so somewhere there is a data truncation happening. is GT svn revision 718 the versuion you patched? i might be out-of-date. ok -- so there is a problem there somewhere, never-the-less i applied the patch locally and changing the output cmdline directive to --out ./mcclellan_intraday_fiat_1min_postpatch.png i got the chart attached as mcclellan_intraday_fiat_1min_postpatch.png. ok -- the patch truncated the year-month-day part of the date. i don't know that that is a good thing or not. it is possible my data truncation problem might be clobbering some of the good-ness of the patch. so far i've gotten more confused the more i evaluate charts based on my /tmp/FIAT data, but i will continue to ponder it as time permits. i'm still looking to find where the data is being truncated and will then re-evaluate the patch in a more complete context. mark if you can and want to share your spx intraday database (a small piece only; say a month or two at most) and or any of the other config data needed to generate a graphic.pl chart please contact me off-list @ ras at acm dot org. aloha ras |
From: Mark M. <ma...@gm...> - 2016-01-15 14:30:50
|
I've hacked GT::Graphics::Tools.pm to build a clean intra-day axis. Tools.pm attached. [image: 20160114gspc_5.png] |
From: Delix <del...@t-...> - 2013-11-21 20:53:39
|
Hi Robert, after some reading I decided not to follow the recommendations to use HTML::MASON and the .xml database for the further evaluation of the backtest results. I'm not at all sure whether I could get the results I want finally, but I'm pretty sure the effort would be enormous..... So I think, it's better to try another approach and to get the backtest results finally stored in a SQLite database. The best way I found is to modify the Report.pm module for this purpose. The options I found : 1. including the SQL statements directly in the module, including the connect, insert and quit statements 2. writing the output additionally to the formated output written on the screen into an unformated csv file. SQLite can import this csv file later by a simple command file. my questions : - must I expect any serious conflicts with the other GT modules/scripts if I choose one of these options ? - any does and don'ts ? - or recommendations ? would be nice if you can send a short statement on this plan... ciao, delix -- Delix <del...@t-...> |
From: Robert A. S. <ra...@ac...> - 2013-11-12 16:24:36
|
Delix wrote: > On Mon, 11 Nov 2013 14:34:24 -0800 > "Robert A. Schmied" <ra...@ac...> hatte geschrieben : > < snip > > > if it is 'available on request' -- can you please send me copy of this > version ? are there modifications all over or in certain parts of the > moduls ? are they marked/documented ? > > < snip > you sure can, i'll send it to you directly along with unpacking/install instructions. it comes as two (well three actually) tarballs, one for each of the standard gt directories: gt_top_level, GT and Scripts. aloha ras |
From: Delix <del...@t-...> - 2013-11-12 08:43:42
|
On Mon, 11 Nov 2013 14:34:24 -0800 "Robert A. Schmied" <ra...@ac...> hatte geschrieben : > >>./backtest --nb-item=840 CCItest[8,-30,8,30,1.4,1.4] BUND > >>oops --nb-item=840 is greater than size of BUND.txt?! > >> wc /var/tmp/delix_cci/BUND.txt > >> 829 4557 35310 /var/tmp/delix_cci/BUND.txt > >>i don't know if that is good or bad, it is just out-of-sync. > > > > it has no effect as far as I can tell > > if i recall correctly --nb-item has no effect when using DB:Text > > >>just for fun i tried to duplicate your exact problem but got different > >>results. i suppose it could be due to differences in my version of gt > >>and the one you are using ... > > > > yes, seems so -- I still get different results (26 gainers and 27 > > loosers with an overall performance of +1.3%) > > but this seems to be at least reasonable. > > I grabbed my version (v.720) from the sourceforge repo, I think it was > > the trunk branch. > > yep -- so far i've only been testing with my 'available on request' version > which has it's own flavor of kruft and rough edges ... if it is 'available on request' -- can you please send me copy of this version ? are there modifications all over or in certain parts of the moduls ? are they marked/documented ? > > think i found the principle testing problem i was having -- using a bad > (incomplete) set of DB::text::fields:: directives for the data file i > was using -- that problem will always generate hard to diagnose issues ... > > can't do much more today, but will re-evaluate things again tomorrow. > I continue with the CCI testing..... -- Delix <del...@t-...> |
From: Robert A. S. <ra...@ac...> - 2013-11-11 22:34:32
|
Delix wrote: > On Mon, 11 Nov 2013 11:16:29 -0800 > "Robert A. Schmied" <ra...@ac...> hatte geschrieben : > > > >>i've mentioned the missing volume data values in about 1/2 of the >>BUND prices data -- that cannot be good, but haven't looked at cci >>to see if it or any associated indicators/signals use volume data. > > > I tried both the part with and without volume data -- this had no > effect yea! it doesn't appear that any sys-sig-indic your trading system is using depends on volume ... > > >>i've looked at backtest text output -- study the very top line: it >>prints the actual trading system that gt processed based in the inputs >>it got -- this is significant because it can show you how arguments >>have been parsed and substituted. >> >>look at the right side -- notice the last CloseStrategy CS:OppositeSignal >>is not separated from the prior one with a '|' character: >> >> CS:Stop:KeepRunUp 1.4 CS:OppositeSignal {I:Prices HIGH} {I:Prices CLOSE}|MM:Basic >>----- right about here ^^^^ >> >>this is also present in your options file: >> Aliases::Global::CCItest[] SY:Generic \ >> {S:Generic:CrossOverUp {I:CCI #1} #2 } \ >> {S:Generic:CrossOverDown {I:CCI #3} #4} | \ >> TF:LongOnly | \ >> CS:Stop:Fixed #5 | \ >> CS:Stop:KeepRunUp #6 \ >> CS:OppositeSignal >> >>this is why i tend to format aliases with leading '|' chars like this: >> Aliases::Global::CCItestso[] SY:Generic \ >> {S:Generic:CrossOverUp {I:CCI #1} #2 } \ >> {S:Generic:CrossOverDown {I:CCI #3} #4} \ >> | TF:ShortOnly \ >> | CS:Stop:Fixed #5 \ >> | CS:Stop:KeepRunUp #6 \ >> | CS:OppositeSignal > > > BINGO: that's it (at least for the big part of it...) > thanky again Robert -- I must apolegize for all the time you spent on > MY problems... > > >>now let's look at your command line: >>./backtest --nb-item=840 CCItest[8,-30,8,30,1.4,1.4] BUND >>oops --nb-item=840 is greater than size of BUND.txt?! >> wc /var/tmp/delix_cci/BUND.txt >> 829 4557 35310 /var/tmp/delix_cci/BUND.txt >>i don't know if that is good or bad, it is just out-of-sync. > > > it has no effect as far as I can tell if i recall correctly --nb-item has no effect when using DB:Text > > >>using your slight altered 'options' file suited for my system and dirs, >>your exact BUND data and the following (bash) backtest command line that >>outputs in .html and graphs the trades all in the same html file: >> >>bash-3.00$ ./backtest.pl --timeframe day --html \ >> -dt -gr /var/tmp/delix_cci/bt_BUND_CCItestSO.png \ >> --start 2010-06-21 --end 2013-09-13 \ >> --opt 'DB::text::directory=/var/tmp/delix_cci' \ >> --opt 'DB::timeframes_available=day,week,month,year' \ >> --opt 'DB::text::format=0' \ >> --opt 'DB::text::marker=\t' \ >> 'CCItestso[8,-30,8,30,1.4,1.4]' BUND \ >> > /var/tmp/delix_cci/bt_BUND_CCItestSO.html \ >> 2> /var/tmp/delix_cci/bt_BUND_CCItestSO.log >> >>and i get the two attached files (for the html to connect with the png >> >>let me know if this helps you -- my first thought in order to check >>closestratgy correctness would be to reduce the data range to just a >>few months or quarters. >> >>just for fun i tried to duplicate your exact problem but got different >>results. i suppose it could be due to differences in my version of gt >>and the one you are using ... > > > yes, seems so -- I still get different results (26 gainers and 27 > loosers with an overall performance of +1.3%) > but this seems to be at least reasonable. > I grabbed my version (v.720) from the sourceforge repo, I think it was > the trunk branch. yep -- so far i've only been testing with my 'available on request' version which has it's own flavor of kruft and rough edges ... think i found the principle testing problem i was having -- using a bad (incomplete) set of DB::text::fields:: directives for the data file i was using -- that problem will always generate hard to diagnose issues ... can't do much more today, but will re-evaluate things again tomorrow. > > Once agai, thanks for your help. Robert. I'l really really to my best > to avoid such simple mistakes .... not a problem -- it provides real-world user feedback that should ideally be detected and warned about wherever it happens and can be detected ... hard to do though ... aloha ras > > |
From: Delix <del...@t-...> - 2013-11-11 20:45:17
|
On Mon, 11 Nov 2013 11:16:29 -0800 "Robert A. Schmied" <ra...@ac...> hatte geschrieben : > i've mentioned the missing volume data values in about 1/2 of the > BUND prices data -- that cannot be good, but haven't looked at cci > to see if it or any associated indicators/signals use volume data. I tried both the part with and without volume data -- this had no effect > i've looked at backtest text output -- study the very top line: it > prints the actual trading system that gt processed based in the inputs > it got -- this is significant because it can show you how arguments > have been parsed and substituted. > > look at the right side -- notice the last CloseStrategy CS:OppositeSignal > is not separated from the prior one with a '|' character: > > CS:Stop:KeepRunUp 1.4 CS:OppositeSignal {I:Prices HIGH} {I:Prices CLOSE}|MM:Basic > ----- right about here ^^^^ > > this is also present in your options file: > Aliases::Global::CCItest[] SY:Generic \ > {S:Generic:CrossOverUp {I:CCI #1} #2 } \ > {S:Generic:CrossOverDown {I:CCI #3} #4} | \ > TF:LongOnly | \ > CS:Stop:Fixed #5 | \ > CS:Stop:KeepRunUp #6 \ > CS:OppositeSignal > > this is why i tend to format aliases with leading '|' chars like this: > Aliases::Global::CCItestso[] SY:Generic \ > {S:Generic:CrossOverUp {I:CCI #1} #2 } \ > {S:Generic:CrossOverDown {I:CCI #3} #4} \ > | TF:ShortOnly \ > | CS:Stop:Fixed #5 \ > | CS:Stop:KeepRunUp #6 \ > | CS:OppositeSignal BINGO: that's it (at least for the big part of it...) thanky again Robert -- I must apolegize for all the time you spent on MY problems... > now let's look at your command line: > ./backtest --nb-item=840 CCItest[8,-30,8,30,1.4,1.4] BUND > oops --nb-item=840 is greater than size of BUND.txt?! > wc /var/tmp/delix_cci/BUND.txt > 829 4557 35310 /var/tmp/delix_cci/BUND.txt > i don't know if that is good or bad, it is just out-of-sync. it has no effect as far as I can tell > > using your slight altered 'options' file suited for my system and dirs, > your exact BUND data and the following (bash) backtest command line that > outputs in .html and graphs the trades all in the same html file: > > bash-3.00$ ./backtest.pl --timeframe day --html \ > -dt -gr /var/tmp/delix_cci/bt_BUND_CCItestSO.png \ > --start 2010-06-21 --end 2013-09-13 \ > --opt 'DB::text::directory=/var/tmp/delix_cci' \ > --opt 'DB::timeframes_available=day,week,month,year' \ > --opt 'DB::text::format=0' \ > --opt 'DB::text::marker=\t' \ > 'CCItestso[8,-30,8,30,1.4,1.4]' BUND \ > > /var/tmp/delix_cci/bt_BUND_CCItestSO.html \ > 2> /var/tmp/delix_cci/bt_BUND_CCItestSO.log > > and i get the two attached files (for the html to connect with the png > > let me know if this helps you -- my first thought in order to check > closestratgy correctness would be to reduce the data range to just a > few months or quarters. > > just for fun i tried to duplicate your exact problem but got different > results. i suppose it could be due to differences in my version of gt > and the one you are using ... yes, seems so -- I still get different results (26 gainers and 27 loosers with an overall performance of +1.3%) but this seems to be at least reasonable. I grabbed my version (v.720) from the sourceforge repo, I think it was the trunk branch. Once agai, thanks for your help. Robert. I'l really really to my best to avoid such simple mistakes .... -- Delix <del...@t-...> |
From: Robert A. S. <ra...@ac...> - 2013-11-11 19:16:42
|
Delix wrote: > On Fri, 08 Nov 2013 11:13:17 -0800 > "Robert A. Schmied" <ra...@ac...> hatte geschrieben : > > > >>aloha delix and fellow gt'ers >> >>ok -- i've found the source of the bad date strings that are causing >>i:g:M*InPeriod to fail in the cs:s:KeepRunUp directive. it has to do >>with the sub hour timeframe capabilities implemented via GT::Prices.pm >>*NOT I:Prices* >> >>you can avoid the problem by forcing date parsing format 0, which is >>what the sample 13000.txt file uses. by default date parsing format 3 >>is used and that is the source of the problem. >> >>tentatively you can eliminate the problem by two changes to the file >>GT/Prices.pm. in sub loadtxt >>change line (around 372 or 1465 depending on your source version) >>to: >> ( $year, $month, $day, $tm ) = split /[- ]/, $udate, 4; >>from: >> ( $year, $month, $day, $tm ) = split /[- ]/, $udate; >> >>and change line (around 388 or 1485) >>to: >> $date .= " $tm" if $tm && $tm != "00:00:00"; >>from: >> $date .= " $tm" if $tm; >> >> >> >> >>i've done *very limited* testing of this change which is >>continuing, but to get you started here are the basic >>failing and work-around commands i've been evaluating. >> >>this defaults to date parsing format 3 and without the changes >>to the file GT/Prices.pm noted above should generate erroneous results. >>bash-3.00$ ./backtest.pl -dt -gr ./graphs/bt_cs-kru_13000.png \ >> --start 2000-09-04 --end 2001-06-01 \ >> --opt 'DB::module=Text' \ >> --opt 'DB::text::directory=/usr/local/src/genius_trader/sample_data' \ >> --opt 'DB::timeframes_available=day,week,month,year' \ >> --opt 'Brokers::module=NoCosts' \ >> --timeframe day \ >> --html \ >> 'SY::Generic >> {S:Generic:CrossOverUp {I:SMA 20 {I:Prices CLOSE}} >> {I:SMA 60 {I:Prices CLOSE}}} >> {S:Generic:CrossOverDown {I:SMA 20 {I:Prices CLOSE}} >> {I:SMA 60 {I:Prices CLOSE}}} >> | TF:ShortOnly >> | CS:Stop:KeepRunUp >> ' 13000 > ./bt_cs-kru_13000.html >> >>this one forces date parsing format 0 and should return more rational >>results. in addition this should return identical results with or >>without the change to file GT/Prices.pm. >>bash-3.00$ ./backtest.pl -dt -gr ./graphs/bt_cs-kru_13000.png \ >> --start 2000-09-04 --end 2001-06-01 \ >> --opt 'DB::module=Text' \ >> --opt 'DB::text::directory=/usr/local/src/genius_trader/sample_data' \ >> --opt 'DB::timeframes_available=day,week,month,year' \ >> --opt 'Brokers::module=NoCosts' \ >> --opt 'DB::text::format=0' \ >> --timeframe day \ >> --html \ >> 'SY::Generic >> {S:Generic:CrossOverUp {I:SMA 20 {I:Prices CLOSE}} >> {I:SMA 60 {I:Prices CLOSE}}} >> {S:Generic:CrossOverDown {I:SMA 20 {I:Prices CLOSE}} >> {I:SMA 60 {I:Prices CLOSE}}} >> | TF:ShortOnly >> | CS:Stop:KeepRunUp >> ' 13000 > ./bt_cs-kru_13000.html >> >>open the output file (./bt_cs-kru_13000.html) in your favorite browser >> >> >> >>*note* -- changes made to GT/Indicators/Generic/MaxInPeriod.pm and >>GT/Indicators/Generic/MinInPeriod.pm must be reversed. >> >> >> >> >>things i'm still looking at: >> 1) does CS:Stop:KeepRunUp really do what the pod says it does >> -->> anybody got thoughts on that please let us know >> 2) is the change to GT::Prices.pm correct for all timeframes and >> most common database types. >> 3) does this change correct other CS:Stop: problems. >> > > > Hi Robert ! > Thanks for all your help and time you spend on it. > The fix seems to solve this issue at least to some extent. > I could run your example without errors and warnings and the results > look rational to me. > However, then I tried my setup I use for the testing. The options file > and the data file are attached below. > (btw: I had to put the system into the option file as I wasn't able to > access the local aliases for systems -- whereas the local aliases for > signals are accessable) . > I run the tests with the command > ./backtest --nb-item=840 CCItest[8,-30,8,30,1.4,1.4] BUND > > and the first results seems to be promissing. Actually, I think the > results are correct. > Then I started with variations of the systems. And here I run into the > next error : using the same command and changing the TF:LongOnly to > TF:ShortOnly results in no errors or warnings, but strange results. > I attached the output file for this test, too. > > Just hope, the email with all the attachments gets through..... think so -- i got the BUND.txt, options and backtest text output. i've mentioned the missing volume data values in about 1/2 of the BUND prices data -- that cannot be good, but haven't looked at cci to see if it or any associated indicators/signals use volume data. i've looked at backtest text output -- study the very top line: it prints the actual trading system that gt processed based in the inputs it got -- this is significant because it can show you how arguments have been parsed and substituted. look at the right side -- notice the last CloseStrategy CS:OppositeSignal is not separated from the prior one with a '|' character: CS:Stop:KeepRunUp 1.4 CS:OppositeSignal {I:Prices HIGH} {I:Prices CLOSE}|MM:Basic ----- right about here ^^^^ this is also present in your options file: Aliases::Global::CCItest[] SY:Generic \ {S:Generic:CrossOverUp {I:CCI #1} #2 } \ {S:Generic:CrossOverDown {I:CCI #3} #4} | \ TF:LongOnly | \ CS:Stop:Fixed #5 | \ CS:Stop:KeepRunUp #6 \ CS:OppositeSignal this is why i tend to format aliases with leading '|' chars like this: Aliases::Global::CCItestso[] SY:Generic \ {S:Generic:CrossOverUp {I:CCI #1} #2 } \ {S:Generic:CrossOverDown {I:CCI #3} #4} \ | TF:ShortOnly \ | CS:Stop:Fixed #5 \ | CS:Stop:KeepRunUp #6 \ | CS:OppositeSignal i have also tweaked CCItest[] so there is one (CCItest[]) without any trade filtering, one (CCItestlo[]) with a longonly trade filter, and of course the one above with a shortonly tf. now let's look at your command line: ./backtest --nb-item=840 CCItest[8,-30,8,30,1.4,1.4] BUND oops --nb-item=840 is greater than size of BUND.txt?! wc /var/tmp/delix_cci/BUND.txt 829 4557 35310 /var/tmp/delix_cci/BUND.txt i don't know if that is good or bad, it is just out-of-sync. now i don't ever think i use --nb-item, but instead --start and --end so i'm gonna change --nb-item=840 to --start 2010-06-21 and --end 2013-09-13 using your slight altered 'options' file suited for my system and dirs, your exact BUND data and the following (bash) backtest command line that outputs in .html and graphs the trades all in the same html file: bash-3.00$ ./backtest.pl --timeframe day --html \ -dt -gr /var/tmp/delix_cci/bt_BUND_CCItestSO.png \ --start 2010-06-21 --end 2013-09-13 \ --opt 'DB::text::directory=/var/tmp/delix_cci' \ --opt 'DB::timeframes_available=day,week,month,year' \ --opt 'DB::text::format=0' \ --opt 'DB::text::marker=\t' \ 'CCItestso[8,-30,8,30,1.4,1.4]' BUND \ > /var/tmp/delix_cci/bt_BUND_CCItestSO.html \ 2> /var/tmp/delix_cci/bt_BUND_CCItestSO.log and i get the two attached files (for the html to connect with the png you have to put both files in dir /var/tmp/delix_cci). the log is just a 0.5mb of print lines that are still present from current price timeframe date string conversion testing and is not useful... note the first lines of the html file again shows the trading system as processed by gt, and the last two closestrategy are now separated. let me know if this helps you -- my first thought in order to check closestratgy correctness would be to reduce the data range to just a few months or quarters. just for fun i tried to duplicate your exact problem but got different results. i suppose it could be due to differences in my version of gt and the one you are using ... bash-3.00$ ./backtest.pl --nb-item=840 --timeframe day --opt 'DB::text::directory=/var/tmp/delix_cci' --opt 'DB::timeframes_available=day,week,month,year' --opt 'DB::text::format=0' --opt 'DB::text::marker=\t' 'CCItestXso[8,-30,8,30,1.4,1.4]' BUND 2> /var/tmp/delix_cci/bt_BUND_CCItest_orig.log ## ## Analysis of code BUND using System Spec SY:Generic {S:G:CrossOverUp {I:CCI 8 {I:Prices HIGH } {I:Prices LOW } {I:Prices CLOSE }} -30 } {S:G:CrossOverDown {I:CCI 8 {I:Prices HIGH } {I:Prices LOW } {I:Prices CLOSE }} 30 } | TF:ShortOnly | CS:Stop:Fixed 1.4 | CS:Stop:KeepRunUp 1.4 CS:OppositeSignal {I:Prices HIGH } {I:Prices CLOSE } | MM:Basic History of the portfolio : -------------------------- Short position (0) on BUND 2011-09-12 Sell 72 at 138.0500 2011-09-13 Buy 72 at 138.1000 Short position (1) on BUND 2011-09-14 Sell 72 at 137.9900 2011-09-15 Buy 72 at 136.8100 Short position (2) on BUND 2011-09-27 Sell 73 at 136.7500 2011-09-28 Buy 73 at 136.1300 Short position (3) on BUND 2011-10-07 Sell 74 at 135.8700 2011-10-10 Buy 74 at 135.6800 Short position (4) on BUND 2011-10-20 Sell 75 at 135.4800 2011-10-21 Buy 75 at 135.2800 Short position (5) on BUND 2011-10-24 Sell 75 at 134.4400 2011-10-25 Buy 75 at 134.8000 Short position (6) on BUND 2011-10-28 Sell 75 at 133.4000 2011-10-31 Buy 75 at 134.0900 Short position (7) on BUND 2011-11-14 Sell 73 at 137.2800 2011-11-15 Buy 73 at 138.6000 Short position (8) on BUND 2011-11-17 Sell 72 at 138.2300 2011-11-18 Buy 72 at 138.0000 Short position (9) on BUND 2011-12-21 Sell 72 at 137.5100 2011-12-22 Buy 72 at 137.7700 Short position (10) on BUND 2012-01-04 Sell 72 at 138.2000 2012-01-05 Buy 72 at 137.9400 Short position (11) on BUND 2012-01-20 Sell 71 at 138.8900 2012-01-23 Buy 71 at 138.1900 Short position (12) on BUND 2012-02-06 Sell 72 at 138.4700 2012-02-07 Buy 72 at 138.8300 Short position (13) on BUND 2012-02-20 Sell 72 at 138.1800 2012-02-21 Buy 72 at 137.8800 Short position (14) on BUND 2012-03-09 Sell 71 at 138.2800 2012-03-12 Buy 71 at 138.6000 Short position (15) on BUND 2012-04-18 Sell 71 at 139.9800 2012-04-19 Buy 71 at 140.3100 Short position (16) on BUND 2012-04-26 Sell 71 at 140.3900 2012-04-27 Buy 71 at 141.2200 Short position (17) on BUND 2012-05-22 Sell 69 at 143.3500 2012-05-23 Buy 69 at 143.5700 Short position (18) on BUND 2012-06-07 Sell 68 at 143.5900 2012-06-08 Buy 68 at 143.4100 Short position (19) on BUND 2012-07-18 Sell 68 at 145.0600 2012-07-19 Buy 68 at 145.2100 Short position (20) on BUND 2012-07-20 Sell 68 at 145.2000 2012-07-23 Buy 68 at 146.1000 Short position (21) on BUND 2012-07-25 Sell 68 at 145.1200 2012-07-26 Buy 68 at 144.6600 Short position (22) on BUND 2012-09-03 Sell 68 at 144.0000 2012-09-04 Buy 68 at 143.5600 Short position (23) on BUND 2012-09-24 Sell 70 at 140.1800 2012-09-25 Buy 70 at 140.4100 Short position (24) on BUND 2012-10-05 Sell 69 at 141.3200 2012-10-08 Buy 69 at 141.0700 Short position (25) on BUND 2012-10-17 Sell 70 at 140.5500 2012-10-18 Buy 70 at 139.4900 Short position (26) on BUND 2012-11-16 Sell 69 at 143.3200 2012-11-19 Buy 69 at 143.1100 Short position (27) on BUND 2012-12-04 Sell 70 at 142.4800 2012-12-05 Buy 70 at 142.6000 Short position (28) on BUND 2012-12-14 Sell 68 at 144.9800 2012-12-17 Buy 68 at 144.7100 Short position (29) on BUND 2013-01-03 Sell 69 at 143.9100 2013-01-04 Buy 69 at 143.1700 Short position (30) on BUND 2013-01-18 Sell 70 at 142.5000 2013-01-21 Buy 70 at 143.2500 Short position (31) on BUND 2013-01-28 Sell 70 at 142.2100 2013-01-29 Buy 70 at 141.8700 Short position (32) on BUND 2013-02-13 Sell 70 at 142.6100 2013-02-14 Buy 70 at 142.0300 Short position (33) on BUND 2013-02-21 Sell 70 at 142.7100 2013-02-22 Buy 70 at 143.4000 Short position (34) on BUND 2013-03-06 Sell 69 at 145.1000 2013-03-07 Buy 69 at 143.2800 Short position (35) on BUND 2013-04-10 Sell 69 at 145.6500 2013-04-11 Buy 69 at 145.2400 Short position (36) on BUND 2013-04-17 Sell 69 at 145.7600 2013-04-18 Buy 69 at 146.2000 Short position (37) on BUND 2013-04-25 Sell 69 at 146.1600 2013-04-26 Buy 69 at 146.3700 Short position (38) on BUND 2013-05-06 Sell 69 at 146.1500 2013-05-07 Buy 69 at 146.1800 Short position (39) on BUND 2013-05-21 Sell 70 at 144.8600 2013-05-22 Buy 70 at 144.6500 Short position (40) on BUND 2013-06-19 Sell 70 at 143.3500 2013-06-20 Buy 70 at 142.0300 Short position (41) on BUND 2013-07-08 Sell 72 at 141.6800 2013-07-09 Buy 72 at 141.9300 Short position (42) on BUND 2013-07-24 Sell 71 at 143.8600 2013-07-25 Buy 71 at 142.4700 Short position (43) on BUND 2013-09-03 Sell 73 at 140.1600 2013-09-04 Buy 73 at 139.7400 ## Global analysis (full portfolio always invested) Analysis of the portfolio (2011-09-01 / 2013-09-13) ----------------------------------------------------- Performance : 3.6% ( 0.0%) Buy & Hold : 2.0% ( 0.0%) () => by day MaxDrawDown : 2.9% B&H MaxDrawDown : 10.8% Best performance : 3.6% Worst performance : -1.4% Net gain : 364.15 Gross gain : 364.15 Trades statistics Number of trades : 44 Trades/Year : 21.63 Number of gains : 24 Number of losses : 20 Win. ratio : 54.5% Max consec. win : 4 Max consec. loss : 4 Expectancy : 0.00 Average gain : 0.40% Average loss : -0.30% Avg. perf : 0.08% Biggest gain : 1.25% Biggest loss : -0.96% Profit fac : 1.33 Sum of gains : 969.38 Sum of losses : -605.23 Risk of ruin : 0.0% aloha ras |
From: Robert A. S. <ra...@ac...> - 2013-11-11 17:05:27
|
Delix wrote: > On Fri, 08 Nov 2013 11:13:17 -0800 > "Robert A. Schmied" <ra...@ac...> hatte geschrieben : > > > >>aloha delix and fellow gt'ers >> >>ok -- i've found the source of the bad date strings that are causing >>i:g:M*InPeriod to fail in the cs:s:KeepRunUp directive. it has to do >>with the sub hour timeframe capabilities implemented via GT::Prices.pm >>*NOT I:Prices* >> >>you can avoid the problem by forcing date parsing format 0, which is >>what the sample 13000.txt file uses. by default date parsing format 3 >>is used and that is the source of the problem. >> >>tentatively you can eliminate the problem by two changes to the file >>GT/Prices.pm. in sub loadtxt >>change line (around 372 or 1465 depending on your source version) >>to: >> ( $year, $month, $day, $tm ) = split /[- ]/, $udate, 4; >>from: >> ( $year, $month, $day, $tm ) = split /[- ]/, $udate; >> >>and change line (around 388 or 1485) >>to: >> $date .= " $tm" if $tm && $tm != "00:00:00"; >>from: >> $date .= " $tm" if $tm; >> >> >> >> >>i've done *very limited* testing of this change which is >>continuing, but to get you started here are the basic >>failing and work-around commands i've been evaluating. >> >>this defaults to date parsing format 3 and without the changes >>to the file GT/Prices.pm noted above should generate erroneous results. >>bash-3.00$ ./backtest.pl -dt -gr ./graphs/bt_cs-kru_13000.png \ >> --start 2000-09-04 --end 2001-06-01 \ >> --opt 'DB::module=Text' \ >> --opt 'DB::text::directory=/usr/local/src/genius_trader/sample_data' \ >> --opt 'DB::timeframes_available=day,week,month,year' \ >> --opt 'Brokers::module=NoCosts' \ >> --timeframe day \ >> --html \ >> 'SY::Generic >> {S:Generic:CrossOverUp {I:SMA 20 {I:Prices CLOSE}} >> {I:SMA 60 {I:Prices CLOSE}}} >> {S:Generic:CrossOverDown {I:SMA 20 {I:Prices CLOSE}} >> {I:SMA 60 {I:Prices CLOSE}}} >> | TF:ShortOnly >> | CS:Stop:KeepRunUp >> ' 13000 > ./bt_cs-kru_13000.html >> >>this one forces date parsing format 0 and should return more rational >>results. in addition this should return identical results with or >>without the change to file GT/Prices.pm. >>bash-3.00$ ./backtest.pl -dt -gr ./graphs/bt_cs-kru_13000.png \ >> --start 2000-09-04 --end 2001-06-01 \ >> --opt 'DB::module=Text' \ >> --opt 'DB::text::directory=/usr/local/src/genius_trader/sample_data' \ >> --opt 'DB::timeframes_available=day,week,month,year' \ >> --opt 'Brokers::module=NoCosts' \ >> --opt 'DB::text::format=0' \ >> --timeframe day \ >> --html \ >> 'SY::Generic >> {S:Generic:CrossOverUp {I:SMA 20 {I:Prices CLOSE}} >> {I:SMA 60 {I:Prices CLOSE}}} >> {S:Generic:CrossOverDown {I:SMA 20 {I:Prices CLOSE}} >> {I:SMA 60 {I:Prices CLOSE}}} >> | TF:ShortOnly >> | CS:Stop:KeepRunUp >> ' 13000 > ./bt_cs-kru_13000.html >> >>open the output file (./bt_cs-kru_13000.html) in your favorite browser >> >> >> >>*note* -- changes made to GT/Indicators/Generic/MaxInPeriod.pm and >>GT/Indicators/Generic/MinInPeriod.pm must be reversed. >> >> >> >> >>things i'm still looking at: >> 1) does CS:Stop:KeepRunUp really do what the pod says it does >> -->> anybody got thoughts on that please let us know >> 2) is the change to GT::Prices.pm correct for all timeframes and >> most common database types. >> 3) does this change correct other CS:Stop: problems. >> > > > Hi Robert ! > Thanks for all your help and time you spend on it. > The fix seems to solve this issue at least to some extent. > I could run your example without errors and warnings and the results > look rational to me. > However, then I tried my setup I use for the testing. The options file > and the data file are attached below. > (btw: I had to put the system into the option file as I wasn't able to > access the local aliases for systems -- whereas the local aliases for > signals are accessable) . > I run the tests with the command > ./backtest --nb-item=840 CCItest[8,-30,8,30,1.4,1.4] BUND > > and the first results seems to be promissing. Actually, I think the > results are correct. > Then I started with variations of the systems. And here I run into the > next error : using the same command and changing the TF:LongOnly to > TF:ShortOnly results in no errors or warnings, but strange results. > I attached the output file for this test, too. > > Just hope, the email with all the attachments gets through..... > > aloha delix i've been running thru a bunch of my cache of tests and have uncovered many issues with GT/Prices.pm and GT/DB/Text.pm and even GT/DB/bean.pm. i've been unable to make sense of most of the errors i've encountered, so i'm unable to suggest any fixes yet. they seem to be related to converting date formats between timeframes. however, i do think i've been able to eliminate the GT/Prices.pm fix i suggested in this thread as the primary source of the problem. meanwhile you report a problem with ./backtest --nb-item=840 CCItest[8,-30,8,30,1.4,1.4] BUND the first likely problem is your BUND price data. it appears to be missing about half of the volume data values. if any of the indicators used to calculate CCI depend on volume this is going to be an issue. i've snipped most of the unneeded BUND data leaving only the parts showing when volume begins to appear. i will look at the rest of the CCItest data files in due course. aloha ras > > ------------------------------------------------------------------------ > first few lines -- no volume 2010-06-18 .. 2012-01-31 > 128.27 128.41 127.54 127.67 2010-06-18 > 127.37 127.63 127.12 127.4 2010-06-21 > 139.25 139.77 139.11 139.67 2012-01-30 > 139.59 139.89 139.08 139.72 2012-01-31 volume starts to appear 2012-02-01 .. 2013-09-13 > 139.75 139.77 138.99 139.24 702811 2012-02-01 > 139.04 139.79 138.88 139.08 759514 2012-02-02 > 139.34 139.59 138.13 138.32 730110 2012-02-03 > 137.46 137.94 137.4 137.78 663871 2013-09-12 > 137.29 138.16 137.17 137.99 586954 2013-09-13 |
From: Robert A. S. <ra...@ac...> - 2013-11-08 19:13:24
|
Delix wrote: > On Wed, 23 Oct 2013 14:09:41 +0200 > Delix <del...@t-...> hatte geschrieben : > > >>Hi Robert, it's me again..... >> >>I run into a problem with this trailing-stopp CloseStrategy : it simply >>has no effect. So I search the archive of the mailing lists and found >>http://sourceforge.net/p/geniustrader/mailman/message/26755661/ >> >>I tried the example you provided in your last answer. Here the >>CS:KeepRunUp has the same effect : i.e. NONE >>then I checked the data of the 13000.txt example. => the exit should >>have be triggered by KeepRunUp several times. >>So I guess, there is an error in the original version of this modul. >>Can you please provide your modified version you mentioned in the >>posting ? >>Thanks again, >>delix >> >>-- >>Delix <del...@t-...> >> > > Hm, with some print-lines added > > [code] > sub manage_long_position { > my ($self, $calc, $i, $position, $pf_manager, $sys_manager) = @_; > my $percentage = $self->{'args'}->get_arg_values($calc, $i, 1); > my $date = $position->open_date; > my $code = $position->code; > my $prices = $calc->prices; > > if ($i >= $prices->date($date)) { > > my $max = GT::Indicators::Generic::MaxInPeriod->new([$date, > $self-> > {'args'}->get_arg_names(3) ]); $max->calculate($calc, $i); > > my $highest_high = $calc->indicators->get($max->get_name, $i); > print ("$highest_high\n"); ########inserted > $position->set_stop($highest_high * (1 - $percentage / 100)); > } > > return; > } > > sub manage_short_position { > my ($self, $calc, $i, $position, $pf_manager, $sys_manager) = @_; > my $percentage = $self->{'args'}->get_arg_values($calc, $i, 1); > > my $date = $position->open_date; > my $code = $position->code; > my $prices = $calc->prices; > > if ($i >= $prices->date($date)) { > > my $min = GT::Indicators::Generic::MinInPeriod->new([$date, > $self-> > {'args'}->get_arg_names(2) ]); $min->calculate($calc, $i); > > my $lowest_low = $calc->indicators->get($min->get_name, $i); > print ("$lowest_low\n"); ############ inserted > $position->set_stop($lowest_low * (1 + $percentage / 100)); > } > > return; > } > > [/code] > > I get several lines like > 00:00:00 > 00:00:00 > .. > > these are datetime-formats, not quotes as expected. I guess the $i > variable is set incorrectly -- should it be $prices instead of > $prices-->date ???? > > aloha delix and fellow gt'ers ok -- i've found the source of the bad date strings that are causing i:g:M*InPeriod to fail in the cs:s:KeepRunUp directive. it has to do with the sub hour timeframe capabilities implemented via GT::Prices.pm *NOT I:Prices* you can avoid the problem by forcing date parsing format 0, which is what the sample 13000.txt file uses. by default date parsing format 3 is used and that is the source of the problem. tentatively you can eliminate the problem by two changes to the file GT/Prices.pm. in sub loadtxt change line (around 372 or 1465 depending on your source version) to: ( $year, $month, $day, $tm ) = split /[- ]/, $udate, 4; from: ( $year, $month, $day, $tm ) = split /[- ]/, $udate; and change line (around 388 or 1485) to: $date .= " $tm" if $tm && $tm != "00:00:00"; from: $date .= " $tm" if $tm; i've done *very limited* testing of this change which is continuing, but to get you started here are the basic failing and work-around commands i've been evaluating. this defaults to date parsing format 3 and without the changes to the file GT/Prices.pm noted above should generate erroneous results. bash-3.00$ ./backtest.pl -dt -gr ./graphs/bt_cs-kru_13000.png \ --start 2000-09-04 --end 2001-06-01 \ --opt 'DB::module=Text' \ --opt 'DB::text::directory=/usr/local/src/genius_trader/sample_data' \ --opt 'DB::timeframes_available=day,week,month,year' \ --opt 'Brokers::module=NoCosts' \ --timeframe day \ --html \ 'SY::Generic {S:Generic:CrossOverUp {I:SMA 20 {I:Prices CLOSE}} {I:SMA 60 {I:Prices CLOSE}}} {S:Generic:CrossOverDown {I:SMA 20 {I:Prices CLOSE}} {I:SMA 60 {I:Prices CLOSE}}} | TF:ShortOnly | CS:Stop:KeepRunUp ' 13000 > ./bt_cs-kru_13000.html this one forces date parsing format 0 and should return more rational results. in addition this should return identical results with or without the change to file GT/Prices.pm. bash-3.00$ ./backtest.pl -dt -gr ./graphs/bt_cs-kru_13000.png \ --start 2000-09-04 --end 2001-06-01 \ --opt 'DB::module=Text' \ --opt 'DB::text::directory=/usr/local/src/genius_trader/sample_data' \ --opt 'DB::timeframes_available=day,week,month,year' \ --opt 'Brokers::module=NoCosts' \ --opt 'DB::text::format=0' \ --timeframe day \ --html \ 'SY::Generic {S:Generic:CrossOverUp {I:SMA 20 {I:Prices CLOSE}} {I:SMA 60 {I:Prices CLOSE}}} {S:Generic:CrossOverDown {I:SMA 20 {I:Prices CLOSE}} {I:SMA 60 {I:Prices CLOSE}}} | TF:ShortOnly | CS:Stop:KeepRunUp ' 13000 > ./bt_cs-kru_13000.html open the output file (./bt_cs-kru_13000.html) in your favorite browser *note* -- changes made to GT/Indicators/Generic/MaxInPeriod.pm and GT/Indicators/Generic/MinInPeriod.pm must be reversed. things i'm still looking at: 1) does CS:Stop:KeepRunUp really do what the pod says it does -->> anybody got thoughts on that please let us know 2) is the change to GT::Prices.pm correct for all timeframes and most common database types. 3) does this change correct other CS:Stop: problems. |
From: Robert A. S. <ra...@ac...> - 2013-11-07 17:35:05
|
Delix wrote: > On Mon, 04 Nov 2013 11:38:27 -0800 > "Robert A. Schmied" <ra...@ac...> hatte geschrieben : > > >>http://sourceforge.net/mailarchive/message.php?msg_id=31553124 >>just so we are looking at the same thing -- please provide the date range >>plus the dates you believe should be triggered by KeepRunUp. >> >>i've only tested these two cases (below) with identical results >> >>backtest.pl -dt -gr ./graphs/bt_cs-kru_13000.png \ >> --start 2000-09-04 \ >> --end 2002-09-27 \ >> --opt 'DB::module=Text' \ >> --opt 'DB::text::directory=/usr/local/src/genius_trader/sample_data' \ >> --opt 'DB::timeframes_available=day,week,month,year' \ >> --opt 'Brokers::module=NoCosts' \ >> --timeframe day \ >> 'SY::Generic >> {S:Generic:CrossOverUp {I:SMA 20 {I:Prices CLOSE}} >> {I:SMA 60 {I:Prices CLOSE}}} >> {S:Generic:CrossOverDown {I:SMA 20 {I:Prices CLOSE}} >> {I:SMA 60 {I:Prices CLOSE}}} >> | CS:OppositeSignal >> | CS:Stop:KeepRunUp 1' \ >> 13000 \ >> > /dev/tty 2>bt_cs-kru_13000.out >> >>and >> >>backtest.pl -dt -gr ./graphs/bt_cs-kru_13000_x.png \ >> --start 2000-09-04 \ >> --end 2002-09-27 \ >> --opt 'DB::module=Text' \ >> --opt 'DB::text::directory=/usr/local/src/genius_trader/sample_data' \ >> --opt 'DB::timeframes_available=day,week,month,year' \ >> --opt 'Brokers::module=NoCosts' \ >> --timeframe day \ >> 'SY::Generic >> {S:Generic:CrossOverUp {I:SMA 20 {I:Prices CLOSE}} >> {I:SMA 60 {I:Prices CLOSE}}} >> {S:Generic:CrossOverDown {I:SMA 20 {I:Prices CLOSE}} >> {I:SMA 60 {I:Prices CLOSE}}} >> | CS:Stop:KeepRunUp 1 >> | CS:OppositeSignal' \ >> 13000 \ >> > /dev/tty 2>bt_cs-kru_13000_x.out >> >> >>i've attached an alternate version of ../GT/CloseStrategy/Stop/KeepRunUp.pm >> >>the usual caveats apply (e.g. might depend on other changes, etc) >> >> >>ras >> >> >> >> >>>So I guess, there is an error in the original version of this modul. >>>Can you please provide your modified version you mentioned in the >>>posting ? >>>Thanks again, >>>delix >>> >>>-- >>>Delix <delix.fb@...> > > > thanks Robert, especially for your version of the modul. I 'll do the > testing (probably) next weekend. > I think, the problem with the KeepRunUp and the CCI moduls come from the > same origin: the moduls pick their input data from the wrong place of > the data line (at leat if you are using plain text data file with the > same order of the data as the example files). The formulas should be > correct. > I guess, this is a matter of changes in the data reading part of GT > during the delvopment process which have not been adopted to all > moduls. And this means, it is very likely that other moduls and other > data input methods (generic.db, csv, maybe even bean) are affected by > this problem, too...... this seems to be have the potential to be a > maior issue. > > I' ll send my reports to both e-mail addresses in the hope you get them > timely. aloha delix as far as CS:Stop:KeepRunUp goes -- it is doing something -- it may be incorrect, but it does appear to set/update stops which are then processed. developing a good close strategy is not an easy job. using CS:OppositeSignal is probably the worst of them all, but at least it ensures a trade is exited when the trend reverses. compare the results from these two systems: no closing directives at all: bash-3.00$ ./backtest.pl -dt -gr ./graphs/bt_cs-kru_13000.png --start 2000-09-04 --end 2002-09-27 --opt 'DB::module=Text' --opt 'DB::text::directory=/usr/local/src/genius_trader/sample_data' --opt 'DB::timeframes_available=day,week,month,year' --opt 'Brokers::module=NoCosts' --timeframe day --html 'SY::Generic {S:Generic:CrossOverUp {I:SMA 20 {I:Prices CLOSE}} {I:SMA 60 {I:Prices CLOSE}}} {S:Generic:CrossOverDown {I:SMA 20 {I:Prices CLOSE}} {I:SMA 60 {I:Prices CLOSE}}} | TF:ShortOnly ' 13000 > ./bt_cs-kru_13000.html 2> ./bt_cs-kru_13000.out with a (default) CS:Stop:KeepRunUp: bash-3.00$ ./backtest.pl -dt -gr ./graphs/bt_cs-kru_13000.png --start 2000-09-04 --end 2002-09-27 --opt 'DB::module=Text' --opt 'DB::text::directory=/usr/local/src/genius_trader/sample_data' --opt 'DB::timeframes_available=day,week,month,year' --opt 'Brokers::module=NoCosts' --timeframe day --html 'SY::Generic {S:Generic:CrossOverUp {I:SMA 20 {I:Prices CLOSE}} {I:SMA 60 {I:Prices CLOSE}}} {S:Generic:CrossOverDown {I:SMA 20 {I:Prices CLOSE}} {I:SMA 60 {I:Prices CLOSE}}} | TF:ShortOnly | CS:Stop:KeepRunUp ' 13000 > ./bt_cs-kru_13000.html 2> ./bt_cs-kru_13000.out it might appear that CS:Stop:KeepRunUp 10 (default) and CS:Stop:KeepRunUp <some other value> should (possibly) yield different results, but maybe not. i've got a lot of debugging print statements scattered around the GT/Portfolio module tree and i do see differences in the stop values being generated/set by CS:Stop:KeepRunUp <percentage> when i vary <percentage>. so at least that part is working to some extent. looking at the KeepRunUp code -- the stop value is being adjusted based on the results of this basic indicator: I:G:M*InPeriod <position_open_date> <I:Prices> where * is Max and <I:Prices> is HIGH for a long position and * is Min and <I:Prices> is LOW for a short position when I:G:M*InPeriod is used with a 'date' string, it will generate the M* value since that 'date'. by default CS:Stop:KeepRunUp implements these arguments <percentage> <short position reference> <long position reference> <relative stop reference> by default these arguments are: <10> <{I:Prices LOW}> <{I:Prices HIGH}> <{I:Prices CLOSE}> so the default CS:Stop:KeepRunUp is a very simple CloseStrategy comparator. the pod says: "strategy closes the position once the prices have crossed the trailing stop defined as a percentage below the highest high value for a long trade or above the highest low value for a short trade" 13000 prices: 77.3 78.65 74.65 75 3500007 2000-10-06 73.75 74.2 71 72.25 3913178 2000-10-09 74.1 76 73.1 76 7342019 2000-10-10 short trade -- for position taken on 2000-10-06 on 2000-10-09 10% above 71.00 is 78.10 the price has already fallen well below this value so the 'runup' is kept and the trade is closed. well -- the code disagrees with what the pod says 'cause it is getting the MinInPeriod since date-open of low for short and MaxInPeriod since date-open of high for long but changing that makes no difference in outcome -- still closes first position on 2000-10-09 and it really should not be doing that ... so there is so another problem someplace ... ahha! yep -- $min->get_name in stmt "my $lowest_low = $calc->indicators->get($min->get_name, $i);" returns an almost correct string: "MaxInPeriod[2000-10-06, 00:00:00, {I:Prices LOW}]" the almost part is the date string has an unescaped comma between date and time. so the next statement fails to get {I:Prices LOW}, but instead 00:00:00. so how/where/why does that unacceptable namestring happen ??? that is as far as i've been able to track the problem -- it is likely that some (many) close strategies need improvements in order to correctly address/access/register, call it whatever you want, the myriad data objects correctly. could be as simple as providing a sub init in CS:Stop:KeepRunUp ... when (if) i figure this issue out i will post it so others can evaluate the solution before i push it onto the gt repo. |
From: Delix <del...@t-...> - 2013-11-05 09:58:58
|
On Mon, 04 Nov 2013 11:38:27 -0800 "Robert A. Schmied" <ra...@ac...> hatte geschrieben : > http://sourceforge.net/mailarchive/message.php?msg_id=31553124 > just so we are looking at the same thing -- please provide the date range > plus the dates you believe should be triggered by KeepRunUp. > > i've only tested these two cases (below) with identical results > > backtest.pl -dt -gr ./graphs/bt_cs-kru_13000.png \ > --start 2000-09-04 \ > --end 2002-09-27 \ > --opt 'DB::module=Text' \ > --opt 'DB::text::directory=/usr/local/src/genius_trader/sample_data' \ > --opt 'DB::timeframes_available=day,week,month,year' \ > --opt 'Brokers::module=NoCosts' \ > --timeframe day \ > 'SY::Generic > {S:Generic:CrossOverUp {I:SMA 20 {I:Prices CLOSE}} > {I:SMA 60 {I:Prices CLOSE}}} > {S:Generic:CrossOverDown {I:SMA 20 {I:Prices CLOSE}} > {I:SMA 60 {I:Prices CLOSE}}} > | CS:OppositeSignal > | CS:Stop:KeepRunUp 1' \ > 13000 \ > > /dev/tty 2>bt_cs-kru_13000.out > > and > > backtest.pl -dt -gr ./graphs/bt_cs-kru_13000_x.png \ > --start 2000-09-04 \ > --end 2002-09-27 \ > --opt 'DB::module=Text' \ > --opt 'DB::text::directory=/usr/local/src/genius_trader/sample_data' \ > --opt 'DB::timeframes_available=day,week,month,year' \ > --opt 'Brokers::module=NoCosts' \ > --timeframe day \ > 'SY::Generic > {S:Generic:CrossOverUp {I:SMA 20 {I:Prices CLOSE}} > {I:SMA 60 {I:Prices CLOSE}}} > {S:Generic:CrossOverDown {I:SMA 20 {I:Prices CLOSE}} > {I:SMA 60 {I:Prices CLOSE}}} > | CS:Stop:KeepRunUp 1 > | CS:OppositeSignal' \ > 13000 \ > > /dev/tty 2>bt_cs-kru_13000_x.out > > > i've attached an alternate version of ../GT/CloseStrategy/Stop/KeepRunUp.pm > > the usual caveats apply (e.g. might depend on other changes, etc) > > > ras > > > > > So I guess, there is an error in the original version of this modul. > > Can you please provide your modified version you mentioned in the > > posting ? > > Thanks again, > > delix > > > > -- > > Delix <delix.fb@...> thanks Robert, especially for your version of the modul. I 'll do the testing (probably) next weekend. I think, the problem with the KeepRunUp and the CCI moduls come from the same origin: the moduls pick their input data from the wrong place of the data line (at leat if you are using plain text data file with the same order of the data as the example files). The formulas should be correct. I guess, this is a matter of changes in the data reading part of GT during the delvopment process which have not been adopted to all moduls. And this means, it is very likely that other moduls and other data input methods (generic.db, csv, maybe even bean) are affected by this problem, too...... this seems to be have the potential to be a maior issue. I' ll send my reports to both e-mail addresses in the hope you get them timely. -- Delix <del...@t-...> |
From: Robert A. S. <ra...@ac...> - 2013-11-04 16:20:49
|
> is anybody using the CCI indicator ? > I tried to check the results with the data and parameters of the > following web site : > http://www.ariva.de/euro-dollar-kurs/chart?compare=None&idstring=x&box2=0&avgVal1=20&t=quarter&box3=0&avgVal2=0&end=27.10.2012&avgType1=EMA&resolution=auto&scale=lin&type=CandleStick&displayHighLow=1&box4=0&band=BB&avgType2=None&typ=&grid=1&show_ind_params=0&volume=1&boerse_id=130&antiAlias=0&go=Aktualisieren&savg=0&events=None&indicator=MACD&indicator=Aroon&indicator=CCI&indicator=SStoch&indicator=ROC&box5=0 > > GTs CCI always gives similar results but the values are too low (i.e. > -60 instead of -100) > has anybody an explanations for this ? most likely, it is a matter of > the formular but I'm not sure what it is finally... > > -- > Delix <linux.fb@...> aloha delix the above message is from way back in may'13 -- have you determined there is an actual issue and fix? price - moving_average cci = ------------------------ 0.015 * normal_deviation i see the indicator is implemented using gt indicators true price (I::TP) for 'price' and the simple moving average (I::SMA) and an internal to i::cci calculation of 'normal_deviation'. i'm not sure why the gt indicator I::StandardDeviation was not used or if it generates different data from the internal i::cci mean_deviation. also at least one cci definition (http://www.investopedia.com/terms/c/commoditychannelindex.asp) suggests 'price' might be todays price (I::CLOSE) rather than the true price. how does Donald Lambert define 'price" if you know? ras ps -- once again the gt mailing list traffic (for oct'13) is not being forwarded so i will be looking at those messages next -- ras |
From: Delix <del...@t-...> - 2013-10-27 11:11:40
|
On Thu, 24 Oct 2013 19:26:05 +0200 Delix <del...@t-...> hatte geschrieben : > On Wed, 23 Oct 2013 14:09:41 +0200 > Delix <del...@t-...> hatte geschrieben : > > > Hi Robert, it's me again..... > > > > I run into a problem with this trailing-stopp CloseStrategy : it simply > > has no effect. So I search the archive of the mailing lists and found > > http://sourceforge.net/p/geniustrader/mailman/message/26755661/ > > I think, I got it. replacing line 142 of ..GT/Indicators/Generic/MaxInPeriod.pm my $val = $self->{'args'}->get_arg_values($calc, $n, 2); by my $val = $self->{'args'}->get_arg_values($calc, $n, 3); solves this problem for me. same thing with line 94 in MinInPeriod.pm -- Delix <del...@t-...> |
From: Delix <del...@t-...> - 2013-10-24 17:26:16
|
On Wed, 23 Oct 2013 14:09:41 +0200 Delix <del...@t-...> hatte geschrieben : > Hi Robert, it's me again..... > > I run into a problem with this trailing-stopp CloseStrategy : it simply > has no effect. So I search the archive of the mailing lists and found > http://sourceforge.net/p/geniustrader/mailman/message/26755661/ > > I tried the example you provided in your last answer. Here the > CS:KeepRunUp has the same effect : i.e. NONE > then I checked the data of the 13000.txt example. => the exit should > have be triggered by KeepRunUp several times. > So I guess, there is an error in the original version of this modul. > Can you please provide your modified version you mentioned in the > posting ? > Thanks again, > delix > > -- > Delix <del...@t-...> > Hm, with some print-lines added [code] sub manage_long_position { my ($self, $calc, $i, $position, $pf_manager, $sys_manager) = @_; my $percentage = $self->{'args'}->get_arg_values($calc, $i, 1); my $date = $position->open_date; my $code = $position->code; my $prices = $calc->prices; if ($i >= $prices->date($date)) { my $max = GT::Indicators::Generic::MaxInPeriod->new([$date, $self-> {'args'}->get_arg_names(3) ]); $max->calculate($calc, $i); my $highest_high = $calc->indicators->get($max->get_name, $i); print ("$highest_high\n"); ########inserted $position->set_stop($highest_high * (1 - $percentage / 100)); } return; } sub manage_short_position { my ($self, $calc, $i, $position, $pf_manager, $sys_manager) = @_; my $percentage = $self->{'args'}->get_arg_values($calc, $i, 1); my $date = $position->open_date; my $code = $position->code; my $prices = $calc->prices; if ($i >= $prices->date($date)) { my $min = GT::Indicators::Generic::MinInPeriod->new([$date, $self-> {'args'}->get_arg_names(2) ]); $min->calculate($calc, $i); my $lowest_low = $calc->indicators->get($min->get_name, $i); print ("$lowest_low\n"); ############ inserted $position->set_stop($lowest_low * (1 + $percentage / 100)); } return; } [/code] I get several lines like 00:00:00 00:00:00 .. these are datetime-formats, not quotes as expected. I guess the $i variable is set incorrectly -- should it be $prices instead of $prices-->date ???? -- Delix <del...@t-...> |
From: Delix <del...@t-...> - 2013-10-23 12:09:52
|
Hi Robert, it's me again..... I run into a problem with this trailing-stopp CloseStrategy : it simply has no effect. So I search the archive of the mailing lists and found http://sourceforge.net/p/geniustrader/mailman/message/26755661/ I tried the example you provided in your last answer. Here the CS:KeepRunUp has the same effect : i.e. NONE then I checked the data of the 13000.txt example. => the exit should have be triggered by KeepRunUp several times. So I guess, there is an error in the original version of this modul. Can you please provide your modified version you mentioned in the posting ? Thanks again, delix -- Delix <del...@t-...> |
From: Delix <del...@t-...> - 2013-10-19 16:37:55
|
just for the info : I found this webage : http://user42.tuxfamily.org/chart/index.html and I think it's interesting for other Debian users, too. Actually, I didn't test it yet, but I got it installed and I'm planning to play aroud with it (sooner or later :-)) ). -- Delix <del...@t-...> |
From: Robert A. S. <ra...@ac...> - 2013-09-19 18:34:53
|
Evgeny Shragovich wrote: > Hi Robert, > > Yesterday I have tried the same procedure again. > The good news are that I was able to checkout "Scripts" with no issues > at all. I *think* that the same line failed and then succeeded for the > second time without making any changes to it, but I might be wrong. > However I still have the same problem with GT. That's very strange. without the specifics of the error output etc it is difficult for me to diagnose the problem you are having ... > While googling this error, I have found that it might mean database > corruption. But this is obviously not the case since didn't have any > issues with that.. > > Do you have any ideas what might be the issue here? Maybe I miss > something basic... evgeny however, i suspect some sort of issue in the command line you are using ... i think that cut+paste from the webpage browser display is somewhat risky due to white spaces as well as your specific destination path the general svn co command line must be $ svn co ( or checkout ) source_url destination_path you must separate the destination_path from the source_url the destination_path (a directory) most likely has to exist on your system, but this might depend a bit on your svn client. so here are the working command line using my fairly old svn client svn, version 1.4.3 (r23084) the svn client and command: *svn co* the gt repo url for the trunk and for the GT subdir *https://geniustrader.svn.sourceforge.net/svnroot/geniustrader/trunk/GT* my destination_path (yours might be somewhat different) */var/tmp/evgeny_19sep13/gt/GT* the complete command line: svn co https://geniustrader.svn.sourceforge.net/svnroot/geniustrader/trunk/GT /var/tmp/evgeny_19sep13/gt/GT if you are using the svn client try svn help co for more details. good luck ras > > > Thanks again! > Eugene > > > On 18 September 2013 09:11, Evgeny Shragovich <shr...@gm... > <mailto:shr...@gm...>> wrote: > > Hi Robert, > > Thank you for your quick reply! > Hmm.. that's strange. I will try the same procedure again while > paying special attention to spaces. > > > Eugene > > > > On 18 September 2013 05:58, Robert A. Schmied <ra...@ac... > <mailto:ra...@ac...>> wrote: > > Evgeny Shragovich wrote: > > Greetings Robert, > > I am setting up GT on a fresh CentOS system and I get the > following error > when trying to checkout the code: > > [Eugene@localhost ~]$ svn checkout > https://geniustrader.svn.__sourceforge.net/svnroot/__geniustrader/trunk/__GTgeniustrader/GT > <https://geniustrader.svn.sourceforge.net/svnroot/geniustrader/trunk/GTgeniustrader/GT> > svn: Can't read file 'geniustrader/GT/.svn/entries'__: End > of file found > > > Any idea why it happens? > > Cheers! > Eugene > > > aloha evgeny > > well checkout for Scripts worked for me: > > > $ mkdir /var/tmp/evgeny_17sep13 > $ cd /var/tmp/evgeny_17sep13 > $ mkdir gt > $ mkdir gt/Scripts > $ mkdir gt/GT > $ cd gt/Scripts > $ svn checkout > https://geniustrader.svn.__sourceforge.net/svnroot/__geniustrader/trunk/Scripts > <https://geniustrader.svn.sourceforge.net/svnroot/geniustrader/trunk/Scripts> > . > A display_system.pl <http://display_system.pl> > A report_old.ash > A backtest_multi.pl <http://backtest_multi.pl> > A graphic.pl <http://graphic.pl> > A analyze_backtest.pl <http://analyze_backtest.pl> > A Templates > A Templates/backtest.mhtml > A Templates/portfolio_historic.__mhtml > A Templates/analyze_backtest.__mhtml > A Templates/portfolio_positions.__mhtml > A Templates/backtest.mpl > A Templates/portfolio_historic.__mpl > A Templates/analyze_backtest.mpl > A Templates/portfolio_positions.__mpl > A backtest_many.pl <http://backtest_many.pl> > A scan.pl <http://scan.pl> > A manage_portfolio.pl <http://manage_portfolio.pl> > A anashell.pl <http://anashell.pl> > A report_summary.ash > A t > A t/launch.sh > A t/TODO > A t/TODO.en > A t/bin > A t/bin/test_indicator.sh > A t/bin/output_indicator.pl <http://output_indicator.pl> > A t/bin/function.sh > A t/data > A t/data/alcatel.txt > A t/.cvsignore > A t/README > A t/lists > A t/lists/TEST.Indicators > A OptimizeGT.pm > A backtest.pl <http://backtest.pl> > A select_combination.pl <http://select_combination.pl> > A display_indicator.pl <http://display_indicator.pl> > A display_signal.pl <http://display_signal.pl> > A .cvsignore > A test.xml > U . > Checked out revision 720. > > did similar on for GT subdir -- it also worked > > aha your command line is missing some whitespace here (but that > could be the emailers) > > > https://geniustrader.svn.__sourceforge.net/svnroot/__geniustrader/trunk/__GTgeniustrader/GT > <https://geniustrader.svn.sourceforge.net/svnroot/geniustrader/trunk/GTgeniustrader/GT> > > ^^^ > > > |