I am using this function on matlab
[ProbData,HazData] = cdsbootstrap(ZeroData,MarketData,Settle,[],[],[],[],[],[],0.25)
and it is giving me an error because it dose not understand the [ ].
I want to keep the default inputs from 4-->9 and change the ninth input to 0.25. What should I put instead of the [ ]?
The function cdsbootstrap uses matlab's very common Name/Value pair syntax. Read the first few lines here:
Specify optional comma-separated pairs of Name,Value arguments. Name
is the argument name and Value is the corresponding value. Name must
appear inside single quotes (' '). You can specify several name and
value pair arguments in any order as Name1,Value1,...,NameN,ValueN.
So if you wanted ALL default values, you would use the call:
[ProbData,HazData] = cdsbootstrap(ZeroData,MarketData,Settle);
If you wanted to change one of these possiblities you would simply include the name and value, all names omitted are set to defaults. Based on your value of 0.25 I'm going to assume you are trying to set the RecoveryRate since 0.25 is close to the default.
[ProbData,HazData] = cdsbootstrap(ZeroData,MarketData,Settle,'RecoveryRate',0.25);
Ref:
http://www.mathworks.com/help/fininst/cdsbootstrap.html
Related
I'm trying to use add_line() to organize a link with the 'autorouting' parameter.
Here is my code :
add_line(sprintf('%s',diagrammeName), [pos_array_out{pos_out};pos_array_in{pos_in}], 'autorouting','on');
where pos_array_out is a cell of Output position and pos_array_in is a cell of Input position.
And pos_in and pos_out are indices of cell.
But it returns an error :
Not enough input arguments
Why do I get this error?
add_line() has three mandatory arguments when using name-value pairs: sys, out, and in, and optional name-value pairs. Breaking down your input:
add_line(sprintf('%s',diagrammeName),...
[pos_array_out{pos_out};pos_array_in{pos_in}],...
'autorouting','on'...
);
Directly tells you what the problem is. You have two input variables: 1) sprintf('%s',diagrammeName), 2) [pos_array_out{pos_out};pos_array_in{pos_in}], and the name-value pair ('autorouting','on'). So basically you fed it two of the three mandatory parameters, hence you get the error.
I suspect, due to the way you use your variable names, you should do
add_line(sprintf('%s',diagrammeName),...
pos_array_out{pos_out},...
pos_array_in{pos_in},...
'autorouting','on'...
);
i.e. split the out and in variables as suggested in the documentation.
The other type of input add_line() accepts is h = add_line(sys,points), in which case you have two positional arguments, like you do here, but cannot use name-value pairs apparently. The reason for this is that the former syntax tells you where the line starts and where it ends, and name-value pairs then control what the line looks like, i.e. where the line actually passes (moving around objects). Using sys, points is like doing plot(x,y), it draws a line between pre-specified points. Using a name-value pair to control the shape is then moot, since you already implicitly provide the shape with the points.
Doing [a;b] creates an array, which is a single variable, hence the error.
I am running something like this:
table = readtable(path,'ReadVariableNames',true);
In the .csv file all of the cells of the first row contain string identifiers like '99BM', '105CL', etc. Everything starts with a number. The command above gives a table with variable names like 'x99BM', 'x105CL', etc.
Is it possible to get rid of this 'x'? I need to compare these identifiers with a column of another table that is clear of this 'x'.
No, table variable names can't start with a number since they follow the same naming conventions as normal variables. The 'x' is automatically added by readtable to create a valid name. You should have noticed this warning when calling readtable:
Warning: Variable names were modified to make them valid MATLAB identifiers.
The original names are saved in the VariableDescriptions property.
So, you can't get rid of the 'x' within the table. But, if you need to do any comparisons, you can do them against the original values saved in the VariableDescriptions property, which will have this format:
>> T.Properties.VariableDescriptions
ans =
1×2 cell array
'Original column heading: '99BM'' 'Original column heading: '105CL''
You can parse these with a regular expression, for example:
originalNames = regexp(T.Properties.VariableDescriptions, '''(.+)''', 'tokens', 'once');
originalNames = vertcat(originalNames{:});
originalNames =
2×1 cell array
'99BM'
'105CL'
And then use these in any string comparisons you need to do.
No. As mentioned by gnovice, the readtable function automatically renames invalid names. It does this by calling matlab.lang.makevalidname and setting the output as the column name.
If I understand correctly, you're comparing the contents of a column from one table with the names of the columns of another table. In that case contains(['x' <contents of single row of column>], table.VariableNames) will prepend x to the value in a row of the table column (for this implementation, you need to loop through every row of the table) and then compare this string with the variable names of the table. You can also do this in a single line with arrayfun or something but I am doing this from memory right now and can't recall the correct syntax.
I have a function
function [ obsTime, obsWDIR, obsWSPD, obsSWH, obsMWD ] = readObsC(obsFile, endTime)
that when I run it, it gives an output of a huge array ans, which is the same array as obsTime. But obsTime, obsWDIR, obsWSPD, etc. don't display. Not a single line of code is supposed to display ans.
When I'm in debugging mode, I run the code and stop it at the very last line, and it doesn't give an output ans. Only when I hit 'step' twice and the function ends, does the ans output appear.
Everything in the function has semicolons.
Why does ans appear? Where are my other outputs?
In your function definition, you name the formal input and output arguments. That determines the name which these arguments will use within the function.
The function has its own environment, and variable names inside the function are completely independent of variable names outside the function, unless you use global or evalin('caller').
You have to provide actual input and output arguments at the time of the call, which determines how the code outside the function refers to those same arguments. There is no automatic passing of arguments simply because the names match! The only automatic thing is that if you don't specify the actual output arguments, the first actual output argument will be ans and the rest are discarded.
You could have figured this out if you simply read the MATLAB documentation for ans:
The MATLAB® software creates the ans variable automatically when you specify no output argument.
The function declaration specifies the return values, but when you call it, you don't specify anywhere for the output to go. When you call something on the command line, the output is always defaulted to ans unless you assign a variable to the output of the function when you call it.
I defined a simple function called myfunc as:
function [one,two,three,four] = myfunc(value1,value2)
Ex, using workspace variables (denoted ws_) to capture function output:
>> [ws_one,ws_two,ws_three,ws_four] = myfunc(1,2)
prints:
ws_one =
1
ws_two =
2
ws_three =
1
ws_four =
2
I don't think SPSS macros can return values, so instead of assigning a value like VIXL3 = !getLastAvail target=VIX level=3 I figured I need to do something like this:
/* computes last available entry of target at given level */
define !compLastAvail(name !Tokens(1) /target !Tokens(1) /level !Tokens(1))
compute tmpid= $casenum.
dataset copy tmpset1.
select if not miss(!target).
compute !name= lag(!target, !level).
match files /file= * /file= tmpset1 /by tmpid.
exec.
delete variables tmpid.
dataset close tmpset1.
!enddefine.
/* compute last values */
!compLastAvail name="VIXCL3" target=VIXC level=3.
The compute !name = ...is where the problem is.
How should this be done properly? The above returns:
>Error # 4285 in column 9. Text: VIXCL3
>Incorrect variable name: either the name is more than 64 characters, or it is
>not defined by a previous command.
>Execution of this command stops.
When you pass tokens to the macro, they get interpreted literally. So when you specify
!compLastAvail name="VIXCL3"
It gets passed to the corresponding compute statement as "VIXCL3", instead of just a variable name without quotation marks (e.g. VIXCL3).
Two other general pieces of advice;
If you do the command set mprint on before you execute your macro, you will see how your tokens are passed to the macro. In this instance, if you had taken that step, you would have seen that the offending compute statement and error message.
Sometimes you do what to use quotation marks in tokens, and when that is the case the string commands !QUOTE and !UNQUOTE come in handy.
I have some code where I am converting some data elements in a flat file. I save the old:new values to a hash which is written to a file at the end of processing. On subsequence execution, I reload into a hash so I can reuse previously converted values on additional data files. I also save the last conversion value so if I encounter an unconverted value, I can assign it a new converted value and add it to the hash.
I had used this code before (back in Feb) on six files with no issues. I have a variable that is set to ZCKL0 (last character is a zero) which is retrieved from a file holding the last used value. I apply the increment operator
...
$data{$olddata} = ++$dataseed;
...
and the resultant value in $dataseed is 1 instead of ZCKL1. The original starting seed value was ZAAA0.
What am I missing here?
Do you use the $dataseed variable in a numeric context in your code?
From perlop:
If you increment a variable that is
numeric, or that has ever been used in
a numeric context, you get a normal
increment. If, however, the variable
has been used in only string contexts
since it was set, and has a value that
is not the empty string and matches
the pattern /^[a-zA-Z][0-9]\z/ , the
increment is done as a string,
preserving each character within its
range.
As prevously mentioned, ++ on strings is "magic" in that it operates differently based on the content of the string and the context in which the string is used.
To illustrate the problem and assuming:
my $s='ZCL0';
then
print ++$s;
will print:
ZCL1
while
$s+=0; print ++$s;
prints
1
NB: In other popular programming languages, the ++ is legal for numeric values only.
Using non-intuitive, "magic" features of Perl is discouraged as they lead to confusing and possibly unsupportable code.
You can write this almost as succinctly without relying on the magic ++ behavior:
s/(\d+)$/ $1 + 1 /e
The e flag makes it an expression substitution.