This question already has an answer here:
How to unhide an overriden function?
(1 answer)
Closed 9 years ago.
On my Matlab path there's a custom zeros function. I want to store a handle to the built-in zeros in a variable. How can I do that?
Thought about #(varargin)builtin('zeros',varargin{:}), but this would probably slow down the operation due to the string comparison.
Also, I've noticed that it's possible to refer to diag as #numel\diag, but this doesn't seem to work with other built-in functions (zeros in particular).
Suggestion #1
% At the beginning of your script:
rmpath('C:\the\folder\containing\the\custom\zeros');
builtInZeros = #zeros;
addpath('C:\the\folder\containing\the\custom\zeros');
% Calling the custom zeros later:
a = zeros(10, 20);
% Calling the built-in zeros:
b = builtInZeros(10, 20);
Suggestion #2
Put these three lines into your startup file:
rmpath('C:\the\folder\containing\the\custom\zeros');
builtInZeros = #zeros;
addpath('C:\the\folder\containing\the\custom\zeros');
Suggestion #3
It's definitely a dangerous idea to reuse the name of a built-in function. It ruins the readability of your scripts, making them much more difficult to maintain. So if you have control over the custom zeros function, then rename it to something else. Use a name which describes how the custom version is different from the built-in one (for example, call it fastZeros if it's faster).
Well, this doesn't give you an exact answer to your question, but it could solve the problem:
I think this seems to be a good solution:
matlabcentral: How to call a shadowed function
Withn the last post:
Just stumbled upon this problem and found the following solution: For
example, I have matlab svmtrain shadowed by libsvm toolbox:
which svmtrain -all
C:\Projects\Ichilov\Misc\MVPA\libsvm-mat-3.0-1\svmtrain.mexw64
C:\Program Files\MATLAB\R2009b\toolbox\bioinfo\biolearning\svmtrain.m
% Shadowed
But I can access the original function by using str2func:
org_svmtrain = str2func([matlabroot '\toolbox\bioinfo\biolearning\svmtrain'])
and then simply calling:
org_svmtrain(training, groupnames)
Related
Problem
My web front-end calls back-end queries with complex arguments. During development, to avoid time-consuming manual replication of those arguments, I want to capture their values in Vars, which can be used in REPL.
Research
This article shows that inline def is a suitable solution, but I couldn't make it work. After a call from the front-end happened, the Var remained unbound.
I launched the backend with REPL through VS Code + Calva, with the following code:
(defn get-analytics-by-category [params]
(def params params)
...)
And here's the evaluation of the Var in the REPL:
#object[clojure.lang.Var$Unbound 0x1298f89e "Unbound: #'urbest.db.queries/params"]
Question
Why the code above didn't bound value of the argument to the Var? Is there another solution?
The best way that I found is to use scope-capture library. It captures all the local variables with addition of 1 line in a function, and then with another 1-liner you can define all those variables as global, which allows you to evaluate in REPL any sub-expression in the function using runtime values.
If you ever spent a lot of time reproducing complex runtime values, I strongly recommend watching their 8-min demo.
My issue with inline-def was likely caused by reloading namespace after the Var was bound to a value. After restarting VS Code and carefully doing everything again, the issue went away.
Another way to look at the runtime is to use a debugger.
It is more flexible than scope-capture, but requires a bit more work to make variables available outside an execution.
VS Code's Calva extension comes with one, there's also Emacs packages.
I am attempting to make modifications to an old fortran code to get it to handle a slightly different binary input file format. In the process of doing this I have been encountering * used in a unary fashion. For example, this code found within a loop:
CALL EVENT1(QDRBUF(IPNTR+EVTHSZ),EVTSIZ,EVTID,
- *11000,*10000,*80000)
There are other cases as well but as far as I have seen / remember it is only in function calls. What is this doing?
I'm not a Fortran guy, but this question intrigued me, so I did some looking. It appears to be an alternate return specifier. The number after the asterisk is a label that can be used in place of a normal return, almost like catching an exception.
I've been working on a programme to solve any maximisation LPP using the Revised Simplex Method. I have a problem with it though as I'm trying to input a sequence to solve the problem of non-basic variables.
My code is as follows:
matmax:=proc(tableau,basic)
local pivot,T,nbv,n,m,b;
T:=evalm(tableau);
n:=coldim(T); m:=rowdim(T);
b:=evalm(basic);
print(evalm(T));
nbv:={seq(i,i=2..n-1)}minus{seq(b[i],i=1..m)};
pivot:=getpiv(T,nbv);
while not pivot=FAIL do
b[pivot[1]]:=pivot[2];
T:=evalm(gauss(col(T,pivot[2]),pivot[1])&*T);
print(evalm(T));
nbv:={seq(i,i=2,..n-1)}minus{seq(b[i],i=1..m)};
pivot:=getpiv(T,nbv);
od;
[evalm(T),evalm(b)];
end;
The gauss and getpiv commands are procedures written to work in this programme, these work fine. However upon executing this procedure Maple returns with the message "Error, (in matmax) unable to execute seq" If anyone can give me any help on how to fix this problem it would be greatly appreciated.
If you have not loaded the linalg package before calling your matxmax then commands like coldim will simplify not work and not produce the integer results for n and m that are expected when using those in the bound of the seq calls. I believe that is why your seq error occurs, because n and m are not being assigned integer intermediate results like you expect.
You could try to remedy this by either loading the package before calling matmax, with with(linalg). But that is not so robust, and there are scenarios where it might not work. The with command won't work within a procedure body, so you can't put that inside the defn of proc matmax.
You could insert a line into matmax above, say, the local declaration line, like,
uses linalg;
That would make coldim and friends from the linalg package work. Unfortunately you've used the name pivot as a local variable, and that clashes with the pivot export from linalg package. So that simple fix via uses is not quite enough. You could use some name other than pivot, and that simple uses line, sure.
My own preference would be to make everything fully explicit, so that later on you or anyone else reading the code can understand it more clearly, even if it's longer. So I would use linalg[coldim] instead of coldim, and so on for the other exports uses from the linalg package within matmax.
Having said all the above, you should know that the linalg package is deprecated in modern Maple and that LinearAlgebra is the new package that offers the functionality you seem to be using. The command names are longer, but using the newer package means that you don't need all those evalm calls (or anything like it).
The problem could lie in your gauss and getpiv commands as they may not work with your procedure, could you expand on what they do?
I have 2 notebooks in Mathematica. I need to open nb B from nb A and get a value of some parameters (List) with known names. How can I do it without running nb B?
I think you want the functions
NotebookOpen[]
and
NotebookFind[]
but without more information about what you want to do it's difficult to be more specific than this. I'm surprised that your searches of the Mathematica documentation didn't lead you to these functions (and their relatives) already.
This question follows on from the answer given by Michael Pilat in Preventing “Plus” from rearranging things. There he defined a custom + notation using
Format[myPlus[expr__]] := Row[Riffle[{expr}, "+"]]
The problem with this is you can't copy and paste the output (although % or Out[] still works). To get around this you should use the Interpretation type facility which allows an expression to be displayed as one thing, but interpreted as another when supplied as input. My modification of Michael's answer is
Format[myPlus[expr__]] := Interpretation[Row[{expr}, "+"], myPlus[expr]]
This can be copied and pasted successfully. The problem lies in modifying copied expressions. You can convert a copied expression back to InputForm using Ctrl-Shift-I then change anything you want and use the InputForm in any expression. But if you try to change it back to StandardForm using Ctrl-Shift-N then you enter an recursion where the second argument in the Interpretation repeatedly gets evaluated. This is despite Interpretation having the attribute HoldAll (which works properly during normal evaluation).
Normally, when defining simple notations I use the low-level MakeBoxes, eg
myPlus/:MakeBoxes[myPlus[expr__],fmt_]:=With[{r=Riffle[MakeBoxes/#{expr},"+"]},
InterpretationBox[RowBox[r],myPlus[expr]]]
which works perfectly, so I have not encountered this recursion problem before.
So my question (finally) is:
What went wrong with my Format type command and how can it by fixed?
Or: How do you make a high-level equivalent of my MakeBoxes type command?
I consulted with a colleague about this, and his recommendation was essentially that putting up-value definitions on MakeBoxes as you demonstrate is better than using Format when you want things to be tightly integrated from output back to input. Format isn't really intended to produce output that can be re-used as input, but just to format output, hence the unexpected recursion with Interpretation when converting to StandardForm, etc.
You might find the function ToBoxes a useful complement to MakeBoxes.
Finally, here's a tutorial about box structures.
HTH!