I am little bit stuck with contivo mapping analyst 5.6
issue is that I could not find any function to multiple some source value with another integer value.
Example
If Source exists
Move Source * 3 to Target
Else
Move -1 to target
EndIf
Thanks
You can use Compute method for contivo:
If Source exists
compute target = Source * 3
Else
Move -1 to target
EndIf
Related
Can't work out why 1/6 keeps returning me 0 and how to resolve it.
Print(1/6);
Print(DoubleToString((1/6),8));
Prints 0.00000000
You need one double number in expression. Try: Print(1/6.0);
Why:
The code above presents a pair of constant ( that happen to be 1 and 6 in the posted case ).
The MQL4 language is a compiled language and ( after expansion of #define macros, #include and similar pre-compilation steps have taken their place ) the compiler in the compilation phase "reads" your code and lexically analyses, what is there intended to be done.
Having seen an expression of 1 / 6 in the code, the compiler knows, there is nothing that could change this part of code at runtime, inside the run-time ecosystem, and thus it tried to reduce this part of static-value code.
The compiler was hardwired so as to assemble the code-execution file-format ( an .MQ4-file ) into which it will -- no surprise in this -- put a straight 0, as the compiler decided from the static code analysis -- a constant, derived from a compile-time known pair of integer literal constants 1 and 6, not to waste a single nanosecond at runtime to ( re-)-evaluate the compile-time known value of 0.
How to resolve it:
double enumerator = 1,
divisor = 6;
Print( enumerator / divisor );
Print( DoubleToString( enumerator / divisor ),
8
)
);
I'm using luacheck (within the Atom editor), but open to other static analysis tools.
Is there a way to check that I'm using an uninitialized table field? I read the docs (http://luacheck.readthedocs.io/en/stable/index.html) but maybe I missed how to do this?
In all three cases in the code below I'm trying to detect that I'm (erroneously) using field 'y1'. None of them do. (At run-time it is detected, but I'm trying to catch it before run-time).
local a = {}
a.x = 10
a.y = 20
print(a.x + a.y1) -- no warning about uninitialized field y1 !?
-- luacheck: globals b
b = {}
b.x = 10
b.y = 20
print(b.x + b.y1) -- no warning about uninitialized field y1 !?
-- No inline option for luacheck re: 'c', so plenty of complaints
-- about "non-standard global variable 'c'."
c = {} -- warning about setting
c.x = 10 -- warning about mutating
c.y = 20 -- " " "
print(c.x + c.y1) -- more warnings (but NOT about field y1)
The point is this: as projects grow (files grow, and the number & size of modules grow), it would be nice to prevent simple errors like this from creeping in.
Thanks.
lua-inspect should be able to detect and report these instances. I have it integrated into ZeroBrane Studio IDE and when running with the deep analysis it reports the following on this fragment:
unknown-field.lua:4: first use of unknown field 'y1' in 'a'
unknown-field.lua:7: first assignment to global variable 'b'
unknown-field.lua:10: first use of unknown field 'y1' in 'b'
unknown-field.lua:14: first assignment to global variable 'c'
unknown-field.lua:17: first use of unknown field 'y1' in 'c'
(Note that the integration code only reports first instances of these errors to minimize the number of instances reported; I also fixed an issue that only reported first unknown instance of a field, so you may want to use the latest code from the repository.)
People who look into questions related to "Lua static analysis" may also be interested in the various dialects of typed Lua, for example:
Typed Lua
Titan
Pallene
Ravi
But you may not have heard of "Teal". (early in its life it was called "tl"); .
I'm taking the liberty to answer my original question using Teal, since I find it intriguing.
-- 'record' (like a 'struct')
local Point = record
x : number
y : number
end
local a : Point = {}
a.x = 10
a.y = 20
print(a.x + a.y1) -- will trigger an error
-- (in VS Code using teal extension & at command line)
From command line:
> tl check myfile.tl
========================================
1 error:
myfile.tl:44:13: invalid key 'y1' in record 'a'
By the way...
> tl gen myfile.tl'
creates a pure Lua file: 'myfile.lua' that has no type information in it. Note: running this Lua file will trigger the 'nil' error... lua: myfile.lua:42: attempt to index a nil value (local 'a').
So, Teal gives you a chance to catch 'type' errors, but it doesn't require you to fix them before generating Lua files.
I have two Mat:
A:
size(1,640)
B:
size(640,480)
I want to copy A to B's first column so I use A.copyTo(B.col(0)).But this failed. How to do it?
You were on the right track! Mat:col is the matching tool to use :)
But beware, simply assigning one col to another one won't work as you may expect it, because Mat:col just creates a new matrix header for the matrix column you specified and no real copy of the data.
Example code:
B.col( 0 ) = A.col( 0 ); // won't work as expected
A.col( 0 ).copyTo( B.col(0) ); // that's fine
x(n) is given
need x(-n+3)
so to solve it:
first advance the x(n) signal by 3 units(time)
then fold it, or make a reflection of it
are the above steps correct or is the following correct
first fold the x(n) signal
then advance the signal by 3 units
?
Yes, this is a common source of confusion when learning about signals. Here's what I usually do.
Let y[n] = x[-n+3]. Because of -n, y[n] is obviously a time-reversed version of x[n]. But the question about the shift remains.
Notice that y[3] = x[0]. Therefore, y[n] is achieved by first reflecting x[n] about n=0 and then delaying the reflected signal by 3.
For example, let x[n] be the unit step function u[n]. Draw x[n], then draw y[n].
Actually here is what I do:
Let
x(n) = {1,-1,2,4,-3,0,6,-3,-1,2,7,9,-7,5}
^
Suppose origin or n=0 is 6. Note that the ^ symbol indicates the origin. First, we find the folder sequence of x(-n) from x(n). So first we fold or we can say reverse the form of x(n), we get,
The folder sequence of x(-n) from x(n) is
x(-n) = {5,-7,9,7,2,-1,-3,6,0,-3,4,2,-1,1}
^
then shift the sequence of x(-n) towards right hand side by 3 units, we will get
x(-n+3) = {5,-7,9,7,2-1,-3,6,0,-3,4,2,-1,1}
^
Now, the sample 4 is at the origin.
Above steps are correct.
The following steps can be corrected too if these are followed like:
first fold the x(n) signal
then delay the signal by 3 units this will yield x(-n+3).
I've been working on Issue 14 on the PascalScript scripting engine, in which using a Goto command to jump out of a Case block produces a compiler error, even though this is perfectly valid (if ugly) Object Pascal code.
Turns out the ProcessCase routine in the compiler calls HasInvalidJumps, which scans for any Gotos that lead outside of the Case block, and gives a compiler error if it finds one. If I comment that check out, it compiles just fine, but ends up crashing at runtime. A disassembly of the bytecode shows why. I've annotated it with the original script code:
[TYPES]
<SNIPPED>
[VARS]
Var [0]: 27 Class TFORM
Var [1]: 28 Class TAPPLICATION
Var [2]: 11 S32 //i: integer
[PROCS]
Proc [0] Export: !MAIN -1
{begin}
[0] ASSIGN GlobalVar[2], [1]
{ i := 1;}
[15] PUSHTYPE 11(S32) // 1
[20] ASSIGN Base[1], GlobalVar[2]
{ case i of}
[31] PUSHTYPE 25(U8) // 2
{ 0:}
[36] COMPARE into Base[2]: [0] = Base[1]
[57] COND_NOT_GOTO currpos + 5 Base[2] [72]
{ end;}
[67] GOTO currpos + 41 [113]
{ 1:}
[72] COMPARE into Base[2]: [1] = Base[1]
[93] COND_NOT_GOTO currpos + 10 Base[2] [113]
{ goto L1;}
[103] GOTO currpos + 8 [116]
{ end;}
[108] GOTO currpos + 0 [113]
{ end; //<-- case}
[113] POP // 1
[114] POP // 0
{ Exit;}
[115] RET
{L1:
Writeln('Label L1');}
[116] PUSHTYPE 17(WideString) // 1
[121] ASSIGN Base[1], ['????????']
[144] CALL 1
{end.}
[149] POP // 0
[150] RET
Proc [1]: External Decl: \00\00 WRITELN
The "goto L1;" statement at 103 skips the cleanup pops at 113 and 114, which leaves the stack in an invalid state.
Delphi doesn't have any trouble with this, because it doesn't use a calculation stack. PascalScript, though, is not as fortunate. I need some way to make this work, as this pattern is very common in some legacy scripts from a much simpler system with little in the way of control structures that I've translated to PascalScript and need to be able to support.
Anyone have any ideas how to patch the codegen so it'll clean up the stack properly?
IIRC the goto rules in classic pascals were:
jumps are only allowed out of a block (iow from a higher to a lower nesting level on the "same" branch of the tree)
from local procedures to their parents.
The later was afaik never supported by Borland derived Pascals, but the first still holds.
So you need to generate exiting code like Martin says, but possibly it can be for multiple block levels, so you can't have a could codegeneration for each goto, but must generate code (to exit the precise number of needed blocks).
A typical test pattern is to exit from multiple nested ifs (possibly within a loop) using a goto, since that was a classic microoptimization that was faster at least up to D7.
Keep in mind that the if evaluation(s) and the begin..end blocks of their branches might have generated temps that need cleanup.
---------- added later
I think the codegenerator needs a way to walk the scopes between the goto and its endpoint, generating the relevant exit code for blocks along the way. That way a fix works for the general case and not just this example.
Since you can only jump out of scopes, and not into it that might not that be that hard.
IOW generate something that is equivalent to (for a hypothetical double case block)
Lgoto1gluecode:
// exit code first block
pop x
pop y
// exit code first block
pop A
pop B
goto real_goto_destination
Additional analysis can be done. E.g. if there is only one scope, and it has already a cleanup exit label, you can jump directly. If you know for certain that the above pop's are only discarded values (and not saves of registers) you can do them at once with add $16,%esp (4*4 byte values) etc.
The straightforward solution would be:
When generating a GOTO for goto statement, prefix the GOTO with the same cleanup code that comes before RET.
It looks to me like the calculation of how far to jump forward is the problem. I would have to spend some time looking at the implementation of the parser to help further, but my guess would be that additional handling must be performed when using a goto and there are values on the stack AND the goto would be placed after those values would be removed from the stack. Of course to determine this you would need to save the current location being parsed (the goto) and the forward parse to the target location watching for stack changes, and if so then to either adjust the goto location backwards, or inject the code as Martin suggested.