The Annual Return/Trade is using 6.5 hours per day for backscans with bar => 1 day, instead of 24 hours. As a result the results are overstated by 24/6.5 or 3.69. It would seem to me that is the bar interval is >= 1 day, don't use 6.5, use 24.

=============================
As to "we'll soon be working on StockFinder 5.1, which will tackle all documented BackScanner issues".   Can this list be published so that users may comment on omissions?

I know it is not policy to reveal features, except by release, however it would be good to know what the general game plan is for the backscanner. Is there any intention of supporting any of the following?:

1.     A way of saving the results that permits reconstruction or at least realization  of what the backscan rules were at the time it was run.

2.     Improved run to run results tracking

a.     Tabbed scan results, so that one can appreciate result improvements

b.     The ability to provide description with the scan results. Typically consecutive scans are run tweaking settings. There is no easy way to review multiples runs and appreciate what caused the improvements

3.     Money management with support for

a.     Tie breaker, for picking which trades to execute when multiple opportunities are presented

b.     Margin

c.     Minimum/maximum  setups per bar

d.     Minimum/Maximum trades per bar

e.     Maximum open trades

f.      Multiple Trade sizing models

4.     A standard template and support for user specified result templates. This would permit users to compute their own metrics as in  Sharpe, Kelly, RAR,  etc. etc

a.     For scan results

b.     For MM results

c.     For optimization run summaries

5.     Intermediate results display of backscan results, to permit early termination if the results don’t look promising. This is particularly helpful when running long scans.

6.     Equity curve display during backscan

7.     Interruption of backscan with partial results retained

8.      Entry and exit @Price

9.     Realcode access to Trade information

10.   Saving backscan trade sets permitting running vai realcode post scan

a.     Money management studies

b.     Entry studies

c.     Exit studies

d.     Correlation studies

11.   For saved backscan trade sets, permitting additional indicator values to be associated with each trade. For example @ trade entry what various ATR values were.

12.   bars in Trade variable in realcode

13.   realcode Loop support for both backscan and Money Management  runs to permit optimization

14.   For optimization

a.     Multiple formats for stating variable values

                                          i.     A set, as in  [5,7,13,23,42]

                                         ii.    A stepped range, x to y stepped by z, as in (5 to 30 by 5)

b.     Realcode access to variable assignments.

15.   Standard IO for reading and writing results. This would permit post processing of run results and adjustments of parameters for scans or MM runs.

16.   Realcode support for multiple positions with scaling into and out of positions

I  believe SF would have to be organized to use a CUDA library.  I am not sure whether vb.net programs even take advantage of multi-core processors.  i.e. it would be nice if each indicator or realcode snippet could be pushed out to a "core". 

The effort would assume that the average stockfinder user or majority could/would benefit from and afford this type of hardware.

And assume that the increases in Standard CPU motherboards would not chip away at this effort before you even finished making the code changes.  

Obviously, SF already takes advantage of threads and perhaps these can easily be tied to the CUDA calls, such that if the the CUDA/hardware exists then it uses them else uses stander multicore CPU.

-----
Assuming the vb.net is able to take advantage of the multicore arch.  Not sure if it even
     http://www.codeproject.com/KB/threads/tricky_multicore.aspx

 -- The Task Parallel Library (TPL) is designed to make it much easier to write managed code that can automatically use multiple processors. --

This test uses Microsoft Parallel Extensions to .NET Framework 3.5. The advantages of using Parallel FX are:

• No need in thread synchronization (meaning main thread and both sorting threads)
• The smallest code

Minimum SF computer is probably your Mean audience, so why put the extra effort to program/develop for CUDA environment if it takes special attention in designing code to run on CUDA.

However, once the SF is stable and you investigated