I have not thought so much of this before I started learning c++ and I have not needed to terminate matlab from a program so many times before. The question just occured to me:
Are there any perils in using the functions quit and exit in matlab? I know that these functions should never be used except for emergencies in c++. However, in my little dream world matlabs functions are in most cases stable which speaks towards that matlab do a successful cleaning of resources even in the case where exit or quit is called. As always this kind of documentation is a bit hard to find for matlab. I am also curious if the same principles applies for both windows and linux.
In case no cleaning is done here, are there any way to fix it? Like creating the file finish.m and letting it contain only a clear all call or so?
BR/Patrik
Unlike c++, Matlab has its own garbage collector that takes care of all the "cleaning" stuff for you. So, when you exit or quit Matlab resources are cleaned for you (!)
If you are using some custom data types or you have data you want to save prior to exit you'll need to take care of them by yourself. You can define a custom script containing commands to be executed upon terminating Matlab, see finish for more details.
Related
Lisp allows one to recompile segments of code during debugging producing live stack frames. I know that lisp is dynamic and that it's easy to rebind a symbol associated to a method. However Lisp also easily allows to redefine single forms inside a function. This is even more powerful and flexible than what C# and Java debuggers can do. Why and how does it work? Why modern languages do not provide the same level of sophisitication? Where I can find some papers or books so to learn more?
It's not magic. I did the same in the old days in assembly. I created a DOS TSR program that pointed the interrupts I could handle to my own location. When you did a division by zero or something like that it jumped into my program and the stack had all the previous programs stack and where it had gone wrong. I just provided a menu with ways to mend it so that it didn't exit with DOS default behaviour.
In CL you have like a default exception handler that calls a function that you can see your options on restarts. Restarts are like code within the scope of where the error originates with ways to mend the situation. It's possible to make something like this in any language that has exceptions and closures. The debugger and restarts become a part of the running program and thus it becomes more safe on the cost of less performance. Here is a JavaScript implementation.
There is a way to turn it off and it might make your programs faster in CL. The standard does not require to do anything so it's optional, but implementations do make unsafe fast code that might end up as a segmentation fault instead of the debugger.
I wounder what is the most efficient way to run a program, given as executable, from Matlab many times in a for loop. At the moment I use the following Code:
for i = 1:100
system('MyProgram.exe');
% Do something with the output from the .exe
end
So, from the profiler I know that 99,9% of the time is used in the execution of the Program itself. My question is basically if there is a more efficient way to run executables in general from within Matlab?
I have read that everytime I run an exe like described above, a process is created which has to initialize the Matlab runtime environment... Is there possibly a way to avoid this by only doing the initialization once and from there on run the programm multiple times?
I am guessing your can't directly modify the .exe's you are given, so perhaps there is a way to instead of calling the .exe directly, you could call a .bash shell script.
I would imagine that if you do this and within the shell script check to see if a workspace is already open to associate the execution of the .exe with a specific process ID. Although I would guess that when the executable finishes it closes the session.
Just throwing some stuff out there :P I have had lots of trouble with how Matlab handles this kind of thing (Also things like Excel).
Hope you figure this out.
EDIT: I found some possible examples here Example Descriptions
-Kyle
I'm currently doing some combustion engine analysis which has lead me to try and pass some specific heats from EES to matlab, by using EES-macros (.emf files) to generate the properties. This works great for simple tasks where the properties are just assigned to variables in the macros which is then exported and read by Matlab.
Now, I'm interested in getting the properties of products in chemical equilibrium calculations, so I need to solve coupled equations in EES. This poses a problem since you can't have unassigned stuff on the right hand side in EES-macros.
The above problem was quickly solved simply by solving the equations for the equilibrium composition in a reguler .ees-file and then exporting the results. But this has led to another problem:
Once I call my Matlab-script the procedure starts "hanging" just before the specific heats are returned. I've found that the script completes once you manually close the now-opened EES-window, but this is not viable since i need to make several hundreds of imports.
The problem doesn't occur when using EES-macros instead of files, since in these you can simply use the Quit statement in the end, but as mentioned macros are not an option for this. Does anyone know of an equivalent statement that you can use in an EES-FILE? I've also tried to shut down EES with a system-command in my script: system('taskkill /F /IM EES.EXE');. But this doesn't seem to be able to find the EES-task, although it appears in the task manager and in the taskbar (the statement is tested, it works if you open EES manually).
Any help is very much appreciated, thanks in advance!
Regards
You can use a macro file to solve the EES file and then quit the program.
Example.emf contains:
Open C:\Example.ees
Solve
Quit
And then the MATLAB system call
system('$EESPath\ees.exe C:\Example.emf');
will do the job.
You will need to leverage the $Export directive to place the results into an external file that MATLAB can then import.
I have a lot of if statements throughout my code and was wondering if there is anyway in Matlab to see which if statements are being used when I run my code. I know I could put variables throughout my code and see which ones are being triggered, but I was wondering if there is an easier way. Maybe a built in MATLAB function or something.
Thanks
Type profile viewer in the command line of matlab and execute your code from there. There you can see in the profile report how many times each line is called as well as how long it takes executing the line of code.
More information:
http://www.mathworks.nl/help/matlab/ref/profile.html
http://www.mathworks.nl/help/matlab/matlab_prog/profiling-for-improving-performance.html
To answer precesely to your question, there is a command to log every line the execution is going through. And if you're familiar with unix-like platform, it is the same command: echo. See the Matlab help of echo to see how you can use it. For example, echo on all sets echoing on for all function files.
Besides that, I advise you two things better than analysing the output of echoing a whole script:
look at every warning in the code editor, and apply meaningful corrections.
use the profiler of matlab, as stated in the answer from EJG89, it is indeed a powerful tool!
Whether or not I compile a Racket program seems to make no difference to the runtime performance.
Is it just the loading of the file initially that is improved by compilation? In other words, does running racket src.rkt do a jit compilation on the fly, which is why I see no difference in compiling vs interactive?
Even for tight loops of integer arithmetic, where I thought some difference would occur, the profile times are equivalent whether or not I previously did a raco make.
Am I missing something simple?
PS, I notice that I can run racket against the source file (.rkt) or .zo file. Does racket automatically use the .zo if one is found that corresponds to the .rkt file, or does the .zo file need to be used explicitly? Either way, it makes no difference to the performance numbers I'm seeing.
Yes, you're right.
Racket compiles code in two stages: first, the code is compiled into bytecode form, and then when it runs it gets jitted into machine code. When you compile a file, you're basically creating the bytecode which saves on re-compiling it later. Since that's usually not something that takes a lot of time for small pieces of code, you won't see any noticeable difference in runtimes. For an extreme example, you can delete all *.zo files in the collection tree and start DrRacket -- it will take a lot of time to start since there's a ton of code, but once it does start, it would run almost as usual. (It would also be slow to click "run" since that will reload and recompile some files.) Another concern for bigger pieces of code is that the compilation process can make memory consumption higher, but that's also not an issue with smaller pieces of code.
See also the Performace chapter in the guide for hints on how to improve performance.
Racket will always compile your code, regardless of whether it is run interactively at the REPL or run from the command-line. Here is the section in the guide that explains it. In interactive mode, the compiler turns every expression/definition into bytecode in memory and executes that. Otherwise, the compilers outputs the bytecode to zo files.
Note: Eli replied at the same time I did. See his response for more details.