Forums Scripts & Popups binary arithmetic

Since when did I say that truncating and wrapping are the same thing? OK, perhaps this thread could do with a summary before it dies:

1. I stated that $and evaluated to an incorrect value when either input A or input B are too high.
2. 5618 agreed.
3. argv0 disagreed, stating that the mIRC help file isn't incorrect, but incomplete.
4. I disagreed with argv0, stating that the mIRC help file is incorrect until it documents the behaviour. I provided an example which involved a function that isn't relevant and shouldn't have been brought into the discussion (stupid me!).
5. argv0 disagreed with me. In a strange twist, argv0 then agreed with me, stating that the mIRC help fle is incorrect and requires further elaboration. argv0 then assumed that I was making implementation assumptions.
6. I disagreed with argv0's assumptions, attempting to bring the discussion back into relevance by stating the definition of a "binary and" operation.
7. Thrull made a rather humorous attempt at pointing out the whole love/hate relationship.
8. argv0 informs Thrull that he missed the point.
9. argv0 disagreed with me again. He then brought irrelevance in the form of assumptions that would have been fair to state, if they were stated. He then made an assumption regarding atoi returning the same value "on 32bit systems", and at the same time technically agreed with me regarding this undefined behaviour.
10. I state that a helpful participant would be better off acknowledging my point of view and discussing possible alternatives that may be better defined and provide better results. I give one example of such alternative, that would return an infinitely greater variety of correct result.
11. argv0 agrees in regards to the undefined behaviour.
12. I agree in regards to the undefined behaviour.
13. Darwin_Koala agrees in regards to the undefined behaviour. Darwin_Koala then states "If you truncated the extra bits - the original problem you complained about would still exist (an unexpected answer to a function)" (only true if both inputs are truncated) and "You can't both truncate and wrap." He then suggests that it isn't important because it's not going to break anything in the near future, thus disagreeing with my definition of a helpful participant.
14. I disagree with Darwin_Koala's statement: "You can't both truncate and wrap." I state that truncating results in wrapping (for the record, this is not a statement of equality). I would like to state, from the ISO C99 standard: "C's unsigned integer types are 'modulo' in the LIA−1 sense in that overflows or out-of-bounds results silently wrap." What exactly does that mean? Well, if you take a number that is larger than an unsigned integer (eg. that 'overflows' the unsigned integer), it silently wraps. For example, if a 64-bit unsigned integer is assigned to a 32-bit unsigned integer, the 32-bit unsigned integer's result is wrapped, and truncated, at the same time.
15. genius_at_work stated "functions that can only handle 32-bit numbers should only ACCEPT 32-bit numbers." genius_at_work provides another possible, and perfectly acceptable alternative.
16. Darwin_Koala attempts to defend his ego by listing part of his library. Darwin_Koala then agrees that the behaviour is undefined. Darwin_Koala attempts to agree with something that genius_at_work didn't state: "Genius_at_work notes that mIRC handles this undefined behaviour in a consistent manner." He then states that I should learn how computers work before telling him he's stupid.
17. I state my point again, that the behaviour should be defined rather than left undefined, to prevent scripts from breaking.
18. Darwin_Koala states that I stated that "truncating and wrapping are the same thing". Darwin_Koala stated that genius_at_work agrees that the behaviour is consistent.

Read my post again. Just because going up results in coming back down doesn't mean they're the same thing. Now tell me, where did I state that truncating and wrapping are the same? You may not have made any argument against my point, but it is still my point, and you are still bringing irrelevancy to this thread.

Read genius_at_work's post again. Now tell me, where within genius_at_work's post, would I "see that the behaviour at the moment is consistent." I forgive you if English is your second language, but please learn to read more accurately. Also, please refrain from bringing irrelevancy to this thread.

Thankyou, s00p.

edit: argv0, I missed your most recent post. I apologise. My original point could be about either. The documentation can not define the behaviour, unless a defined behaviour is used. If a defined behaviour is used, then it should be noted in the help file. At the moment, I suspect that it's entirely up to the compiler.

In the interest of reason, and ensuring that the general readership are properly informed:

genius_at_work noted that
Thus, mIRC treats this consistently. It might be (in our opinion) consistently bad - but it is still consistent.



However, you appear to have a different view and want to put other views down with a cry of "irrelevance", so please answer me this:
- What do you get from the C Manual (your reference, not my chosen one) that sheds light on this discussion, and how does it help solve the issue.
- Truncating and wrapping are not the same, and truncating does not result in wrapping. Please provide some examples to demonstrate your perspective. I am listening and waiting to learn from the obvious master.
- Rather than dismissing the points out of hand - try to explain why they are irrelevant. From my point of view - the points made are exteremely relevant and it is you who is missing the point. Again, I am listening.

Try to learn where Australia is, and then revise your assumption on whether English is, or is not, my first language.

Try not to assume that people are stupid, either - it is rude, unnecesary. From your tone and language I too can make assumptions - and I assume that I have been working in IT longer than you have been on this planet.

Taking into account genius_at_work's point - the behaviour is defined for invalid inputs. Perhaps not defined the way we would like it. The help file may not be too clear on this either.

Cheers,

DK

Seriously? You guys are still responding to this? I know tolls in this forum are rare, but c'mon, this is exactly what's happening.

You've given him the answer, he refuses to believe you and insults you. The sooner you stop responding, the sooner this thread can get buried.

You seem to suffer from a condition that limits you to selective reading. The fact that the functions return 0 for "invalid input (non-numbers)" is not even the slightest bit relevant to the fact that it's not providing correct output for numbers that are out of range. Again, please learn to read accurately. This is irrelevant because the input we're dealing with is numerical. Stating that this quote, with ellipsis at each end, implies consistency just goes to show how easy it is to omit key aspects of the paragraph and derive pure bullshit from it. Allow me to take the same quote, omitting the rest of the paragraph and derive some more bullshit to counter your own: $and(0,0) returns 0, thus 0 must be a non-number. That would be consistent, correct?

1. "What do you get from the C Manual (your reference, not my chosen one) that sheds light on this discussion, ..."?
Consistency, which is not the equivelant of some pseudo-realism derived from an quote that unreliably displays obvious signs of omissions. If you can't find the answer, assume it to be implementation defined. In this case, I can't find the answer within the mIRC help files. It's not fair enough to say that mIRC is a single implementation (because this can, will and already has changed many times), so I'm kicking up a stink.
2. "... and how does it help solve the issue."
It provides examples of this consistency. I've already quoted them, but for the benefit of a moron: "C's unsigned integer types are 'modulo' in the LIA−1 sense in that overflows or out-of-bounds results silently wrap." This quote defines a perfectly acceptable solution to the problem: wrapping. Truncating is irrelevant, as I have already said so many times before, and wasn't brought into this conversation by me.
3. "Truncating and wrapping are not the same, ..."
correct.
4. "... and truncating does not result in wrapping. Please provide some examples to demonstrate your perspective. I am listening and waiting to learn from the obvious master."
uint32_t x = 0, *y = &x, z = y; // <--- this may result in truncation of the pointer to uint32_t y.
I never did imply that truncating and wrapping are the same. That was another case of your selective reading. Real number truncating is irrelevant to this thread, because we're dealing with numbers that are outside of the range, not numbers that have decimal points. This is an example of the form of truncating we've been referring to, straight from the draft:

Please stop bringing irrelevance into this thread.

I know where Australia is; I live there. It would be an assumption if I were to say that everyone who lives in Australia speaks English as their first language. It would be most rude, too.

If you have been working in IT longer than I have been on this planet, then perhaps it's time for your retirement. Your wisdom is deteriorating, and the inebidable signs of brain damage are starting to show. Immediate attention may be required if you believe you can accurately pinpoint "tone" within posts on a forum.

You may find what mIRC considers to be "valid" and "invalid" inputs, are not necessarily what atoi() considers to be valid/invalid. In this case if atoi() is being used (quite likely), then it considers a number greater than UINT_MAX or smaller than -UINT_MAX to be invalid, and as a result the return value is saturated (consists of all 1's in it's binary representation). The result is inconsistency between the return value that atoi() provides (assuming atoi() is being used) and the return value that $and provides for invalid input.

.. I was hoping to at least correct some of the misinformation so that the real readers of this thread could learn. However, the last response rambled even more incoherently than previous ones.

In a battle of wits, I have been bested by an unarmed man. I now retire, hurt.

Cheers,

DK.

lol @ me == troll. I've asked for no more responses on a number of occasions, and I'm not giving in to those trolls to see nothing done about this so if I'm a troll then I'm a troll