I'm making a script that sorts the depth for my objects by prioritizing the y variable, but then afterwards checks to see if the objects that are touching each other have a higher depth the further to the right they are, but for some reason the last part isn't working.
Here's the code:
ds_grid_sort(_dg,1,true);
_yy = 0;
repeat _inst_num
{
_inst = _dg[# 0, _yy];
with _inst
{
with other
{
if (x > _inst.x and y = _inst.y)
{
_inst.depth = depth + building_space;
}
}
}
_yy++;
}
I've identified that the problem is that nothing comes out as true when the game checks the y = _inst.y part of the _inst statement, but that doesn't make any sense seeing how they're all at the same y coordinate. Could someone please tell me what I'm doing wrong?
As Steven mentioned, it's good practice to use double equal signs for comparisons (y == _inst.y) and a single equals sign for assignments (_yy = 0;), but GML doesn't care if you use a single equals sign for comparison, so it won't be causing your issue. Though it does matter in pretty much every other language besides GML.
From what I understand, the issue seems to be your use of other. When you use the code with other, it doesn't iterate through all other objects, it only grabs one instance. You can test this by running this code and seeing how many debug messages it shows:
...
with other
{
show_debug_message("X: "+string(x)+"; Y: "+string(y));
...
You could use with all. That will iterate through all objects or with object, where object is either an object or parent object. That will iterate through all instances of that object. However, neither of these functions check whether the objects overlap (it's just going to iterate over all of them), so you'll have to check for collisions. You could do something like this:
...
with all
{
if place_meeting(x, y, other)
{
if (x > _inst.x and y = _inst.y)
{
_inst.depth = depth + building_space;
}
}
...
I don't know what the rest of your code looks like, but there might be an easier way to achieve your goal. Is it possible to initially set the depth based on both the x and y variables? Something such as depth = -x-y;? For people not as familiar with GameMaker, objects with a smaller depth value are drawn above objects with higher depth values; that is why I propose setting the depth to be -x-y. Below is what a view of that grid would look like (first row and column are x and y variables; the other numbers would be the depth of an object at that position):
Having one equation that everything operates on will also make it so that if you have anything moving (such as a player), you can easily and efficiently update their depth to be able to display them correctly relative to all the other objects.
I think it should be y == _inst.y.
But I'm not sure as GML tends to accept such formatting.
It's a better practise to use == to check if they're equal when using conditions.
This is from CPLEX.
I tried doing this but getting no results. Basically my model need a forall statement with these two conditions using decision variables and multiple relations under that. All the equality constraints. Can anyone explain what is the problem in my syntax.
Error : Function operator<(dvar float+,float) not available in context CPLEX.
Some of the screenshots and actual equation from the document is provided alongwith the problem.
Regards,
Debtirthaenter image description here
// code from the model.
enter image description here
forall (a in A, j in Ji[a], n in N: j==jbreak)
{Ts[a][j][n] < tbreak && Tf[a][j][n] > tbreak} => (yvr1[j][n] == yv[j][n]);// && wvr1[a][n] == wv[a][n] && Balr1[a][j][n] == Bal[a][j][n] && Tsr1[a][j][n] == Ts[a][j][n] &&Tfr1[a][j][n] == Tf[a][j][n]);
forall (b in B: b==jbreak,i in Ij[b], n in N) ctTBRD[i][b][n]:
Tsr1[i][b][n] >= tbreak + tmaint;
}
strict inequality is not allowed so can you change
Tf[a][j][n] > tbreak
into
Tf[a][j][n] >= tbreak+1
?
Expanding on Alex's answer: the problem is indeed that strict inequality is not supported. However, Alex's solution will only work if tbreak is an integer variable. According to your error message, tbreak is a float+ variable, though. So the fix should be something like this:
Ts[a][j][n] <= tbreak - eps
where eps is a small constant, like 1e-6.
However, working with these tolerances is always a bit shaky, so you may want to double-check whether you can get around this. For example, by making tbreak an integer variable or by reverting the condition so that a strict less-than becomes a greater-than-or-equal (not sure this can be done but it is worth thinking about).
I'm investigating kotlin using decompilation to java code.
I've found one interesting nuance and can't understand how it is implemented.
Here's the kotlin code:
val result = 50 in 1..100
I'm using intelij idea decompilation to look for the equivalent of java code and here's what we have:
public final class Test14Kt {
private static final boolean result = true;
public static final boolean getResult() {
return result;
}
}
So as i understand it, kotlinc somehow knows that the element is in range and saves true to result variable on the stage of compilation.
It's cool. But how is it achieved?
This is very simple constant folding:
Terms in constant expressions are typically simple literals, such as the integer literal 2, but they may also be variables whose values are known at compile time. Consider the statement:
i = 320 * 200 * 32;
Most modern compilers would not actually generate two multiply instructions and a store for this statement. Instead, they identify constructs such as these and substitute the computed values at compile time (in this case, 2,048,000). The resulting code would load the computed value and store it rather than loading and multiplying several values.
Constant folding can even use arithmetic identities. When x is an integer type, the value of 0 * x is zero even if the compiler does not know the value of x.
Here,
50 in 1..100 ==
1 <= 50 && 50 <= 100 ==
true && true ==
true
I am writing a code in FORTRAN to calculate the position of the planets. I need to solve Kepler's equation using newtons numerical method and I am having trouble with my loop. The code is shown below. I can compile it with no error messages, but it wont run. It just gets stuck in a forever loop. I want the loop to run until E(i) and the following result are equal. Any help would be greatly appreciated.
do while (E(i)/=E(i+1))
E(1)=M
E(i+1)=E(i)-((M-E(i)+(p*sin(E(i))))/((p*cos(E(i)))-1))
end do
Also, how do i define the variable 'E' at the beginning of my program. I currently have this but the '11' is only because I originally had my loop run 10 times. If I don't specify the number of times I want the loop to run, how do i define the variable?
double precision :: E(11)
I did not check if your convergence implementation is correct, but you definitely do not want to check for exact equality. You must allow for some inexactness, because floating point calculations are inexact
(abs(E(i)-E(i+1))<eps)
where eps is some small number.
As #agentp suggests you don't change i, so you always work with 2 values E(i) and E(i+1) (i being whatever you set it before the loop). You do not use any other elements of your array.
For the array which can have any length, depending on your need, you could theoretically use
double precision, allocatable :: E(:)
but you probably do not want to use an array at all and you just want two scalar values
double precision :: E1, E2
E1 = M
do
E2 = E1 - ((M-E1+(p*sin(E1))) / ((p*cos(E1))-1))
if (abs(E1-E2) < eps) exit
E1 = E2
end do
Note that the kind notation (real(....)) is preferable in new code instead of the old double precision.
I want to check whether a value is equal to 1. Is there any difference in the following lines of code
Evaluated value == 1
1 == evaluated value
in terms of the compiler execution
In most languages it's the same thing.
People often do 1 == evaluated value because 1 is not an lvalue. Meaning that you can't accidentally do an assignment.
Example:
if(x = 6)//bug, but no compiling error
{
}
Instead you could force a compiling error instead of a bug:
if(6 = x)//compiling error
{
}
Now if x is not of int type, and you're using something like C++, then the user could have created an operator==(int) override which takes this question to a new meaning. The 6 == x wouldn't compile in that case but the x == 6 would.
It depends on the programming language.
In Ruby, Smalltalk, Self, Newspeak, Ioke and many other single-dispatch object-oriented programming languages, a == b is actually a message send. In Ruby, for example, it is equivalent to a.==(b). What this means, is that when you write a == b, then the method == in the class of a is executed, but when you write b == a, then the method in the class of b is executed. So, it's obviously not the same thing:
class A; def ==(other) false end; end
class B; def ==(other) true end; end
a, b = A.new, B.new
p a == b # => false
p b == a # => true
No, but the latter syntax will give you a compiler error if you accidentally type
if (1 = evaluatedValue)
Note that today any decent compiler will warn you if you write
if (evaluatedValue = 1)
so it is mostly relevant for historical reasons.
Depends on the language.
In Prolog or Erlang, == is written = and is a unification rather than an assignment (you're asserting that the values are equal, rather then testing that they are equal or forcing them to be equal), so you can use it for an assertion if the left hand side is a constant, as explained here.
So X = 3 would unify the variable X and the value 3, whereas 3 = X would attempt to unify the constant 3 with the current value of X, and be equivalent of assert(x==3) in imperative languages.
It's the same thing
In general, it hardly matters whether you use,
Evaluated value == 1 OR 1 == evaluated value.
Use whichever appears more readable to you. I prefer if(Evaluated value == 1) because it looks more readable to me.
And again, I'd like to quote a well known scenario of string comparison in java.
Consider a String str which you have to compare with say another string "SomeString".
str = getValueFromSomeRoutine();
Now at runtime, you are not sure if str would be NULL. So to avoid exception you'll write
if(str!=NULL)
{
if(str.equals("SomeString")
{
//do stuff
}
}
to avoid the outer null check you could just write
if ("SomeString".equals(str))
{
//do stuff
}
Though this is less readable which again depends on the context, this saves you an extra if.
For this and similar questions can I suggest you find out for yourself by writing a little code, running it through your compiler and viewing the emitted asembler output.
For example, for the GNU compilers, you do this with the -S flag. For the VS compilers, the most convenient route is to run your test program in the debugger and then use the assembeler debugger view.
Sometimes in C++ they do different things, if the evaluated value is a user type and operator== is defined. Badly.
But that's very rarely the reason anyone would choose one way around over the other: if operator== is not commutative/symmetric, including if the type of the value has a conversion from int, then you have A Problem that probably wants fixing rather than working around. Brian R. Bondy's answer, and others, are probably on the mark for why anyone worries about it in practice.
But the fact remains that even if operator== is commutative, the compiler might not do exactly the same thing in each case. It will (by definition) return the same result, but it might do things in a slightly different order, or whatever.
if value == 1
if 1 == value
Is exactly the same, but if you accidentally do
if value = 1
if 1 = value
The first one will work while the 2nd one will produce an error.
They are the same. Some people prefer putting the 1 first, to void accidentally falling into the trap of typing
evaluated value = 1
which could be painful if the value on the left hand side is assignable. This is a common "defensive" pattern in C, for instance.
In C languages it's common to put the constant or magic number first so that if you forget one of the "=" of the equality check (==) then the compiler won't interpret this as an assignment.
In java, you cannot do an assignment within a boolean expression, and so for Java, it is irrelevant which order the equality operands are written in; The compiler should flag an error anyway.