as you can see:
For the same netgen::Mesh object,after mesh generating,print the returned value of mesh.GetNSE(),I got:
256
Then passing the this object to WriteUserFormat(),and print the returned value of mesh.GetNSE(),I got a totally different value:
868
Why does this happen?
Related
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;
I have a test case with the following line:
XCTAssert(testVal == value)
value and testVal are both Decimals. In most cases the equivalence test gives the expected result, but not always. For instance
let value = Decimal(0xFFFF)
... do stuff that generates testVal
XCTAssert(testVal == value) // evaluates false
BUT, when I look at value and testVal, they appear to be the same.
(lldb) print testVal == value
(Bool) $R0 = false // the condition causing the test to fail
(lldb) print value.description
(String) $R1 = "65535" // what you would expect, given the init
(lldb) print testVal.description
(String) $R2 = "65535" // the same as value. Hmmm...
(lldb) print (testVal - value).isZero
(Bool) $R3 = true // the difference is zero, but they are not equal?
I checked all the attributes of the two Decimals and even the hash values are the same, yet they evaluate to not being equal. The only difference I see is that one is compact and the other is not. I don't see a way to force compaction, so I don't know if this is a factor.
When initializing with other values, like 0xFF, 65535.1, and a host of others, the tests compare successfully.
While this sort of behavior is typical of floats, it should not happen for Decimals, should it?
OK, found the answer not long after posting this: It does have to do with the Decimal being compacted. From the docs:
All the NSDecimal... arithmetic functions expect compact NSDecimal arguments.
Once I added the line
NSDecimalCompact(&testVal)
The comparisons worked as expected.
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.
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
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));