Scripting Function: llPrecision()

A simple server side rounding function, to save us from constantly scripting it.

llPrecision(<float>, <decimal places>)

llPrecision would round a given float to the given decimal places, returning a float result. eg: llPrecision(1.2345678, 2) == 1.23.

Mostly handy for spewing (chat) info to users, scoreboards, etc.

Bos

Boso, I think you might have the definition of float slightly incorrect.

float llPrecision(float toRound, integer decimalPlaces);


Lets say you imput 1.58473 and 3

Your saying that the result will be 1.585, however, because it is a float, the result may as well be:

1.58499999999 or 1.5850000012

Thats really... what you get with the SL Float system.

I see the point in rounding float values, however, that could be done with simple math.

Not if llPrecision() returned a string, which is really the only time you'd want to chop a float like this, if you were using it for output.

Special bonus tip: here's how to very quickly round a positive float to a whole number

integer round(float in)
{
   return (integer)(in + 0.5);
}

and here's the more general version

float sign(float in)
{
   if (in >= 0.0) return 1.0;
   return -1.0;
}
integer round2(float in)
{
   return (integer)(in + sign(in) * 0.5);
}

No, the result would be 1.585. Because the server would be:
1. Rounding, until..
2. the precision decimal place is met.

You couldn't get 1.5850000012 from 1.58499999999. Nine does not round to two, nor to one.. well unless I'm doing the math, in which case anything is possible!

Wed has a point in having it return a string, as this is when such a function would be used. I know it's not hard to script, cuz I do it already. Just why have the script handle it when it could be a function (and I'd think an easy one to implement).

I use rounded/precision floats in a number of different things, and a scripted function that gives a precision isn't, I'd think, as efficient as an LSL function would be.

Bos

Edit: Opps just re-read your post Chris, I used the wrong value and I see what you're saying -- but still, given 1.587..whatever the number is, can't see your post when editing my reply).. anyway no matter what the value is, it's rounding the value you input.

1.23456
even if it uses 8 decimal places (1.23456000), it wouldn't round the zeros, it'd start at the "6". Unless it was poorly coded anyway to round zeros (assuming it tacks them on) to anything other than another zero.

If I input a float of "1.23456", and LSL doesn't consider that the value is:
1.23456000000...infinite_zeros
..then something is wrong with the code.

I'm not sure about this. Many languages use binary representation for the mantissa of floating-point numbers, and there isn't an exact equivalence for many decimal values. For the kind of accuracy you're asking for, LSL would have to implement BCD (Binary Coded Decimal), and I doubt it is.

Binary fractions! (well they aren't decimals, are they binarials?)

1 is 1
10 is 2
100 is 4
1000 is 8

.1 is 1/2 = 0.5
.01 is 1/4 = 0.25
.001 is 1/8 = 0.125

given an infinite number of digits you could create any decimal number. But computers don't use infinite digits. Instead they use exponential form with limited digits.

There is a base number such as 10001110 and an exponent such as 011 and a sign bit for the exponent such as 1.

We pretend that the first number is actually 1.0001110 and a 1 in the sign bit means the exponent is negative 3 so now the number is 0.0010001110.

In this example there are 12 bits being used so 2^12 distinct numbers. However the range of numbers is far greater than 2^12 because of the form used. The cost is precision.
I dunno if that will help you understand at all or not.