bj_CONSTANT_REALS

[tooltiperror]

call BJDebugMsg(R2S(bj_PI))

It displays 3.14159.

    constant real      bj_DEGTORAD                      = bj_PI/180.0

I'm fairly certain this will return 0.017, or even .01, because it does not go past hundredths. So is it better to just use [ljass]bj_DEGTORAD[/ljass], [ljass]bj_PI/180[/ljass], or [LJASS].01[/LJASS]?

 

[SineCosine]

self created constants ftw

 

[Romek]

> It displays 3.14159.
> it does not go past hundredths.


Use radians directly whenever possible. If you need a conversion, use [ljass]bj_DEGTORAD[/ljass], not [ljass]bj_PI / 180[/ljass].

 

[Nestharus]

[ljass]R2S[/ljass] not great for viewing reals. I suggest [ljass]R2SW[/ljass] as you can define the precision of the decimal places and see what is really going on with your numbers.

[ljass]real x[/ljass]
Range- -2147483647 to 2147483647

These can be in all the forms of integers and have the same range, but they can have decimal places. They are dropped down to 4 decimal places when they pass in between functions. They round to 3 decimal places when they are displayed. Globals are dropped down to 4 decimal places. Locals maintain absolute accuracy in increments/decrements of 2147483647 or 32 bits, meaning you could have an n bit real number.

[ljass]real x = .999999999[/ljass] displays 1.000
[ljass]real x = .999499999[/ljass] displays 1.000 (the 9 rounds 4 up to 5, which rounds up)
[ljass]real x = .999399999[/ljass] displays .999



Keep in mind that the range isn't from those small numbers to those huge numbers, but it's an absolute range. For example, your range might be this if you wanted 9 decimal accuracy-
-2.147483647 to 2.147483647

Reals can only go out to 9 decimals as there is always a 0 in front.
0.999999999

Reals maintain absolute accuracy while inside of a given function.

 

[SineCosine]

But [lJASS](0.(9) == 1) == true[/lJASS] ._.

 

[Lehona]

Doesn't use Warcraft 3 the 32 bit IEEE 754 floats standard? I thought everyone used it in that time...

That would mean its actually 1 bit sign (negative/positive), 8 bit exponent and 23 bit mantissa (In reality its ((-/+) mantissa * 2^exponent)).

That would mean the range 9 decimal accuracy isn't ~(-2) - 2 - though it would have a loss accuracy... :/

But probably I'm just talkin' shit here.

 

[Nestharus]

I can't even get 0.(9) to compile...

and [ljass]0.9 == 1[/ljass] returns false

 

[SineCosine]

1/3 = 0.(3)

so..
Try this?

real OneThird = 1/3
real PointNine = 3 * OneThird

if PointNine == 1 then
    BJDebugMsg("0.(9) = 1");
endif

XD

 

[Jesus4Lyf]

1/3 = 0.(3)

so..
Try this?

real OneThird = 1/3
real PointNine = 3 * OneThird

if PointNine == 1 then
    BJDebugMsg("0.(9) = 1");
endif

XD

It has previously been proven that the opposite is true.
If you make the value of a real slightly inaccurate, we have seen it round down in the past.
IE. Something like some int * 10.0 / 10.0 not equaling the original int. There was a thread about it because of something someone was doing in GUI.

 

[SineCosine]

Aw..
Darn. xD

 

[Troll-Brain]

No it's only because 1/3 == 0. , since it considers "1" and "3" as integers.

local real r = 7/2 // 3.

but do that instead : "1./3" and your if will be true.
"==" works like an offset error it rounds up the difference (3 numbers under the digit taken in consideration or so), where >= and <= not, or at least with more digits.