MaplePrimes - answers and comments on Question, Error, (in printtab[CodeGeneration

local variables cannot have Array types

pagan — Thu, 05 Jan 2012 06:29:49 Z

The Compiler demands that local variables cannot have Array types, but your procedure references the entries of the locals E, V, and s as if they were 1-dimensional Arrays. Hence the procedure is doing something that the Compiler does not support.

Another way to say it is that local variables cannot be Arrays or Vector or Matrices, for the Compiler to accept the procedure. (And lists and sets and tables are not allowed, since Arrays, Vectors, and Matrices of hardware datatype are the indexable structures that the Compiler admits.)

If you read the help page Compiler you can see early on where it says, "Procedures that return arrays or allocate new arrays cannot be translated." That means that local variables cannot get new Array/Vector/Matrix assigned to them, inside the procedure.

The correct way to do what you are trying is to create all the Arrays outside of the procedure, and then to pass them in as arguments. This means locals V, E, s, and also your current global u.

It's then your choice whether to have the procedure continue to return s[Nr-1], or to just return NULL (since outside of procedure X you have access to the Array you pass in for argument s, and it gets updated in-place).

You should consider making the other globals into arguments too. Using globals when not necessary just leads to sloppy code with problems, IMNSHO. But also, for the Compiler it means callbacks to main Maple and conversions from software to hardware scalar types, and if that occurs inside a loop (not your situation here...) that can be costly (relative to compiled operations).

Also, if you are going to use the Compiler than give your procedure's arguments and locals the type information (using :: double-colon) the makes things unambiguous. Don't rely on the Compiler to magically guess that you intend on using this as a float and that as an integer, etc, because if deduced wrongly the code may compute wrongly through no fault of its own.

hm ...

Axel Vogt — Thu, 05 Jan 2012 20:31:11 Z

Have not worked it out, but I neither would use indexed variables nor arrays for
storage and also think, that 1 loop is enough, like this

for ...

v_new = ...
E_new = ...
s_new = ...

s_old = s_new, E_old = E_ new, ...

end for

Also you do not use previous values of your u, no updates while looping ?

So Pagan, could you please have a look at

alex_01 — Thu, 05 Jan 2012 16:51:38 Z

So Pagan, could you please have a look at the two attached file.
The data is in the first file and the Maple caluclations in the second.

GARCH_Estimation_(Hu.xls

pagan.mw

I tried to do as you said but I still get an error message. How would you solve that?

global u

pagan — Thu, 05 Jan 2012 18:55:27 Z

@alex_01 You need to add one more argument to `f`, for u::Array(datatype=float[8]) which was previously declared as a global.

If I add that, then `f` itself Compiles.

But GRADIENT(f) produces an error about array bounds, which you'd have to fix before you could Compile that.

The code of `f` looks logically wrong in some other respects. How can the entries of V be used if you haven't given them any values? At one point, you divide by V[i] which is going to return undefined if V[i] is zero.

I am not sure that `kuk` is going to have the correct form for the (commented out) style of call to NLPSolve.

I would try getting the Optimization call to work first (prefereably under evalhf mode as indicated by Optimization's userinfo, but in any event get it working in some usual way) and think about compiling it only later.