int is useless

[Tyhm]

int (-1.5) returns -2, not -1.
int(262143/32768) (which is 7.999969482421875) returns 8, not 7.

This is, understandably, brutally murdering all my attempts to script.

[Tyhm]

In case anyone else is having this problem:

function trueInt(){
setstring DammitStefan,#v(intThis);
intThis=strtofloat(#e(0,indexof(.,#s(DammitStefan) ),#s(DammitStefan)));
}

[xXziroXx]

Originally Posted by Tyhm

int (-1.5) returns -2, not -1.

This is, understandably, brutally murdering all my attempts to script.

int() rounds decimals down, and thus -1.5 becomes -2 in the same way 1.5 would become 1. If it bothers you that much, you can always abs() it prior do the int().

[Loriel]

Originally Posted by xXziroXx

int() rounds decimals down

[xXziroXx]

Originally Posted by Loriel

Right.

[Deas_Voice]

Originally Posted by xXziroXx

int() rounds decimals down, and thus -1.5 becomes -2 in the same way 1.5 would become 1. If it bothers you that much, you can always abs() it prior do the int().

returns 7.999969482

[xXziroXx]

Originally Posted by Deas_Voice

returns 7.999969482

I never replied to the 7.99adjhafgafe whatever, now did I?

[Deas_Voice]

Originally Posted by xXziroXx

I never replied to the 7.99adjhafgafe whatever, now did I?

uhm.....
no?
so what?

[Loriel]

Whatever, int()'s behaviour is obviously inconsistent, it does not work like C's int casts or floor(), and if there is any documentation that explains its behaviour I must have missed it in the past couple of years.

Unless you can explain how to use int() to get the effect that Tyhm is achieving with his horrible string manipulation abomination, stop trolling.

[DarkReaper0]

Originally Posted by xXziroXx

I never replied to the 7.99adjhafgafe whatever, now did I?

No, but if you paid attention you'd realize not recognizing that point 'brutally murdered' your response.

[LoneAngelIbesu]

From my experiences with PHP, when using fractions, you might lose float point precision because it's impossible to express some fractions in a finite number of digits. This commonly affects the use of intVal(), which is the PHP equivalent to GS2's int().

From PHP.net website:

Warning
Floating point precision

It is typical that simple decimal fractions like 0.1 or 0.7 cannot be converted into their internal binary counterparts without a small loss of precision. This can lead to confusing results: for example, floor((0.1+0.7)*10) will usually return 7 instead of the expected 8, since the internal representation will be something like 7.9.

This is due to the fact that it is impossible to express some fractions in decimal notation with a finite number of digits. For instance, 1/3 in decimal form becomes 0.3 (repeating).

So never trust floating number results to the last digit, and never compare floating point numbers for equality. If higher precision is necessary, the arbitrary precision math functions and gmp functions are available.

Note: floor() is a PHP function that rounds a number down to the whole number closest to zero... which is probably closer to GS2's int() than intVal(), since intVal() accepts a base (defaults to base 10) parameter.

[Loriel]

Originally Posted by LoneAngelIbesu

From my experiences with PHP, when using fractions, you might lose float point precision because it's impossible to express some fractions in a finite number of digits. This commonly affects the use of intVal(), which is the PHP equivalent to GS2's int().

From PHP.net website:


Note: floor() is a PHP function that rounds a number down to the whole number closest to zero... which is probably closer to GS2's int() than intVal(), since intVal() accepts a base (defaults to base 10) parameter.

Nice theory, except booth floor and intval get 262143/32768 right.

[LoneAngelIbesu]

Originally Posted by Loriel

Nice theory, except booth floor and intval get 262143/32768 right.

In PHP, maybe. We're talking about GS2 here, so we have to assume that it's going to screw up easily with large decimals, as seen when it can't correctly subtract 8 from 7.999969482. Obviously, it's rounding 7.999969482 to 8, which is also why int(7.999969482) returns 8 instead of 7.

I did a quick test on RC. int(7.999) returns 7, but int(7.9999) returns 8. int(7.9998) returns 7, as well as int(7.999899999). Considering that 7.9999 and 7.999969482 have one thing in common, it's safe to assume that when Graal sees ".9999", it'll round up to the nearest whole number.

Originally Posted by Tyhm

I'd love to, but it's difficult to determine if the bitflag 262143 contains 32768 (2^15th) or not without doing a little division.

What are you trying to accomplish, exactly? Perhaps if you showed us the problem in context, somebody might be able to figure something out (unless you're fine with using your work-around).

[Tyhm]

Bee Ess. Any language that thinks 0.1+0.7=0.79 is not a language worth trusting.

[LoneAngelIbesu]

Originally Posted by Tyhm

Bee Ess. Any language that thinks 0.1+0.7=0.79 is not a language worth trusting.

It's probably more complex than you think it is. PHP is a very good language. The point I was trying to make, though, was that you should try and not use non-terminating decimals, or at least round them to terminating decimals.

Using large decimals is bound to cause problems. For instance, in GS2 "7.999969482 - 8" produces 0. But, "7.99 - 8" produces -0.01. So, I wouldn't say that int() is useless. It just faces the same problems that other languages face when it comes to floating points.