I am trying to learn some simple matlab code posted by my professor, and the first line goes somehting like
load /class/mat121/lab1/data
I've never seen "load" used like this before, what does it do? does it load all .m files in the directory?
I also see a lot of custom functions in the code, such as "T()", "Lon()", "Lat()" etc, they aren't standard matlab functions therefore I am assuming they are imported from that directory?
thanks
Title is incorrect, because "data" is not directory.
You can refer to load function.
Anyway,
/class/mat121/lab1/
this should be the directory path
data
this should be a file called "data.mat" which contains matlab workspace variable that is previously saved with save function.
So,
load /class/mat121/lab1/data
loads workspace variables from "data.mat" which is located under "/class/mat121/lab1/".
If you have access to matlab, the best thing to do would be to run the following commands and have a look at the results:
help load
help which
which T
help T
which Lon
which Lat
Running these commands should tell you:
What Load does
What which does
Where T is
What T does
Where Lon is
Where Lat is
Related
I have an .m file which I wish to share with my friends but I am not interested in giving .m file. Could someone help me with best possible ways to convert it to a file that is not decodable?
I tried converting it to .p file by simply typing pcode example.m
however I don't believe it is really protecting it. I was able to convert my .p file back to .m file with the following link. https://sites.google.com/site/sippeyfunlabs/matlab-hacks/please-do-not-secure-your-password-in-matlab-p-code
This actually confirms that my code is not protected.
It'll be nice if someone shares the best methodology to protect .m file and sharing.
Thanks
The link you provided yourself already indicates that it is very difficult to obfuscate MATLAB code:
In fact, MATLAB language is very difficult to be secured or even obfuscated.
This is due to the late binding (or dynamic binding) feature of
MATLAB. [...] The amount of meta information associated with this
feature basically forbid any attempt of adding code level security.
Simply put, if there is a MATLAB file, and it calls a function foo
inside it. Until the runtime, the MATLAB interpreter do not even know
if foo is a function stored in M file or a built-in function or a mex
function or even a workspace function handle. Thus, it must store foo
as is somewhere inside the generated P-code.
Also to best solution is already mentioned on that page:
If there is really a need to do this, using the good old binary is a
much better solution. Or you can put critical code on a server, away
from the user.
Create a binary, i.e. mex file (see the answer of Wolfie): Note that to some extent also binary code can be decompiled especially small ones.
Host your code on a server (and run the code server-side): This is the best method to protect your code. You should let the user upload the input for your script and return the result. You can also automatize this process using a matlab script to make this process transparent to the user.
You could build a mex file.
This will completely obfuscate your actual MATLAB code, since it will be written in C/C++/FORTRAN, but the algorithms will still be there if your friends are determined enough to look for them.
I've recently been using the surfnorm function and would like to access the code to see what it's actually doing. I assume it's stored on my PC somewhere, but I don't know where.
Type in edit surfnorm to open it or which surfnorm to display the path.
I have been reading someone else's matlab code and I don't know how the code structured. I mean I would like to know the hierarchy of functions, which function uses which function. I am reading the code to figure that out but its taking a lot of time.
So is there any other way I can see this hierarchy without reading the whole thing? To be honest it is starting to get confusing. Maybe MatLab has a built in function for that! I found this:
How can I generate a list of function dependencies in MATLAB?
but this doesn't seem to be helpful!
The MATLAB profiler will show you what functions are called by your code (and much more information to boot) and allow you to click through the hierarchy of function calls. You can either call profile on and then run your code, then call profile off and profile viewer, or you can simply call profile viewer and type a single line of code to run in the edit box at the top.
Use the dependency report provided in MATLAB:
http://www.mathworks.co.uk/help/matlab/matlab_prog/identify-dependencies.html
There are also some tools on the File Exchange, such as fdep.
No idea about a function to show visible or depended-upon functions. However the basic rules are:
1) Only the first function in a .m file (normally has to have the same name as the file itself) is visible outside that file.
2) Any function can see any top level (see 1.) function if the file is in the matlab path. Matlab can show you the path so you know where it's hunting.
3) The order of the path is important, the first instance of a function called foo found in the path will be called. Obviously the current directory is at the top of the path.
3) All functions in a given file can see all other functions in that file.
That's the basics. No doubt there are other rules, and possibly exceptions to this. But that understanding generally serves me well.
Obviously the easiest way to work out which function is being called is to click on it in the editor and open it.
One thing I do is simply place in each function at the beginning fprintf("inside function <name>/n"); and at the end of the function fprintf("leaving function <name>/n"); where <name> is the name of the function.
This will give you a very specific list of which function is being called by which function (based on the order that they appear). Another thing like this would be to place fprintf("function <name1> calling function <name2>/n"); so you can be more explicit about which function is being called by which one.
I am trying to put some .fig and their corresponding .m files in package.
I have:
+ui/mainWindow.fig
+ui/mainWindow.m
But when I try to run mainWindow.fig Matlab prints an error from GUIDE:
Error using feval
Undefined function or variable mainWindow
The funny thing is that if i call with its fully qualified name:
ui.mainWindow
the window appears normally (but all callbacks don't work anyway).
I have tried to import ui.* before running it.
Please note that I want to do this as sort of namespace. I don't want to have my entire application in the global scope of Matlab.
Explanation
The fundamental problem is that MATLAB GUIDE is unaware of packages. Normally, it manages the callback names automatically, keeping the .m and .fig files synchronized, and everyone is happy. When the figure is within a package, it fails to properly update the callbacks in the .fig properties - these still point to the unqualified name mainWindow rather than the correct ui.mainWindow. Subsequently, all callbacks fail.
Workarounds
Two ways around this one:
Export your figure: Guide -> File -> Export. Place this file within your +ui folder. Open the file, and do a find-replace replacing all instances of #(hObject,eventdata)mainWindow with #(hObject,eventdata)ui.mainWindow.
Alternatively, you can manually update the references directly within GUIDE itself, without exporting. For each button and element, Right Click -> Property Inspector then edit the 'Callback' field, replacing mainWindow with ui.mainWindow.
Personally, I prefer the first solution because you can replace all occurrences with a single find-replace command.
I have a simulink model with a scope output that I want to observe. However, I want the data shown on the previous simulation while being stopped to be continuously shown on the scope window, or saved to a file somewhere. Is there any easy way to achieve this? Thanks in advance.
I'm not sure about showing it on the scope, but you can save the data shown in a scope to a workspace variable, and then save that variable to a mat file.
See the section on Save data to workspace in the scope documentation