Check if integer is bigger OR smaller

and a bitwise and literally compares the bits in one operand with the other and returns those (set) bits that match... does it equal a specific value assinged to true or false? no, but then LSL uses a construct of 0 = false and all else = true, for better of worse, because ther are no actual boolean values in lsl. even going as far as saying TRUE = 1 for portability is going to cause you issues when you run across a language like VB that uses a 16bit -1 = TRUE


I certainly mind them less by example, but I think it's deeper than that. given the above case as an example it's a stated behavior in lsl that any non-zero value in an integer evaluates to true in a test... that's not an implication, it's a feature of how tests in lsl are executed. no types are being converted as are in languages like PHP, so I don't see it as implied in any way. while one might consider that int * flt implies a cast, I also know that LSL treats those combined types as floats, in any order, though I'm aware some languages would use the last given type for conversion, or in still other produce an error. I'm ok with that though because I do know that it works, and if it comes down to portability I'd see I have two type and toss in a cast. but in other cases I'm very careful to be explicit and declare because the know the language will treat it differently. vectors for instance...


but in truth that's not the whole story, since the compiler takes what is written and converts it using it's own optimizations (or lack thereof), etc on down to the cpu.... but in truth, implicit or explicit doesn't matter if the person KNOWS it is going to occur.


I'm not sure how you got debasing of your experience out of the disagreement, I only said that my experience was different on some points.

No, it is a boolean algebra operation, much like multiplication is to normal arithmetic. It wasn't originally designed to "compare bits"; it was designed as an algebraic function taking two inputs and returning an output based on a truth table. It has functionality far more diverse than simply comparing two bits to see if they match. It turns out that it works pretty good for that, too, which is why people use it for that.



I know; I consider the language "broken" for that reason, too. It predefines "TRUE" as the integer value "1" all by itself. That VB example actually illustrates one of my points.



Actually, the fact that integers are treated as booleans IS implicit in the language design itself. You CAN'T explicitly cast them, because, as you said, they don't exist! Sure, it is a well-known implication, but it still is an implied behavior.



I dunno. I remember having to solve some issues with LSL in the past where an implicit conversion involving mixed types resulted in a truncated float value. Since I don't leave that to chance anymore, I don't recall what it was, but if I can remember or run across it again, I'll post the sample code that caused it.

In short, I don't trust it (more specifically, I don't trust LL to not muck it up), so I explicitly cast anyway.



That's orthogonal to the point I was making. When you make assumptions about defaults and implicits (which is the nature of defaults and implicits), those assumptions may be wrong, and they can change. If you assume the computer "knows what you mean", then you're likely going to get in trouble over it at some point (even if you "KNOW" it is going to occur). Whereas, if you always EXPLICITLY tell the computer what you mean, in as unambiguous and nonequivocal terms as possible, you essentially remove a level of uncertainty from the "correctness" of your code, and will run into fewer problems as a result over the long term.



Well, when someone tells me that some rather important methodologies that I have learned over the years are nothing more than a "matter of style", it sure sounds rather debasing. It isn't a matter like whether or not curly braces belong on a line by themselves. There are valid concerns here, and I think it is fair to air them as such.

but it's ACTION in every language that I know of is a bitwise comparison... it breaks each number down to it's base 2 bits, and compares them returning the (set) bits that match....
10 & 12 = 8 is of very little use algebraically until you know it's 0x1010 & 1100 = 0x1000


I see the boolean operators as functions, 0 and 1 just being return values... they could just as easily be different values like -1 and 3, but they aren't, because 0|1 fit's well with the evaluation process. I can't even imagine a reason for LL to modify those returns. from my side of this the only actual implication isn't the behavior, but how a person is looking at it. I personally don't even see booleans, only possible return values and how they'll be evaluated.


I don't feel that relying on core behaviors is implicit, especially after observing them in action, and testing them. abstracting them to untested types or presuming they work as they do in other languages without that knowledge... I 'll agree that's not wise.

in the case of boolean operators and their returns I'll expect them not to muck it up, if only because it's core behavior stemming all the way from C, and the minor fact that it'd break 99% of content in existence, I still make sure to use explicit casts on other types like lists and vectors and rots, simply because they're behavior isn't as stable in the historical or damaging sense... and that may just be paranoia on my part, but I feel it's justified to some extent by LL's past actions.


I'll chalk that up to a failure of language, I consider methodologies to be a part of a persons style. all of which are adopted to address concerns as each person see them, whether they be as minimal as visual ease, or deeper as in the case of portability. neither is ephemeral, they only address different things at different levels.

Sorry to interrupt, but I just want to thank you both as a non-IT professional. I can't pretend to understand all the finer points of your arguments, but I appreciate having the chance to hear them. You've given me things to think about as I write my own scripts.

I'll count that as a success regardless of which conclusions you come to...

unless you think we're both nuts in which case we'll have to gang up you =) j/k

It also is used for masking, it also is used for more complex logical equations, such as for encryption, it also can be used for domain/set membership determination, and many other specific functions.



I see them as expressions, which generate boolean set members TRUE and FALSE, according to the mathematical / set theory model. How they are represented by any particular language is of little consequence, as long as the language provides a way to properly abstract them back to their theoretical representation. When you start down the road to manipulating the specific representations, rather than the actual meaning of those representations, it makes it more difficult to recognize and process the abstractions at the level of algorithms.

The particular choice of 0|1 as representations is local to the language, and varies (even within the same language). In truth, C (and C-like languages like LSL) uses the representation 0|!0, which is actually indefinite. In boolean algebra, there are only two definite values; assigning multiple values as a representation for the meaning of one boolean value complicates matters. For example, how do you go about safely adding the "boolean" result of an expression to a bitset? Don't you find that it is a little obtuse?

Other languages use all kinds of different ways to represent boolean values. Depending on the specific values of the representations not only can lose meaning, but can also make algorithms developed from that dependency non-portable and more difficult to maintain.



Core behaviors is tangential to the issue of whether something is implicit or explicit in function or representation.



..and I would rather "play it safe", among other benefits in the practices I find useful.

I'm not too worried about breakage if they "muck it up". We're primarily talking about language and compiler behavior here; compiled code out there won't change if they change the compiler in this way. REcompiling existing code might be problematic, but at least it can be dealt with at that point.



There are some methodologies (or aspects of same) which are a bit more universal in scope, approach, and effect. I don't think I would say that such considerations are a matter of "personal style", because they transcend the person. Take for example your point about speed/space efficiency. I don't find it any more a "matter of personal style" than I find maintainability/readability/scalability/portability. How we each address each one of those aspects may define our "personal style", but those considerations themselves are not matters of such.

I can't speak for anyone else, but I'm definitely a TRUE member of the Set of Nuts. <.<

The Operators page on the wiki could really use completing...
https://wiki.secondlife.com/wiki/LSL_Operators

I could sear I replied to this, but the forum or the net may have eaten it, or maybe I was too fast closing the window or something but anyway, the short version follows since Strife rightly reminded me (or anyone else that wants to have a go at it) that there were threats/ideas tossed about for cleaning up the Operators wiki page, and time spent there will probably be more useful to everyone...


all predicated on what it's literal action is though...


well I can see why that might bother you then, since they not only aren't they converted to actual boolean members, but aren't really boolean members at all. I personally find it easier to think of them as their literal evaluations and how they run programatically ex...
if (some test result == 0) then goto next
;do stuff if it was != 0
goto end
label next
;do stuff if it was == 0
label end

because as you pointed out, LSL (and C) evaluate on a basis of 0|!0. the fact that there is no indeterminate value available in the integer number system (of two's complement anyway) just necessitates picking a value that fit's the criteria of the evaluation... 0 is obvious, 1 is just a convenient stand in that makes a certain mathematical sense and eases certain operations.


(test using boolean operator) * bitmask ?
(test using non boolean operator != 0) * bitmask ?


I would hold that nothing operates outside the context of it's application. we're talking about what and why we do, but anything we "do" or even choose "not to do" has personal context through that decision. the consideration of "why/why not" and the value attached makes all those decisions personal... we all value each consideration differently and often in comparison to other considerations... each value we assign is personal. in short no offense was meant by "style, it was only intended as a placeholder for the differences between two sets of considered valuations.

now i'll run off and think of interesting ways to group the mass of operator information that's possible for the LSL portal... maybe build a few sub pages and get input before I attempt the shift to multiple sub page groupings.

I only have one comment on the explicit/implicit debate and, because I'm feeling snarky, it will be in the form of an LSL comment you should place in front of any use of implicit behavior...

// I am relying on LL to not bork the following line of code

lol... although that comment does fail the portability discussion, it's still damn funny

No, it's the other way around, actually. The literal action is a boolean AND function over a set of bits. How it is used is an expression of that literal action to perform a task to obtain a result, not the other way around.



Correct, they are "shortcutted", which leads to problems in analysis and implementation.



Well, when one has to keep multiple different languages that one uses frequently straight in one's head, one generally has to resort to the most universal mathematical models and implement from there. It also makes it easy to make one's code portable between those different languages should one have the opportunity and desire to do so.

How any particular high-level language compiler translates a mathematical construct to literal machine code should be subordinated below what is exposed to the programmer. Otherwise, what is the point of a high-level language?

Since we both know that many high-level languages allow the programmer to muck around with things that they shouldn't need to be concerned with (for whatever reason), I find it invaluable to still render code aligned to the models and constructs. However, I am not blind to the fact that the strictest adherence to such convention may not be optimal, and am willing to compromise where necessary and practical. However, in all other cases, I will stick to convention.

Your argument that ALL cases are necessary and practical (that optimal efficiency must always be pursued -- not your exact words, but my understanding of them) is no less extreme than strict adherence to mathematical models/constructs. I've stipulated repeatedly that complete strict adherence isn't practical.



There most certain can be a determinant value for FALSE and TRUE in the integer number system. Languages which have explicit boolean types and constants use them. Most often, they are 0|1. However, they treat False|True as opaque ordinal values, and make it straightforward in how to deal with them. There is no "explicit/implicit" dichotomy. There is no ambiguity. Thus, in a language where such a dichotomy / ambiguity exists, I find it more useful to opt for explicitness.



Which illustrates my point. You can't replace (test using boolean operator) with (test using integer operator). However, people still try and wonder why they are getting the wrong results.



One word: Math.



Even still, our personal decisions for ourselves often have repercussions far outside our sphere of influence. We don't each live in our own personal universes where anything we do has no effect on anything or anyone else.

I mean, after all, isn't that the whole point in sharing wisdom and knowledge in the first place?



I looked at it, but am not sure what needs to be done with it. What do you have in mind, Strife?

which was my point (although I phrased it in layman's terms)


if I understand your argument correctly, you're saying how it's used trumps what it's action is? ie multiple uses = multiple actions? I see it as one action that has multiple uses... like a shovel you can dig with it, and you can bean someone in the head with it, but neither action changes it's shape



Correct, they are "shortcutted", which leads to problems in analysis and implementation.



to leverage different efficiencies based on their individual paradigms? ex Fortran =)


different conventions, same premise. Do things a certain way, based on certain considerations, unless it's necessary or practical to do otherwise...


but not LSL, which was my point. not that they can't exist, but that in LSL they don't.


I don't know of a language in which you can conveniently replace those two constructs with each other in that context... so I'm kind of lost as to what your argument is there... now in an evaluation test, it's possible to replace them, and if the language supports it the trailing != 0 for boolean operators isn't needed... in that context


even math has no meaning outside of it's context of counting. so I suppose it's more correct to say a thing has no meaning outside of it's use.which isn't to say it's properties don't remain the same, or that you don't need to know those properties to put it to effective use.


agreed. but that doesn't mean each person will make the same decisions, or have the same value assigned to those repercussions.

as a for instance, I depreciate the value of portability in favor of of the value of efficiency due to a belief that (in LSL at least) it's easy enough to modify tests to conform to the ported language while a person is correcting syntax (which almost invariably needs to be done when porting code),

additionally I value it's guaranteed local repeated use higher than the one time, and only "possible", act of it being ported. I also tend to suit my choices to the environment, which means the same choices could change. I assume you follow a different logic that supports your own choices.


I had left some thoughts on it on the talk page a while back, but I missed Strife's reply saying to go ahead and work on it if I wanted. you're more than welcome to run with it too... there's a potential mountain of information to add, just in individual "operator vs variable type" behavior.

Umm. OK. <.<



No, I am saying that its shape is that of a boolean AND function over a number of bits. One USE is to compare (intersect) bits.



The language (and translator) itself should do that without requiring ambiguous syntax.



I think that's what I said.



Sure they do. TRUE is 1, FALSE is 0. Conditional expressions can be made so they evaluate to those values consistently.



That was my point. People get used to integer conditional expressions by rote, then erroneously use them where they can't be used because of the ambiguity they represent.

In my code, they ARE needed, because it makes things readable, maintainable, and portable. Another point I would like to make about portability is the ability to port code INTO LSL. I've quite a library of code from decades of software development. Code that I have written in other languages that uses the same conventions. Because I normalized said code in the past, I can easily drop it in-place with very little syntactical changes. I don't think it would be wise to go back through and remove those "extra" operators, unless there was a REALLY good reason to do so.

Also, let me ask you a question:

If there is no speed/space penalty to using the "extra" ==0 / != 0, would you use it, or disagree with its use in general?



Umm. No. Math is nothing BUT meaning. Theorems, proofs, equations. Math does a HELL of a lot more than simply effect a means of "counting". <.<

x^2 + y^2 = 1 -- means a "circle"; specifically, a "unit" circle.



Experience tells me maybe they should.



*shrugs* Probably duplicated effort at the moment, at least until I can figure out what it would need. There's more on that page than most language reference manuals bother to provide in the first place.

A while ago I did the type table for addition, the other operators need tables done too but I lost motivation on the topic.

I disagree, I've broken a few shovels in the course of using them. The trick isn't getting them to dig the hole, it's to get them to hit themselves over the head with the shovel and fall into the hole.

-----

I'm going to take a moment to summarize what I think the topic currently is:
The mix of boolean logic with integer arithmetic is less than optimal.

No argument there. LL should have made it a separate type and just implicitly converted it where necessary (and not). Overloading a type in this manner causes strife in the long run (I should know).

As to implicit vs. explicit: Typecasting at it's core allows for derived classes to be cast to base classes and vice versa. The feature however has been extended in most languages to perform type conversion (which is how LSL uses it). Implicit type conversions are a very powerful tool. As a language designer you have to be careful with them as they become in a way part of the language.

In most situations I'm content to use implicit type conversions but there are times when I want to be sure that they happen when I am expecting them to happen so I make them explicit. If I'm writing really devious code, I don't want to have to think about where the compiler is placing the type conversions. After all, this is algebra we are talking about, order of operations are important, and an implicit type conversion, despite it being implicit is still an operation that must be completed.

Booleans, bit-fields and integers should never have been combined into a single user type. In doing so we have lost syntax potentials for each of those types since they must share a single set of operators.

P.S. Just be glad we don't have Octal support in the integer system to contend with anymore.

P.S.S. I hope my post was on topic.

should it also write the code for us? it's up to us to get it to do exactly what we mean


yes and you applied it yourself alone, I'm saying it applies to me too.


no, TRUE is NOT equal to one... TRUE (in the evaluative sense of LSL) is equal to !0, as you yourself pointed out. the constant value "TRUE" and the value 1 are token representations provided for convenience.


the only ambiguity I see is the assumption that lsl reduces all test to 0 or 1, or evaluates them on that basis... if nothing else people will learn very quickly that assumption isn't correct. being less portable doesn't make that wrong, just less portable


neither most likely, if I knew it'd be evaluated that way already... feels redundant. I did mention portability is way down on my list, apparently below speed of typing too. but I'd certainly not fault anyone else for using it in that context.


that proves my point, not counters it... it describes a circle, ie it has context as a real word construct. Measuement is counting too.. in fact I find it hard to separate them mentally... and that's what math is largely used to describe, sometimes literally, sometimes in relatively. but without context for it's use, it's just symbols strung together. as an example a button has no meaning in and of itself... tell a person to press it every day and what's the first question they ask? "why?" because it has no meaning with the context of it's use.


benevolent dictatorship? I think the problem is that peoples experiences differ so they'll never entirely agree on everything, including who should be the benevolent dictator. (though often enough if no one cares enough it's left to whoever will take the job.... eg modern politics)

ETA:
I think that summation would remove most of the disagreements.

PS
seems on topic to the expanded discussion... but I think we passed the scope of the OP somewhere on the first page.... :hrug::

Don't be obtuse. The whole point of algorithms is to describe what we want to do in a highly-explicit and unambiguous way, REGARDLESS of the specific language used to express them.



OK.



llOwnerSay((string)TRUE); // outputs "1"

LSL (like other C-like languages) ALSO ambiguously uses an indefinite value set to represent the same thing as TRUE. That's the problem.

It shouldn't be a matter of "convenience". It should be a matter of determinism.



I've seen code from people who have been programming for years who use them interchangeably in situations where they are not interchangeable, even though they know better. "Force of habit" is the usual excuse.



Fair enough. The only question is if the mono compiler recognizes and performs the obvious optimization. I would imagine it does, since it does for other languages that compile on that platform.



Not to me it doesn't. Math IS definition and meaning expressed in the most simple and elegant forms possible.

Yes, that is more or less the "short, sweet, too-the-point" examination of the issue I think I was trying to express.



Absolutely 100% agreed. One of the issues I have run into with development of languages is that implicit functionality in any language causes loss of meaning and context in the code itself. In other words, if I were otherwise unfamiliar with the language, but could parse its syntax, some statements or operations would make no sense, because the context is hidden in the translator, rather than being explicitly represented in the code itself. More or less, it suffers from the "colloquialism syndrome". This also comes into play with dialects of languages. It causes a number of problems, not the least of which is increasing the "learning curve" of such languages significantly, if it is ill-considered.



This, most definitely. I try to recover some of that potential through these and other methodologies, but obviously, anything complex, like set manipulations, is just going to get ugly fast.



0RLY?

Without offering judgements one way or the other with respect to the debate, I thought I would share an interesting perspective once expressed by a manager I worked for. He once made the startling declaration that he was more interested in seeing code that was readable and clear in meaning, than code that was correct. Here was his reasoning:

If the code is clear and readable, it becomes much easier to *see* whether or not it is correct, both when it is written and when it is subsequently changed. Since that reduces the cost (time requirement) of debugging and maintaining the code, which is far more significant over the lifetime of the code than the cost of writing it in the first place, clarity is the most valuable quality. Any obfuscation in meaning, regardless of the efficiencies it may bring, are a false economy *unless* you have first determined that the gains in other metrics justify the loss in clarity.

Of course, none of that says anything about what is or is not a 'clear' expression of intent in code, but perhaps it offers an interesting perspective on why that matters in the first place

That's pretty much the way I look at it; I just wouldn't say it quite that way.

I would say it like this: "I am most interested in seeing code which is readable, clear in meaning, and correct. If it can't be correct (because of circumstance), then I would still want it to be readable and clear in meaning so it will more easily facilitate correction."

That is probably not quite as startling to say.



I agree with that reasoning, and would add that, if obfuscation is determined necessary, it *must* be documented well enough to provide the missing clarity.

which would be the crux of our main discussion. you seem to prefer universal meaning, I prefer leveraging as much as possible from each languages unique abilities. each comes at a cost to the the other.


unfortunately we can't test, but as a counter, we also know that LSO doesn't and the MONO compiler and VM were put together in this case for compatibility. so there's really no telling. I would love to know one way or another.

key words there. it's being used to define. ie it becomes meaningful in it's use...



I think I see this as an extension of the core discussion, generalized versus localized solution.

Not always. One doesn't have to come at a cost to the other; in cases where it doesn't, or the cost is inconsequential, one methodology should be preferred.



Well, the code at that level doesn't have to be verbatim, as long as the functionality is preserved exactly.

For example:

if (x & 3)

should (potentially) compile to x86 machine code:

AND [x],3
JZ IsZero

if ((x & 3) != 0)

should compile to the same thing, not

AND [x],3
CMP [x],0
JE IsZero

because the compiler should recognize that the state of the Zero flag after the AND operation is already set to indicate what it would be after the compare instruction.

The mono compiler should perform that optimization by default anyway, because it is handled at a lower level than where the LSL translation code exists.



Yes, but as I said, the expression is only a matter of parametrization and interaction, both of which are still within the domain of math itself.



Perhaps, but that doesn't invalidate the point(s). Generalized vs localized shouldn't be such a big dichotomy. In theory, it shouldn't be a dichotomy at all.

no, of course not always, but generally, with exceptions either way... and presuming both are being considered... as some might not value one or the other position at all.

should, but I don't trust LL not to have done a bare strip of optimizations as quicker to getting compatibility... unfortunately we can't know because it's server side and the memory functions have "problems" (to be charitable)


but it's still a matter of using to describe something else, even if you're only manipulating the description...

depends on how different the locales are in comparison to the considerations.

Well, I doubt seriously that they would muck about in that part of mono, since the whole point of mono and .NET is to avoid having to do that in the first place.



What else is meaning but description of being and interacting?



Not really; algorithms don't change depending on what literal translation is done on them.