compile m-file, loops, nested loops, more comprehensive solution

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

compile m-file, loops, nested loops, more comprehensive solution

GoSim
Hello, I will write another mail with some more ideas about compiling m-files. It is once again based on this quote from this thread and I am once again tired...:
 
"It could be a lot faster, if you can determine that some variables
will only be ints, doubles, double precision matrices, etc., and not
have to worry about the possibility that a variable can hold many
different kinds of values at different times during the lifetime of
the program.  But doing that automatically is what makes writing the
compiler far from trivial. "
 
http://octave.1599824.n4.nabble.com/compiling-m-files-td1616306.html
 
 
 
The basic idea is again to rename the variables. Create a class named Variable
 
Class Variable{
 
String original_variable_name = "A";
int counter = 0;//counter to add number to the end of the variable
String size = "1,1"; //size of matrix
String type = "int";//type, int, double etc
 
}
 
These values change for every variable and are only initiated here with a variable "A", "1,1" and "int" for clarity.
 
example m-code:
 
A=1; %A is int
B=1.1; %B is double
%code using A and B
 
B=2;
A=1.3;
%A and B change types
 
for i=1:10
 
A=A+B;
 
for j=1:10
 
B=1.5; %B changes to double
 
end
 
A=1; %A changes to int
 
end
 
 
//interpreted code, the name changes and the variable is redeclared if the type or size changes (for speed, don't redeclare if not necessary). It is strange to me that you automatically can handle size change of matrices but not type change, the problem is the same....?
 
//I am assuming your interpreter can figure out what type is needed
 
int A_0=1; //A is int
double B_0=1.1; //B is double
//code using A_0 and B_0
 
int B_1=2;
double A_1=1.3;
//A and B change types, no problem, their counters are increases and they are given a new name and are newly declared
//if they don't change type or size they will not be redeclared and renamed
 
 
boolean octave_flag___0=true;//flag to determine if it is the first iteration of the loop or not, this is added by the interpreter and these variables also have a counter which is increased for every loop
boolean octave_flag___1=true; flag for the inner loop, all declared outside
for int i_0=1:10 //i is int
 
if(octave_flag___0){
octave_flag___0=false;//first iteration is over
 
A_1=A_1+B_1;
//A_1 remains the same (double )as it did not change type or size,
 
 
 
 
 
for int j_0=1:10
 
if(octave_flag___1){
octave_flag___1=false;//first iteration is over
 
double B_2=1.5; //B changes to double
 
}
else{
double B_2=1.5; //B changes to double
]
 
 
end
 
int A_2=1; //A changes to int
 
}//end for octave_flag___0
else{
//the exact same code but the variables that last changed are used instead of the variables before the loop
//the last variable (A_2) replaces A_1. So create a list of variables that are used in every loop, their names before the loop
//and the name they have at the end of the loop. (The closest to "end" will be the last name of the variable and this solves
the case of nested loops)
 
 
double A_3=A_2+B_2;
//A_3 changes to double, note that it uses A_2 which is the last name of the variable instead of A_1 which is outside of the loop
 
 
 
 
 
for int j_0=1:10
 
if(octave_flag___1){
octave_flag___1=false;//first iteration is over
 
double B_2=1.5; //B changes to double
 
}
else{
double B_2=1.5; //B changes to double
]
 
 
end
 
int A_2=1; //A changes to int
 
}
 
end
 
 
So for every loop create lists that keep track of the variables that change and their names before the loop and their last names which is the names closest to the end. It is not too hard. A loop class can be created with the necessary variables (like lists) in it.
 
If the main problem for creating code that can be compiled automically is the type changes I think this can be a solution. I estimate that a compiled m-file would be 5-20 times faster so hopefully this can kindle some ideas and motivation to implement a m-file compiler. Kind regards.