Develop Reference

Integrality Gap in MAXIMIZATION in CPLEX+Java | Bug?

I try to solve a large MIP in which the . If it does not solve optimally, it shall return the integrality gap (that is, difference between best integer solution and best solution of the linear relaxation).
Using getMIPRelativeGap of the Java+CPLEX interface, I sometimes got values in the range of 1.0E11-1.0E13 which does not make sense, as an integrality gap should be a percentage between 0 and 1. I tracked those cases down and found out that I get those results, if the best integer solution has a value of 0 (my inner problem is a profitable tour problem, thus, if the best route is not visiting any vertice). The integrality gap should be (bestobjective-bestinteger)/bestobjective (https://www.ibm.com/support/knowledgecenter/SSSA5P_12.6.0/ilog.odms.cplex.help/refdotnetcplex/html/M_ILOG_CPLEX_Cplex_MIPInfoCallback_GetMIPRelativeGap.htm), yet, it seems to be (bestobjective-bestinteger)/bestinteger.
I also tested a couple of other values (if the integer objective is positive), and were able to confirm this in examples.
Can someone else reproduce this behavior? Does this behavior make sense to you?
Thanks :)

Indeed, the documentation for CPXgetmiprelgap in the Callable Library (C API) says the following:
For a minimization problem, this value is computed by
(bestinteger - bestobjective) / (1e-10 + |bestinteger|)
where bestinteger is the value returned by CPXXgetobjval/CPXgetobjval
and bestobjective is the value returned by
CPXXgetbestobjval/CPXgetbestobjval. For a maximization problem,
the value is computed by:
(bestobjective - bestinteger) / (1e-10 + |bestinteger|)
So, it looks like the documentation for the Java API is buggy. The Java API just calls CPXgetmiprelgap under the hood, so it should be the same. Thanks for reporting this. I'll make sure that this gets passed on to the folks who can fix it.

java.lang.ArithmeticException: Division is undefined

I have a simple operation going on in my program:
exposureNoDecimals =
BigDecimal.valueOf(curEffSpreadPremium).multiply(BigDecimal.valueOf(100)).divide(wsRate, 0,
java.math.RoundingMode.HALF_UP).longValue();
exposureNoDecimals - long
curEffSpreadPremium - long
wsRate - BigDecimal
However I am getting
"java.lang.ArithmeticException: Division is undefined"
at java.math.BigDecimal.longScaledDivide(BigDecimal.java:3105)
at java.math.BigDecimal.divide(BigDecimal.java:2409)
at java.math.BigDecimal.divide(BigDecimal.java:2396)
at java.math.BigDecimal.divide(BigDecimal.java:2361)
The problem is the issue is recreatable on production and not on my machine (cant debug, or cant see the inputs)
What can be the issue here? Any suggestions/ideas?

Take a look at the source code for BigDecimal (e.g. here).
An ArithmeticException is only thrown with the message "Division undefined" when you attempt to divide zero by zero.
I'm not going to suggest a fix, because the >>correct<< fix will depend on what this calculation is supposed to be doing, and why the divisor / dividend happen to be zero. Putting in some zero checks might be a solution, but it could also be a "band-aid solution" that hides the problem rather than fixing it. It could come back to bite you later on.
The problem is the issue is recreatable on production and not on my machine (cant debug, or cant see the inputs)
As noted in various comments, there are different versions of BigDecimal depending on the Java version and (apparently) vendor. One of the differences between (some) versions is that the exception messages differ.
If you really want to track this down this reproducibility issue, you are going to have to look at the source code for BigDecimal in production and on your machine. (Unfortunately, a stacktrace involving Java SE classes is often difficult to diagnose without precise Java vendor and version number information. It is not helpful in this case ... for that reason.)

According to the source code of BigDecimal, java.lang.ArithmeticException: Division undefined (without the is) is only thrown when you divide zero by zero.
Looks like in your case curEffSpreadPremium and wsRate both are zero.
So you need to guard the line with zero-checks.

CheckStyle with warning '100' is a magic number

In my code,it shows the warning with message '100' is a magic number.See the below code,
int randomNo = generator.nextInt(100);
I read it here What is a magic number, and why is it bad? but my doubt is declaring 100 by creating variable with static will occupy more space,since i am using this in a single place.Is this a correct way to solve this?
public static final int HUNDRED= 100;
Any Suggestion?

well HUNDRED really is kinda silly, but why did you choose 100 and what is its meaning?
something like:
public static final int RANDOM_UPPER_LIMIT=100;
or something even more informative, depending on what you use the value for:
public static final int MAX_NUMBER_OF_COLORS=100;
would make more sense and improve readability.
Space saving should not be a consideration in this case, the space overhead of declaring a variable, if there is such, is completely negligible.

It doesn't really have to do with storage, it's readability. If you want to change some number it can be difficult to find in code, if it's up at the top then it's better (if it's in a config file, better yet in many cases).
Yes, that's a good solution.
If you don't need it outside that file, you should make it "private", and you might want to be even more readable and use a name that indicates what it really means, like:
MAX_RANDOM_NUMBER=100
better yet include what it's used for
MAX_RANDOM_FOR_CARD_SELECTION
or something like that.
In this way when you go to look into that file 5 months from now because you added 20 new cards, it's completely obvious what you have to change without even glancing at the code.

It's good to write not the shortest code, but code which is easy to understand and maintain. Storing this 100 to constant you may add a good name explaining why it's really 100. For example if you want to generate random score and your maximal possible score is 100, then you can define
static final int MAX_SCORE = 100;
After that you can use it in other places as well. Everybody will understand why it's 100 and nothing else. And if someday you will need to change it, say, to 200, you will have to replace it in only one place without searching through the code.
Also it's possible that in some other part of your program you will have 100 which has different meaning (say, MAX_PERCENT). If you want to change MAX_SCORE to 200, but leave MAX_PERCENT as is, it would be much easier if you have separate constants.

Check out Robert Martin's (Uncle Bob)
Clean Code
book for a thorough explanaition (or any other guide on coding style). Basically a hard coded '100' doesn't mean anything to the reader of your code. It won't mean anything to you in 6 months either, after you are done with your app. It is a magic number since it appears in the code - in 99 out of 100 cases - as almost out of nowhere. Why is it 100 and not 99 or 101? Why should your app limit the random number generation to 100 and not above (or below)?
To wrap up, it's a thing of readability of your code for yourself and for present or future readers of your code, it's a matter of coding style.

Most compilers, including JIT compilers, will inline constant primitives, including statics. IE, at compile time it will remove the variable and expand your code back to
generator.nextInt(100);
So in practice there won't be space trade-offs, and you're improving readablity.
Be careful about expanding the idea out to more complicated code though. There are compiler and language dependent rules on when it is able to do certain optimisations.

Unexpected results from Metaphone algorithm

I am using phonetic matching for different words in Java. i used Soundex but its too crude. i switched to Metaphone and realized it was better. However, when i rigorously tested it. i found weird behaviour. i was to ask whether thats the way metaphone works or am i using it in wrong way. In following example its works fine:-
Metaphone meta = new Metaphone();
if (meta.isMetaphoneEqual("cricket","criket")) System.out.prinlnt("Match 1");
if (meta.isMetaphoneEqual("cricket","criketgame")) System.out.prinlnt("Match 2");
This would Print
Match 1
Mathc 2
Now "cricket" does sound like "criket" but how come "cricket" and "criketgame" are the same. If some one would explain this. it would be of great help.

Your usage is slightly incorrect. A quick investigation of the encoded strings and default maximum code length shows that it is 4, which truncates the end of the longer "criketgame":
System.out.println(meta.getMaxCodeLen());
System.out.println(meta.encode("cricket"));
System.out.println(meta.encode("criket"));
System.out.println(meta.encode("criketgame"));
Output (note "criketgame" is truncated from "KRKTKM" to "KRKT", which matches "cricket"):
4
KRKT
KRKT
KRKT
Solution: Set the maximum code length to something appropriate for your application and the expected input. For example:
meta.setMaxCodeLen(8);
System.out.println(meta.encode("cricket"));
System.out.println(meta.encode("criket"));
System.out.println(meta.encode("criketgame"));
Now outputs:
KRKT
KRKT
KRKTKM
And now your original test gives the expected results:
Metaphone meta = new Metaphone();
meta.setMaxCodeLen(8);
System.out.println(meta.isMetaphoneEqual("cricket","criket"));
System.out.println(meta.isMetaphoneEqual("cricket","criketgame"));
Printing:
true
false
As an aside, you may also want to experiment with DoubleMetaphone, which is an improved version of the algorithm.
By the way, note the caveat from the documentation regarding thread-safety:
The instance field maxCodeLen is mutable but is not volatile, and accesses are not synchronized. If an instance of the class is shared between threads, the caller needs to ensure that suitable synchronization is used to ensure safe publication of the value between threads, and must not invoke setMaxCodeLen(int) after initial setup.

what is the standard number of parameters that a java method should have?

I am writing a program that checks the number of parameters of a methods and prints out a warning message (its a codesmell program) If there are more than what the standard is, the problem is that I don't know what the agreed number is. I have looked around and not had any luck. Can anyone tell me or at least point me in the right direction?

There is no standard limit on the number of parameters you can specify in Java, but according to "Code Complete" (see this post) you should limit the amount of parameters to about 7, any more and it will have a negative effect on the readability of your code.

This really has nothing to do with Java specifically. And you should definitely make it configurable, because there are quite different views on this.
In "Clean Code", Robert Martin argues that the ideal number of method parameters is 0, 1 is OK, 2 needs strong justification, and 3 or more requires special dispensation from the pope.
Most people will consider this way too strict and wouldn't blink twice at a method with 3 parameters. You can probably get broad agreement that 6 parameters is too many.

In Java you can't define more than 255 pararmeters for a method. This is the restriction.
For and advise, Uncle Bob says -Clean Code- max parameter count should be three.
Too many parameters, parameter xxxxxxx is exceeding the limit of 255 words eligible for method parameters

Checkstyle is a popular tool to check java coding standard.
Here is the link the the ParameterNumber rule: ParameterNumber

My honest opinion is there is no defined limit to the number of parameters. My personal preference is not to have more than 3 or at least 4 since this can affect readability and mental mapping (difficult to remember more than 4 parameters). You can also have a quick peep at Uncle Bob's Clean Code and Steve McConnell's Code Complete regarding this.
There is a similar thread in StackOverflow see When a method has too many parameters?

There really is not a standard number of parameters.

You can use any number of arguments in a function in java. There is no standard limit to have this number of argument in function in java.[As per I know] IMO as a practice you should not have more than 4 arguments for a function but this is not the standard you can have any number of arguments.

There's no hard limit, but I'd say more than five is a code smell in a language that has no keyword arguments (such as Java).