|
PureBytes Links
Trading Reference Links
|
Hello,
Answering to first paragraph. It was well-though decision and the reason was quite simple:
if all variable values (including *ARRAYS*) were conserved between runs, your memory requirements
would be 20x higher than they are now. Keeping all temporary arrays would be tremendous waste of space (RAM)!
And no, do not tell me that "memory is cheap" because
32 bit Windows has limit of 2GB /3GB virtual memory size and people use such big data sets
that this limit can actualy be reached.
AFL formula should be treated as a "program". You run a program from the command line, it executes
and it exits. That's it. If you run it for second time, it runs from the scratch. If you want variables
to keep their values between runs you need to explicitely request that on variable-by-variable basis.
And taking eSignal as reference is particularly bad choice because
a) they did not write the language nor the interpreter (they use Microsoft's interpreter)
b) their system is great example how slow JScript is.
c) all eSignal formulas are 10x to 20x LONGER to write than equivalent AFL formulas.
d) it exactly shows the weakness of your concept of preserving all values - RAM is consumed much faster.
Even simplest thing (one liner in AFL) is 20 lines in eSignal.
Look at the S&C Traders Tips. AmiBroker AFL is the shortest one all the time. eSignal is the longest.
And now this is supposed to be "improvement"? No thanks.
If you like to write tons of code to do simple thing, use eSignal and JScript.
I would stay with AFL and save my fingers from ache.
Best regards,
Tomasz Janeczko
amibroker.com
----- Original Message -----
From: "scourt2000" <stevehite@xxxxxxxxxxx>
To: <amibroker@xxxxxxxxxxxxxxx>
Sent: Friday, November 06, 2009 10:56 AM
Subject: [amibroker] Re: Biggest shortcoming of AFL scripting language
>
>
>
>
> Tomasz,
>
> First off, if we're talking about programming languages in-the-large, I have no earthly idea why you ever decided that global
> variables in a script should not be remembered between runs of that script. It was your decision as a language designer to
> diverge from standard implementation practices and *that* is the root cause of confusion if we're going to compare mature,
> widespread programming languages with AFL.
>
> That being said, I will give you a perfect example of what I'm talking about in reality with another well-known charting package
> as it compares to AFL and there is absolutely no confusion involved.
>
> We all know that eSignal uses Javascript for its chart scripting language. In eSignal's usage of Javascript (aka EFS), global
> variables are, well, global variables. They retain their values through multiple runs of a script in a chart. They are global
> to the script and also private to that particular script. So, global variables are not shared among different scripts in the
> same chart or different charts.
>
> But, how did eSignal allow variables to be shared between different Javascript (EFS) scripts? Simple...in THE SAME WAY Amibroker
> does it.
>
> They created 2 functions: setGlobalValue(name, variable) and getGlobalValue(name) or, in example form:
>
> In chart #1, running script A:
>
> var a = 10; // some global variable in script A
> setGlobalValue("a", a); // set private global 'a' to a shared global 'a'. note: the global shared "a" could be any name I wanted
> it to be
>
> In chart #2, running script B:
>
> var b = 0; // some global variable in script B
>
> b = getGlobalValue("a"); // retrieve shared global 'a' and place in private global 'b'
>
> Gee, where's the confusion? There is none. Because you use a function to get and set global shared variables while normal global
> variables are "global private" (and remembered between runs) in their respective scripts.
>
> Was deciding NOT to have global variables in AFL, in the first place, NOT be remembered between runs of an AFL script a languauge
> design flaw? The answer is YES! The eSignal example proves that because temporary global variables whose values are overwritten
> between runs of a script do not have harmful side effects to global variables which don't get overwritten between runs of that
> same script. The example also showed how eSignal has implemented Amibroker's usage of setting global shared variables between
> scripts.
>
> By the way, I told everyone in my first post what the answer would be for my request..."nothing is broken, use StaticVarSet/Get".
>
> Note:
>
> ALL programming languages are flawed. But global variables retaining their values for the life of their runtime has never been
> one of them. Tomasz decided that the phrase "life of their runtime" meant one pass of a script's execution. He had no choice but
> to create a set of functions in AFL to retain global values though multiple script runs. But you should NEVER use functions to
> fix language design problems. The only purpose of the StaticVarSet/Get family of functions should be to share variables between
> DIFFERENT scripts, not to provide persistence within the same script.
>
> I don't know what the ramifications are of changing the semantics of AFL's global variables to be persistent between separate
> invocations without having to do anything else. Tomasz would be the one to give specific examples of where that would break
> existing, working code.
>
> What I do know though, is that if there is a problem with changing the semantics, it could easily be fixed to not break old code
> by introducing a new #pragma statement like:
>
> #pragma persistentglobals
>
> This would make everything transparent from the user's perspective. The old semantics would be retained and the new semantics of
> using global variables in a script to mean "global private" would have to be requested by "the unconfused" among us. ;-)
>
> There's nothing in this for Tomasz. He doesn't make more money and he could care less if I have to litter AFL code with umpteen
> thousand StaticVarSet/Get functions to solve the problem on "my side" instead of "his".
>
> But if I were the developer of AFL, it would really bother me and I would fix it so that AFL were easier to read and code.
>
> ...but I'm not...so there you go.
>
>
>
>
>
> --- In amibroker@xxxxxxxxxxxxxxx, "Tomasz Janeczko" <groups@xxx> wrote:
>>
>> Hello,
>>
>> I would not call it "shortcoming" at all. It would be shortcoming if there was NO static variables,
>> but they *are* available.
>> Sure you can complain that you need to type few more letters to read/store static variable,
>> but the functionality is there and what you call "shortcoming" is rather (in)convenience.
>>
>> As to the suggestion - actually I was thinking about it BUT... there is one rather important issue:
>>
>> in contrast to C/C++ where static variables are INVISIBLE to other object code blocks (non-shared, private variables),
>> in AFL static variables are in fact GLOBAL SHARED variables. The only common thing is than in both C/C++ and AFL
>> the static variables "keep" their values as long as program runs.
>>
>> Implementing what you are suggesting will lead to confusion and misunderstandings because
>> same syntax would have different semantics for C/C++ coders coming to AFL.
>>
>> If static keyword was introduced it would need to be private, non-shared.
>> For strict equivalence to StaticVarSet/Get one would need to introduce completely different keyword,
>> such as "shared" or "shared static". Otherwise there would be endless problems with misunderstandings
>> of visibility and scope of variables.
>>
>> Best regards,
>> Tomasz Janeczko
>> amibroker.com
>> ----- Original Message -----
>> From: "scourt2000" <stevehite@xxx>
>> To: <amibroker@xxxxxxxxxxxxxxx>
>> Sent: Thursday, November 05, 2009 9:14 PM
>> Subject: [amibroker] Biggest shortcoming of AFL scripting language
>>
>>
>> >
>> > AFL needs something like:
>> >
>> > static {
>> > a = 1;
>> > b = 2.3;
>> > c = "hello world"
>> > }
>> >
>> > The first time the script is read into a chart, the variables within the static{} clause would be created and initialized.
>> > Their values would be GLOBAL and REMEMBERED from run-to-run of the script.
>> >
>> > I know what you're thinking....
>> >
>> > "Well, you can use StaticVarGet(), StaticVarSet(), StaticVarGetText() and StaticVarSetText() and do the same thing you're
>> > trying
>> > to show here so what's your point?".
>> >
>> > My reaction to that kind of question is...HUH?!
>> >
>> > Oh, you mean you would rather say:
>> >
>> > "StaticVarSet("a", 3)" or "a = StaticVarGet("a")"
>> >
>> > rather than:
>> >
>> > "a = 3" or "a"
>> >
>> > to have values set/get and remembered between runs of the script (global, yet private to that particular script)?
>> >
>> > Now, tell me honestly, which one makes YOUR programming life easier and your scripts easier to be read by others?
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > ------------------------------------
>> >
>> > **** IMPORTANT PLEASE READ ****
>> > This group is for the discussion between users only.
>> > This is *NOT* technical support channel.
>> >
>> > TO GET TECHNICAL SUPPORT send an e-mail directly to
>> > SUPPORT {at} amibroker.com
>> >
>> > TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at
>> > http://www.amibroker.com/feedback/
>> > (submissions sent via other channels won't be considered)
>> >
>> > For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
>> > http://www.amibroker.com/devlog/
>> >
>> > Yahoo! Groups Links
>> >
>> >
>> >
>>
>
>
>
>
> ------------------------------------
>
> **** IMPORTANT PLEASE READ ****
> This group is for the discussion between users only.
> This is *NOT* technical support channel.
>
> TO GET TECHNICAL SUPPORT send an e-mail directly to
> SUPPORT {at} amibroker.com
>
> TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at
> http://www.amibroker.com/feedback/
> (submissions sent via other channels won't be considered)
>
> For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
> http://www.amibroker.com/devlog/
>
> Yahoo! Groups Links
>
>
>
------------------------------------
**** IMPORTANT PLEASE READ ****
This group is for the discussion between users only.
This is *NOT* technical support channel.
TO GET TECHNICAL SUPPORT send an e-mail directly to
SUPPORT {at} amibroker.com
TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at
http://www.amibroker.com/feedback/
(submissions sent via other channels won't be considered)
For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
http://www.amibroker.com/devlog/
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/amibroker/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/amibroker/join
(Yahoo! ID required)
<*> To change settings via email:
amibroker-digest@xxxxxxxxxxxxxxx
amibroker-fullfeatured@xxxxxxxxxxxxxxx
<*> To unsubscribe from this group, send an email to:
amibroker-unsubscribe@xxxxxxxxxxxxxxx
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|