dividing by 1 is a special case

04-29-2009, 03:38 AM	#1
Feroc1ty	JASS: call BJDebugMsg(R2S(209817650/1.00))

04-29-2009, 04:31 AM	#2
MaD[Lion]	wat is so special about it, dont just post code, not all can be arsed to test just 1 line.

04-29-2009, 05:20 AM	#3
PipeDream	Yes, floating point arithmetic is weird, particularly so because warcraft's implementation is broken. http://en.wikipedia.org/wiki/IEEE_fl...point_standard Several good references at the bottom. I don't know if it's technical or historical, but Kahan is sure to be interesting.

04-29-2009, 05:49 AM	#4
Feroc1ty	Apparently 209817650 divided by 1 is 209817648.

04-29-2009, 07:46 AM

akolyt0r

Quote:

Originally Posted by Litany

It's specific to reals, so 209817650 / 1. = 209817648. Unless you're directly comparing this probably isn't going to be an issue, but if you need something like 1. + .05 - .05 = 1., it sucks. Not only are the numbers off, but the two reals don't even cancel each other out. You can work around this to some extent by converting to strings and comparing those instead--for example, 1. + .05 = 1.049999952, while R2S(1. + .05) = "1.05"--but this will bog down your map if you do it a lot. Hooray for strings in WC3.

why not R2I(yourReal1*ACCURACY)==R2I(yourReal2*ACCURACY)...
or RAbs(yourReal1-yourReal2)<ACCURACY ..thats obviously a lot better than the massive usage of strings

04-29-2009, 10:48 AM	#6
akolyt0r	with a accuracy-multiplicator of 10 to 100 the R2I thing would work quite anyway ..and you dont need that much of accuracy anyway most of the time...

04-29-2009, 12:22 PM	#7
Toadcop	imo it's obvious... you can't store something in 32 bit and not to loose precision. (if it's not an 32 bit integer) so it just another

04-29-2009, 06:35 PM

Feroc1ty

Quote:

Originally Posted by Toadcop

imo it's obvious... you can't store something in 32 bit and not to loose precision. (if it's not an 32 bit integer)
so it just another

Dividing or multiplying by 1 is some srs business.

04-29-2009, 09:32 PM	#9
cosmicat	I think it has more to do with the fact that 209817650 simply can't be stored accurately in a 32-bit real. That is, perhaps it remains accurate if nothing changes, but dividing/multiplying by 1 is still an operation.

04-30-2009, 01:45 AM

#10

cosmicat

How is that surprising? That's about the same precision Java has, too. C++ is capable of more, but it's system-dependent while Java and Jass have to be portable (i.e. Warcraft has to show the same result for every user, C++ does not - necessarily).

What's surprising is that you folks aren't thinking in binary. 209817650. = 13113603*(2^4) + 2.

Dec(13113603) = Bin(101000000001010000000110010000001100100000011)

That's really amazing precision - at least 48 bits, which is surprising in a good way (I suppose it's possible that long strings of zeroes are represented by something other than long strings of zeroes to save bit space, which would bring down the precision a bit...).
So probably at least 3-7 bits are reserved for information about the location of the floating point and the power 2 to multiply the number represented by.

Compare:

###101000000001010000000110010000001100100000011
###1010000000010100000001100100000011001000000110010

Yep, assuming a certain amount of space is reserved for general information about the real itself, this is really pretty amazingly precise.

04-30-2009, 02:10 AM	#11
Mr_Saturn	I always assumed a real was a double. Goddamn floats.

04-30-2009, 03:15 AM

#12

PipeDream

Quote:

Originally Posted by Mr_Saturn

I always assumed a real was a double. Goddamn floats.

All warcraft types are dwords