Develop Reference

AnyLogic: Agent not sure where exactly it need to go

The delay1 can only contain agent.paint. On the exit of the delay1, a new agent gets released from the delay.
But the released agent is not an agent.paint instead it is an agent.repair or agent.bwork.
The delay2, delay4, and delay7 can contain agent.repair and agent.bwork but these delays are full, so now the agent is a problem, which is not supposed to happen.
Problem:
In delay1 only agent.paint can go, after getting free from delay and In delay2, delay4 or delay7 only agent.repair or agent.bwork can go, if delay have them.
And that is not happening in the existing model.
I try to explain in the image below:
My existing approach which is no working.

There are several things that are incorrect in your model. First of all, please keep in mind that when you use the word agent in a flowchart block, it always refers to the agent contained in the current flowchart block from where you are calling it.
I assume, in the "on exit" function of delay1 you want to release an agent from delay which has a parameter paint == true. However, you wrote the function as
if (delay.size() > 0 && agent.paint == true) delay.stopDelay(delay.get(0));
The second condition agent.paint == true refers to the current agent in delay1 flowchart block and not the agent in the delay that you want to release. Additionally, you are calling stopDelay() for the agent at position 0 in the delay block, regardless of whether this agent is the correct agent.
Instead, you need to iterate over all agents contained in the delay flowchart block, find the agent that meets your condition and release this specific agent. Your code can look like this:
if (delay.size() > 0) {
Agent agentToRelease = null;
for (int i = 0; i++; i < delay.size() {
if (delay.get(i).paint == true) { // Note: The function delay.get(i) is very slow. See if you can use Collection instead.
agentToRelease = delay.get(i);
break;
}
}
if (agentToRelease != null) {
delay.stopDelay(agentToRelease);
}
}
The same goes for delay2, delay4 and delay7.
The "on enter" function of delay is always called by the agent that is currently entering the delay. Because you check the condition for this specific agent here, you can directly call stopDelay() for this agent in case the condition returns true. So the first part of your code should look like this (the same goes for the remaining conditions)
if (agent.paint == true && delay1.size() + moveTo.size() < 2) {
delay.stopDelay(agent);
} else if (...)

in delay you are using stopDelay with an agent without caring for the value of its 3 parameters.
So it's perfectly possible to release an agent that is NOT paint when delay1 is empty... and this agent will go to any of the other 3 delays... no reason why not to.
Besides this.. you have moveTo blocks that mess up your condition... so if an agent is in moveTo4 and delay2 is empty, it will go to delay 2 anyways... because why not? You don't have any restriction for that to happen
You are overcomplicating an extremely simple problem

guava - bloomfilter: is it possible to get a true-negative for a value that was **previously** a false-positive?

If I understand correctly, once an item is put inside a guava bloom filter, mightContain will always return true. If the filter returns false on mightContain, then the value has never been put inside the filter. What I'm wondering is for the values that might be a false positive at a given moment, as more values are put in, the once false-positives might become true-negatives later on (if they are not put in, of course).
Something like this:
GuavaBloomFilter<Integer> bf = new GuavaBloomFilter<>(blah, blah);
# if I start checking, none of the values should return tru at the monent
System.out.println(bd.mightContain(5)); // false
System.out.println(bd.mightContain(10)); // false
System.out.println(bd.mightContain(15)); // false
# fine
# let's put in a value now
bf.put(10);
System.out.println(bd.mightContain(5));
System.out.println(bd.mightContain(10)); // true, every time from now on
System.out.println(bd.mightContain(15));
On the last 3 checks, when checking for 10, it will always return true. For 5 and 15, it might return true. Suppose that for 5 we get false (never put inside), for 15 we get a false positive.
So, we continue:
bf.put(5);
System.out.println(bd.mightContain(5)); // true, every single time from now on
System.out.println(bd.mightContain(10)); // true, every time from now on
System.out.println(bd.mightContain(15));
So.... now, when checking for 5, we will always get true. Is it possible that because of the state change inside the bloom filter, the result for checking 15 which was previously a false-positive, might return a true-negative value?

For a true Bloom filter, the bits only ever go from 0 to 1, never back - so the result of a mightContain call can only ever go from false to true, never back, because mightContain returns true if a certain subset of all bits are 1, and once they're 1 they'll stay 1.
Guava's implementation is indeed a true Bloom filter, since the BloomFilter.put method (source) delegates to Strategy.put (source), an interface implemented in BloomFilterStrategies (source). The Bloom filter's bits are stored in a LockFreeBitArray named bits, and the strategy only calls its bitSize, set and get methods. Of those, only set changes bits (source), and it only uses the bitwise 'or' operator | to change them. This can never change a 1 back to a 0.
So, it is indeed impossible for a value which was previously a false-positive to later become a true-negative.

Equivalent boolean statements have different results

I am confused about how && operator is working
if (StringUtils.isNotEmpty(cartModification.getStatusCode())
&& (cartModification.getStatusCode().equalsIgnoreCase(UNFCommerceCartModificationStatus.Sell_Out)))
Above statement is coming as true
while
if (StringUtils.isNotEmpty(cartModification.getStatusCode())
&& cartModification.getStatusCode().equalsIgnoreCase(UNFCommerceCartModificationStatus.Sell_Out))
is evluaated as false.Only difference between the 2 statements are braces.
As an additional input i have checked it with debugger and
StringUtils.isNotEmpty(cartModification.getStatusCode() =true
cartModification.getStatusCode().equalsIgnoreCase(UNFCommerceCartModificationStatus.Sell_Out)=true
I just added extra parenthesis in the second part and it was evaluated as true, Data is same as i have pointed out in question.

Since the commentbox isn't really approriate for this one:
How about trying this in a single run.
if(StringUtils.isNotEmpty(cartModification.getStatusCode())
&& cartModification.getStatusCode().equalsIgnoreCase(UNFCommerceCartModificationStatus.Sell_Out))
System.out.println("First try is true");
if(StringUtils.isNotEmpty(cartModification.getStatusCode())
&& (cartModification.getStatusCode().equalsIgnoreCase(UNFCommerceCartModificationStatus.Sell_Out)))
System.out.println("Second try is true");
No matter what, you should either get no or two lines (since both statements are the same).
Note it's possible that just one line is printed, this means that any call on getStatusCode() invokes a change on any value used in at least one of the conditions.

Java Assert statement usage, exam certification 1Z0-851

I am studing for 1Z0-851 Oracla Java SE 1.6 Certification and I saw this question:
I marked the first alternative as the correct one and failed! "All of the assert statements are used appropriately" and the answer says that the first one assert(x > 0); is incorrect.. the question is why?

The correct answer is this
Appropriate and inappropriate use of assertions
You can place an assertion at any location that you don't expect to be reached normally.
Assertions can be used to validate the parameters passed to a private method. However,
assertions should not be used to validate parameters passed to public methods because a
public method must check its arguments regardless of whether assertions are enabled or
not. However, you can test postconditions with assertions in both public and non-public
methods. Also, assertions should not change the state of a program in any manner.
Src: http://www.freejavaguide.com/java-scjp-part1.pdf

Line 12 is redundant.
if you remove it, the assertion on line 15 will cover the case where x <= 0
To be honest its a strangely worded question but that is all I can see. I am not sure what is meant by appropriately

If you read just the first assert statement -- which should be interpreted as a "precondition" because of its position --, it implies that the function should work properly with any positive int value, which is not true. Therefore, that assertion is misleading.

Starting by go2, it is easy to understand the assert.
The method does nothing, it just asserts your expectation, that x < 0.
The go method, on the other hand, has a switch.
It is good practice to assert false on the default clause, if you absolutely do not expect your program to fall under this clause, ie, under normal circumstances, one of the cases has to be correct.
The only case on the switch expects x to be exactly 2.
So, to sum up, you don't expect x to be greater than 0, as the first assertion says, you expect x to be 2 and nothing else. Thus, the assertion is not used appropriately.
However, as Jeff noted, the case has no break, which means the default will always be executed, leading, in every scenario, to assert false.
Conclusion: The go method should always result in an error, making assert false properly used, while assert x > 0 isn't correct at all.

Why is order of expressions in if statement important

Suppose I have an IF condition :
if (A || B)
∧
|
|
left
{
// do something
}
Now suppose that A is more likely to receive a true value then B , why do I care which one is on the left ?
If I put both of them in the IF brackets , then I know (as the programmer of the code) that both parties are needed .
The thing is , that my professor wrote on his lecture notes that I should put the "more likely variable to receive a true" on the left .
Can someone please explain the benefit ? okay , I put it on the left ... what am I gaining ? run time ?

Its not just about choosing the most likely condition on the left. You can also have a safe guard on the left meaning you can only have one order. Consider
if (s == null || s.length() == 0) // if the String is null or empty.
You can't swap the order here as the first condition protects the second from throwing an NPE.
Similarly you can have
if (s != null && s.length() > 0) // if the String is not empty
The reason for choosing the most likely to be true for || or false for && is a micro-optimisation, to avoid the cost of evaluated in the second expression. Whether this translates to a measurable performance difference is debatable.

I put it on the left ... what am I gaining ? run time ?
Because || operator in C++ uses short-circuit evaluation.
i.e: B is evaulated only if A is evaluated to a false.
However, note that in C++ short-circuit evaluation is guaranteed for "built in" data types and not custom data types.

As per javadoc
The && and || operators perform Conditional-AND and Conditional-OR operations on two boolean expressions. These operators exhibit "short-circuiting" behavior, which means that the second operand is evaluated only if needed
So, if true statement comes first in the order, it short-circuits the second operand at runtime.

If the expression on the left is true, there is no need to evaluate the expression on the right, and so it can be optimized out at run time. This is a technique called short-circuiting. So by placing the expression more likely to be true on the left, we can expect our program to perform better than if it were the other way around.

You should place the condition that is more likely to be true first because that will cause the if statement to short-circuit. Meaning it will not evaluate the rest of the if statement because it will already know the answer is true. This makes code more efficient.
This is especially useful when your if statement is evaluating expensive things:
if(doExpensiveCheck1() || doExpensiveCheck2()) { }
In this case cause the checks are expensive it is in your benefit to place the most likely check first.

In many cases there is no practical difference apart from a tiny performance improvement. Where this becomes useful is if your checks are very expensive function calls (unlikely) or you need to check things in order. Say for example you want to check a property on something and to check if that something is nil first, you might do something like:
If (a != nil && a.attribute == valid)
{}

Yes exactly, you're gaining runtime, it won't seem much for one operation, but you have to keep in mind that operations will get repeated millions of times
Why perform two evaluations when one is enough is the logic

At runtime if(a||b) will test a first, if a is true it will not waste time testing b therefor the compiler will be 1 execution ahead. Therefore if a is more likely to be true than b this test is also likely to cut 1 line. The total number of lines not executed is tiny on a single line but it’s huge if the statement is nested in a loop of some sort(for,while ,recession or database related queries ). Eg per say we have 1million mins to test data in a database at 1 minute per record (30sec for condition A and 30 sec for condition B). Let A have 80% chances to be true and B have 20% chances to be true. The total time needed if you put A first is 600-000hrs yet it’s 900-000hrs if you put B first.if A is tested first[(0,8*1millions hours)*0,5mins+(0,2*1million hours)*1min]===6000-000hrs : if B is tested first [(0,2*1million hours)*0,5mins+(0,2*1million hours)*1min]===9000-000hrs. However you will notice the difference is less significant if the probability of A becoming true is closer to that of B.

public class Main
{
public static void main(String[] args) {
System.out.println("Hello World");
Integer a = null;
Integer b = 3;
Integer c = 5;
if(a != null && a == 2){
System.out.println("both");
}else{
System.out.println("false");
}
}
}
Hello World
false