Forums Bug Reports $base identifier

hello, i was trying to manually write a number conversion alias when i realize that there is a $base identifier that does what i wanted to do.

problem was that, it doesn't do limit checks. meaning to say if i were to do something like $base(g,16,10), it would return 16 instead of an error say -1 or something. likewise if i were to do $base(8,8,10), it would return 8, which really makes no sense because 8 does not exist in a set of octals, or g in a set of hexadecimals for that matter.

sure we could all write a script to check for these limits before we feed it into the $base identifier, but since the identifier is there, might as well modify the source a bit to return an error value when an illegal number has been found?

what do you all think?

mIRC seems to be ignoring the value passed as $2 (number of possible digits) seems to be a bug to me...

It doesn't really ignore the 2nd parameter (the inbase). It's just that $base() is not strict, it won't complain if you use something like $base(1A2,3,10) but will calculate the result as expected:
2 * 3^0 + 10 * 3^1 + 1 * 3^2 = 41
The fact that it returns a different (but correct) number with something like $base(1A2,4,10) (where it outputs the correct 58) makes me think that this isn't a bug: I wouldn't expect a bug to always output the "correct" result, which means that it does what it does intentionally.

I can imagine why some people don't like this behaviour, but I rather like it the way it is. If something should be fixed first are the other $base() bugs (which are very real I'm afraid).

Well A is not a decimal digit, if I type $calc(A + 2) I get 2, not 12. If mIRC treats decimal digits as 0-9 elsewhere, why should it treat 0-Z as decimal digits in $base?

Because it has to for inbase/outbase values that exceed 10. The source for $base is exceedingly simple, and yes, buggy too (does precision even do anything?)

I however like the current way $base returns, even if you use a digit that exceeds the inbase bounds. I think this is quite handy infact.

Now if there were only a way to specify a custom inkey/outkey, $base would be a blast for simple ciphers.

- Raccoon

You're not making sense there. "because it has to" not it doesn't have to. I just tested with the C function, if I tell it to convert from a base 10 to a base 10 it prints 0 when I enter "A" because "A" is not a decimal digit. However if I use "A" and tell it do convert from hex to decimal then it correctly outputs 10. If it "has to" how come the C function to do the same thing doesn't "have to" as well?

The 'because it has to' is my response to your question why should it treat 0-Z as decimal digits in $base?. I understand that the C function uses more precise bounds checking, but the mIRC one does not. No, mIRC doesn't 'have to' return 10 when you pass A for any inbase below 11, but it does for those that exceed 10. Again, Khaled seems to have decided (at least indirectly) that this part of the bounds checking should be left up to the user, to allow greater freedom for other users who desire this effect. I personally hope he keeps it this way.

- Raccoon

That, or he mistakenly forgot to add the check that would make it fail.