AmiBroker 6.26.0 BETA released

[SpinTrader]

Thank you Tomasz, for going out on a limb and trying to take us to the leading edge of afl.
I am sure everyone shares my appreciation for all your efforts.

Best regards,
Herman

[Tomasz]

I mean it works the way he provided the formula but somehow it doesn’t when I try to mimic his code in a different form.

That is because @aron has read what I wrote carefully and he calls StaticVarRemove BEFORE declaring the variable, so he removes variable from global memory before it gets read from global memory when variable is declared as static. That is why it works. In all your attempts you called StaticVarRemove after declarations. That is why it doesn’t have any effect.

[Tomasz]

To allow faster evolution and freedom of experimenting without “legacy” baggage some APIs (AFL functions but in the future not only that) will be marked as “Private APIs”.

Private APIs

• don’t come with backward compatibility guarantees
• they are subject to (even drastic) change from version to version
• come without any help, support, hand-holding, spoon feeding, extra education except written documentation in the readme/release notes/manual
• come “as is”, use them at your own risk/discretion
• have target audience of advanced users only, able to understand all complexities required

All functionality provided by #pragma directive is now marked as Private API.

[thankyou18]

Good idea. Don’t let support burden slow down progress of Amibroker.
The Amibroker community can assist for issues that are out of the scope of support. Perhaps pointing to the right documentation would be enough.

[Tomasz]

One feature is not mentioned in the Read Me.

AmiBroker 6.26 comes with Edit->Delete Range feature now.

So here it comes, how to use delete range feature:

1. Select begin and end of the range (double click to mark “begin” then double click to mark “end”) - green (begin) and red (end) vertical lines will appear
2. Select Edit->Delete Range menu
3. Confirmation box will appear asking you if you are sure to delete (irreversibly) the quotes from given range. Caution: this can not be undone.

The operation is pretty much instant regardless of how many quotes you have.

[ara1]

Using WIN 7 and AB ver 6.26

Runing Backtest I get a strange error

The code shown in this message is not part of the code of this program. It s on my computer someplace as I wrote it as another program.

The problem disappears when I downgrade to AB version 6.25
Ara

[Tomasz]

You should REALLY read this thread - it is already answered few posts above. And generally ALWAYS search the forum BEFORE posting.

[TrendXplorer]

After updating to 6.26 a couple of error 66's show up. When I roll back to 6.25 the errors disappear.
What could be the issue here?

One bar loop triggers the error message, while another apparently gets a pass.

JW

[Tomasz]

Scroll UP in this thread - it is described in the read me and in this thread.

[fxshrat]

@TrendXplorer,

The Readme says:

AFL: Another protection against users shooting themselves in foot, VarSet/VarGet now displays error when you try to use characters different than A-Z, 0-9 and ‘_’ in variable names

Simply use debugging methods and trace your VarGet/VarSet name.
Then you would see that it has invalid characters within varname.

Your varname is

"PosSize" + symbol + bar

So for example trace it

varname = "PosSize" + symbol + bar;
_TRACE( varname );

You will see that varname simply has invalid characters.
My guess is that you have symbol names of this type:

XXXX.TO

If you would not use Varget/VarSet but would use standard way of setting variables then you would not be allowed to create variables such as following ones too. Would you?

var.16-AAPL = "Hello World";

or

10var = "Hello World";

or

+1var = "Hello World";

etc.

No, as you know already varnames have to start with underscore or letter but are not allowed to start with number or other characters. Also one and only character different from A-Z, 0-9 being allowed within variable name is underscore “_”. No point sign, no plus sign, no minus sign, no slash … etc within variable name are allowed. Have you ever used plus sign within variable name? Surely not.

So proper examples for variable names are

var1 = "Hello World";

var_20= "Hello World";

_var10_AAPL = "Hello World";

etc.

So since your var names differ from those naming rules it is the reason for your error message.

[TrendXplorer]

No point sign, no plus sign, no minus sign, no slash … etc within variable name are allowed.

@fxshrat: Thanks for your comprehensive clarification. I should have paid closer attention when digesting the Readme.

The culprit is indeed the symbol naming: $ETF, with the now forbidden $-sign.

With the new “protection” for VarSet/VarGet in place, how are we to handle synthetic symbols like $SPY, #SPY, or @SPY? I have lots of those in my data base. Actually the Norgate data set has those too: #SPX%MA200, $SPX, %IRX to mention a few.

[fxshrat]

Replace “symbol” by “i” within varname.

So instead of

varname = "PosSize" + symbol + bar;

use

varname = "PosSize_" + i + "_" + bar;

[TrendXplorer]

@fxshrat: That’s a handy solution. Thanks again.

[TrendXplorer]

@Tomasz: Any chance making the new VarSet/VarGet variable name convention part of the system preferences?
Default setting “On” and allowing the user to opt-out, which would preserve downward compatibility of existing AFLs at the same time.

[Tomasz]

Variable identifiers must only use A-Z letters, digits and underscore. The fact that people were using invalid names caused problems including in extreme cases - crashes.

AmiBroker in version 6.26 will fix human errors itself, by replacing invalid characters with underscore automatically

[portfoliobuilder]

@Tomasz I am just curious from the non-programming background as to the reason

variable identifiers must only use A-Z letters, digits and underscore

I have seen this is the case in C++ and I assume there is a technological (legacy of programming languages? other symbols reserved for other purposes?) reason, and am just trying to learn what that might be.

[Tomasz]

The reasons were outlined already in @fxshrat post.
If you allowed *, +, -, @, /, ", spaces and all other characters in variable names, how would you know if

a+b +"c"

means:

• addition of a and b and text "c"? (what it “normally” means), or maybe rather
• variable that is called a+b+"?, or maybe
• variable that is called a+, or zillion of other choices

There is a reason why in elementary school you used convention to write x instead of 23 &%#b lah 45 to describe the variable

[TrendXplorer]

And in this course of events AmiBroker in version 6.26 will fix human errors itself, by replacing invalid characters with underscore automatically behind the scenes

@Tomasz: Well, that sure is mighty kind of you. Thanks.

[RichardScanlan]

I use eSignal data and the symbology includes “-” “~” and “$” in many symbol Names
for example" AP Z7-SFE", Z Z7-EEI …

I use many Static Variables that dynamically append the symbol name.
eg

StaticVarSet( "L_SlowMAPeriod" + Name() + Ver, LongSlowMAPeriod, persistent = True );

Given “Name()” has “-” as part of the symbol it generates error 66.
As you have automatically replaced all “-” with “_” the code still runs correctly.
Since version 6.26 every time I run a backtest I get several of these error 66 messages to close.
Took me a whie to work out what was generating this error as the error message does not reference the offending line of code.

I would like a means of eliminating the error message when I run a backtest please.

Many thanks to all in this forum who proved great support and share ideas and code.

Thanks to Tomasz and team for a truly great trading software and the ongoing development.

Richard Scanlan