It's not working well :-(
there is a bug with $cos and $sin, because $cos(270).deg should be 0 and $sin(180).deg, too.

return 0.000001 (for example)

I honestly never used $sin/$cos before. but you might want to mix them with $int. for example $int(0.000001) would return 0 (integer)

try this ;-)

That looks like a bug to me. Those should definately be 0.

-genius_at_work

this doesn't really look like a bug, just seems that whatever algorithm is used for the trig functions (perhaps a taylor series) involves eg. raising them to high enough powers such that precision is lost.. it would explain why the precision gets progressively worse as you start dealing with larger and larger angles.. i.e. //echo -a $sin(360).deg $sin(3600).deg $sin(36000).deg which of course should all be 0. but, i just noticed $sin(3690).deg is 1 as expected.. doesnt really agree with that hypothesis

anyway, you could improve this by observing some trig rules like taking mod 360 since every angle is equivalent to itself mod 360. so $sin(5678).deg should be equal to $sin($calc(5678 % 360)).deg but isnt, although the latter is closer to the actual value

of course you've seen that taking mod360 isnt really enough, $sin(180).deg is still kinda wrong if only by a little

if that's still a problem there's a few ways to go from here, the first is using a little more trig and realising that, when considering these functions, every angle has a (possibly negative) equivalent acute angle. theres a few things to do here to determine the acute angle and the sign change, its not as simple as taking mod90. look up basic trigonometry for these rules

you could also of course just $round it off, 5 decimal places should do the trick. oh and 3rd option is to convert this number mod360 to radians, for some reason that appears to be more precise

//echo -a $sin(540).deg $sin($calc((540 % 360) * $pi / 180))

-0, but still numerically correct lol

I would say it's a bug in that the identifiers (by whatever method, and for whatever reason) are returning incorrect values. My $3.00 calculator can get it right, so why shouldn't mIRC?

Also, I'm not completely familiar with what the values of $tan().deg should be, but they look kind of strange to me. Correct me if I'm wrong here.

-genius_at_work

The $int identifier doesn't rectify the computational values that mIRC is returning in all cases.

Not knowing how its deriving at these values makes it difficult to answer your question, but I ran a few tests, and there is definately some issues with the values that mIRC is returning for these identifiers, they are incorrect, for $tan(N).deg included.

Bottom line is that $sin(180).deg should be 0, it's not - therefore it's a bug. Doesn't matter why it's wrong, how wrong it is, or how easy it is to work around. A bugs a bug and should be fixed.

While some other programming languages can sometimes come up with an accuracy-based issue of something like 1.01e-16 or something, mIRC's limited accuracy in calculations means there's no reason it should be experiencing these issues and more importantly is apparently raising that innaccuracy by many orders of magnitude in order to get the answer it returns.

Also it would be nice if the documentation actually stated what the .deg property does. I'm sure people can figure out it's short for degrees but they wouldn't know from the helpfile if it takes degrees as a parameter, returns degrees, or both. I know it says in versions.txt but a) nobody seems to read it and b) it's not in the shortened versions.txt distributed with mIRC anymore.

Thanks this has been fixed for the next version.