Jump to content

Why does this always return 0.0000%?


Life Camino
 Share

You are about to reply to a thread that has been inactive for 3471 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

I figured out that I needed to use float values for all the elements.  But, it still makes no sense to me that I should be required to use float values for all the elements.  If you divide an integer by a larger integer, you get a float value - but, not in this case.  For some strange reason, in LSL, you must treat all the elements as floats.  That is what is counterintuitive.

I understand that I broke a rule.  It's just that I don't think the rule makes any sense - because, it is not mathematically sound and is counterintuitive.

Link to comment
Share on other sites


Life Camino wrote:

I figured out that I needed to use float values for all the elements.  But, it still makes no sense to me that I should be required to use float values for all the elements.  If you divide an integer by a larger integer, you get a float value - but, not in this case.  For some strange reason, in LSL, you must treat all the elements as floats.  That is what is counterintuitive.

I understand that I broke a rule.  It's just that I don't think the rule makes any sense - because, it is not mathematically sound and is counterintuitive.

Nope, it's all like it should be and it makes sense.

Otherwise it is impossible to do integer math. If you don't need that - that doesnt mean that nobody else needs it. :D

At the moment the scripter has full control of what and how it is calculated, so it's exactly like it should be.

Link to comment
Share on other sites


Life Camino wrote:

"
Because an integer divided by an integer times an integer is an integer"

 

No, it isn't.  That is why this was causing me grief.  It was counterintuitive for the functions to require float values for all elements.

Well, yes it is an integer. The default type for a constant absent a decimal point is "integer". So, here's the default interpretation (for many (most?) computer languages)...

float percent_used = ((integer)7887/(integer)15000) * (integer)100;

Casting the result to float does not, and should not, override the default integer typecasting. One could argue that, for a static constant construct like this, where everything is known at compile time, there's no penalty for performing float arithmetic. But if the numbers in question had been variables, there could be a significant penalty for doing floating point computations instead of integer at run-time. That's the reason the compiler doesn't promote to float in this situation.

Now, using your logic, if you wanted an integer result, how would you get it. Where would any truncation occur?

Take 4/10*3, for example. If you promote to float, then cast to integer, the result is 2 (the integer expression of 2.4). If you leave everything as integer, the result is 0 (because 4/10 is zero). If the result you desired was zero, how would you get it?

There are a lot of things in this world that are counterintuitive. That doesn't mean they're wrong.

;-).

Link to comment
Share on other sites

Well, it's nothing uniquely weird about LSL. Integer arithmetic is simply different from floating point, not wrong. It's perfectly valid -- and often desirable -- to divide two integers and get an integer result. The type specified to hold the result of a string of calculations doesn't contaminate all the intermediate values calculated. I guess it could work that way but it would take a whole lot of llFloor()s to recreate integer arithmetic that way.

Link to comment
Share on other sites


Qie Niangao wrote:

Well, it's nothing uniquely weird about LSL. Integer arithmetic is simply different from floating point, not wrong. It's perfectly valid -- and often desirable -- to divide two integers and get an integer result. The type specified to hold the result of a string of calculations doesn't contaminate all the intermediate values calculated. I guess it
could
 work that way but it would take a whole lot of llFloor()s to recreate integer arithmetic that way.

Had it worked that way, a lot of early computers would have been huffing and puffing to do even the simplest tasks. Floating point hardware (which has its own mathematical peculiarities) hasn't always been available. My first Mac had no floating point hardware, and floating point math (emulated by libraries of integer code) was 100x slower than integer. I'd hate to pay that penalty for stuff that could be done well by integers.

And, if everything were promoted to float, how would you do 384&256?

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 3471 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...