Forums Scripts & Popups binary arithmetic

Am I insane or does this code not provide the correct/expected answer?



I'm pretty sure the answer should be 0, as in the testcase below:

mIRC handles a max of 32 bits in this operation.

11111111111111111111111111111111 = 4294967295

Any decimal value above that becomes a 33-bit binary value.

Don't you think I already worked that out? Wait, you did read my post, right?

The mIRC help file states "$and(A,B) Returns A binary and B.", which isn't true. That is my point. >32-bit ops work for other functions, such as $base, so why not this one?

heh, but then again, what would $not(0) return?

It seems you already know the answer.

The help file is not incorrect, it's just incomplete, but that's not a new accusation as the help file is rarely that detailed. $and() *does* return binary AND of A and B, it just does it with a 32-bit operation. That part is simply undocumented (because mIRC is not a language that needs to concern itself with bits and bytes).

The expected result should take into account this 32-bit limitation.

Maybe at some point mIRC will support 64-bit numbers, you can suggest this, but there are other ways to handle that.

I'm curious as to how you would go about defining the mIRC scripting language without bits and bytes. I suppose you could call the wildchars "magic", and the tokens, well lets just say a random butcher decides where tokens begin and end

The help file is incorrect until it documents the behaviour. $and(4294967296,1) is not the correct value for binary 4294967296 and 1. synonymously, 4294967296 binary and 1 is 0, not 1. Even if mIRC wrapped 4294967296 into a 32-bit int, the behaviour isn't consistent. If you wrap 4294967296 into a uint32_t, you get 0. $and(0,1) = 0. not 1.

// 32-bit operations...
<n00p> relipmoc: uint32_t x = atoi("4294967296"); printf("%u\n", x);
<relipmoc> n00p > 0
<n00p> relipmoc: uint32_t x = atoi("4294967296"); printf("%u\n", x & 1);
<relipmoc> n00p > 0

"The help file is incorrect until it documents the behaviour."

Again, no. The help file may lack details, but the statement "Returns A binary AND B" is not incorrect on its own. It doesn't state that this will work for any number, and it would be just as incorrect to assume that it would, especially within the context of mIRC (a language where you should already know of and expect many size/functional limitations). And funny enough, mIRC doesn't even say A and B should be numbers, or even that they should be base 10. Hey, maybe we should complain that mIRC doesn't accept $and(0A, 0A) as valid input. I mean, under MY assumptions that should work, therefore the helpfile is wrong-- right?

But this is all pointless semantics and completely besides the point. The help file is not a spec for behaviour, it's merely a pointer. It's not meant to enumerate every detail, although that would be nice. If you can't deal with this and still want to call the help file "incorrect", go ahead, but I don't see what that changes.

As far as the "wrapping" is concerned, you're making implementation assumptions. Who says mIRC integer overflow is involved here? How do you know its not truncation? Again, the behaviour is defined by.. the behaviour. That's how it works. If you want, you can think of the help file as saying: "takes the binary AND of A and B. If A or B are greater or equal to 2^32 the result is undefined."-- Happy now?

If you're not, make a feature suggestion to extend the behaviour to 64-bit integers on the Feature Suggestion forum. Complaining about it here is completely unproductive.

Don't assume that I'm making an assumption. Each bit in the result should be set if and only if each of the corresponding bits in the converted operands is set. Sign bits are included in this internal representation. This is irrelevant to the fact that a value outside of the range produces unexpected results.

"Because Mirc only works with 32 bits."

"NO, THAT'S WRONG."

"Really, it doesn't work in 64 bits."

"NO, THAT'S WRONG."

...

Don't feed the trolls.

I believe you missed the issue entirely.

Seriously? Forgive me, I almost died laughing of the sheer recursive idiocy of that statement.

Is it still an assumption if I use your own words?



So, if 4294967296 is "wrapped" (read: integer overflow) into a uint32_t data type... that is not an assumption? Telling us what function mIRC is using is not an assumption? Telling us what data structure mIRC uses is not an asumption? Cause you know, there's zero chance your assumption is wrong and mIRC is obviously not simply using, say, the value 1 in this case, or maybe the value 2147483647 which is incidentally what atoi("4294967296"), atoi("4294967297"), etc. give on 32bit systems (unlike your examples, this is what I got). But you don't make assumptions.

When's your birthday... I'll buy you a dictionary.

But you're right. This is all irrelevant to the fact that mIRC doesn't support the integer range above 2^32. I'm glad you worded it so succinctly.

... and yet you make more assumptions:


This is technically undefined behaviour. That is, the behaviour is left to be defined by the implementation of C, not the standard. I also consider it stupid that you're arguing with me, rather than attempting to see my point of view. If you wanted to post some code that was beneficial to this topic, rather than arguing pointlessly, your code might look like this.

To the power who be, please lock this topic so that no more childish, useless comments can be posted.

Great, you acknowledge the concept of undefined behaviour. The same concept applies to $and (since it likely depends on that very function).

Case closed.

"I'm right. It's undefined, and that's the way it is" - this is the message I get from you. Well, it might not be that way in the future, if a compiler that Khaled chooses to use defines the behaviour of atoi() differently. Why not make an effort to use a function that defines the behaviour, or better yet takes advantage of C/C++'s silent wrapping to produce a correct behaviour, providing one of the two arguments isn't truncated? Well, if you want to be an idiot... then feel free to argue against a change that would eliminate undefined changes for $and/$or/$xor...

This is like watching a tennis match - and I am getting a crick in the neck.

Undefined behaviour means undefined results.

If you truncated the extra bits - the original problem you complained about would still exist (an unexpected answer to a function). If you wrapped the extra bits - the original problem you complained about would still exist. You can't both truncate and wrap.

Nor can you magic extra bits out of a routine if it doesn't handle it!

if you want to suggest then it becomes just that ... a suggestion. Until then, you have to accept that things are the way they are. Perhaps, instead of complaining about something that isn't going to change in the next few weeks, you could scrpt a way around it - do your own checking?

Cheers,

DK

Sure, you can truncate and wrap. That's exactly what truncating does!

No, you can't add extra bits magically, but you can perform a binary 'and' operation and get correct results providing ONE of the inputs is within the range (that is, isn't wrapped, or truncated). The other one may be. Wouldn't it be better to define the behaviour this way, than using an undefined function and (at the moment) providing an incorrect answer if one of the inputs is out of range?

"The C Programming Language" by Kerninghan and Ritchie is a good book to read before you go saying stupid things, Darwin_Koala.

It seems to me that these functions that can only handle 32-bit numbers should only ACCEPT 32-bit numbers. Any input that is outside the numeric range accepted by $and/$or/etc should be considered invalid input. If you input a number greater than 0b11111111111111111111111111111111 you should get a standard mIRC error message or a $null/0 return from the function. In my opinion, these examples should give the same result.

$and(bonnie,clyde) = $null
$and(9999999999,9999999999) = $null

The functions currently return 0 for invalid input (non-numbers), but since 0 can be a valid result ($and(1,0) = 0), I think that they should be changed to return $null instead. This would cause the functions to always give a known result (valid result or $null).

A simple pseudocode:



-genius_at_work

Oops, obviously I haven't read my own copy of "The C Programming Language" often enough, nor my own copy of Deitel's C++ Programming guide, nor my copies of the MC68000 design books. That is not to mention the other books in my library that deal with computer design.

What argv0 was originally telling you, and that you refuse to listen to, is that the behaviour of the function is undefined for inputs greater than 32-bit.

Genius_at_work notes that mIRC handles this undefined behaviour in a consistent manner.

Your point that it would be useful to have the behaviour of the function defined differently for invalid input is understood by all here. However, because this is a design feature - it is a Suggestion, rather than a bug. Sometimes a fine line?

Perhaps you should learn how computers work and note the inputs of others before you accuse anyone of saying "stupid things".

Cheers,

DK

What I'm telling you, and argv0, is that this is all irrelevant. My point is that some effort should be made to define the behaviour, because mIRC does on occasions work with larger numbers. If you weren't stupid, you wouldn't be arguing against consistency in behaviour for the future. Whenever someone asks for a feature and you argue "no, that would break scripts", I'm likely to point out that a revision of $and/$or/$xor is required to prevent scripts from breaking in the future. That is my point, leave it at that. No more replies, please.

edit: thankyou, genius_at_work.

There is no need to be rude. Your ignorance has already been demonstrated - in that you think "truncating" and "wrapping" are the same thing (read your previous posts).

If you also bothered to read my post - you see that I made no argument whatsoever about breaking any scripts.

If you read genius_at_work's post - you would see that the behaviour at the moment is consistent. You should also note that I agree that a better form of behaviour would be preferred. Feel free to make a suggestion on how this can be achieved.

Please try an understand that computers are not magical beings and they have limitations. In this case, the discussion was around a limitation of 32 bits. If you try to push the computer past this limitation using functions that are only designed to work with 32 bits then the functionality will break. If you want to work with large numbers, then use functionality that is optimised to work with large numbers. less chance of something breaking or meeting undefined behaviour.

I hope I have made this point clear. Your point (suggesting an improved feature to mIRC) is also clear to me. If you had made this point in the first place instead of leading yourself up the garden path you may not have had to resort to belittling others who have tried to help and educate you.

As further reading, somewhere in the archives here (over the last couple of years) there have been other discussions in replacing outputs of functions with "$null" to get around similar poorly defined outputs.

Cheers,
DK.

Your original point seemed to revolve around expected behaviour, not documentation, but anyway...

I believe this thread is a testament to the effort made to sufficiently define the behaviour for you. Has it not been sufficiently defined?

If you meant the help file, you're barking up the wrong tree. Adjustments to the help file are rarely made. You can feel free to suggest it, but it's not likely to happen.

One of the great things about mIRC's community is that there is a relatively active forum and at least a few IRC support channels whose purpose is to act as an addendum to the help file. The help file will never be perfect or cover every detail of the language, so, in cases like these, a forum or IRC channel is a much better source of information. There is also a wiki that has some interesting information.

With that in mind, why is a response on the forums not a sufficient description of the behaviour?