(03-24-2018, 01:09 PM)tommiehansen Wrote: 1. Make sure you run a recent PHP version. A problem could be that you're running something old; goto your terminal and write php -v. Don't run versions prior to PHP 7.
2. "pretty recent" doesn't mean much, if you want to know your max check your cpu-usage when running 1, 2, 3.. threads.
3. The errors you're seeing is because it could not add the trades to the $trades array. Thus you also see 'division by zero'. I don't know how to solve that since it makes no logical sense since there should be values there. This could be because of old php version that does things differently.
4. No appending results to a date range would be terrible since different date ranges always yield different results and thus SET A shouldn't be compared to B since they would live in completely different universes backtesting-wise.

Btw -- if my answers seem a bit short it's simply because i got a lot of stuff to do.

Quote:php -v
PHP 7.2.3-1+ubuntu16.04.1+deb.sury.org+1 (cli) (built: Mar  6 2018 11:18:25) ( NTS )
Copyright © 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright © 1998-2018 Zend Technologies
    with Zend OPcache v7.2.3-1+ubuntu16.04.1+deb.sury.org+1, Copyright © 1999-2018, by Zend Technologies

Quote: xxx POST /api/backtest 500 242ms -

  Error: non-error thrown: Child process has died.
      at Object.onerror (/home/david/gekko/node_modules/koa/lib/context.js:105:40)
      at <anonymous>
      at process._tickCallback (internal/process/next_tick.js:188:7)

(03-24-2018, 01:52 PM)donkykong017 Wrote:

(03-24-2018, 01:09 PM)tommiehansen Wrote: 1. Make sure you run a recent PHP version. A problem could be that you're running something old; goto your terminal and write php -v. Don't run versions prior to PHP 7.
2. "pretty recent" doesn't mean much, if you want to know your max check your cpu-usage when running 1, 2, 3.. threads.
3. The errors you're seeing is because it could not add the trades to the $trades array. Thus you also see 'division by zero'. I don't know how to solve that since it makes no logical sense since there should be values there. This could be because of old php version that does things differently.
4. No appending results to a date range would be terrible since different date ranges always yield different results and thus SET A shouldn't be compared to B since they would live in completely different universes backtesting-wise.

Btw -- if my answers seem a bit short it's simply because i got a lot of stuff to do.

thx again.

1. should not be the problem:

Quote:php -v
PHP 7.2.3-1+ubuntu16.04.1+deb.sury.org+1 (cli) (built: Mar  6 2018 11:18:25) ( NTS )
Copyright © 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright © 1998-2018 Zend Technologies
    with Zend OPcache v7.2.3-1+ubuntu16.04.1+deb.sury.org+1, Copyright © 1999-2018, by Zend Technologies

2. i know its not a powerhouse. its a dell xps 13 i7 8550U CPU @ 1.80GHz x 8 16Gb Ram. it should cope with most of what i throw at it. have around 80% CPU with 4-5 backtests at the same time
3. ok no clue there lol
4. ok get it. seems legit if you say so 

dont worry man. you have been very helpful. thanks for that.

will try to test some further. 
btw do you know if resuming tests on the same exact set will append the results with tests with never before used settings. do you know what i mean. sry i cant seem to explain that in english 
cheers

edit1:

so one new developement. now i also got error output in gekko commandline.
i have not seen it before:

Quote: xxx POST /api/backtest 500 242ms -

  Error: non-error thrown: Child process has died.
      at Object.onerror (/home/david/gekko/node_modules/koa/lib/context.js:105:40)
      at <anonymous>
      at process._tickCallback (internal/process/next_tick.js:188:7)

(03-24-2018, 04:46 PM)tommiehansen Wrote:

(03-24-2018, 01:52 PM)donkykong017 Wrote:

(03-24-2018, 01:09 PM)tommiehansen Wrote: 1. Make sure you run a recent PHP version. A problem could be that you're running something old; goto your terminal and write php -v. Don't run versions prior to PHP 7.
2. "pretty recent" doesn't mean much, if you want to know your max check your cpu-usage when running 1, 2, 3.. threads.
3. The errors you're seeing is because it could not add the trades to the $trades array. Thus you also see 'division by zero'. I don't know how to solve that since it makes no logical sense since there should be values there. This could be because of old php version that does things differently.
4. No appending results to a date range would be terrible since different date ranges always yield different results and thus SET A shouldn't be compared to B since they would live in completely different universes backtesting-wise.

Btw -- if my answers seem a bit short it's simply because i got a lot of stuff to do.

thx again.

1. should not be the problem:

Quote:php -v
PHP 7.2.3-1+ubuntu16.04.1+deb.sury.org+1 (cli) (built: Mar  6 2018 11:18:25) ( NTS )
Copyright © 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright © 1998-2018 Zend Technologies
    with Zend OPcache v7.2.3-1+ubuntu16.04.1+deb.sury.org+1, Copyright © 1999-2018, by Zend Technologies

2. i know its not a powerhouse. its a dell xps 13 i7 8550U CPU @ 1.80GHz x 8 16Gb Ram. it should cope with most of what i throw at it. have around 80% CPU with 4-5 backtests at the same time
3. ok no clue there lol
4. ok get it. seems legit if you say so 

dont worry man. you have been very helpful. thanks for that.

will try to test some further. 
btw do you know if resuming tests on the same exact set will append the results with tests with never before used settings. do you know what i mean. sry i cant seem to explain that in english 
cheers

edit1:

so one new developement. now i also got error output in gekko commandline.
i have not seen it before:

Quote: xxx POST /api/backtest 500 242ms -

  Error: non-error thrown: Child process has died.
      at Object.onerror (/home/david/gekko/node_modules/koa/lib/context.js:105:40)
      at <anonymous>
      at process._tickCallback (internal/process/next_tick.js:188:7)

1. No, not a problem at all. You're basically on the last version which is great.
2. I would really not run over 3 threads with an i7 8550u (or any laptop) though. This could lead to what i was saying about it being a que created and do note that max timeout for runner.php (the thing that runs stuff) is 900 by default (which equals 15 minutes). If you start queing up backtests that take longer then that time you'll start getting errors.
3. -
4. -

Resuming
Yes, resuming will always append if the daterange has not changed (one has not imported new data etc). This is sort of a core feature due to the fact that one may not want to run all the runs one would want in a single run (because that could literally take over 30 hours). So just stop anything and run it at a later time if you need to to free up CPU-resources etc.

Gekko error
I don't know about this. Be sure that you have your UIconfig.js @ /gekko/web/vue/UIconfig.js set to a higher then default value though (default is like 2 minutes).


This is my UIconfig.js:

Code:

// This config is used in both the
// frontend as well as the web server.

// see https://github.com/askmike/gekko/blob/stable/docs/installing_gekko_on_a_server.md

const CONFIG = {
 headless: false,
 api: {
   host: '127.0.0.1',
   port: 3000,
   timeout: 7200000 // 120 minutes
 },
 ui: {
   ssl: false,
   host: 'localhost',
   port: 3000,
   path: '/'
 },
 adapter: 'sqlite'
}

if(typeof window === 'undefined')
 module.exports = CONFIG;
else
 window.CONFIG = CONFIG;

(03-24-2018, 05:58 PM)donkykong017 Wrote: 1. done
2. ok well thats a bummer. will try with up to 3. it makes no sense to change the timeout, because if its queued it will not be faster anyways. on the other hand this should not be a problem with gekko itself as i can run 8 backtests at a time in parallel with other tools.
3.
4.

Resuming:
well thats awesome. just as i would have done it. 

Error. 
i found an issue on github that tries to solve that.
https://github.com/askmike/gekko/issues/2040
https://github.com/askmike/gekko/issues/1879

this could have something to do with the strat using tulib/talind. im using your "old" strat. will try updating to the new version with built in indicators.

Edit:
ok sry. it was obviously that. runs butter smooth now and 10 times faster than before. now i am just shaking my head over me.


btw i thought a little bit about reading the results of GAB and just to use the Strats with the best test results is not always the best way. as one should consider e.g sharpe ratio and other things.
wouldn't it be a good idea to somehow mix the listing of the best results that had good results (profit) and good sharpe ratio not just one of the two?


and i think it could also be a good idea to put in the slippage value as that allows you to get more realistic results to real trading.

Edit2:
to get the average from the best results i can only choose the best 99 tests. wouldn't it be good to have even more when we have more than 1000 or even 10000 tests done. what would you recommentd for average?


thanks
cheers 
DK

(03-25-2018, 06:35 PM)0mathew0 Wrote: Awesome work Tommie

EDIT: one little feature wish from my side: limit date/time-range for the chosen dataset (sometimes I may not want to have the dec bullrun in my backtest).

(03-25-2018, 02:33 PM)tommiehansen Wrote:

(03-24-2018, 05:58 PM)donkykong017 Wrote: 1. done
2. ok well thats a bummer. will try with up to 3. it makes no sense to change the timeout, because if its queued it will not be faster anyways. on the other hand this should not be a problem with gekko itself as i can run 8 backtests at a time in parallel with other tools.
3.
4.

Resuming:
well thats awesome. just as i would have done it. 

Error. 
i found an issue on github that tries to solve that.
https://github.com/askmike/gekko/issues/2040
https://github.com/askmike/gekko/issues/1879

this could have something to do with the strat using tulib/talind. im using your "old" strat. will try updating to the new version with built in indicators.

Edit:
ok sry. it was obviously that. runs butter smooth now and 10 times faster than before. now i am just shaking my head over me.


btw i thought a little bit about reading the results of GAB and just to use the Strats with the best test results is not always the best way. as one should consider e.g sharpe ratio and other things.
wouldn't it be a good idea to somehow mix the listing of the best results that had good results (profit) and good sharpe ratio not just one of the two?


and i think it could also be a good idea to put in the slippage value as that allows you to get more realistic results to real trading.

Edit2:
to get the average from the best results i can only choose the best 99 tests. wouldn't it be good to have even more when we have more than 1000 or even 10000 tests done. what would you recommentd for average?


thanks
cheers 
DK

1. Ok
2. If you can run 8x with other tools you can run 8x with this, all the tools uses the same thing (the localhost:3000/api/ endpoint). GAB doesn't really use any resources in itself and when you run the only thing taking resources is the AJAX stuff... but that's basically 0.
I still would watch the que though. My older laptop using a 4720HQ starts queing stuff up after around 3 threads and your newer is only about +14% faster.
3. Yes, the new version is faster. Don't create new versions for the fun of it.   (except the last unpublished version that is more of a cleanup) 
-  
4. The 'best profit' is only one way to sort it. You got multiple ways of sorting the data like sorting it by Sharpe, Win% etc. Use the tool?


5. Slippage: Yes, more options would be good but i personally think the defaults for slippage is a good "worst case scenario" since the slippage and loss for each trade is usually qute a bit higher then at the less expensive exchanges.

Also adding slippade etc would make RUNS A incompatible with RUNS B since if you run with the same strategy, same params and same daterange but have different slippage these two will not be comparable any longer so each such change would create a new dataset.

6. Max 99: Yes, problem is that with many runs there will be a lot of junk runs; runs that simply wasn't that great anyway. I changed that now, new limit is 10,000. Do note that looping trough 10,000 of datapoints take longer time though since there will be more data to process etc.
How many results in the average depends, i find that 10 is usually a good value. It totally depends on how many successful runs one got in total.

(03-26-2018, 07:15 AM)askmike Wrote: I am doing some updates to the backtest API (in 0.6), see this thread for more info: https://forum.gekko.wizb.it/thread-56603.html