I'm trying to make a path (CGMutablePath) to be used for a shape node in SpriteKit (SKShapeNode). I'm running my code and it stops and says EXC_BREAKPOINT as if there's a breakpoint in the compiler, when there isn't one. Below is a screenshot of what I have.
As you can see, I have no breakpoint set in the compiler. It just tends to stop at line 31. There's nothing in the logs that give a reason for this crash, if there were one to begin with.
I'm used to Objective-C stopping in main.m with Thread 1: SIGABRT and an NSException in the log, but this just makes no sense. Can someone please explain what's wrong?
EDIT: here are more screenshots to prove I have no breakpoints set. When I get an exception, it simply throws a breakpoint.
That exception happens because arc4random() returns UInt32 and you are subtracting a value of that, which possibly causes a negative value, which is not representable as an unsigned integer.
To fix this you may want to cast the expression to Int32 before subtracting:
var y = CGFloat(self.size.height / 3) + CGFloat((Int32)(arc4random() % 100) - 50)
Regarding the x value above - you create CGFloat and only subtract after that and therefore not encounter the above situation. Therefore a different fix would be the following
var y = CGFloat(self.size.height / 3) + CGFloat(arc4random() % 100) - 50
You basically have to ensure that at the point where you subtract something you have no unsigned type present.
The annoying thing about this is that the compiler does not warn you and the code actually works sometimes, every time when arc4random returns something larger than 50 and will therefore not drift into the negative values...
Incorporating the feedback and suggestion that you should not use arc4random % something the best solution would be to use arc4random_uniform.
arc4random % something will not yield a proper distribution of the random values, while arc4random_uniform(something) does - this has already been discussed on SO before.
A final note: you probably should choose 101 as upper bound instead of 100 because both arc4random as well as arc4random_uniform produce a value between 0 and (upper-1), e.g. 0 and 99. If you subtract 50 you get a value between -50 and +49. Choosing 101 will yield the desired range of -50 to +50.
var y = CGFloat(self.size.height / 3) + CGFloat(arc4random_uniform(101)) - 50
Related
I am trying to create a EA in mql4, but in OrderSend function, when i use some value instead of zero it show ordersend error 130. Please help to solve this problem
Code line is
int order = OrderSend("XAUUSD",OP_SELL,0.01,Bid,3,Bid+20*0.01,tp,"",0,0,Red);
error number 130 means Invalid stops.
so that means there is a problem with the stops you set with the ordersend function.
I suggest you set it like that:
int order = OrderSend("XAUUSD",OP_SELL,0.01,Bid,3,Bid+20*Point,tp,"",0,0,Red);
so you could use Point instead of hard coding it.
and to check what is the error number means. I think you could refer to: https://book.mql4.com/appendix/errors
You should know that there exists a minimum Stop Loss Size (mSLS) given in pips. "mSLS" changes with the currency and broker. So, you need to put in the OnInit() procedure of your EA a variable to get it:
int mSLS = MarketInfo(symbol,MODE_STOPLEVEL);
The distance (in pips) from your Order Open Price (OOP) and the Stop-Loss Price (SLP) can not be smaller than mSLS value.
I will try to explain a general algorithm I use for opening orders in my EAs, and then apply the constrain on Stop-Loss level (at step 3):
Step 1. I introduce a flag (f) for the type of operation I will open, being:
f = 1 for Buy, and
f = -1 for Sell
You know that there are mql4 constants OP_SELL=1 and OP_BUY=0 (https://docs.mql4.com/constants/tradingconstants/orderproperties).
Once I have defined f, I set my operation type variable to
int OP_TYPE = int(0.5((1+f)*OP_BUY+(1-f)*OP_SELL));
that takes value OP_TYPE=OP_BUY when f=1, while OP_TYPE=OP_SELL when f=-1.
NOTE: Regarding the color of the orders I put them in an array
color COL[2]= {clrBlue,clrRed};
then, having OP_TYPE, I set
color COLOR=COL[OP_TYPE];
Step 2. Similarly, I set the Order Open Price as
double OOP = int(0.5*((1+f)*Ask+(1-f)*Bid));
which takes value OOP=Ask when f=1, while OOP=Bid when f=-1.
Step 3. Then, given my desired Stop Loss in pips (an external POSITIVE parameter of my EA, I named sl) I make sure that sl > SLS. In other words, I check
if (sl <= mSLS) // I set my sl as the minimum allowed
{
sl = 1 + mSLS;
}
Step 4. Then I calculate the Stop-Loss Price of the order as
double SLP = OOP - f * sl * Point;
Step 5. Given my desired Take Profit in pips (an external POSITIVE parameter of my EA, I named tp) I calculate the Take-Profit Price (TPP) of the order as
double TPP = OOP + f * tp * Point;
OBSERVATION: I can not affirm, but, according to mql4 documentation, the minimum distance rule between the stop-loss limit prices and the open price also applies to the take profit limit price. In this case, a "tp" check-up needs to be done, similar to that of the sl check-up, above. that is, before calculating TPP it must be executed the control lines below
if (tp <= mSLS) // I set my tp as the minimum allowed
{
tp = 1 + mSLS;
}
Step 5. I call for order opening with a given lot size (ls) and slippage (slip) on the operating currency pair (from where I get the Ask and Bid values)
float ls = 0.01;
int slip = 3; //(pips)
int order = OrderSend(Symbol(),OP_TYPE,ls,OOP,slip,SLP,TPP,"",0,0,COLOR);
Note that with these few lines it is easy to build a function that opens orders of any type under your command, in any currency pair you are operating, without receiving error message 130, passing to the function only 3 parameters: f, sl and tp.
It is worth including in the test phase of your EA a warning when the sl is corrected for being less than the allowed, this will allow you to increase its value so that it does not violate the stop-loss minimum value rule, while you have more control about the risk of its operations. Remember that the "sl" parameter defines how much you will lose if the order fails because the asset price ended up varying too much in the opposite direction to what was expected.
I hope I could help!
Whilst the other two answers are not necessarily wrong (and I will not go over the ground they have already covered), for completeness of answers, they fail to mention that for some brokers (specifically ECN brokers) you must open your order first, without setting a stop loss or take profit. Once the order is opened, use OrderModify() to set you stop loss and/or take profit.
I am using lua 5.3.2 and the following piece of code gives me an error:
string.format("%d", 1.16 * 100)
whereas the following line works fine
string.format("%d", 1.25 * 100)
This is probably related to this question but the failure depends on the floating point value. Given that, in my case, a local variable (v) holds the float value, and is generated by an expresson that produces a value between 0 and 2 rounded to 2 decimal places.
How can I modify the code to ensure this doesn't fail for any possible value of v ?
You can use math.floor to convert to integer and add +0.5 if you need to round it: math.floor(1.16 * 100 + 0.5). Alternatively, "%.0f" should have the desired effect as well.
I have this values that i've logged:
label.frame.size.height :18.000000, label.font.lineHeight: 17.895000
if i use roundf() like:
roundf(label.frame.size.height / label.font.lineHeight) // answer: 1
while with ceil()
ceil(label.frame.size.height / label.font.lineHeight) // answer: 2
but when computed manually: answer is 1.00586756
I wonder whats the best and more reliable(generally) between this two. Why is everybody using ceil() to determine the number of lines of UILabel?
In the case of number of lines each letter after the limit a line could display should be taken to next line so .005 is also significant this .005 part of the text should carry to next line. So it is better to use ceil() rather than roundf( ). In roundf( ) a value will be significant only when it is greater or equal to its half value)
ceil()
The C library function ceil(x) returns the smallest integer value greater than or equal to x.
I still dont understand why must of the people use ceil() when computing the number of line since roundf() is more accurate..
But when talking about computing for the number of line.. i look to me that 'roundf()' is indeed more accurate, but since its number of lines.. decimal values are not significant..
Computing what is the image:
54 / 17.895000 = 3.01760268
And numberOflines = 3
if we use roundf() answer would be 3 as well
while if ceil() is already 4
therefore using floor() or simply converting the result to int will do the work:
int result = (int)floor(answer);
//or
int result = (int)answer;
About my question, i think roundf() to the work for me for computing number of lines generally..
I'm making a class that will compute the number of line base from this values, and will be used by the whole app.
Hello well all is in the title. The question apply especially for all those values that can be like NSTimeInterval, CGFloat or any other variable that is a float or a double. Thanks.
EDIT: I'm asking for value assignment not format in a string.
EDIT 2: The question is really does assigning a plain 0 for a float or a double is worst than anything with f a the end.
The basic difference is as :
1.0 or 1. is a double constant
1.0f is a float constant
Without a suffix, a literal with a decimal in it (123.0) will be treated as a double-precision floating-point number. If you assign or pass that to a single-precision variable or parameter, the compiler will (should) issue a warning. Appending f tells the compiler you want the literal to be treated as a single-precision floating-point number.
If you are initializing a variable then it make no sense. compiler does all the cast for you.
float a = 0; //Cast int 0 to float 0.0
float b = 0.0; //Cast 0.0 double to float 0.0 as by default floating point constants are double
float c = 0.0f // Assigning float to float. .0f is same as 0.0f
But if you are using these in an expression then that make a lot of sense.
6/5 becomes 1
6/5.0 becomes 1.2 (double value)
6/5.0f becomes 1.2 (float value)
If you want to dig out if there is any difference to the target CPU running the code or the binary code it executes, you can easily copy one of the command lines compiling the code from XCode to command line, fix missing environment variables and add a -S. By that you would get assembly output, that you can use to compare. If you put all 4 variants in a small example source file, you can compare the resulting assembly code afterwards, even without being fluent in ARM assembly.
From my ARM assembly experience (okay... 6 years ago and GCC) I would bet 1ct on something like XORing a register with itself to flush it's content to 0.
Whether you use 0.0, .0, or 0.0f or even 0f does not make much of a difference. (There are some with respect to double and float) You may even use (float) 0.
But there is a significant difference between 0 and some float notation. Zero will always be some type of integer. And that can force the machine to perform integer operations when you may want float operations instead.
I do not have a good example for zero handy but I've got one for float/int in general, which nealy drove me crazy the other day.
I am used to 8-Bit-RGB colors That is because of my hobby as photographer and because of my recent background as html developer. So I felt it difficult to get used to the cocoa style 0..1 fractions of red, green and yellow. To overcome that I wanted to use the values that I was used to and devide them by 255.
[CGColor colorWithRed: 128/255 green: 128/255 andYellow: 128/255];
That should generate me some nice middle gray. But it did not. All that I tried either made a black or white.
First I thought that this was caused by some undocumented dificiency of the UI text objects with which I was using this colour. It took a while to realize that this constant values forced integer operations wich can only round up or down to 0 and 1.
This expession eventually did what I wanted to achieve:
[CGColor colorWithRed: 128.0/255.0 green: 128.0/255.0 andYellow: 128.0/255.0];
You could achieve the same thing with less .0s attached. But it does not hurt having more of them as needed. 128.0f/(float)255 would do either.
Edit to respond to your "Edit2":
float fvar;
fvar = 0;
vs ...
fvar = .0;
In the end it does not make a difference at all. fvar will contain a float value close to (but not always equal to) 0.0. For compilers in the 60th and 70th I would have guessed that there is a minor performance issue associated with fvar = 0. That is that the compiler creates an int 0 first which will then have to be converted to float before the assignment. Modern compilers of today should optimize automatically much better than older ones. In the end I'd have to look at the machine code output to see whether it does make a difference.
However, with fvar = .0; you are always on the safe site.
I'm having a problem regarding reading the pixel values (w=30, h=10). Suppose I'm using
int readValue = cvGetReal2D(img,y,x); and
int readValue = data[y*step+x];
Lets say I am trying to access pixel values at w=35, h=5 using the (1) and (2) method.
The (1) will output an error of index out of range. But why (2) does not output an error of index out of range?
After that, I'm trying to use try...catch()...
You have a continuous block of memory of
size = w*h = 300
At w = 35 and h = 5 your equation gives
data[5*30+35] = data[190] < data[300]
so there is no error. If this is c++ then even if your index in data was larger than 299 it wouldn't throw an error. In that case you would be accessing the data beyond its bounds which results in undefined behavior.
I assume cvGetReal2D(img,y,x) is smart enough to tell you that one of your indices is larger than the defined size of that dimension even though it could be resolved to a valid address.