a small java program

[gowrisonia]

sum of two varaibles without using mathematical operators.

[JosAH]

sum of two varaibles without using mathematical operators.

Is this a quiz question? What can I win?

kind regards,

Jos

[TripleDES]

sum of two varaibles without using mathematical operators.

if the two variables are of type float or double, you would have to implement IEEE-754-conforming addition without using arithmetic operators. It could probably be done, but the resulting code would certainly not be "a small java program".

So if the question is: "How do you make a small java program that calculates the sum of two variables without using arithmetic operators?", my answer is: "It can't be done"

So what do I win? :)

[blazedaces]

if the two variables are of type float or double, you would have to implement IEEE-754-conforming addition without using arithmetic operators. It could probably be done, but the resulting code would certainly not be "a small java program".

So if the question is: "How do you make a small java program that calculates the sum of two variables without using arithmetic operators?", my answer is: "It can't be done"

So what do I win? :)

Small is a relative term... an adder isn't tall too complicated (three-bit input, two variables you're going to sum and the input carry bit, two-bit output, carry bit and sum bit) and then we just need to convert the variables to their two's-compliment byte equivalents and that's easy enough since java already stores only signed values.

Note: your computer does this when you use the '+' sign anyway.

There would be no difference between any primitive type (float, double, integer, long, short). So long as your "convert-to-bytecode" methods work correctly you should be perfectly fine.

-blazed

[TripleDES]

Small is a relative term...

Of course, but since this is a typical "trick question", wouldn't one expect the answer to be very concise? I know I would.

an adder isn't tall too complicated (three-bit input, two variables you're going to sum and the input carry bit, two-bit output, carry bit and sum bit) and then we just need to convert the variables to their two's-compliment byte equivalents and that's easy enough since java already stores only signed values.

Floating point addition is much more complicated than simply doing a bitwise add w/carry and convert to two's complement.

You have to convert the the exponent from sign-magnitude form to 2's complement without using arithmetic operators. The easiest way to do this would probably be a lookup table.

You would then have to use alignment and normalization routines, again implemented without arithmetic operators to align the numbers and normalize as necessary. Your implementation would of course also have to simulate the three different guard bits to be conforming.

Finally comes rounding. Fortunately, Java only supports round-to-nearest, so you don't have to implement all the IEEE-754 rounding modes.

Don't forget to that you also have to correctly handle the encoding of NaNs, +/- INF and denormalized numbers (a special encoding to increase precision in certain cases). I believe it would take quite some code to implement the latter in software without arithmetic operators.

You would also have to emulate the strictfp behavior somehow. That is, your implementation may have to yield a different result if strictfp is specified, to perfectly emulate addition using operator '+'.

Oh, and if the two variables are not of the same type (e.g if you want to add a double and an int) you would also have to implement the appropriate conversion function.

[blazedaces]

Of course, but since this is a typical "trick question", wouldn't one expect the answer to be very concise? I know I would.


Floating point addition is much more complicated than simply doing a bitwise add w/carry and convert to two's complement.

You have to convert the the exponent from sign-magnitude form to 2's complement without using arithmetic operators. The easiest way to do this would probably be a lookup table.

You would then have to use alignment and normalization routines, again implemented without arithmetic operators to align the numbers and normalize as necessary. Your implementation would of course also have to simulate the three different guard bits to be conforming.

Finally comes rounding. Fortunately, Java only supports round-to-nearest, so you don't have to implement all the IEEE-754 rounding modes.

Don't forget to that you also have to correctly handle the encoding of NaNs, +/- INF and denormalized numbers (a special encoding to increase precision in certain cases). I believe it would take quite some code to implement the latter in software without arithmetic operators.

You would also have to emulate the strictfp behavior somehow. That is, your implementation may have to yield a different result if strictfp is specified, to perfectly emulate addition using operator '+'.

Oh, and if the two variables are not of the same type (e.g if you want to add a double and an int) you would also have to implement the appropriate conversion function.

Hmm... well I completely forgot that it's obviously not the same for floating point numbers... That does complicate things quite a bit.

I would avoid emulating scriptfp behavior and just use a add(float a, float b) method ("small" right ;) )

As for adding a double and an int... well java doesn't support that so I don't see why it would be a prerequisite for this program.

I honestly had no idea how numbers were represented by floating point precision (or to be specific in this case IEEE-754 conforming floating point and double precisions) until I went and read up on it just now... interesting stuff.

And I definitely ignored NaN and infinities...
Yup, there's no way you could quite call this a small program any more...

Still cool to think about though...

-blazed

[TripleDES]

As for adding a double and an int... well java doesn't support that so I don't see why it would be a prerequisite for this program.
-blazed

what if you write this? :)
[CODE=java]
int j = 42;
double d = 55.64;
double result = d + j;
[/CODE]

[RexSilex]

what if you write this? :)
[CODE=java]
int j = 42;
double d = 55.64;
double result = d + j;
[/CODE]

Java supports adding different variable types together,you just get interesting results if you don't know what you're doing and it sometimes requires casting. Since double is larger than an int you'll get about what'd you expect 97.64 for the code above. if u tried:
[CODE=java]
int j =42;
double d=55.64;
int result=d+j;
[/CODE]
You'd have to get into casting.

[JosAH]

Hmm... well I completely forgot that it's obviously not the same for floating point numbers... That does complicate things quite a bit.

It doesn't; think of a full adder a simple ALU and a bunch of barrel shifters.

kind regards,

Jos

[TRScheel]

Cast the values to bytes

So...
Value1[] array of bits (or bools...)
Value2[]
Answer[]

Answer[n] = (Value[n] XOR Value[n]) XOR (Value[n-1] & Value[n-2])

0101 = 5
0111 = 7
1100 = 12

0110 = 6
1001 = 9
1111 = 15

0110 = 6
0111 = 7
1101 = 13

[JosAH]

Answer[n] = (Value[n] XOR Value[n]) XOR (Value[n-1] & Value[n-2])

That definitely doesn't work for n < 2.

kind regards,

Jos

[blazedaces]

It doesn't; think of a full adder a simple ALU and a bunch of barrel shifters.

kind regards,

Jos

Ah, I see. This is an interesting subject. As for double and float added together it would be a simple conversion of the float to a double by casting or vice versa though if it's too large a number an obvious error would arise.

Still, I don't think this is too complex/long a program...

-blazed

[TripleDES]

It doesn't; think of a full adder a simple ALU and a bunch of barrel shifters.

kind regards,

Jos

You need more logic than is present in a typical ALU. In particular, logic for doing sign-magnitude conversion, round-to-nearest, and the encoding of subnormal numbers as described above.

It is true that you do not have to implement conversion. My mistake.

[blazedaces]

You need more logic than is present in a typical ALU. In particular, logic for doing sign-magnitude conversion, round-to-nearest, and the encoding of subnormal numbers as described above.

It is true that you do not have to implement conversion. My mistake.

Isn't just the following steps:

1. Aligning the exponents
2. Adding the mantissa (is that what it's called... why?)
3. Re-evaluating the exponent (is this where rounding would occur?)

Sign-magnitude conversion is not all too complicated, it's simply -1^(Most Significant Bit) * 1.Mantissa (23 least significant bits for float, 52 for double) * 2^Exponent (8 bits after sign for float, 11 for double)

Maybe I'm misunderstandin g you...

-blazed

[TRScheel]

That definitely doesn't work for n < 2.

kind regards,

Jos

Its pseudo code, and for n < 2 (or... n = 1 in an array starting at 1) then you just eliminate the final portion asking for n - 1 and just XOR the two values, AKA just do the first portion of the giant bool statement