Ignoring an output parameter from vDSP - swift

When using vDSP to perform some speedy calculations, I often don't care about one of the output parameters. Let's say I'm finding the index of an array's maximum value:
var m:Float = 0
var i:vDSP_Length = 0
vDSP_maxvi(&array,
1,
&m,
&i,
vDSP_Length(array.count))
Ideally, I'd like to get rid of m altogether so that vDSP_maxvi fills i only. Something like:
var i:vDSP_Length = 0
vDSP_maxvi(&array,
1,
nil,
&i,
vDSP_Length(array.count))
But of course this doesn't work ("nil is not compatible with expected argument type 'UnsafeMutablePointer<Float>'"). Is there some sort of argument I can send to these kinds of methods that says "ignore this parameter"? Thanks for reading.

Except for documented cases where a null argument is accepted, you must pass a valid address. There is no argument value that tells vDSP to ignore the argument.

Related

getting the value from a checkbox in Matlab 2018

I am upgrading my Matlab from 2013b to 2018b and have found out that MathWorks have made quite a few changes to the GUI's.
One problem I am having is getting the value of checkbox. The line below is the code I used to use but now it doesn't work.
if get(handles.check_perf_attr,'Value') == 1
The error message is,
Undefined operator '==' for input arguments of type 'cell'.
So I tried the line below to just get the value that is being returned and then apply some logic.
tValue = get(handles.check_perf_attr,'Value');
However tValue is 2 x 1 cell which in (1, 1) = 0 & (2, 1) = 1. I don't really understand this as surely a checkbox can only be one value true (1) or false (0)?
get returns a cell array with values when applied to an array of handles.
Thus, I think your problem is that handles.check_perf_attr contains two handles, not one.
"Dot notation is a new syntax to access object properties starting in R2014b."
so try
if handles.check_perf_attr.Value == 1
or
tValue = handles.check_perf_attr.Value;

Specman: Why DAC macro interprets the type <some_name'exp> as 'string'?

I'm trying to write a DAC macro that gets as input the name of list of bits and its size, and the name of integer variable. Every element in the list should be constrained to be equal to every bit in the variable (both of the same length), i.e. (for list name list_of_bits and variable name foo and their length is 4) the macro's output should be:
keep list_of_bits[0] == foo[0:0];
keep list_of_bits[1] == foo[1:1];
keep list_of_bits[2] == foo[2:2];
keep list_of_bits[3] == foo[3:3];
My macro's code is:
define <keep_all_bits'exp> "keep_all_bits <list_size'exp> <num'name> <list_name'name>" as computed {
for i from 0 to (<list_size'exp> - 1) do {
result = appendf("%s keep %s[%d] == %s[%d:%d];",result, <list_name'name>, index, <num'name>, index, index);
};
};
The error I get:
*** Error: The type of '<list_size'exp>' is 'string', while expecting a
numeric type
...
for i from 0 to (<list_size'exp> - 1) do {
Why it interprets the <list_size'exp> as string?
Thank you for your help
All macro arguments in DAC macros are considered strings (except repetitions, which are considered lists of strings).
The point is that a macro treats its input purely syntactically, and it has no semantic information about the arguments. For example, in case of an expression (<exp>) the macro is unable to actually evaluate the expression and compute its value at compilation time, or even to figure out its type. This information is figured out at later compilation phases.
In your case, I would assume that the size is always a constant. So, first of all, you can use <num> instead of <exp> for that macro argument, and use as_a() to convert it to the actual number. The difference between <exp> and <num> is that <num> allows only constant numbers and not any expressions; but it's still treated as a string inside the macro.
Another important point: your macro itself should be a <struct_member> macro rather than an <exp> macro, because this construct itself is a struct member (namely, a constraint) and not an expression.
And one more thing: to ensure that the list size will be exactly as needed, add another constraint for the list size.
So, the improved macro can look like this:
define <keep_all_bits'struct_member> "keep_all_bits <list_size'num> <num'name> <list_name'name>" as computed {
result = appendf("keep %s.size() == %s;", <list_name'name>, <list_size'num>);
for i from 0 to (<list_size'num>.as_a(int) - 1) do {
result = appendf("%s keep %s[%d] == %s[%d:%d];",result, <list_name'name>, i, <num'name>, i, i);
};
};
Why not write is without macro?
keep for each in list_of_bits {
it == foo[index:index];
};
This should do the same, but look more readable and easier to debug; also the generation engine might take some advantage of more concise constraint.

Strings Expansion is changing order or the string

I'm trying to so some normal variable expansion in a string and, when it's in a function, it comes out out-of-order.
function MakeMessage99($startValue, $endValue) { "Ranges from $startValue to $endValue" }
MakeMessage99(1, 100)
This returns Ranges from 1 100 to then it should return Ranges from 1 to 100
Functions in powershell shouldn't use parenthesis to enclose parameters. Instead:
PS C:\> MakeMessage99 1 100
Ranges from 1 to 100
Where MakeMessage is your function, "1" is a parameter in the first position, and "100" is a parameter in the second position. According to about_Functions_Advanced_Parameters:
By default, all function parameters are positional. Windows PowerShell assigns position numbers to parameters in the order in which the parameters are declared in the function.
Powershell has several ways to check input going in. You could cast the input as a numeric type. There are also baked-in validation methods for parameters that may prevent this sort of error in the future. If you really want an integer, a simple cast would cause an array to be invalid input. For example:
function MakeMessage99 {
Param
(
[int]$startValue,
[int]$endValue
)
"Ranges from $startValue to $endValue"
}
You could also explore range validation (such as [ValidateRange(0,100)]), pattern validation (such as [ValidatePattern("[0-9][0-9][0-9][0-9]")] to validate a four-digit number) or other validation attributes listed in the link above.
This is a common pitfall in PowerShell. When you invoke...
MakeMessage99(1, 100)
...you're actually passing an array containing the values 1 and 100 as the first parameter. To pass 1 as the first parameter and 100 as the second parameter, use...
MakeMessage99 1 100

Error comes in Expected expression?

Here I tried to insert a value in GLKVector2Add value but the error comes expected expression missing in this line.
GLKVector2 self.position = GLKVector2Add({-200.695, 271},{-803.695, 0}); //Error - Expected expression
Try creating "GLKVector2" variables, setting them and then passing those as arguments in your call to "GLKVector2Add". It may be that the compiler simply doesn't know what to do with "{-200.695,271}" (a mix of float and integer numbers).
You must add them using GLKVector2Make.
So, your code will be:
GLKVector2 position = GLKVector2Add(
GLKVector2Make(-200.695, 271),
GLKVector2Make(-803.695, 0));

Coffeescript: how do I convert a string to a number?

I am building a JSON object that is sent in a POST request.
This object has properties that need to be converted from string type to integer type before sending. How does one do that with coffeescript?
Use the javascript parseInt function.
number = parseInt( stringToParse, 10 );
Reference is here.
Remember, coffeescript is just javascript after it's compiled
You can use the less obvious, more magical, less keyboard-intensive operator +:
+"158"
Javascript's parseInt function will achieve this. Remember to set the radix parameter to prevent confusion and ensure predictable behaviour. (E.g. in Coffeescript)
myNewInt = parseInt("176.67", 10)
There's a few good examples in the MDN resources: https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/parseInt
It hasn't been documented in the official manual yet, but it seems that cast operators works too:
myString = "12323"
myNumber = (Number) myString
I don't recommend using parseInt since it's wrong in one case - which I found :
parseInt('09asdf', 10);
#> return 09 which is not correct at all. It should return NaN
The correct answer should be the one from #Corkscreewe. And there is another:
cleanInt = (x) ->
x = Number(x)
(if x >= 0 then Math.floor(x) else Math.ceil(x))
Learn from https://coderwall.com/p/cbabhg
Based on the link, mentioned in nXqd's answer, you can also implicitly convert a string by multiplying it by 1:
'123' * 1 // 123
It behaves correctly for incorrect input:
'123abc' * 1 // NaN
You can do this also with floats:
'123.456' * 1 // 123.456
This is a simple way for your need. NaN will be returned as expected.
parseInt( "09asdf".match(/^\d+$/)?[0] ? NaN, 10)
stringToConvernt = "$13,452,334.5"
output = Number(stringToConvernt.replace(/[^0-9\.]/g, ''))
console.log(output)
//The output is `13452334.5`.
I'm always using bitwise OR to convert strings into integers.
"99.999" | 0 // returns 99