Negative Variable Problem As2

[Siasmic]

Hello, I am having a very recurring issue with variables going negative and I can't seem to stop it. I want a certain variable to, once it hits its maximum or minimum to stop being edited or stop going in that direction depending on the circumstance.

I have tried:

if(variable <(or >) min(or max)){
// stuff
}

I am sorry if this is very simple but if someone could please lend me a little bit of their time to help me, I would really appreciate it. I can provide the swf/fla or screen shots if necessary.

[Jin]

var val:int = 50;
var max:int = 100;
var min:int = 0;
if (val > max)
	val = max;
else if (val < min)
	val = min

[Sandremss128]

At 42 minutes ago, Jin wrote: var val:int = 50;
var max:int = 100;
var min:int = 0;

val = Math.min(Math.max(min, val), max);

If you can do it in 1 line without making it more complex you should :)

[Jin]

At 50 minutes ago, Sandremss128 wrote: If you can do it in 1 line without making it more complex you should :)

lol

[Siasmic]

Both of those failed, I'm afraid. I am more than certain that I messed up somewhere, I will look over the entire code and look for errors.

[Diki]

At 10 hours ago, Sandremss128 wrote: If you can do it in 1 line without making it more complex you should :)

No you should not. You should be doing it in the least ambiguous way, which does not describe your method.
In a practical sense your code does not have flaws. However, it offers no improvements to efficiency (in regard to code execution time), while making what is actually happening less intuitive.

In short: having less lines of code does not intrinsically make your code better.

At 6 hours ago, Siasmic wrote: Both of those failed, I'm afraid. I am more than certain that I messed up somewhere, I will look over the entire code and look for errors.

Is it possible that a different section of your program is modifying the value of the variable?
You might have to do some very tedious debugging to track down the issue.

[Diki]

At 29 seconds ago, Diki wrote: No you should not.

In retrospect I figured that I should add to what I said here.
I do not mean you should never condense several lines of code into a lesser amount. You should only do so if there is justifiable, and easily explainable, reason behind the decision to do so.
There is a quote that I once read regarding programming which describes this well (I am paraphrasing): "If you cannot easily explain a decision that you made [in programming] then you are probably doing something wrong".

I also forgot to comment on this:

At 10 hours ago, Sandremss128 wrote: If you can do it in 1 line without making it more complex you should :)

You made the code significantly more complex. So even by your own logic you should not be writing it the way that you did.

In the code originally posted by Jin there were only three variables and a single if() statement with an else if() attached.
Your code contains the same three variables and two function calls, both of which (at best) will have an if() statement with an else if() attached.

[milchreis]

At 2 minutes ago, Diki wrote: There is a quote that I once read regarding programming which describes this well (I am paraphrasing): "If you cannot easily explain a decision that you made [in programming] then you are probably doing something wrong".

That's a fairly neutral statement.
An easy explanation could be "because I like it that way".

You made the code significantly more complex.

A matter of opinion.

[Diki]

At A few seconds ago, milchreis wrote: That's a fairly neutral statement.
An easy explanation could be "because I like it that way".

Do you understand what the point that that quote is making?
If you cannot easily explain a design decision in your code then there is probably a flaw in that design. For example the flaw could be caused by the designer attempting something outside the scope of their ability and/or experience.

The qualifier "probably" is used because, just like with anything, there are exceptions to this.

And if any programmer were to use "because I like it that way" as a defence of their application's design then they are an abhorrent programmer whom should immediately seek a new profession/hobby.
There are people who prefer to nest several ternary operators. Them liking it doesn't make it any less of a bad idea.

At A few seconds ago, milchreis wrote: A matter of opinion.

No it is not. That code is objectively more complex. Complexity is not subjective, it is a branch of mathematics, which is a science, which is objective.
If you genuinely believe that complexity is subjective then my only advice is to look up the definition of the the word.

The only matter of opinion is whether the extra complexity is a worthwhile tradeoff for a more succinct (and ultimately more ambiguous) design.
That I cannot argue. If you, or Sandremss128, genuinely believe that his code is more easily understandable, and overall better, than the original code posted by Jin then that is your prerogative.

However this is entirely irrelevant as this is comparing the taste of faeces to the taste of food.
Something intrinsically being subjective (such as taste) does not immediately absolve it of criticism.

[dELtaluca]

I honestly have to say that Math.min(Math.max(val,min),max) is in my opinion a fairly standard way of computing a bounded value :P

[milchreis]

At 2 minutes ago, Diki wrote:

At A few seconds ago, milchreis wrote: A matter of opinion.

look up the definition of the the word.

complexity
The state of being complex

complex
Not simple or straightforward.

I pointed out that using the terms "min" and "max" can be more straight forward than "if, else" and "<" for somebody.
Making this solution appear less complex.

[Sam]

At 2 minutes ago, dELtaluca wrote: I honestly have to say that Math.min(Math.max(val,min),max) is in my opinion a fairly standard way of computing a bounded value :P

I agree, but I think Diki's point was more focused around the fact that the complexity between using that and a pair of if statements isn't great enough to justify condensing it (even though, personally I'd rather write less lines).

[Diki]

At 12 minutes ago, dELtaluca wrote: I honestly have to say that Math.min(Math.max(val,min),max) is in my opinion a fairly standard way of computing a bounded value :P

I agree, and I even stated in one of my previous posts that there are no flaws in that code.
More than anything I was arguing against the defence of writing that, which was solely: "If you can do it in 1 line without making it more complex you should".

At 11 minutes ago, milchreis wrote: complex
Not simple or straightforward.

You cherry picked this definition, and that is also an inaccurate definition of "complex"; this is more a definition of the word ambiguous.

Complex, as an adjective, means:
- Consisting of many different and connected parts
- Composed of many interconnected parts
- Characterized by a very complicated or involved arrangement of parts, units, etc

The code posted by Sandremss128 is the same save for an extra two function calls. That makes it objectively more complex.
In this example the additional complexity is paltry, but exists nonetheless.

At 11 minutes ago, milchreis wrote: I pointed out that using the terms "min" and "max" can be more straight forward than "if, else" and "<" for somebody.

You didn't "point out" anything, you just stated I was wrong and provided no explanation for your conclusion.
Having said that, I agree with this statement.

If using the min() and max() function calls is more intuitive to you then that is your justification for doing so, which is very easily explainable, making the design not flawed.

At 22 minutes ago, Sam wrote: I agree, but I think Diki's point was more focused around the fact that the complexity between using that and a pair of if statements isn't great enough to justify condensing it

Hit the nail on the head, my friend. :)

[milchreis]

At 17 minutes ago, Diki wrote: you just stated I was wrong

Huh? No, I didn't.

and provided no explanation for your conclusion.

The quote was not an argument for any way to code, because it asked for an explanation, which could possibly be subjective, yet legit. Over exaggerating "I like it that way" was supposed to make that clear, apparently it didn't.

But you came to the same conclusion:

If using the min() and max() function calls is more intuitive to you then that is your justification for doing so, which is very easily explainable, making the design not flawed.

If something is more intuitive, it is less complex.
Intuition and complexity are quite subjective I guess, making this whole thing:

A matter of opinion.

[Diki]

At 6 minutes ago, milchreis wrote: Huh? No, I didn't.

You didn't explicitly state the words "you are wrong", but you did offer a dissenting opinion.
I claimed that the rewrite was more complex which you stated was "a matter of opinion".

In other words, I made a claim of objectivity, which you stated was, in direct contrast, subjective. This is where I drew the conclusion that you were claiming I was "wrong".

At 6 minutes ago, milchreis wrote: The quote was not an argument for any way to code, because it asked for an explanation, which could possibly be subjective, yet legit.

I do agree that any given explanation for a design decision is going to contain subjectivity, it's human nature. And in some instances there can be no truly objective explanation (such as using an insertion sort algorithm over a selection sort when efficiency is irrelevant).
However the point behind the quote is still there, but will be missed if it is taken at face value. Every design decision that one makes in their application should have a reason for its existence. If said reason cannot be easily conveyed then it is, more likely than not, being over-complicated or misunderstood and as a result is hindering efficiency.

Even something as intricate as applications utilising networking and threading should have an easily explainable reasoning to their design decisions.
Hell, even the usage of something as esoteric as the volatile keyword (not found in ActionScript, of course) can very easily be explained. If one could not easily explain why they chose to use volatile then they probably don't understand what it does, and as a result have produced a flawed design.

At 6 minutes ago, milchreis wrote: Over exaggerating "I like it that way" was supposed to make that clear, apparently it didn't.

I may have missed your point there, but I was merely stating that anyone who would use that as an explanation for a design decision is an "abhorrent programmer".

At 6 minutes ago, milchreis wrote: But you came to the same conclusion:

If using the min() and max() function calls is more intuitive to you then that is your justification for doing so, which is very easily explainable, making the design not flawed.

That was regarding this specific example.

At 6 minutes ago, milchreis wrote: If something is more intuitive, it is less complex.

That would require intuitiveness to be objective, which you have claimed, and I agree with, is subjective.

At 6 minutes ago, milchreis wrote: Intuition and complexity are quite subjective I guess

Intuitiveness is subjective (to a certain degree*), yes. The more one understands a subject matter the more intuitive anything regarding that subject matter will become.
But, again, complexity is very much objective.

If you draw a square on a piece of paper, and I draw an octagon, I have objectively drawn a more complex shape. There is no subjectivity to it. It involves more line segments, ergo it is more complex.
The code posted by Sandremss128 involves function calls not found in Jin's code while involving the same number of other arguments, ergo it is more complex.

Where are you finding subjectivity in this? I truly do not understand.

* I say that it is "to a certain degree" because there comes a point where something is so unintuitive that to claim otherwise is arrogant and condescending. Quantum physics, for example, is by no stretch of an imagination intuitive. Anyone who would claim otherwise is only being smug.
Even something as simple as the Monty Hall problem is very unintuitive, and would only be smug to claim otherwise.

[dELtaluca]

At 24 minutes ago, Diki wrote: The code posted by Sandremss128 involves function calls not found in Jin's code while involving the same number of other arguments, ergo it is more complex.

the the other code has an if...else if and 2 conditionals and extra assignments that are not found in the other code, ergo it is more complex :P

[Diki]

At A few seconds ago, dELtaluca wrote: the the other code has an if...else if and 2 conditionals and extra assignments that are not found in the other code, ergo it is more complex :P

It has more assignments, actually. Look at Jin's code.
It contains three assignments for the min, max, val variables. Both sets of code require these, so both immediately have three assignments.
If the first if() statement is fulfilled then the second is ignored, resulting in a total of four assignments and one conditional. Otherwise the result will be four assignments and two conditionals.

In the rewrite, each function (i.e. min() and max()) takes two arguments, and both functions are being used, so there is immediately an additional four assignments (albeit references).
Both of these functions will also, at best, contain a single conditional check, so add an additional two conditionals.
Both functions also return a value, so there is another additional two assignments.
Resulting in, in a best case scenario, a total of nine assignments and two conditionals.

The if {} else if {} logic, and resulting assignments, are only being obfuscated by using the min() and max() functions, whereas Jin's code explicitly writes it out without calling any functions.

This is what makes it more complex.

[dELtaluca]

The whole point of functions is that we do not need to care about 'how' they are implemented, only what they do.

When you do x = 5, what really happens? you get bytecode which is generated, executing of that bytecode will result in thousands of conditionals and assignments and movements of memory and memory access, it also will involve runtime JIT'ing of code into native mahcine code, and execution of that machine code invovles thousands of conditionals in hardware.

Does it matter? fuck no.

[dELtaluca]

If you're going to look at it that way, then you should be arguing that we should all code in pure machine code, and that doing so is the least complex way of coding.

Coding in AS3 or any high level language, even coding in C must be ABSURDLY complex according to your reasoning, certainly magnitudes more complex than machine code!

[Diki]

At 11 minutes ago, dELtaluca wrote: The whole point of functions is that we do not need to care about 'how' they are implemented, only what they do.

Perhaps that is how you use functions, but if you care at all about the efficiency of your application(s) then you should be taking into consideration what happens when the function is called.

The rest of this post, and the one following, are strawman arguments so I won't comment on them.

[milchreis]

At 1 hour ago, Diki wrote:

At 11 minutes ago, dELtaluca wrote: The whole point of functions is that we do not need to care about 'how' they are implemented, only what they do.

Perhaps that is how you use functions, but if you care at all about the efficiency of your application(s) then you should be taking into consideration what happens when the function is called.

That's why you did not get my argument. For you, complexity of code seems to depend (not solely, but almost) on what it looks like after the compiler has done its job. But there's also a human who should be able to read it. And some human can think of either version to be more or less complex, for whatever personal reason. That's all I said.

I agree to delta:

At 1 hour ago, dELtaluca wrote: If you're going to look at it that way, then you should be arguing that we should all code in pure machine code, and that doing so is the least complex way of coding.

Coding in AS3 or any high level language, even coding in C must be ABSURDLY complex according to your reasoning, certainly magnitudes more complex than machine code!

[Jin]

if...else is more flexible, cheaper, and readable than Math functions. So here.

val = (val > max) ? max : (val > min) ? val : min;

[Diki]

At 11 hours ago, milchreis wrote: That's why you did not get my argument. For you, complexity of code seems to depend (not solely, but almost) on what it looks like after the compiler has done its job.

What language do you think the min() and max() functions are written in?
Do you treat every function you use in ActionScript, one you wrote or written by a third party, only as the value that it returns?
If a function takes a reference to a DisplayObject do you pass it in willy nilly and assume that the DisplayObjectwon't change?

At 11 hours ago, milchreis wrote: And some human can think of either version to be more or less complex, for whatever personal reason. That's all I said.

Indeed you did say this. Though you didn't answer my question when I asked how you are concluding that complexity is subjective.
Complexity is essentially, in laymen terms, "has lots of parts to it". So if something "has more parts" it is more complex.

An analogy would be that the number 8 is more complex than the number 3 as it is greater. You are claiming, however, that it is a matter of opinion that 8 is greater than 3.

Complex does not mean "difficult to understand". Complex does not mean "unintuitive". Complexity is an objective metric.
Measurements are not affected by opinion.

So, again I ask, what logic are you using to conclude that complexity is subjective?

[Diki]

Oh, and by the way, yes, I do very much care about what happens to my code after the compiler is done with it.

[milchreis]

At 3 minutes ago, Diki wrote: So, again I ask, what logic are you using to conclude that complexity is subjective?

That's actually what all my posts were about.

At 21 hours ago, milchreis wrote: [...] using the terms "min" and "max" can be more straight forward than "if, else" and "<" for somebody.
Making this solution appear less complex.

If "min" and "max" is more intuitive to one person, that person would say that using the "if" is more complex, because it uses things that are less intuitive (to that person).

[Diki]

At 14 minutes ago, milchreis wrote: If "min" and "max" is more intuitive to one person, that person would say that using the "if" is more complex, because it uses things that are less intuitive (to that person).

That's not what complexity means though; it is a metric. Understanding X more so than Y does not make Y more complex. That makes said person not understand Y as well as they do X and nothing more.
Complexity isn't a matter of perspective.

Using that logic it is possible for English to be more complex than Mandarin.
If a foreigner from China were to attempt to learn English for the first time they would obviously not understand it as well as they do Mandarin (or Cantonese). They would probably also struggle with conjunctions, as they do not exist in Mandarin or Cantonese.
This does not mean English is more complex than Mandarin. It means that person understands Mandarin better than they understand English.

And, do not forget, that Mandarin has an alphabet with over 20,000 characters. It is inarguably more complex than English.

[milchreis]

At 20 hours ago, Diki wrote: That's not what complexity means though; it is a metric.
And, do not forget, that Mandarin has an alphabet with over 20,000 characters. It is inarguably more complex than English.

You are the one to say that this metric to measure the complexity of a language is the number of characters.

A child that cannot read or write (yet) can draw things. The number of "characters" a drawing can use is infinite.
But I would not call that infinitely complex. One would come to the conclusion that drawing is a rather primitive way to "write". I'd say that's because the association from the written "word" (drawing) to the real world object it describes is very simple, direct, not complex.

If you measure complexity of a language by that metric, English is more complex than drawing, because it maps words to the real world in a much more complex way.

Yes, complexity is a metric, but it depends on the person and its point of view to choose which metric.

The problem with this "English vs. Mandarin" thing is that from your perspective, you'd have to learn both and I agree that probably everybody would say Mandarin is more complex.

Thus the example above with a child that already knows the "more" complex language.
And that's the same with the min/max line. If you already know those two words, if, else/< is possibly more complex.

[Diki]

At 31 minutes ago, milchreis wrote: You are the one to say that this metric to measure the complexity of a language is the number of characters.

Here again is the definition of the world "complex":
- Consisting of many different and connected parts
- Composed of many interconnected parts
- Characterized by a very complicated or involved arrangement of parts, units, etc

Do you genuinely not see how that applies to the number of characters in a given language's alphabet?

That, and this is a strawman argument. I never said the sole method of determining a language's complexity is to count the number of letters in its alphabet. I was providing the fact that there are an absurd number of characters in the Mandarin alphabet as evidence that it is a complex language.

At 31 minutes ago, milchreis wrote: A child that cannot read or write (yet) can draw things. The number of "characters" a drawing can use is infinite.
But I would not call that infinitely complex.

This is a non sequitur.
There is not an infinite number of "things" that can be drawn. It is very much finite due to a limiting factor: A child, or adult, is only capable of drawing that which they have already experienced. Usually as an external stimuli (e.g. looking at something).

So, in theory, the complexity of one's imagination, in regard to their ability to draw, is infinite. There is no practical way to determine the "limit" of potentially acquirable imagination.
However, given that it is not possible to draw something that does not contain features that are within your imagination, there is a finite limit to the complexity of what you could possibly draw.

At 31 minutes ago, milchreis wrote: One would come to the conclusion that drawing is a rather primitive way to "write".

It is primitive in the sense that it is a comparatively inefficient method of communication. One that pre-humans used before inventing language.
In modern times though, drawing is used more so for expression than communication. Inversely, writing is used more for communication than expression.

Given how much humans have evolved since first using simplistic drawings to communicate, leading to the invention of language, I wouldn't call drawing a "primitive" form of "writing". They're just not comparable enough.

At 31 minutes ago, milchreis wrote: Yes, complexity is a metric, but it depends on the person and its point of view to choose which metric.

If you choose a different metric then the metric is no longer "complexity".
If you wish to include subjectivity into your metric, go for it. It just will no longer be "complexity".

At 31 minutes ago, milchreis wrote: The problem with this "English vs. Mandarin" thing is that from your perspective, you'd have to learn both

What? I have to learn Mandarin to know that it's a complex language?

At 31 minutes ago, milchreis wrote: Thus the example above with a child that already knows the "more" complex language.
And that's the same with the min/max line. If you already know those two words, if, else/< is possibly more complex.

It would be more intuitive. The complexity of an object, or system, is not changed by an external party's understanding of it.
It's not like Heisenberg's Uncertainty Principle applies to this.

[milchreis]

At 19 minutes ago, Diki wrote: It would be more intuitive.

Which would make it more complicated for somebody:

Characterized by a very complicated or involved arrangement of parts, units, etc

This definition is pretty much the same as the one I was sued for having "cherry picked".

[milchreis]

I mean less complicated, of course.