# Category talk:LSL Integer

Are these numbers correct? "values between −2,147,483,648 and +2,147,483,647" . And if they are why the difference between the figures? -- **Eddy** ^{(talk|contribs)} 17:30, 27 June 2009 (UTC)

- Aye correct as saved.

- This truth makes more visual sense in hex. A 32-bit two's complement integer is 0x0, or +0x1 thru +0x7FFFffff, or -1 thru -0x7FFFffff, or -0x80000000. In decimal, that is 0, or 1 thru 2147483647, or -1 thru -2147483647, or -2147483648. The assymetry comes from the zero: both positive integers and zero have the uppermost most bit of the 32 bits zeroed, so the list of positive values loses one element to make room for zero.

- A correspondingly counterintuitive result here is that negating -2147483648 has no effect (-2147483648 == ( 0 - -2147483648 ) == ( 2147483647 + 1 ) ). Ugly as all this is, it's less ugly than the known alternatives, such as the one's complement encoding that can have two zeroes: a positive zero and a negative zero. All that I'm saying here is the convention I remember learning years ago, I imagine LSL behaves this way at these limits, but I haven't tried to see yet ... -- Ppaatt Lynagh 18:10, 27 June 2009 (UTC)

- Thanx Ppaatt. I thought it might be a zero issue but didn't get as far as thinking that (of course) there would have to be (as you say) two zeros for the reach (both pos and neg) to be equal. "Positive Zero". Sounds like a good title for a science fiction novel. Cheers Ppaatt. --
**Eddy**^{(talk|contribs)}18:16, 27 June 2009 (UTC)

- Thanx Ppaatt. I thought it might be a zero issue but didn't get as far as thinking that (of course) there would have to be (as you say) two zeros for the reach (both pos and neg) to be equal. "Positive Zero". Sounds like a good title for a science fiction novel. Cheers Ppaatt. --

- In addition to (--2147483648 == -2147483648) so does (-1 * -2147483648). Everyone knows that 1/0 causes a fatal error in integer math but what few people know is that (-2147483648 / -1) does as well on x86 processors (modulo is equally affected). I have yet to find any mention of this on the internet (except where I have posted it), I found it by accident while exploring edge cases (it crashed the sim). In LSL we papered over the exception, any time you divide by -1 we just apply the "-" operator, and for modulo -1 we just return 0. --
**Strife**^{(talk|contribs)}09:27, 29 June 2009 (UTC)

- In addition to (--2147483648 == -2147483648) so does (-1 * -2147483648). Everyone knows that 1/0 causes a fatal error in integer math but what few people know is that (-2147483648 / -1) does as well on x86 processors (modulo is equally affected). I have yet to find any mention of this on the internet (except where I have posted it), I found it by accident while exploring edge cases (it crashed the sim). In LSL we papered over the exception, any time you divide by -1 we just apply the "-" operator, and for modulo -1 we just return 0. --

- *insert foot in mouth* http://www.codeguru.com/cpp/sample_chapter/article.php/c11111__3/ --
**Strife**^{(talk|contribs)}10:00, 29 June 2009 (UTC)

- *insert foot in mouth* http://www.codeguru.com/cpp/sample_chapter/article.php/c11111__3/ --

lolz (although not at the fact that you can do "Integer math". Now I have to relearn stuff *slumps*). -- **Eddy** ^{(talk|contribs)} 10:03, 29 June 2009 (UTC)

## Sub-classification Constants/Functions

I thought I'd take a quick peek at possible Integer-related Functions. A sea of Constants greeted me. Is a Sub classification perhaps useful? --Vernes 00:43, 8 January 2010 (UTC)

- LSL in Focus: Integers classifies how integers are used in LSL, and might be what you are looking for. The uses are: signed integers, truth values, enumerations and bit vectors. I think every LSL integer constant clearly falls in exactly one of these four categories.--Omei Turnbull 03:28, 8 January 2010 (UTC)

## Editing this wiki

The first sentence on this page reads "An integer data types are signed 32 bit values [...]"; I think this should read "The integer data type is a signed 32 bit value [...]". Is it ok for me to make relatively minor gramatical corrections to errors like this without consultation, or should I flag my suggestion here first? Pete Olihenge 12:19, 26 January 2010 (UTC)

- Hi Pete, it is always OK to make the wiki better! We are all editors. It is good to have a thick hide here, stand your ground and have your facts on file if you are challenged ;) --Cerise Sorbet 13:49, 26 January 2010 (UTC)
- Thanks Cerise. It is done, and I have my tin foil hat at the ready :) Pete Olihenge 13:57, 26 January 2010 (UTC)
- Looks better already. Don't worry about making mistakes, we all make them, and we will all help fix them. As it turns out, since I've been a major contributer of content, a good portion of the mistakes you will be fixing were mine. Sure I take pride in my work, but I take more pride in ensuring that the wiki is the best it can be; whether my contributions stand or fall is of no matter as long as things improve. Contributions can take on several forms, especially after editing: It can be what is written on the page, the ideas on the page but not there form, the form but not the ideas, the layout, the interconnections, the corrections, the usability. None of us control the destiny of the content we contribute, we control not the final form.

- Thanks Cerise. It is done, and I have my tin foil hat at the ready :) Pete Olihenge 13:57, 26 January 2010 (UTC)

- We operate on the same ideals as Wikipedia and similar guidelines. So without further ado I'll point you to a Wikipedia article that answers your question better than I can. Wikipedia:Be bold --
**Strife**^{(talk|contribs)}14:50, 26 January 2010 (UTC)

- We operate on the same ideals as Wikipedia and similar guidelines. So without further ado I'll point you to a Wikipedia article that answers your question better than I can. Wikipedia:Be bold --

## check if a string contains valid integers

The category tab shows a function to determine whether a string of characters consists only of integers. The following would also check that, but I've never yet added anything to this wiki, so added this here for comments

if ((string)((integer)(input)) == input) { llSay(0, "The input contains only valid integers"); }

Avi Savira 17:06, 30 October 2011 (PDT)

- Both methods fail on a signed positive integer ("+1234"), but this seems to be way more efficient. If you do put it into the main page, it'd probably be best to do so as a function. Pete Olihenge 08:30, 1 November 2011 (PDT)

Try this :

<lsl> integer IsInteger(string myInteger) {

integer i = (integer)myInteger; string temp = (string)i; return (temp == myInteger)||( "+" + temp == myInteger);

} </lsl> I don t know why the main page hints to check each number inside a list . It seems very inneficient