Creating a built in function?
조회 수: 47 (최근 30일)
이전 댓글 표시
I'm sure literally everyone who doesn't know a solution to this has done exactly what I'm currently doing...
I've got a special folder on my desktop called 'Functions' where I store all my .m function files that I've written over the years and use quite often. In order to use them in various workspaces/codes I have "Change the MATLAB current folder or add its folder to the MATLAB path." Which to be fair is an acceptable solution, but I would like something a little more elegant since I often update the code to these functions but it doesn't update every copied iteration of this function.
What I would like to do is add/edit the built in functions for MATLAB so I don't have to change the workspace folder or add the function to the path! I was hoping it would be as simple as adding a folder to the C:/Program Files/MATLAB/R2020a/toolbox/matlab and adding all my functions there but I've had no such luck as it still asks me to "Change the MATLAB current folder or add its folder to the MATLAB path."
Has anyone figured out how to do this or maybe another solution? I've searched high and low in the Community Forums and Google and figured it was about time to make a post about it.
댓글 수: 0
채택된 답변
dpb
2020년 7월 29일
Don't put it on the Desktop, create a folder in your user area for MATLAB and then add that folder to the MATLABPATH and make permanent.
Then, do NOT make copies of these functions all over the place, you'll reference the one and only version (excepting of course, if you do have copies for various classes of inputs; there's a whole hierarchy of directory structure outlined for that purpose.
Secondly, don't even think of adding to or modifying TMW-supplied functions -- if you do that, as soon as you update you've got to do it all over again besides the confusion that ensues from having done.
If you are working on a specific project, create a working directory specifically for it and a script to move to/from that subdir and perhaps do some other housekeeping on the way...
My prototype for this purpose looks like
>> type PROJECT
function PROJECT(varargin)
% Set environment for given project work environment
% PROJ -- set working directory for PROJ data work
% Optional arguments
% 'quit' -- restore environment to normal working
% directory prior to initial invocation
% 'init' -- clear local persistent working directory
% from present value for clean slate
% 'info' -- display current target data working directory
% and present return working directory on 'QUIT'
persistent workpath
p='C:\Set\Desired\Path\String\Here';
% handle optional arguments, then quit
option=[varargin{:}];
if strncmpi(option,'init',3), clear workpath, return, end
if strncmpi(option,'info',3),
fprintf('PROJ data location: %s\nFormer working dir: %s\n',p,workpath)
return
end
if strncmpi(option,'quit',2), cd(workpath),return,end % restore working path
% save called-from directory if 1st invocation after 'init'
if isempty(workpath), workpath=cd; end
cd(p) % go to working directory
I've not got fancy-enough to make it self-modifying; I have to go in and create a new one for each new project by replacing PROJECT/PROJ with appropriate names...I do generally use all caps for these and some name that is easily associated with the given project.
Between a base \work directory for run-of-the-mill sandbox, the \UTILS directory that contains my set of functions similar to yours described above, and the above for projects, I've yet to see a message about "change MATLAB folder..."
That's been over 20 years now and counting... :)
댓글 수: 5
dpb
2020년 7월 29일
And with the userpath option that Steven points out (that I hadn't realized was there because the above has worked for me for so long had no need to change it), you could easily add an additional place or two temporarily if needed for each project.
I'll have to think about that going forward; I could probably improve factorization somewhat on some of my stuff that I've not bothered about before.
추가 답변 (2개)
Steven Lord
2020년 7월 29일
You cannot add a built-in function to MATLAB like we at MathWorks can. But you can make the MATLAB scripts, functions, and/or classes that you write accessible to MATLAB by default if you want. See the documentation page for the userpath function.
Whatever you do, I strongly recommend that you not modify any of the folders located under matlabroot and that you do not add a new folder under matlabroot, at least not unless MathWorks Support instructs you to do so or you're installing a new product or an update release.
댓글 수: 3
Steven Lord
2020년 7월 29일
persistent is older than release R2006a. [It was "Introduced before R2006a".] It's been around since at least MATLAB 5.2, release R10 (the earliest version I chose to check) and is probably older than that.
I believe you are correct that we used to create a work folder under matlabroot for users to use, but I think we realized that keeping user files there meant they might be forgotten when users install a new release and uninstall the old. Plus at least Windows tends to be protective of people writing to the Program Files areas where MATLAB is installed by default.
dpb
2020년 7월 29일
That's undoutedly so; didn't really mean to imply it had to have been then that started using persistent.
I couldn't begin to reconstruct the initial pass at the above -- I started w/ the original 3.1 Windows release and have had an install virtually continuously since.
Like many, very early on I also had a penchant to mung on TMW-supplied functions to either fix bugs or modify behavior to fit personal desires before learning that wasn't a wise way to go... :)
It was solving that problem of updating that got me started with installing upgrades into clean, version-named subdirectories which had the side benefit of having multiple versions available with the non-expiring license (other than maintenance). All of those early releases won't run now on 64-bit machine/OS, of course, but still have one older machine with a couple pretty early releases altho I finally did trash the old AST machine w/ NT and OS2 earlier this summer. Was a painful decision to come to... :)
I do recall for a few install cycles having to go and remember to make those changes to that few distribution files; by now I've forgotten just which were the key ones. I do sorta' recall there being a release by which what were bugs had been fixed and building a custom version of the one or two that preferred to operate differently that did put in the UTILS directory instead. I think even those had been relegated to the bit bucket by about R2013 or so. Somewhere there's an archive file but it's on a spare drive so not handy to refer back to, unfortunately.
Morgan Blankenship
2020년 7월 30일
댓글 수: 5
dpb
2020년 7월 31일
You simply name your function the same and put it first in the search path.
I do NOT recommend doing this; create your functions with unique names so you don't break MATLAB compatability. Aliasing builtin or supplied functions can wreak havoc on MATLAB itself if it also relies on one of those functions for a particular behavior.
It's an easy trap to fall into when first introduced to the concept of open source of the TMW m-files or that functions alias anything and everything silently, but as the old saw on some ancient maps says "There be dragons!"
Sorry I mentioned it... :)
But, I do stand by the other advice that the UTILS directory should be static and in MATLABPATH as I illustrated above; only the variable working locations should be the modified paths that use specific locations that don't need/shouldn't have global accessibility.
IF TMW would introduce namespaces it could help a lot and also aid some in the name pollution issue the proliferation of new toolboxes and the duplicated functionality of all the similar but slightly different versions of the same thing that have exploded last few years/release cycles.
참고 항목
카테고리
Help Center 및 File Exchange에서 File Operations에 대해 자세히 알아보기
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!