Spring RTS Engine

Hiya, trying to help a mate with his programing task here...
The thing we're stuck on is that we want to check if the last two digits in a (int) variable are zeros.

Thought someone here might know :)

i % 100 == 0

i dont know any java


Was this information helpful?


[Yes]/[No]/[Maby]

[DESU]

Thanks!

Sleksa wrote:i dont know any java


Was this information helpful?


[Yes]/[No]/[Maby]

[can you repeat the question? you're not the boss of me now!]

On a related note.

I was having fun with a lab assignment (we were given 4 hours to create a temperature converter in VB, and the actual assignment took me about 10 minutes, so I started adding random things to it).

As part of one of those random things, I wanted to write each digit of a number of an arbitrary known length into an array of ints, essentially separating the number into its digits. I know I could convert the number to a String and get substrings, but I stubbornly wanted to do it mathematically.

The number was of the form xxx.x.

I coded it so that the number is multiplied by a multiple of 10 to get the digit I want in the ones place, and then to take that number modulo 10 and stick that in the relevant digit spot in the array.

It quite unexpectedly didn't work.

Was I doing something wrong? I'm not really a mathematical genius, so I may have needed to do something else.

The idea behind it is correct, not sure I can really say anything useful without the code (or an excessively large amount of description of the code), or at least in what way it didn't work, but there are a few issues I can think of.
First, the only numbers that can be accurately represented by a float are the ones produced by dividing a whole number by 2^n. Using only 1 decimal place, that still disincludes everything but .5. You might want to run it through rounding after making it a whole number, then store it as an int. I think that should eliminate this problem.
Second, don't forget to actually divide your number by 10 after storing the result of the modulus operation in your array. If its an int, as it should be, that will lop off the part of the number you are done with (the last digit), just leaving you with the rest.
Third, 1 and 2 is all I've got right now. But to make this one have a purpose I'll say that you also need to watch out for the bounds of your array, and make sure you are writing the values into it in the right order, and a bunch of other stuff like that.

And yah... I've gotten fairly comfortable with Java since this semester started. One class requires it, and the other its just easier to use one language.

All righty.

I'll just chalk it up to "VB sux" and join the other 15 or so people that had to take the idiot class in question in thanking diety/ies of choice that I'll never have to use that crap again.

Well, how the modulus and division operators work on the various numerical primitives is probably consistent across all languages.

It isn't.

Modulo of negative numbers may differ between different C/C++ implementations.

Normal division of two integers in Visual Basic returns a float IIRC, not an integer like in most other languages (at least in C, C++, C#, Java).

Small but important differences.

actually thats not true fo C++

int b = 5;
int c = 6;
int a = (b/c);

b/c is a floating point value which is then cast to integer by the compiler.

so int a = (b/c); is the same as in a = int(b/c);

Of course you'd say that it has no effect at all, but thats a simple calculation.

int b = 5;
int c = 2;
int a = (b/c*2);

Because b/c evaluates as a floating point number you get a = (2.5*2) and a is 5.

But if b/c was evaluated as you said as an integer by the compiler it would mean a = (2*2) and a would equal 4 (in C++ floats are always rounded down when cast as integers, anything smaller than 1 is truncated off the end).

In C++ any integers in a floating point calculation are converted to and kept as floating point until a conversion back to integer is necessary (an assignment operation or a function parameter for example.)

Erhm...
You're using a very strange compiler if a becomes 5.

AF wrote:actually thats not true fo C++

int b = 5;
int c = 6;
int a = (b/c);

b/c is a floating point value which is then cast to integer by the compiler.

so int a = (b/c); is the same as in a = int(b/c);

Of course you'd say that it has no effect at all, but thats a simple calculation.

int b = 5;
int c = 2;
int a = (b/c*2);

Because b/c evaluates as a floating point number you get a = (2.5*2) and a is 5.

But if b/c was evaluated as you said as an integer by the compiler it would mean a = (2*2) and a would equal 4 (in C++ floats are always rounded down when cast as integers, anything smaller than 1 is truncated off the end).

In C++ any integers in a floating point calculation are converted to and kept as floating point until a conversion back to integer is necessary (an assignment operation or a function parameter for example.)

Please go read a C++ book or read assembler output of your compiler, this is bullshit.

Integer division is integer division in C++
Float division is float division in C++

There is NO implicit conversion to float and back to int when dividing two integers!
In this example a is 4.

If you don't believe me try it and you'll see.

If you write it like this however: Then a is 5, because doing the multiplication first prevents the loss of precision that happens when doing the INTEGER division first.

This is also true in C, C# and Java.

huh? but 5 is the correct answer

bwah that's strange, I remember reading that in a C++ book too, I must have misinterpreted..

Must have been a bad book then

5 is correct answer in mathematics yeah, in integer calculations 5/2*2 = 4 and 5*2/2 = 5

In floating point calculations it may be something like 5.0/2.0*2.0=4.9999999 if you're unlucky.

And last but not least, in Excel 2007 is 850 * 77.1 = 100,000

NERD ALERT WEEOWEEEO

im in ur algos

fuxxoring ur radix sort

Tobi wrote:And last but not least, in Excel 2007 is 850 * 77.1 = 100,000 ;-)

Weird. 425*154.2 gives the same result but neither do 75*873.8 or 375*174.76.

Excel has no issue calculating the correct answer, its a purely visual bug, and any calculations based on those numbers will give the correct answer.

There are 12 such numbers in excel that will display as 100,000