Order of addition in Java - java

In what order does Java add up the numbers a + b + c?
Is it a + (b + c) or (a + b) + c?
I just learned how floating point representation works and finished an exercise which explained that if a, b, c are floats, they might yield a different result when added up in the different ways I wrote above.
That left me wondering which way Java actually does it?

The addition operator is left associative, meaning that a + b + c is evaluated the same as (a + b) + c.
The JLS, Section 15.18, states:
The additive operators have the same precedence and are syntactically left-associative (they group left-to-right).

Left to right (jls-15.18) unless you add parenthesis to alter the order of evaluation.
static int a() {
System.out.println("a");
return 1;
}
static int b() {
System.out.println("b");
return 1;
}
public static void main(String[] args) {
System.out.println(a() + b());
}
Output is
a
b
2

The order of a + b + c is that of (a + b) + c (left associativity).

Related

Converting C to Java understanding macro's in C

I'm told the following C code
#define ADD(a, b) a + b
// example function
void foo()
{
int i = ADD(1, 2); // add two ints
double d = //doubles
ADD(3.4, 5.6);
int sly = ADD(1, 2) * 3; // not what it appears to be
}
converts to this Java code
package demo;
public class DemoTranslation {
public static int add(int a, int b) {
return a + b;
}
public static double add(double a, double b) {
return a + b;
}
/**
* example function
*/
public static void foo() {
int i = add(1, 2); // add two ints
double d = /* doubles */ add(3.4, 5.6);
int sly = 1 + 2 * 3; // not what it appears to be
}
}
1+2*3 in java = 7. How does the C code produce that and not 9?
C macro replacement operates on lexical tokens, at a lower level than semantic analysis of the program.
Given #define ADD(a, b) a + b, the source text ADD(1, 2) * 3 is replaced by 1 + 2 * 3, which is evaluated as 1+(2•3) = 7.
Macro replacement was created for convenience in early primitive programming environments. As such, some of the motivation for developing it was simply typing convenience (editing source files could be a burdensome task in hardware of the era), and additional uses of it grew, including using macros to represent simple expressions. To deal with the fact that macros perform lexical substitution rather than semantic functions, C programmers have learned to parenthesize arguments in macro replacement lists as well as the entire list when macros are being used for expressions. So a C programmer would define ADD as:
#define ADD(a, b) ((a) + (b))
Then ADD(1, 2) * 3 will be replaced by ((1) + (2)) * 3, which will be evaluated as (1+2)•3 = 9.

Karatsuba multiplication java recursion code not working?

I am trying to multiply two numbers using karatsuba multiplication. My java code is not working. I have used string as parameters and arguments so that we can multiply two n digit numbers (n is even). Also, I don't want to use long or BigInteger. Please help me to figure out my code mistake.
class karat{
public static String karatsuba(String first, String second){
if(first.length() <= 1 || second.length() <= 1)
return String.valueOf(Long.parseLong(first)*Long.parseLong(second));
String a = karatsuba(first.substring(0, first.length()/2), second.substring(0, second.length()/2));
String b = karatsuba(first.substring(first.length() - first.length()/2, first.length()), second.substring(second.length() - second.length()/2, second.length()));
String c = karatsuba(String.valueOf(Long.parseLong(first.substring(0, first.length()/2)) + Long.parseLong(first.substring(first.length() - first.length()/2, first.length()))), String.valueOf(Long.parseLong(second.substring(0, second.length()/2)) + Long.parseLong(second.substring(second.length() - second.length()/2, second.length()))));
String d = String.valueOf(Long.parseLong(c) - Long.parseLong(b) - Long.parseLong(a));
return String.valueOf(((int)Math.pow(10, first.length()))*(Long.parseLong(a)) + (((int)Math.pow(10, first.length()/2))*Long.parseLong(d)) + (Long.parseLong(c)));
}
public static void main(String[] args){
String result = karatsuba("1234", "5678");
System.out.println(result); }
}
Can you also please refine my code.
Numbers passed for multiplication - 1234 and 5678
Output is - 6655870 (Incorrect)
Output should be - 7006652 (Correct)
Thank you
First of all I tried look at your code, it gets a programmer to get lost, few things before we go into solution.
General advice. It is not good practice to convert string to value and back and forward like you do, it does not work like this. I tried as well to debug your code, it is just devil circle.
So I would start with check if value length and the maximum one.
Than if one of the values is less than 2 of length mean every thing less than 10 do multiplication otherwise do karatsuba recursion algorithm.
Here is the solution:
public static long karatsuba(long num1, long num2) {
int m = Math.max(
String.valueOf(num1).length(),
String.valueOf(num2).length()
);
if (m < 2)
return num1 * num2;
m = (m / 2) + (m % 2);
long b = num1 >> m;
long a = num1 - (b << m);
long d = num2 >> m;
long c = num2 - (d << m);
long ac = karatsuba(a, c);
long bd = karatsuba(b, d);
long abcd = karatsuba(a + b, c + d);
return ac + (abcd - ac - bd << m) + (bd << 2 * m);
}
Some test;
public static void main(String[] args) {
System.out.println(karatsuba(1, 9));
System.out.println(karatsuba(1234, 5678));
System.out.println(karatsuba(12345, 6789));
}
The output would be
9
7006652
83810205
It is less pain than your Stringish code. Btw, the solution is inspired from the pesudo in wiki and this class.
Interesting algorithm. One mistake is in
return String.valueOf(((int)Math.pow(10, first.length()))*(Long.parseLong(a)) + (((int)Math.pow(10, first.length()/2))*Long.parseLong(d)) + (Long.parseLong(c)));
At the end, it should be Long.parseLong(b) instead of Long.parseLong(c).
And in intermediate calculations, it can happen that the two strings are of different lengths. That also doesn't work correctly.
Please, allow some comments to improve the implementation. The idea to use strings seems to allow for big numbers, but then you introduce things like Long.parseLong() or (int)Math.pow(10, first.length()), limiting you to the long or int range.
If you really want to do big numbers, write your own String-based addition and power-of-ten multiplication (that one being trivial by appending some zeroes).
And, try to avoid names like a, b, c, or d - it's too easy to forget what they mean, as was your original mistake. E.g. the names from Wikipedia are a little bit better (using z0, z1 and z2), but still not perfect...

Java variable may not have been initialized

I'm working on Project Euler Problem 9, which states:
A Pythagorean triplet is a set of three natural numbers, a < b < c, for which,
a^2 + b^2 = c^2
For example, 3^2 + 4^2 = 9 + 16 = 25 = 52.
There exists exactly one Pythagorean triplet for which a + b + c = 1000.
Find the product abc.
Here's what I've done so far:
class Project_euler9 {
public static boolean determineIfPythagoreanTriple(int a, int b, int c) {
return (a * a + b * b == c * c);
}
public static void main(String[] args) {
boolean answerFound = false;
int a, b, c;
while (!answerFound) {
for (a = 1; a <= 1000; a++) {
for (b = a + 1; b <= 1000; b++) {
c = 1000 - a - b;
answerFound = determineIfPythagoreanTriple(a, b, c);
}
}
}
System.out.println("(" + a + ", " + b + ", " + c + ")");
}
}
When I run my code, I get this error:
Project_euler9.java:32: error: variable a might not have been initialized
System.out.println("The Pythagorean triplet we're looking for is (" + a + ", " + b + ", " + c + ")");
Note: I get this for each of my variables (a, b, and c) just with different line numbers.
I thought that when I declared a, b, and c as integers, the default value was 0 if left unassigned.
Even if this weren't the case, it looks to me like they all do get assigned, so I'm a bit confused about the error.
Why is this happening?
Instance variables (in your case, they would be integers) are assigned to 0 be default. Local variables not. (From Java Docs)
If the loop is not entered, then your variables won't be initialized, that's the reason of the error.
What you can do is initialize them when declaring:
int a=0, b=0, c=0;
Your problem is this line:
System.out.println("(" + a + ", " + b + ", " + c + ")");
which is after the while (!answerFound) {...} loop. The compiler thinks that there may be a case where one or more of the variables a, b or c isn't initialised.
Use this line:
int a=0, b=0, c=0;
when declaring the variables, so that they are initialised when declared, and the error should go away.
Do this, at the beginning of the method after the local variables are declared:
a = b = c = 0;
The error is basically stating that Java can't be sure that the variables have a value assigned when they reach the System.out.println(). Remember: in Java only attributes have default values, all local variables must be explicitly initialized at some point.
You're right and wrong in your thinking:
Where you're right:
Yes, uninitialized variables may be assigned a value by the compiler, but a) it is considered bad style, b) You shouldn't depend on it, c) That does not apply to local variables (as declared in a method)
Where you are wrong:
Local variables are not assigned a default value, only instance variables.
For reference, take a look at The docs:
Default Values
It's not always necessary to assign a value when a field is declared.
Fields that are declared but not initialized will be set to a
reasonable default by the compiler. Generally speaking, this default
will be zero or null, depending on the data type. Relying on such
default values, however, is generally considered bad programming
style.
The following chart summarizes the default values for the above data
types.
Data Type Default Value (for fields)
byte 0
short 0
int 0
long 0L
float 0.0f
double 0.0d char '\u0000' String (or any object) null
boolean false
Local variables are slightly different; the compiler never assigns a
default value to an uninitialized local variable. If you cannot
initialize your local variable where it is declared, make sure to
assign it a value before you attempt to use it. Accessing an
uninitialized local variable will result in a compile-time error.
When you declare local variables in a method, you have to assign them values before use them.
The Java compiler has to be convinced that when we get to the line HERE, it can prove that a, b, and c have been set to something:
boolean answerFound = false;
int a, b, c;
while (!answerFound) {
for (a = 1; a <= 1000; a++) {
for (b = a + 1; b <= 1000; b++) {
c = 1000 - a - b;
answerFound = determineIfPythagoreanTriple(a, b, c);
}
}
}
// HERE
From the compiler's point of view, if the loop is executed zero times, then it will get to HERE without the variables being initialized; therefore, you can't use them. We know that this is impossible, because we know that answerFound is initialized to false and therefore the loop will be executed at least once, and also that each for loop will be executed at least once. But the language has to have consistent rules to determine which programs are legal and which ones aren't; in order to keep things from being overly complex, the compiler isn't required to make the kinds of deductions that would be necessary to prove that a, b, and c are always initialized. I haven't looked at the actual "definite assignment" rules in detail, but I think they're already fairly complex.
So even though you know that the variables will be initialized, you can't convince the compiler of that. So just initialize them when they're declared.
int a = 0, b = 0, c = 0;
By the way, since the while is outside the for loops, this code will not exit right away when answerFound becomes true. It still executes the for loops until they're done, and only then does it test to see whether to leave the while loop. You'll need to solve that.
P.S. If you want to cheat, note that every Pythagorean triple has the form a = m2 - n2, b = 2mn, c = m2 + n2, for some m and n. You could actually get the answer without a computer, using algebra. But go ahead and finish the program you started--it's great practice.
As others have pointed out your variables a, b, c may not have been initialized by the time you get to System.out.println. There are several ways to avoid this.
Initialize variables explicitly, so:
int a = 0;
Use a do...while loop, which ensures your loop is run at least once, so:
do {
[...]
} while (!answerFound);
Use loop-scoped variables, which avoid local-scoped variables hanging around, so:
for (int a = 1; a <= 1000; a++) {
[...]
}

Code segment on arrays java [duplicate]

This question already has answers here:
How does an array's equal method work?
(5 answers)
Closed 8 years ago.
So I was doing review, and came across this question that I'm not very sure about.
Consider the following code segment:
int[] A = {1,2,3};
int[] B = {1,2,3};
int[] C = A;
After this code executes, which of the following expressions would evaluate to true?
I. A.equals (B)
II. A == B
III. A ==C
I only
II only
III only
I and III only
I, II, and III
I thought it was I only, but one of my classmates said that it was III only.
Could some please explain this?
Thanks for the help.
The answer is in the above linked question by #J L:
Arrays.equals(array1, array2) works as you would expect (i.e. compares
content), array1.equals(array2) falls back to Object.equals
implementation, which in turn compares identity, and thus better
replaced by == (for purists: yes I know about null).
Simply put, you are setting C equal to A, so that's why A == C is true. You performing an Object.equals essentially. While it appears on the surface that A.equals(B) would be true, they are not because of the internals behind Object.equals.
So your friend is right.
The third has a and c pointing the same object. The others not.
Your friend is correct.
In the code you are saying C = A.
This means that C is the same exact object as A.
In other cases, they are not the same object, although they have the same content.
You might want to have a look at Arrays.deepEquals which returns true (your code is slightly modified):
package arrays;
import java.util.Arrays;
public class ArraysTest {
public static void main(String[] args) {
Integer[] A = { 1, 2, 3 };
Integer[] B = { 1, 2, 3 };
Integer[] C = A;
System.out.println("A.equals(B) is " + (A.equals(B)));
System.out.println("Arrays.deepEquals(A, B) is "
+ (Arrays.deepEquals(A, B)));
System.out.println("A == B is " + (A == B));
System.out.println("A == C is " + (A == C));
}
}
The output will be:
A.equals(B) is false
Arrays.deepEquals(a, b) is true
A == B is false
A == C is true
only the third one would be true.
take the first
int[] A = {1,2,3};
witch means A has position 0:1, position 1:2, position 2:3.
then take the second
int[] B = {1,2,3};
witch means B has position 0:1, position 1:2, position 2:3.
so they have the same values in each position but they are two different int arrays
but then take the third
int[] C = A;
their you are saying `int[] C is equal to int[] A,
just like saying
String a = "LOL";
String b = a;
Also just a few notes, Only strings are compared by using .equalsanything else is compared using ==, and always use lower case letters for variables, it makes it easier to code.
you can always test methods with this
if(A.equals(B)
{
System.out.println("A.equals(B) is true");
}
else
{
System.out.println("A.equals(B) is false";
}
same for
if(A == B)
{
System.out.println("A == B is true");
}
else
{
System.out.println("A == B is false");
}
Hope this helps, Luke.

Why don't Java's +=, -=, *=, /= compound assignment operators require casting?

Until today, I thought that for example:
i += j;
Was just a shortcut for:
i = i + j;
But if we try this:
int i = 5;
long j = 8;
Then i = i + j; will not compile but i += j; will compile fine.
Does it mean that in fact i += j; is a shortcut for something like this
i = (type of i) (i + j)?
As always with these questions, the JLS holds the answer. In this case §15.26.2 Compound Assignment Operators. An extract:
A compound assignment expression of the form E1 op= E2 is equivalent to E1 = (T)((E1) op (E2)), where T is the type of E1, except that E1 is evaluated only once.
An example cited from §15.26.2
[...] the following code is correct:
short x = 3;
x += 4.6;
and results in x having the value 7 because it is equivalent to:
short x = 3;
x = (short)(x + 4.6);
In other words, your assumption is correct.
A good example of this casting is using *= or /=
byte b = 10;
b *= 5.7;
System.out.println(b); // prints 57
or
byte b = 100;
b /= 2.5;
System.out.println(b); // prints 40
or
char ch = '0';
ch *= 1.1;
System.out.println(ch); // prints '4'
or
char ch = 'A';
ch *= 1.5;
System.out.println(ch); // prints 'a'
Very good question. The Java Language specification confirms your suggestion.
For example, the following code is correct:
short x = 3;
x += 4.6;
and results in x having the value 7 because it is equivalent to:
short x = 3;
x = (short)(x + 4.6);
Yes,
basically when we write
i += l;
the compiler converts this to
i = (int)(i + l);
I just checked the .class file code.
Really a good thing to know
you need to cast from long to int explicitly in case of i = i + l then it will compile and give correct output. like
i = i + (int)l;
or
i = (int)((long)i + l); // this is what happens in case of += , dont need (long) casting since upper casting is done implicitly.
but in case of += it just works fine because the operator implicitly does the type casting from type of right variable to type of left variable so need not cast explicitly.
The problem here involves type casting.
When you add int and long,
The int object is casted to long & both are added and you get long object.
but long object cannot be implicitly casted to int. So, you have to do that explicitly.
But += is coded in such a way that it does type casting. i=(int)(i+m)
In Java type conversions are performed automatically when the type of the expression on the right hand side of an assignment operation can be safely promoted to the type of the variable on the left hand side of the assignment. Thus we can safely assign:
byte -> short -> int -> long -> float -> double.
The same will not work the other way round. For example we cannot automatically convert a long to an int because the first requires more storage than the second and consequently information may be lost. To force such a conversion we must carry out an explicit conversion.
Type - Conversion
Sometimes, such a question can be asked at an interview.
For example, when you write:
int a = 2;
long b = 3;
a = a + b;
there is no automatic typecasting. In C++ there will not be any error compiling the above code, but in Java you will get something like Incompatible type exception.
So to avoid it, you must write your code like this:
int a = 2;
long b = 3;
a += b;// No compilation error or any exception due to the auto typecasting
The main difference is that with a = a + b, there is no typecasting going on, and so the compiler gets angry at you for not typecasting. But with a += b, what it's really doing is typecasting b to a type compatible with a. So if you do
int a=5;
long b=10;
a+=b;
System.out.println(a);
What you're really doing is:
int a=5;
long b=10;
a=a+(int)b;
System.out.println(a);
Subtle point here...
There is an implicit typecast for i+j when j is a double and i is an int.
Java ALWAYS converts an integer into a double when there is an operation between them.
To clarify i+=j where i is an integer and j is a double can be described as
i = <int>(<double>i + j)
See: this description of implicit casting
You might want to typecast j to (int) in this case for clarity.
Java Language Specification defines E1 op= E2 to be equivalent to E1 = (T) ((E1) op (E2)) where T is a type of E1 and E1 is evaluated once.
That's a technical answer, but you may be wondering why that's a case. Well, let's consider the following program.
public class PlusEquals {
public static void main(String[] args) {
byte a = 1;
byte b = 2;
a = a + b;
System.out.println(a);
}
}
What does this program print?
Did you guess 3? Too bad, this program won't compile. Why? Well, it so happens that addition of bytes in Java is defined to return an int. This, I believe was because the Java Virtual Machine doesn't define byte operations to save on bytecodes (there is a limited number of those, after all), using integer operations instead is an implementation detail exposed in a language.
But if a = a + b doesn't work, that would mean a += b would never work for bytes if it E1 += E2 was defined to be E1 = E1 + E2. As the previous example shows, that would be indeed the case. As a hack to make += operator work for bytes and shorts, there is an implicit cast involved. It's not that great of a hack, but back during the Java 1.0 work, the focus was on getting the language released to begin with. Now, because of backwards compatibility, this hack introduced in Java 1.0 couldn't be removed.

Categories