Forums Bug Reports Division inconsistency

$calc(8670007398507951000000000 / 4294967296) returns 2018643403078418, whereas Windows calculator reports "2018643403078417.9922193288803101". So far mIRC has been reliable for many things, but apparantly it's useless when dealing with large numbers. (I have an actual reason for making this division, I'm not just trying to see where mIRC will screw up.)

I'd love to know what reason could possibly generate such large numbers

Solving mathematical problems. For example, searching for (F[x] % 2^32)=0 when F[x]=F[x-1]+F[x-2] (Fibonacci sequence).

You could of course try to use a program made for such things. mIRC wasn't made for complex mathematical stuffs.

Nah I understand wanting to do it in mIRC... I'm always looking for ways to do things while online chatting, too.

And since a computer is just a big calculator (*grin*), maths seems as good a plaything as any - I mean, why have a scripting language if you don't experiment with it?

PastMaster

LocutusofBorg, your reply doesn't make sense to me. You're ready to dismiss my post because mIRC wasn't made for math purposes? This problem shouldn't be fixed because my usage of mIRC is deemed improper by you? It seems to me that people use mIRC for non-IRC related tasks just as much as IRC-related tasks, and it's needless to say that mIRC has features that have no association with the IRC protocol or the use of IRC servers. I think a feature should work properly no matter how it's used.

BTW, the math problem I was trying to solve with the aid of mIRC, IMO, isn't close to being complicated. The code involved with solving the problem is quite small, in fact.

exactly, if you had asked about a problem with /splay or /sockopen i doubt he/she would have said the same

I dont exactly see mirc needing a complex mathmatical operation. Yes, as you pointed out, mirc has included variious things to "enhance" the chatting experience, but if you've noticed none of them go dramatically away from chatting. Most are things you can do while you chat, not instead of chat. Listining to music, transferring (legal) files to each other, etc.. A mathmatical addition to do precise calculations doesnt really have a place in the IRC experience IMO. Though it may be convenient, its not entirely practical.

If you do need the extended math, try a dll or perhaps /run calc

Well don't you think that if it has been made available, it should work correctly? I do, and if it doesn't work correctly, I would call that a bug, complex operation or not.


Edit: Looks correct to me .. I got:
....$calc = 2018643403078417.992
Win calc = 2018643403078417.9922193288803101

was a $round(,0) added in there?

$calc(8670007398507951000000000 / 4294967296) returns 2018643403078418 here, without using $round(,0). I'm on Win98.

Basically: yes. If you start implementing everything into mIRC it would become like Windows - so many features that the basic features are becoming unimportant.


Not deemed improper by me -- mIRC is a chatting program, not a calculator. Your suggestions is at all unrelated to the concept of chatting. And while as suggested people like to do other things while chatting, I simply run another program at the same time and run it in the background.

As far as I know math problems in programming, I have had experience in programming where the choice of which type of number is imprtant for the outcome. There's integeres, floating point variables, signed and unsigned, blah blah. This could very well be a limitation in the choice Khaled made there, where he chose the simpler, less advanced option because the other, more complex option is unneeded during chatting.

Same here btw.

you win98 also ?

Same here on Win98se with 6.1.

Well I was beginning to think that maybe
it was an OS thing but then I got this:

5.61: 2018643403078418
5.71: 2018643403078417.992
5.82: 2018643403078417.992
5.91: 2018643403078417.992
6.03: 2018643403078417.92
..6.1: 2018643403078418

running XP Pro

Last time i checked this is the bug report forum not the future suggestion forum. Why do you always say negative things? Didnt your mother ever tell you if you cant say something nice dont say anything at all?

You realise that instead of subtling upping your post count, you CAN use bold heading to respond to the person you've intended--right?

Online

Don't you agree?

Who here has used a screw driver to open a can of paint? Perhaps you've used a paper towel to hold a slice of pizza when all the plates were in the dish washer? Have you used a pen to scratch your back? (etc., etc.) You must be breaking some rule or law of ethics (sarcasm)! Original intent of a product means nothing (when it comes to there being a bug in the product that should be fixed), and neither does any of your replies. Your replies have been completely irrelevant.

The fact is that mIRC provides a feature (the $calc function). The mIRC help file gives no warnings of stipulations/limits, such as the size of numbers given as arguments to the $calc function. Since the help file does NOT warn of a limit, while it IS limited, I consider this a bug. If I tried to send data on a socket using mIRC without checking the queue buffer, I wouldn't complain if I received an error because the mIRC help file specifically states that the buffer is limited to a maximum of 16384 bytes. The help file clearly states that when using $round and $int for floating point numbers, "The number of decimals is currently limited to 5 digits". Again, no limit is stated about the $calc function in it's ability to process large numbers. To fix this bug, I think it either needs to be stated in the help file that $calc is meant to be limited, or else the limitation needs to be fixed.

I'm using mIRC 6.01 under Windows 2000 Pro.

Agreed. It doesn't matter for what "principal purpose" mIRC was made when $calc() is already there and no limit of this kind was clearly (yet?) related by Khaled. No one is entitled to judge its usage.