I'm just working on a new porject an I'm working actually with simple coordinates:
if (locationOnJoystick.x > joystickArea.frame.size || locationOnJoystick.y > joystickArea.frame.size) {
But while running the code I get an ERROR:
error: invalid operands to binary > (have 'CGFloat' and 'CGSize')
Can anyone see the solution?!
Sincerly,
mavrick3.
locationOnJoystick.x is a CGFloat, while joystickArea.frame.size is a CGSize. They're different types, you cannot compare them.
I guess you should compare locationOnJoystick.x with the width of your joystickArea.frame.size (and the same with y and height):
if (locationOnJoystick.x > joystickArea.frame.size.width || locationOnJoystick.y > joystickArea.frame.size.height) {
Related
The title says most of it: I'm trying to blend two images with mode F, that is 32-bit float pixel values. However, I get an error from PIL that says:
image has wrong mode
However, I have verified that both images are of mode F and cannot find any evidence that this shouldn't be possible. Is there some way to make this work, preferably without converting to a new image type?
I'm pretty sure, that – under the hood – Image.blend calls this implementation. The very first check there is:
/* Check arguments */
if (!imIn1 || !imIn2 || imIn1->type != IMAGING_TYPE_UINT8 || imIn1->palette ||
strcmp(imIn1->mode, "1") == 0 || imIn2->palette ||
strcmp(imIn2->mode, "1") == 0) {
return ImagingError_ModeError();
}
So, although not stated in the documentation, I'd guess, that Image.blend is only supported for uint8 image modes.
I need to know if something is between two limits, but I keep getting the same 2 errors in playground and I can't seem to find a solution on the web. Any idea how to do this in Swift?
var upperLimit = 20
var a = 10
var lowerlimit = 5
if a > lowerlimit < upperLimit{
println(a)
}
if lowerlimit < a < upperLimit{
println(a)
}
Both of these methods give the same (2) error messages:
---> ! Non-associative operator is adjacent to operator of same precedence
--> Cannot invoke '<'with an argument of list type '($t4, #Ivalue Int)'
That's not a valid way to make the comparison. You need to check against the bounds with two comparisons:
if a > lowerlimit && a < upperLimit {
println(a)
}
Although I prefer this way using pattern recognition on a range.
if lowerlimit..<upperLimit ~= a {
println(a)
}
Note that the pattern recognition way requires the lower bound to be inclusive, so you'd need to increase the lowerLimit variable by one.
I need some help in a bad way. I swear I have looked for now 1 week for an answer to this, and have been unsuccessful, so I come crawling for help.
My goal is simple. I am trying to use the OpenCV library in Xcode. I'm having some round about frustrating problem. I got the OpenCV library to work well with cvCanney and cvAdaptive Transforms, but I can't get it to do cv::dft(). I started by attempting the following:
cv::Mat tempMat = [self.imageView.image CVGrayscaleMat];
cv::dft(tempMat, output2);
This would error because it was not in the proper format (CV_32FC1). So I then tried:
cv::Mat tempMat = [self.imageView.image CVMat];
cv::cvtColor(tempMat, output2, CV_32FC1);
cv::dft(output2, output3);
and I get the same error. Specifically the error reads:
Assertion failed (type == CV_32FC1 || type == CV_32FC2 || type == CV_64FC1 || type == CV_64FC2) in dft
As an update to the original question, I've been trying to determine the type using cv::type() and it returns a type= 24. Can anyone explain to me how to decipher what this type means? Is it the wrong type? Latest attempt:
cv::Mat tempMat = [self.imageView.image CVMat];
cv::Mat output2(tempMat.rows, tempMat.cols, CV_32FC1);
cv::cvtColor(tempMat, tempMat, CV_32FC1);
int type = tempMat.type();
int type2 = output2.type();
When I run this I get a type of 24 for tempMat, and a type of 5 for output2. If I try to add this:
cv::cvtColor(output2, output2, CV_32FC1);
I get error: Assertion failed (scn == 3 || scn == 4) in cvtColor
Any ideas? Even if it a RTFM suggestion, I'll take anything at this point. Please help.
Thank you.
I think it is a variable type and number of channels problem.
cv::Mat tempMat = [self.imageView.image CVMat];
cv::Mat output2;
cv::cvtColor(tempMat,output2, CV_BGR2GRAY);
output2.convertTo(output2, CV_32FC1);
cv::dft(output2, output2);
output2.convertTo(image, CV_8UC1);
Please let me know if this works, I have a similar code in my project and tried to derive an answer from it; thus it may contain some errors. And we can work it through interactively from here.
I have an UIImageView and taking the raw touch input. I need to check if a touch is within a certain set of squares. At the moment...
I have this if statement....
if(46 < touchedAt.x && touchedAt.x < 124 && 18 < touchedAt.y && touchedAt.y < 75)
but I have tried to simplify it to this one...
if(46 < touchedAt.x < 124 && 18 < touchedAt.y < 75)
It didn't work. Is it possible to simplify like this or am I stuck with the slightly lengthier version at the top? Is there a reason why the types of comparisons in the bottom if don't work?
I think a better solution would be to use CGRectContainsPoint:
CGRect rect = CGRectMake(46, 18, 124 - 46, 75 - 18);
if (CGRectContainsPoint(rect, touchedAt))
// do whatever
Some languages support the "simple" version (Python, for example) but the C family doesn't.
In C family languages, the comparison operators are binary operators that return a boolean. One operator, two parameters, one result. Try to add another comparison and you end up comparing your boolean result against the next value. That's why you need all the && operators.
I don't know Objective-C, but I assume it does what C does.
To simplify, just write a simple function (perhaps inline) called "bounds_check" or "range_check" or similar that takes three parameters. Or better still, use one that's already written.
Is there any benefit to structuring boolean expressions like:
if (0 < x) { ... }
instead of
if (x > 0) { ... }
I have always used the second way, always putting the variable as the first operand and using whatever boolean operator makes sense, but lately I have read code that uses the first method, and after getting over the initial weirdness I am starting to like it a lot more.
Now I have started to write all my boolean expressions to only use < or <= even if this means the variable isn't the first operand, like the above example. To me it seems to increase readability, but that might just be me :)
What do other people think about this?
Do whatever is most natural for whatever expression you are trying to compare.
If you're wondering about other operations (like ==) there are previous topics comparing the orderings of operands for those comparisons (and the reasons why).
It is mostly done to avoid the problem of using = instead of == in if conditions. To keep the consistency many people use the same for with other operators also. I do not see any problem in doing it.
Use whatever 'reads' best. One thing I'd point out is that if I'm testing to see if a value is within bounds, I try to write it so the bounds are on the 'outside' just like they might be in a mathematical expression:
So, to test that (0 < x <= 10):
if ((0 < x) && (x <= 10)) { ... }
instead of
if ((0 < x) && (10 >= x)) { ... }
or
if ((x > 0) && (10 >= x)) { ... }
I find this pattern make is somewhat easier to follow the logic.
An advantage for putting the number first is that it can prevent bug of using = when == is wanted.
if ( 0 == x ) // ok
if ( 0 = x ) //is a compiler error
compare to the subtle bug:
if ( x = 0 ) // assignment and not comparison. most likely a typo
To be honest it's unusual to write expressions with the variable on the right-side, and as a direct consequence of that unusualness readability suffers. Coding conventions have intrinsic value merely by virtue of being conventions; people are used to code being written in particular standard ways, x >= 0 being one example. Unnecessarily deviating from simple norms like these should be avoided without good cause.
The fact that you had to "get over the initial weirdness" should perhaps be a red flag.
I would not write 0 < x just as I would not use Hungarian notation in Java. When in Rome, do as the Romans do. The Romans write x >= 0. No, it's not a huge deal, it just seems like an unnecessary little quirk.