odds and evens numbers

[Paul Lutus]

Mark Thornton wrote:

/ ...

Yes it is.

Please? To what does this refer? I offered two alternatives.

Ignoring the special values, the remainder a%b is always a
member of the set of values exactly representable by a double (assuming
a and b are double values). That is the remainder does not have to be
rounded or truncated to a nearby value.

This is true if you limit the values to doubles containing integers of less
than 16 decimal places. My point was the case where someone tries to test a
double value that is not an integer, dubious as this sounds from a
mathematical standpoint.

Thus a%2 will be zero if and only if 'a' an even integer. Similarly
Math.abs(a)%2 will be 1 if and only if 'a' is an odd integer.

All true for doubles that are integers, assuming they fall in the
16-decimal-digit limit for doubles.

Note I could rewrite the tests as

a%2 == 0.0

and

Math.abs(a)%2 == 1.0

Yes, again, assuming the values are integers. My point was someone might
want to test a double that is not an integer, to discover whether the
integer component was odd or even.

this makes it clear that the comparison is done on double values.

After posting I ran some tests and established this. But it leaves open the
possibility that someone might apply a double that is not an integer. I am
not justifying it, only considering it.

 

[Mark Thornton]

Yes, again, assuming the values are integers. My point was someone might
want to test a double that is not an integer, to discover whether the
integer component was odd or even.

Ah, I was assuming that for non integral values both tests were expected
to return false (which they do). Otherwise modify the test to include
Math.ceil or Math.floor as required.

Mark Thornton

 

[Paul Lutus]

Ah, I was assuming that for non integral values both tests were expected
to return false (which they do).

That makes sense.

Otherwise modify the test to include
Math.ceil or Math.floor as required.

Yes.

 

[Jacob]

Juha Laiho wrote:

But then, this method only handles issues with numbers divisible by two;
who don't we generalize it to isDivisibleBy(x)?

No. The even/odd case is special. It really
boils down to how common the operation is.
Note for incrementation how the common "1" case
got a notation of its own:

a += n; // Any n
a++; // n == 1

Equivalent for divisibility:

a % n == 0 // Any n
Integer.isEven(a) // n == 2

 

[Jacob]

Why??

static boolean isEven(double a) {
return a%2 == 0;
}
static boolean isOdd (double a) {
return Math.abs(a%2) == 1;
}

would seem to work for all doubles. Of course the majority of doubles are
neither even nor odd.

The even/odd property is not defined for floating point numbers.
Technically you can make it work by some clever assumptions, but
conceptually the question "isEven(42.0)" doesn't make any sense.

 

[Liz]

Juha Laiho wrote:



No. The even/odd case is special. It really
boils down to how common the operation is.
Note for incrementation how the common "1" case
got a notation of its own:

a += n; // Any n
a++; // n == 1

Equivalent for divisibility:

a % n == 0 // Any n
Integer.isEven(a) // n == 2

But you know that auto increment works on doubles:
-------
class Test6 {
public static void main(String args[]) {
double x = 0.7;
double y = x++;
System.out.println(x);
System.out.println(y);
System.exit(0);
}
}

 

[Paul Lutus]

The even/odd property is not defined for floating point numbers.

Not true. The even/odd property is only defined for integers. The fact that
an integer is contained in a floating-point variable is coincidental, and
floating-point variables can contain unambiguous integers.

Technically you can make it work by some clever assumptions, but
conceptually the question "isEven(42.0)" doesn't make any sense.

Certainly it does. 42.0 is an even integer. It's best not to confuse a
floating-point variable, which can contain an integer or an approximation
of a real, with a mathematical definition that doesn't depend on a
particular embodiment.

 

[Liz]

Not true. The even/odd property is only defined for integers. The fact that
an integer is contained in a floating-point variable is coincidental, and
floating-point variables can contain unambiguous integers.


Certainly it does. 42.0 is an even integer. It's best not to confuse a
floating-point variable, which can contain an integer or an approximation
of a real, with a mathematical definition that doesn't depend on a
particular embodiment.

</snip>

Reminds me of the cross assembler for the Intel 8008 (yes 8008)
that I used a long time ago. The CA was written in Fortran and,
it declared the program counter as a Float!!!

 

[Jacob]

Not true. The even/odd property is only defined for integers. The fact that
an integer is contained in a floating-point variable is coincidental, and
floating-point variables can contain unambiguous integers.

As a programmer you're free to put whatever meaning into
a variable you like as long as it can be held by that type,
like a float can "hold" an integer or a color intensity etc.

But don't loose sight of the original question: Should there
be a Double.isEven() or a Math.isEven(double v)? The answer
is clearly NO!

Certainly it does. 42.0 is an even integer.

42.0 is real by notation. In the context of Java it can be converted
to integer 42 due to the close relationship in representation.
But mathematically such a conversion is absurd; An integer models a
countable set while a real models a continous property.
That a real value happen to be *.000... doesn't make it an
integer. In maths it can't even be "converted" to an integer as
such an operation doesn't exists.

 

[Paul Lutus]

As a programmer you're free to put whatever meaning into
a variable you like as long as it can be held by that type,
like a float can "hold" an integer or a color intensity etc.

But don't loose sight of the original question: Should there
be a Double.isEven() or a Math.isEven(double v)? The answer
is clearly NO!

If the value contained in the floating-point variable is an integer, the
answer is clearly yes.

42.0 is real by notation.

It is an integer. Its decimal component is zero. It happens to be contained
in a floating-point variable.

In the context of Java it can be converted
to integer 42 due to the close relationship in representation.
But mathematically such a conversion is absurd;

No, mathematically 42.0 and 42 and both integers, and, because the
conversion to integer can be carried out without loss of information, it
means the original number is an integer.

An integer models a
countable set while a real models a continous property.
That a real value happen to be *.000... doesn't make it an
integer.

That is exactly what it means. An integer doesn't become a real by being
placed in a container that can accommodate a real. And a real doesn't
become an integer if in doing so there is loss of information.

In maths it can't even be "converted" to an integer as
such an operation doesn't exists.

False. It can be identified as an integer, and converted with no loss of
information.

 

[Liz]

Hay, forget double, how about String?? "42" is an integer.
Do we need "isEven(String a);

 

[Paul Lutus]

Hay, forget double, how about String?? "42" is an integer.
Do we need "isEven(String a);

That would be presumptuous, since a string is not a number at all.

Maybe if the string contained the word "Even", the function would have a
purpose.

 

[Liz]

That would be presumptuous, since a string is not a number at all.

It is a place to put the integer, just like double is a place to put the
integer.
ncest pas?

 

[Paul Lutus]

It is a place to put the integer, just like double is a place to put the
integer.
ncest pas?

Numeric data types can contain only a number. A string can contain anything
textual, including a string of decimal digits. I think this is a case where
a numeric data type is more appropriate.

 

[Babu Kalakrishnan]

Hay, forget double, how about String?? "42" is an integer.
Do we need "isEven(String a);

Hey - stop arguing - "42" is the actually the ultimate answer - not a question

BK

 

[Joona I Palaste]

It is a place to put the integer, just like double is a place to put the
integer.
ncest pas?

By that logic, we would need Math.isEven() and Math.isOdd() methods for
every class that contains an int or double field.

--
/-- Joona Palaste ([email protected]) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"The day Microsoft makes something that doesn't suck is probably the day they
start making vacuum cleaners."
- Ernst Jan Plugge

 

[Paul Lutus]

Joona I Palaste wrote:

/ ...

[ PL: ]

[ Liz: ]

By that logic, we would need Math.isEven() and Math.isOdd() methods for
every class that contains an int or double field.

More to the point, we could write the methods as (and if) the need came up.
No need to burden standard classes with whimsical methods.