Stupid inequality!!

Here's a really simple function that I wrote because I've been scaling a set of numbers for graphing.

float tempnum;

integer nexthighest(integer num)
{
    integer i=1;
    while(num/i >= 10)
        {
            i = i * 10;
            tempnum = num/i;
        }
    return ((integer)(tempnum+1) * i);
}

If I feed it, say, the number 45, it spits back 50. If I give it 6789, it gives me 7000. That's what it's supposed to do. I decided to put in a failsafe, just in case I fed it a number too large to handle, so I modified the function to look like this .....

integer nexthighest(integer num)
{
    if (num < 10000000000)
    {
        integer i=1;
        while(num/i >= 10)
            {
                i = i * 10;
                tempnum = num/i;
            }
        return ((integer)(tempnum+1) * i);
    }
    else
    {
        llSay(0,"Number is out of range.");
        tempnum = 0;
        return ((integer)tempnum);
    }
}

Now, if I feed it 45, or 6789, or ANY positive integer, it gives me the error message, "Number is out of range." However, if I reverse the inequality and test for num > 10000000000, it works fine.

I feel so dumb. What am I missing here?

We only have 32 bits integers: (2^33)-1=8589934591<10000000000
actually the highest positive integer is smaller:2147483647
http://lslwiki.net/lslwiki/wakka.php?wakka=integer

OK.... I had momentarily forgotten that. Yup... changing that by a couple of orders of magnitude makes it work like a charm. Thanks, Dora.

What is your function doing?

return (integer)((num / 10.0) + 0.9375) * 10;

rounds up to the nearest factor of 10, -20 --> -1

you can multiply 0.9375 by (1 | num >> 31), if you want all numbers rounded away from zero, or multiply 10 by (num > 0) to fix all negatives to 0.

Now THAT's cool to know. I wouldn't have thought of that. Thanks.

If I have a set of values to graph, I was annoyed by the fact that my graph always set the maximum on the axis equal to the largest value in the set instead of something nice and round. If the largest value was 78, for example, I wanted to set the maximum on the axis to 80 for graphing purposes. It makes it easier to get tick marks at places that don't look totally stupid. Hence, the function. Now that it works (Thank you again, Dora), it looks like this ....

float tempnum;

integer nexthighest(integer num)
{
    if (num < 100000000 & num > 0)
    {
        if (num <= 10)
        {
            return (10);
        }
        else
        {
            integer i=1;
            while(num/i >= 10)
                {
                    i = i * 10;
                    tempnum = num/i;
                }
            return ((integer)(tempnum+1) * i);
        }
    }
    else
    {
        llSay(0,"Number is out of range.");
        tempnum = 0;
        return ((integer)tempnum);
    }
}

I had a feeling that there was some cool way to do what you wanted done such as the one Void suggested, not that I had the slightest idea what it was. I was thinking about logarithms and exponents and such.

Yeah, that was my first inclination too, but my mind is too brute force for fiddling with exponents for a silly task like this that should only need simple arithmetic. I do like Void's method, though. I wish I could think of things like that.

habit of seeing them so often... integer math is all about abusing numbers

simple way to look at it,take your normal range of values, what theyd be if you divided them by your segment normally, and then add just enough to bump them over the next value (or under the previous), and flatten it by converting to integer.

you can also do the same trick with modulus, get the portion you are over the last segment, subtract it from the segment, and add the result back

num + (10 - num % 10) //-- ps this is probably faster

or round down to your segment
num - num % 10

so how do you come up with these imaginative methods of pushing the numbers around?

don't look at the number itself, look at how much it needs to change by to get the result you want from it.

I was going to pretend this wasn't just for the fun of obfuscation but, yeah, ok, I wouldn't lie to you, this is just for the fun of obfuscation:

return (integer) (((string) ((integer) llGetSubString((string) Thing, 0, 0)) + 1) + llGetSubString("000000000000", 0, llStringLength((string) Thing) - 1));

cute, but doesn't that round up to the next power of 10 even if it's already at a power of ten?

ETA
oops no, just when it's at a 9 leading power of ten
ETA2
and fails on things under ten except 9

My ... brainnn ... hurtzszszssss.

Oh there's lots of things wrong with it, won't work for negatives or scientific notation either, but it's a fun way to "look at how much it needs to change" and was inspired by your quote. TO the extent that it works, it works as intended, but it wasn't intended for use.

(at least some of this and my previous post makes sense. Sorry, I'm in a funny mood)

If you're looking for scaling factors:

fBase = llPow(10.0,llFloor(llLog10(fNumber)));
fNextDivision = llCeil(fNumber / fBase) * fBase;

If you're dealing with graphs/charts, the logarithm/exponential functions are very good things to know.

Thanks, Talarus. If I were dealing with values that range over several orders of magnitude, especially, it would make great sense to graph them logarithmically. It's good to remember that LSL has that capacity.

I LOVE it when a simple question yields so many cool options.