Page 1 of 1

[SOLVED] Scope off variables & Math.PI vs PI et al.

Posted: Wed Aug 28, 2019 5:28 pm
by CVH
I come from an era we programmed a Z80 in machine language.
I've seen passing by Pascal, Basic, C and much, much more.
And along came the scope of variables.
At first this was quite obvious: locals, globals, static, constants and so one.
And they needed to be declared explicitly.

Now I am picking up Javascript on the go as it is used in Qcad.
So don't get me wrong if I got the noun of things wrong.
When you read online about Javascript it seems all are objects.

As I speek of a subroutine I mean a sub function in a script, a 'sub-script'.
Mostly a part of code that is used in multiple places in that script.
I found out that variables declared by var ... in a script are not in the scope of the 'sub-script'.
(as this is not introduced with .prototype. and addressed with this.function())
Declaring them simply without 'var' is as declaring them globally.
(no longer as a variable but as an object)
Then I read it is not of good practice to declare globals in Javascript ???
>> At least one cross application conflict is documented somewhere on this forum.

As Andrew allways pointed out I went through the available Qcad scripts.

For one, I see some major coding differences troughout the project.
some have vars... at the top.
Some have vars... everywhere in between. (doubling is allowed by Javascript)
Some have lots of this.xxx, this.yyy .... others don't.
And I find global declarations as well.

In detail I needed three kinds of variables in the 'sub-script'.
* Statics as pi/2, also needed at script level. (see lower)
* Non altering vars of the scriptfile in a single run.
* Altering vars of the scriptfile. (preferably done by function arguments)
Supplemental the 'sub-script' has it's own locals vars and it has to return answers, increase counters and so on.
You will judge me later if I got all of this right.

By my last count there are about a hundred occurrences of 'Math.PI/2' in the Qcad script files.
The reason I would declare a constant as pi/2 is that any calculation takes time. Just as sqrt(1/2) does.
For that, Math.PI/2 is a floating point division and when using it extremely frequent it serves to put it in a static constant variable.
Although the execution time is minor (and not super stable), the gain is in the rage of factor 10 and over.
On my PC on average 1.00 versus 12.20 nanoseconds every loop. Mega fast vs super fast.
(If you know how a division by 2 is made in an ALU its still slow)
A code snippet of the used benchmarks is include as textfile.

The only occurrence of 1.570796... not a dxf was RMath #defines M_PI_2.
This is a constant for the precompiler and of no use.
So I tested out some declarations for pi/2.

Observing my variables in de debugger scope and scope(1) I stumbled on:
* scope(1) ... Math ... PI (the Math.PI)
* scope(1) ... Math ... LN2, LN10, SQRT1_2, ...
but also:
* Scope(1) ... PI
* Scope(1) ... LN2, LN10, SQRT1_2, ...

And even better, now a plain PI returns 3.1415... !? It didn't before.
I think I can trace these last ones back to input.js implemented by the simple API.

Now I am troubled again. Why declaring all these twice?
And on two levels?

Regards
CVH

Re: Scope off variables & Math.PI vs PI et al.

Posted: Wed Aug 28, 2019 8:40 pm
by andrew
Local variables (var i) are used inside functions and cannot be addressed outside that same function.
Member variables can be used in all member functions of the same class (e.g. this.point1 in class Line2P).
Global variables are sometimes unavoidable.

PI, etc. is defined as convenience to be used in input fields in QCAD where values and expressions can be entered. A user may for example enter 2*PI for the distance of a parallel line instead of the usual JavaScript 2*Math.PI. These should be avoided in scripts and are meant for user level input fields.

Re: Scope off variables & Math.PI vs PI et al.

Posted: Thu Aug 29, 2019 6:04 am
by CVH
andrew wrote:
Wed Aug 28, 2019 8:40 pm
Global variables are sometimes unavoidable.
andrew wrote:
Wed Aug 28, 2019 8:40 pm
These should be avoided in scripts and are meant for user level input fields.
Thanks, Andrew

Maybe something to put in a header?!