This question already has answers here:
"Undefined function 'function_name' for input arguments of type 'double'."
(3 answers)
Closed 5 years ago.
I'm a new user of Matlab, can you please help:
I have the following code in an .M file:
function f = divrat(w, C)
S=sqrt(diag(diag(C)));
s=diag(S);
f=sqrt(w'*C*w)/(w'*s);
I have stored this file (divrat.M) in the normal Matlab path, and therefore I'm assuming that Matlab will read the function when it's starting and that this function therefore should be available to use.
However, when I type
>> divrat(w, C)
I get the following error
??? Undefined function or method 'divrat' for input arguments of type 'double'.
What is the error message telling me to do, I can't see any error in the code or the function call?
You get this error when the function isn't on the MATLAB path or in pwd.
First, make sure that you are able to find the function using:
>> which divrat
c:\work\divrat\divrat.m
If it returns:
>> which divrat
'divrat' not found.
It is not on the MATLAB path or in PWD.
Second, make sure that the directory that contains divrat is on the MATLAB path using the PATH command. It may be that a directory that you thought was on the path isn't actually on the path.
Finally, make sure you aren't using a "private" directory. If divrat is in a directory named private, it will be accessible by functions in the parent directory, but not from the MATLAB command line:
>> foo
ans =
1
>> divrat(1,1)
??? Undefined function or method 'divrat' for input arguments of type 'double'.
>> which -all divrat
c:\work\divrat\private\divrat.m % Private to divrat
As others have pointed out, this is very probably a problem with the path of the function file not being in Matlab's 'path'.
One easy way to verify this is to open your function in the Editor and press the F5 key. This would make the Editor try to run the file, and in case the file is not in path, it will prompt you with a message box. Choose Add to Path in that, and you must be fine to go.
One side note: at the end of the above process, Matlab command window will give an error saying arguments missing: obviously, we didn't provide any arguments when we tried to run from the editor. But from now on you can use the function from the command line giving the correct arguments.
The most common cause of this problem is that Matlab cannot find the file on it's search path. Basically, Matlab looks for files in:
The current directory (pwd);
Directly in a directory on the path (to see the path, type path at the command line)
In a directory named #(whatever the class of the first argument is) that is in any directory above.
As someone else suggested, you can use the command which, but that is often unhelpful in this case - it tells you Matlab can't find the file, which you knew already.
So the first thing to do is make sure the file is locatable on the path.
Next thing to do is make sure that the file that matlab is finding (use which) requires the same type as the first argument you are actually passing. I.el, If w is supposed to be different class, and there is a divrat function there, but w is actually empty, [], so matlab is looking for Double/divrat, when there is only a #(yourclass)/divrat. This is just speculation on my part, but this often bites me.
The function itself is valid matlab-code. The problem must be something else.
Try calling the function from within the directory it is located or add that directory to your searchpath using addpath('pathname').
The error code indicates the function definition cannot be found. Make sure you're calling the function from the same workspace as the divrat.m file is stored. And make sure divrat function is not a subfunction, it should be first function declaration in the file. You can also try to call the function from the same divrat.m file in order to see if the problem is with workspace selection or the function.
By the way, why didn't you simply say
s = sqrt(diag(C));
Wouldn't it be the same?
Also, name it divrat.m, not divrat.M. This shouldn't matter on most OSes, but who knows...
You can also test whether matlab can find a function by using the which command, i.e.
which divrat
I am pretty sure that the reason why this problem happened is because of the license of the toolbox (package) in which this function belongs in. Write which divrat and see what will be the result. If it returns path of the function and the comment Has no license available, then the problem is related to the license. That means, license of the package is not set correctly. Mostly it happens if the package (toolbox) of this function is added later, i.e., after installation of the original matlab. Please check and solve the license issue, then it will work fine.
Related
This is my current workspace. I have the Headers in the same folder with the otp.c but whenever I compile and run it it returns an error telling me that hmac-sha1 is undefined. Hope someone can help me.
Short Background
Including a header file enables you to compile the source file into an object file by declaring the function.
However, to get an executable, you need to link the object files together whereby one function used in one object file may be defined (i.e. implemented) in another object file. When listing the objects for the linker, they must be arranged in order of dependency, e.g if a depends on b the a should appear before b on the command line (in case of circular dependencies please find a post on it).
Solution
The way you run gcc makes it first compile the sources into object files and link them. otp.c requires the function hmac_sha1 is probably in hmac-sha1.c (I am guessing from the header file name) and so you should run:
gcc otp.c hmac-sha1.c -o otp
Note that otp.c depends on hmac-sha1.c hence the order.
I know this is a frequently asked question, but most solutions I have found are from 6-10 years ago and don't seem to work.
As a part of the C program I am writing in Visual Studio, I need to find a function that is able to return a boolean value - whether or not a file with a given name exists (the file in question is located in the debug directory, which is why I am saying file name and not file path).
I need to implement it using a library I am able to include in VS, hence using access() from the unistd.h library will not work.
Also, it has to be a safe function.
If there's a function in the WINAPI that does all of that - that would be best.
Thanks in advance for the help.
PathFileExistsW should do the job. It takes the path of the file or directory, which you want to check the existence of, as the first argument. It returns BOOL (TRUE, if the file or directory exists, and FALSE, if it doesn't. You have to include shlwapi.h as header and link against Shlwapi.lib in order to use this function.
I run the following C code to create a process. The exe file is located at C:\Program Files\Exes\Start\process1.exe
CreateProcessW(NULL, (char*) exePath,
NULL, NULL, TRUE,
flags,
NULL, NULL, &startupInfo, &processInformation);
Now some computers randomly have this file called Program located at C:\Program which causes create process to fail with the error:
%1 is not a valid Win32 application.
Is there a way to fix this problem apart from renaming the file because there are a few dozen Windows Vms on which this C code is executed. This error randomly happens on a few machines.
How does this code even compile? The second parameter to CreateProcessW is defined as a LPWSTR which means it should only accept a wide string.
The next problem: as a result of the cast it's not possible to determine what the source of exePath is. The reason this is of consequence is that the 2nd parameter is defined as a LPWSTR, not a LPCWSTR (i.e. a const wide string) for a reason: CreateProcessW may write to the buffer.
Then the 3rd problem - your exe path had a space in it. When passed as the 2nd parameter (lpCommandLine) CreateProcess has some derpy logic to guess where the exe name ends and the command line begins. Which necessitates quote encoding the exe path part of the command line.
When you have the full path to the exe - and no parameters - the simplest / safest thing to do is to just pass it as the lpApplicationName parameter. This IS a const parameter which avoids any potential undefined behaviour that could result if your command line source was a constant string literal etc. And is simply used as the path to the exe to execute, so does not (and can not) have any quoting requirements.
CreateProcess(exePath,NULL,...);
Aside: Using both parameters to CreateProcess essentially lets you set argv[0] of the launched application to be anything you want. So you could run an application from a particular path / exe name, but make argv[0] point at some other path or exe name.
To pass a parameter to the exe, rather than passing the full (quote enclosed) path you could do something simple like this:
WCHAR cmdLine[] = TEXT("console1.exe --version");
CreateProcessW(exePath,cmdLine,...);
Edits Credit to Paul Sanders and the other comments for pointing out the unquoted exe path, and also caused me to completely break my original answer which had solved that without me realising it.
Credit to RbMm for spotting I had broken my answer, and credit to eryksun for showing me that I've been reading the documentation wrong for almost 20 years now.
Chris makes a lot of good points there and you should take them on board, but the real issue, as immibis says, is that you are using the CreateProcess API incorrectly. The way you've done it requires exepath to be quoted, if it contains any whitespace.
So, instead, after you've fixed all the issues that Chris has raised, do this:
CreateProcessW (exePath, NULL,
NULL, NULL, TRUE,
creation_flags,
NULL, NULL, &startupInfo, &processInformation);
i.e. just swap the first and second parameters around (and perhaps use a more descriptive name for flags, as I've done here).
You can pass any command line arguments you might need in that second parameter, if that ever becomes a requirement. And please, read the docs.
Edit (to get my rep back :)
Also, as Chris says, exepath needs to be a wide string here, so I took out your (redundant) cast which would in fact generate a compiler error (C++) or warning (C) (so, a warning, guess, since your post is tagged As C, thank you #Barmak).
Anyway, if you now don't get one, then exepath must in reality already be a wide string so all is well. If not, then you obviously need to fix that, but I imagine this whole issue is just a typo in your post since you clearly did have your code working in order to report the behaviour you are observing.
For a class assignment we needed to write a compiler. This includes an optimizer portion. In other words, we take in a file with some "code". An output file is generated. In the second step we take in the outputted code and remove any "dead" code and re-output to a second file. I have some problems with the optimizer portion and would like to use gdb. But I can't get gdb to operate properly with the input and output files arguments. The way we would normally run the optimizer is:
./optimize <tinyL.out> optimized.out
where tinyL.out is the file outputted in the first step and optimized.out is the file I want to output with the new optimized and compiled code.
I have searched Google for the solution and the tips I have found do not seem to work for my situation. Most people seem to want to only accept an input file and not output a separate file as I need to do.
Any help is appreciated (of course)
I'm not exactly sure what you're asking. But since I'm not yet able to comment everywhere, I write this answer with a guess and edit/delete if necessary.
When GDB is started and before you start the program you wish to debug, set the arguments you want to use with set args.
A reference to the documentation.
You just need to do the file redirection within gdb.
gdb ./optimize
(gdb) run < tinyL.out > optimized.out
https://stackoverflow.com/a/2388594/5657035
I had some lua code with the following line:
JSON = loadfile("JSON.lua")()
The file JSON.lua is in the same directory as the lua code that line came from. This code worked for me for a while, and then, without my changing either the lua source, or the JSON.lua, or permission of any of the files, or the directory from where I was running the lua code, I started getting a nil error on that line. (I simply recall NO relevant changes that could have any impact on the lua code.)
Adding an assert revealed that the error was caused by the file not being found. Playing with file permissions, restarting my machine didn't resolve the issue, and pulling back code that I had checked in and was working perfectly did not resolve the error.
I resolved the error by changing the line above to provide the absolute path to that JSON.lua file.
Is there anything explaining why the code without the absolute path could have worked for a while and then stopped working?
Note: This behavior of working and then not working happened to me twice over a week. I am puzzled and though I have now found a fix, I am really curious as to the explanation for that intermittent behavior.
Lua uses package.path, whose default value comes from the environment variable LUA_PATH if it is set, as the list of directories to search. You can put . of the front of this list to load files from the current directory, or you can put your files in a path on the list.
A late answer on this, as I found exactly the same problem.
First, contrary to the previous answer, loadfile doesn't use the package.path search path. It only looks in the specified directory. And if you don't specify a directory, it only look in the 'current directory'. I can't explain exactly why it stopped working for you, but probably your Lua code is somehow being run with a different 'current directory' than previous.
There are two possible fixes: One is to specify an absolute path to loadfile.
JSON = loadfile("c:\\my_folder\\JSON.lua")()
The alternative fix depends on the particular library you're using, which I suspect is Jeffrey Friedl's Lua JSON lilbrary. Because this supports the newer Lua module mechanism, you can just load the module with require, which does support the package.path search path.
JSON = require("JSON")