Interviews

Duggys Housemate

everdead.ie wrote: »

Feathers wrote: »

Divide it by 2?

It's more like divide X by two and put the result into an int(Y) then do an if statement to see if X-Y=Y.
If it is then the number is even if its not then its odd.

You can't know what y is.

Feathers

everdead.ie wrote: »

It's more like divide X by two and put the result into an int(Y) then do an if statement to see if X-Y=Y.
If it is then the number is even if its not then its odd.

Yeah, depends on what language you're working in after the div by 2, so didn't flesh it out. Just meant that your 99% of the way there in 2 seconds, not really a difficult programming issue (hopefully).

Duggys Housemate

That's wrong, most languages when dividing by 2 discard the non integer part - its a bitwise shift. Rounding up is an extra operation. You would need to convert to floats then round then test your equivalence. Bad solution.

Feathers

Duggys Housemate wrote: »

That's wrong, most languages when dividing by 2 discard the non integer part - its a bitwise shift. Rounding up is an extra operation. You would need to convert to floats then round then test your equivalence. Bad solution.

So you're telling me that if I say "double d = 5.0/2", most languages will give me 2? Or 3? Hmm…

It's not a bad solution, it's an incomplete solution to an incomplete question. The point is, it's not a difficult problem.

Duggys Housemate

Feathers wrote: »

Duggys Housemate wrote: »

That's wrong, most languages when dividing by 2 discard the non integer part - its a bitwise shift. Rounding up is an extra operation. You would need to convert to floats then round then test your equivalence. Bad solution.

So you're telling me that if I say "double d = 5.0/2", most languages will give me 2? Or 3? Hmm…

It's not a bad solution, it's an incomplete solution to an incomplete question. The point is, it's not a difficult problem.

No he said int. divide an int 13 by 2 and you get 6.

With a double

13 - 6.5 = 6.5
and
12 - 6 = 6

So the logic fails as that always works.

The solution is the bitwise & with 1

nbar12

#include <iostream>
using namespace std;

int main ()
{
cout << "Hello World!";
return 0;
}

Feathers

Duggys Housemate wrote: »

No he said int. divide an int 13 by 2 and you get 6.

With a double

13 - 6.5 = 6.5
and
12 - 6 = 6

So the logic fails as that always works.

The solution is the bitwise & with 1

The original question said 'number' not integer or double. What everdead.ie was saying is that if you divide a number by two, then cast that to an int and subtract one from the other (X – (int) X, where X = Y/2) you'll get 0 for even numbers, anything else is odd. (Not taking into account negative numbers). He never said that either of 'X' or 'Y' in this case were integers and neither did the poster who put the question.

Duggys Housemate

Feathers wrote: »

Duggys Housemate wrote: »

No he said int. divide an int 13 by 2 and you get 6.

With a double

13 - 6.5 = 6.5
and
12 - 6 = 6

So the logic fails as that always works.

The solution is the bitwise & with 1

The original question said 'number' not integer or double. What everdead.ie was saying is that if you divide a number by two, then cast that to an int and subtract one from the other (X – (int) X, where X = Y/2) you'll get 0 for even numbers, anything else is odd. (Not taking into account negative numbers). He never said that either of 'X' or 'Y' in this case were integers and neither did the poster who put the question.

When we are talking about odd or even we are talking about integers. Anyway try the solution for integers, it's wrong.

Feathers

Duggys Housemate wrote: »

When we are talking about odd or even we are talking about integers. Anyway try the solution for integers, it's wrong.

So from you're understanding:

double d = 2;

You're saying that d above isn't odd or even? A mathematical 'integer' (a number that is whole) is different to a computing int value type. You can store integers (in maths terms) as doubles — and if so, having '.0' at the end doesn't make them magically not even any more.

Of course it's wrong for integers, as it depends on information being lost via a cast to an int – i.e. the 0.5 that you would have after dividing an odd number.

Obviously the most straightforward way to do solve this is using bitwise operation. I don't think anyone has questioned this. The point that was being made was that the original poster was calling it a 'bastard of a question' and that there are ways of working it out that can be simple in execution/understanding, even if you're not up on bitwise operators.

Not sure if you've just realised that you were wrong (that the above does work) and want to cover or that you're being precious about doing things in the right way, but you're coming across as overly defensive to be honest.

Duggys Housemate

Feathers wrote: »

Duggys Housemate wrote: »

When we are talking about odd or even we are talking about integers. Anyway try the solution for integers, it's wrong.

So from you're understanding:

double d = 2;

You're saying that d above isn't odd or even? A mathematical 'integer' (a number that is whole) is different to a computing int value type. You can store integers (in maths terms) as doubles — and if so, having '.0' at the end doesn't make them magically not even any more.

Of course it's wrong for integers, as it depends on information being lost via a cast to an int – i.e. the 0.5 that you would have after dividing an odd number.

Obviously the most straightforward way to do solve this is using bitwise operation. I don't think anyone has questioned this. The point that was being made was that the original poster was calling it a 'bastard of a question' and that there are ways of working it out that can be simple in execution/understanding, even if you're not up on bitwise operators.

Not sure if you've just realised that you were wrong (that the above does work) and want to cover or that you're being precious about doing things in the right way, but you're coming across as overly defensive to be honest.

Not being precious. The interviewer is looking for the proper solution. Writing a function or API is not just about getting some solution but the best. The interviewer is looking for the correct. If you use a double he will ask you why you are using a double when integers would suffice. In fact you would write a function and probably given a header to implement.

I.e

Boolean isEven(int number)

If you were to flaff around with floats it would be a fail. The question is asked to work out if you understand bitwise operators. It's not a test to see how much more inefficient you can be than using the real solution.

Storing ints as doubles is wrong.

So.

double i;

for(i=0; i<kMax;i++) is nearly always wrong unless you were using i as a float within the scope and not an enumerator. That kind of coding indicates lack of understanding of core concepts.

Feathers

Duggys Housemate wrote: »

Not being precious. The interviewer is looking for the proper solution. Writing a function or API is not just about getting some solution but the best. The interviewer is looking for the correct. If you use a double he will ask you why you are using a double when integers would suffice. In fact you would write a function and probably given a header to implement.

I.e

Boolean isEven(int number)

If you were to flaff around with floats it would be a fail. The question is asked to work out if you understand bitwise operators. It's not a test to see how much more inefficient you can be than using the real solution.

Storing ints as doubles is wrong.

So.

double i;

for(i=0; i<kMax;i++) is nearly always wrong unless you were using i as a float within the scope and not an enumerator. That kind of coding indicates lack of understanding of core concepts.

If the interviewer asked me why I was flaffing around with floats, I'd politely ask him to reread the question he set me, which was to check if a number was odd or even, not if an int was odd or even. Storing ints as doubles is only wrong if you're certain that you will only be dealing with ints, which you're not in this case - that's just your assumption on the question.

If the interviewer wanted the correct answer, he wouldn't have said 'without using modulo', since this is the "correct" answer that would be used in production code.

Rather the question is qualitative rather than quantitative: he wants to know how you're thinking about the problem. If I said I'd chose to do this via a parseInt method if it were JavaScript for instance (as most JS developers I've dealt with don't come from a computer science background, don't have a good grasp of bitwise operation and therefore the savings made from slightly more efficient code would be lost in maintenance and bug fixes), I'd consider that a good answer.

In hypothetical questions, I'd be much more interested in why someone is giving me an answer than the answer itself. It's not a case of pass or fail!