Bug Reporting

[robocod]

I just found a bug (or undocumented feature). It seems that host:trace() function now does not accept strings containing the "%" symbol.

For example, the following test code fails at "test2".

Code: Select all

    host:trace("test1");
    host:trace("test2: %");
    local x = 100;
    host:trace("test3: "..x.."%");


Not sure of the reason for this. It is a change from he previous interface. The documentation does not describe any changes to this function. Please explain, or correct in the next version.

[Julia CJ]

Hi JakMike,

You can install a new version of Indicore SDK 3.1.0.
This article contains the list of changes in Indicore 3.1.0 and download link: http://fxcodebase.com/wiki/index.php/Wh ... _SDK_3.1.0

[Julia CJ]

Hi Robocod,

Trace can format strings the same way string.format does. If you need the percent sign, use double sign (i.e. %%). The same you can see in “string.format”:

core.host:trace("test1");
core.host:trace("test2: %%");
local x = 100;
core.host:trace("test3: "..x.."%%");

[robocod]

Hi Robocod,

Trace can format strings the same way string.format does. If you need the percent sign, use double sign (i.e. %%). The same you can see in “string.format”:

core.host:trace("test1");
core.host:trace("test2: %%");
local x = 100;
core.host:trace("test3: "..x.."%%");

Ok, I didn't see that in the original SDK. I've got the latest update, and I see it is there.

[ainelle]

Hi,

When the interpretor is detecting an error on an indicator, it often miss to specify the line number and it's hard to correct an error like "Error near ')'".

In case of using instance:updateFrom(), in the last version, the error detector informed the line of the call of this function, then the line of the real error inside the call. Now, only the line of the call of the function is specified. It becomes a nightmare to debug our code.

[robocod]

When making an entry order in MarketScope with stop/limit, the stop/limit price (i.e. cost based on lot size and pips) is shown. The value shown for the stop is wrong. Please check.

Here's a screenshot of what I mean. Here the stop price is lower than it should be, but I think I've seen it higher too.

[Julia CJ]

Hi Ainelle,

Could you please send the code which causes this issue? You can post it here or send at my e-mail: ycherepanova@gehtsoft.com

[Julia CJ]

Hi Robocod,

Thank you for your report about the bug. We should investigate it. I will let you know about the results as soon as possible.

[robocod]

I've found a bug with the mathex.correl() function.

This function used to work correctly, but since the update of Trading Station I have noticed that it is not working properly in some cases.

It's hard to pinpoint the problem, but here is a dump of some variables. The i & j values are indices into some forex data sources. So, it should be finding the correlation of each of these combinations of 4 streams.

Trace: 'i = 3, j = 4, correl = 0'
Trace: 'i = 2, j = 4, correl = 0.831378'
Trace: 'i = 2, j = 3, correl = -0.42464'
Trace: 'i = 1, j = 4, correl = 0'
Trace: 'i = 1, j = 3, correl = 0'
Trace: 'i = 1, j = 2, correl = -0.821594'

The "0" values are wrong. I checked this in Excel, for some of the streams

Correl(3,4) should be -0.245392393 (this was not correctly computed by mathex.correl() )
Correl(2,4) should be 0.831378106 (this was correctly computed by mathex.correl() )
Correl(1,4) should be -0.733895749 (this was not correctly computed by mathex.correl() )
Correl(1,3) should be 0.282875814 (this was not correctly computed by mathex.correl() )
Correl(1,2) should be -0.821593597 (this was correctly computed by mathex.correl() )

So, you see some are computed correctly, but others are 0 ! So, something went wrong with the computation.

I have written my own function to replace mathex.correl(), but clearly this needs investigating / fixing.

Furthermore, it raises the question about what else has been broken in the mathex library?

[robocod]

I've found a bug with the mathex.correl() function.

<< quoted post removed to save space - it's above here >>

Further to me previous bug-report on the mathex.correl() function. I have looked into this. According to internet sources, the correlation function needs to be programmed very carefully since it is summing products and squares, and these can lead to loss of significant digits if not done properly.

So, I suspect that something you have changed in the library you use is not using sufficiently precise / large variables to hold these internal sums and there is over-flow / under-flow, or general loss of significant digits.

This can be corrected by using an appropriate algorithm.