Difference between revisions of "Category talk:Variables"
Jump to navigation
Jump to search
→Overhaul
imported>Scruggs (variables are not stored as integers.) |
imported>Haama |
||
| Line 41: | Line 41: | ||
::::<s>I've done some more tests, and am pretty sure ([s]for CS/OB v1.2[/s] Seems to be the same for CS v.8 and OB v1.0--[[User:Haama|Haama]] 20:54, 6 April 2008 (EDT)) that: | ::::<s>I've done some more tests, and am pretty sure ([s]for CS/OB v1.2[/s] Seems to be the same for CS v.8 and OB v1.0--[[User:Haama|Haama]] 20:54, 6 April 2008 (EDT)) that: | ||
#All variables are 32-bit | #All variables are 32-bit | ||
# | #All script variables are the same, and they're all ''longs''. The stored value is accurate to 2^31, so the range is -2,147,483,648 to 2,147,483,647. This was tested by storing the value with [[Set]] and printing it out with pluggy's [[IntToString]]. (and corrected below --[[User:Haama|Haama]] 19:35, 6 April 2008 (EDT)) | ||
#Scripted Shorts, Scripted Longs, and Scripted Ints are treated as Int32 variables. The stored value is accurate to 2^31, so the range is -2,147,483,648 to 2,147,483,647. This was tested by storing the value and printing it out with pluggy's [[IntToString]]. | #Scripted Shorts, Scripted Longs, and Scripted Ints are treated as Int32 variables. The stored value is accurate to 2^31, so the range is -2,147,483,648 to 2,147,483,647. This was tested by storing the value and printing it out with pluggy's [[IntToString]]. | ||
#Scripted Floats are treated similar to Singles. They are accurate, as floats, up to 2^20 (Estimated range -104857.6*10^n to 104857.5*10^n). Past that point they are treated as Int32s. Tested the same way as shorts above. | #Scripted Floats are treated similar to Singles. They are accurate, as floats, up to 2^20 (Estimated range -104857.6*10^n to 104857.5*10^n). Past that point they are treated as Int32s. Tested the same way as shorts above. | ||
#*Note, however, that is the ''stored'' precision. Once a float value is used in a function it will lose some precision. | #*Note, however, that is the ''stored'' precision. Once a float value is used in a function it will lose some precision. | ||
# | #All global variables are the same, and they're all ''floats''. The stored value is accurate to 2^24 so the range is -16777215 to 16777216 (in testing, it was accurate to 16777216 but not 16777217, so I'm sure about the positive side - not sure why the 0 is on the negative side for these variables). Note that the full 32 bits are used, and 2147483647 will be stored as -2147483648. Tested the same way as above.--[[User:Haama|Haama]] 23:40, 5 April 2008 (EDT) | ||
#All globals are similar to Scripted Floats. They are accurate, as floats, up to 2^20 and are treated as integers after that point. However, they are limited to 24 bit precision, so their (accurate) range is limited from -16777216 to 16777215.</s> | #All globals are similar to Scripted Floats. They are accurate, as floats, up to 2^20 and are treated as integers after that point. However, they are limited to 24 bit precision, so their (accurate) range is limited from -16777216 to 16777215.</s> | ||
::::Oops, was thinking of the wrong script when I did the float tests. I'm simply striking everything above, as editing it would be too messy. I assume that they're accurate to 2^24 or 2^23, but I can't run the tests now. More later--[[User:Haama|Haama]] 15:09, 7 April 2008 (EDT) | ::::Oops, was thinking of the wrong script when I did the float tests. I'm simply striking everything above, as editing it would be too messy. I assume that they're accurate to 2^24 or 2^23, but I can't run the tests now. More later--[[User:Haama|Haama]] 15:09, 7 April 2008 (EDT) | ||
: Some of this information is incorrect. As mentioned previously, all script variables except ref are stored internally as doubles - i.e. 64-bit (double-precision) floats. For example, a short, long, or float containing the value 65535 is not stored as 0x0000FFFF but rather 0x40EFFFE000000000. Ref is a special case in that the 64 bits are treated as a 64-bit integer; a ref variable holding the refID 0106C4FD is stored as 0x000000000106C4FD; this is done to avoid loss of significant digits when down-casting to a 32-bit float. [[User:Scruggs|Scruggs]] 15:56, 7 April 2008 (EDT) | : Some of this information is incorrect. As mentioned previously, all script variables except ref are stored internally as doubles - i.e. 64-bit (double-precision) floats. For example, a short, long, or float containing the value 65535 is not stored as 0x0000FFFF but rather 0x40EFFFE000000000. Ref is a special case in that the 64 bits are treated as a 64-bit integer; a ref variable holding the refID 0106C4FD is stored as 0x000000000106C4FD; this is done to avoid loss of significant digits when down-casting to a 32-bit float. [[User:Scruggs|Scruggs]] 15:56, 7 April 2008 (EDT) | ||
::Forgot to mention that part; it is incorrect - I'd based the above on the assumption that the new Pluggy [[LC]] function worked at Double-precision, but it works on Int32 instead. Striking the whole thing now (the second strikeout undid the nested ones.)--[[User:Haama|Haama]] 16:05, 7 April 2008 (EDT) | |||