Issue With Subtraction example

Nice way of doing that!!

Yep, glad to have helped. I assume that means that solved your issue?

int biggest = Math.max( int, int) would be entirely systematic and robust.

@Krakatoa
That does not solve the question asked. Only gives the maximum of two values.  does still not give a simple  a - b >0 solution. You only tell what is the largest.  To answer in full you also need the smallest.  
Assuming you then go on to us
int smallest = Math.min(int, int)

You are now making TWO function calls and assignments that are not needed in 50% of the time instead of a simple < comparison.

You only tell what is the largest.

You don't say . . .

That's why you can use this application of Math.max, given your existing :

"
                int first = r.nextInt(9) + 1;
            int second = r.nextInt(9) + 1;
"

sum /*[sic]*/ = Math.max(first,second)>second?first-second:second-first; 

Select all Open in new window

If the intention is only to display the answer and never the actual Formula on screen then that works but would be far simpler in that case to use

AbsSum = Math.abs(first-second);
5-2=3  and  2-5=3

But the assumption was from reading the question that the questioner wanted the values such that First was ALWAYS >= Second in order to get the result desired rather than just getting a positive answer from two unknown numbers, undisplayed numbers.

No that's not how I understood the question. The way I understood it was that by "first number", the questioner meant the number FROM WHICH the second number would be subtracted. After all, it doesn't make any sense otherwise, because you would already know, a priori, which number was bigger and so there wouldn't BE a question in the first place.

You misunderstand.

The question is about TWO random numbers, First and Second.  The questioners OWN code ensured that First was always  >= Second but by way of a cpu consuming loop that was not needed.

The question was to ensure that he ended up with two numbers first and second that always satisfied the condition of

First !< Second

Reread the question and you will see.

>>Reread the question and you will see<<

Maybe the OP should tell us what is required.

Indeed a further explanation would be nice to clarify.  I am basing my further comments on the reading of the question and the questioners comment of.. "Nice way of doing that!!"

Krakatoa's moving along the right lines:

int first = r.nextInt(9) + 1;
int second = r.nextInt(Math.max(first - 1, 1)) + 1;

Select all Open in new window

@ Neilsr2014-12-15 at 19:04:09ID: 40501070

Right, but ask yourself why you would ever need to decide which was the biggest of two numbers, if you already knew the answer.

At no point has Krakatoa suggested forcing second to be physically higher, he just argued against it!  Thats how we got to this point!  
My whole point all along has been that first should ALWAYS be <= second.

@Krakatoa

Simple answer is one of a simple Maths quiz for children.  You want to present two numbers on screen, First & Second such that the child can now press a digit of 0-9 to give the answer.

You don't want -7 as an answer.  Hence you ALWAYS want first to be bigger than second and always want the full range of numbers.
Thats one very quick answer to

"Right, but ask yourself why you would ever need to decide which was the biggest of two numbers, if you already knew the answer."

My whole point all along has been that first should ALWAYS be <= second.

This would always ensure a negative result.

Yes typo, wrong key.

rather than just getting a positive answer from two unknown numbers, undisplayed numbers

I've got no idea whether you are speaking from a child's point of view, the programmer, or someone else.

second = (int)(Math.random()*10);

first = Math.max(Integer.rotateRight(second,255),0);

Select all Open in new window

If 0 isn't required as a second val, then that can be taken out.

Do you like to make an argument out of every question and make snide, unneeded remarks every time?

The question was simple, the answer given was simple.  It was a very simple alternative the code that the OP had already given in trying to achieve his chosen task.

Maybe like you already suggested, you should await the OP making a comment before you continue with your  "You don't say . . ." and your "I've got no idea whether you are speaking from a child's point of view"

It's rather you who has taken offence I'd say. And certainly giving it. However, I don't care about that. When you say "every question", I assume you have conducted extensive research into my Comments history, which must have been gratifying work.

'Snide' is really amusing though. But God knows what you are getting at. Let's hope he's looking down, and can be bothered to arbitrate and explain it to me. :0)

I said

I've got no idea whether you are speaking from a child's point of view, the programmer, or someone else.

, as you mentioned the game was for a child, but you didn't seem to grasp that.

It was a bad idea to accept the answer as it stands. Yes, it works, but it is beset by erroneous notions. The first is that, as a model, if it were extended to handle multiple ints, it would amount to little more than a Neolithic bubble-sort, and come the day when such a large array of ints has to be dealt with, perhaps in another context, this approach would send you to sleep.

Secondly, the solution post-fixes the problem, and that, philosophically, is a weakness. By this I mean that swapping the integers around based on their ordinality, is shutting the stable door after the horse has left. The coder DOES HAVE control over how the numbers are generated, as CEHJ has elegantly demonstrated, and so their rank can be fixed at the time of creation, rather than doing this by playing catch-up with swaps afterwards.

And finally the overall weakness is that considering that the numbers are random creations, there is no such thing as a first and a second a priori unless, (and this constitutes the answer that SHOULD have be awarded the points), you choose CEHJ's answer, since there is no way of knowing which is the larger until after the event(s). I share in the responsibility for offering a solution that rests on a post-event decision also, and it is also one which would scale poorly against a background of multiple int sorting. However, it is founded on a more API-conventional basis than a simple swap, and does not suffer from the confusion brought about by effectively changing over the values to which the vars point, as is the case with the accepted solution.
 
Hope this helps.