mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Jun 2016
Posts: 2
H
Hurfie Offline OP
Bowl of petunias
OP Offline
Bowl of petunias
H
Joined: Jun 2016
Posts: 2
in my opinion $calc identifier is useless
it only calculate to the 6th decimal place like 0.000001
some of my calculations need more numbers like 14

this would be a good idea $calc(calculations,N) where N is the # of decimal places you want it to output, if no decimal place is given, it assumes 6.

Joined: Apr 2004
Posts: 871
Sat Offline
Hoopy frood
Offline
Hoopy frood
Joined: Apr 2004
Posts: 871
Originally Posted By: Hurfie
in my opinion $calc identifier is useless

Well, its hyperbolic capabilities are certainly no match for yours, but..

Originally Posted By: Hurfie
$calc(calculations,N) where N is the # of decimal places you want it to output, if no decimal place is given, it assumes 6.

..that is indeed (still) a good idea.


Saturn, QuakeNet staff
Joined: Dec 2002
Posts: 5,490
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,490
Quote:
Well, its hyperbolic capabilities are certainly no match for yours, but..

:-)

Quote:
it only calculate to the 6th decimal place like 0.000001

I cannot remember the exact reason for this, other than there were complicated issues many years ago relating to floating point precision, possibly due to the Visual C++ compiler version that was being used. Handling floating point values correctly can be tricky eg. see here and here. mIRC originally used floats, which had half the precision of doubles - so a maximum of seven digits. The seventh digit was eventually discarded due to rounding issues, noise, etc.

mIRC moved to using doubles many years ago, and enabled options in newer versions of Visual C++, such as the precise floating point model, to resolve a number of issues, so it should be possible to change the routine that chops floating point values to use fourteen instead of six digits. However, this routine is used in many places in the scripting language to try to ensure floating point consistency, so it will apply to all calculations and would not be optional. I will change it for the next beta and we can see how it works out but we will have to keep an eye out for any side-effects.

Joined: Jul 2006
Posts: 4,185
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,185
Well the side effect is that thousand of scripts now have to add $round (or something) when displaying something coming from $calc, because 14 decimals are not that great when displaying the number.
I'm not sure if that's better but that would prevent this issue, adding a property to $calc to get this behavior and restore the previous one: $calc().ext


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Apr 2010
Posts: 969
F
Hoopy frood
Offline
Hoopy frood
F
Joined: Apr 2010
Posts: 969
I feel this is a bad/invalid case. People that wanted to display pretty numbers after using $calc are most likely already using $round() to 'pretty print' said numbers.


I am SReject
My Stuff
Joined: Apr 2004
Posts: 871
Sat Offline
Hoopy frood
Offline
Hoopy frood
Joined: Apr 2004
Posts: 871
I agree. As long as $calc(2 + 1) doesn't result in 3.00000000001 etc - and in the new beta it doesn't look like this is the case - then I doubt there will be many problems with existing scripts.


Saturn, QuakeNet staff
Joined: Jul 2006
Posts: 4,185
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,185
Well ok, we'll see! But $calc is so wildly used, I'm surprised Khaled went ahead that way instead of using a property or whatever to get the new behavior without risking breaking stuff. I still predict people coming on the forum/IRC about this. Think about all the point system script that were so popular some times ago, now the twitch bots.


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
But adding precision should not "break" anything from a functional perspective. The risk of actually changing the behavior of a script is low to nil.

At worst it breaks aesthetics, which is not really significant. Frankly, if your script was displaying floating points without $round() in the first place, it was already broken, since it would have been displaying 6 decimal places-- I doubt anybody wants to see precision to more than 2 decimals in any "point system" script. And technically, a PRIVMSG to a channel that says "%2.562858258205" instead of "2.568367%" shouldn't really be considered "broken" to anyone.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Jul 2006
Posts: 4,185
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,185
I get your point, but the display of the output of a script on IRC is a huge part of functionality, I'm afraid.
Quote:
if your script was displaying floating points without $round() in the first place, it was already broken, since it would have been displaying 6 decimal places
Exactly, my script would be broken/incomplete, yet Khaled always fought for backward compatiblities.
I once asked that /scid and /scon should be able to see the $1- identifiers, since they are as local as a local %variable, which works, I have been answered that it could break script, Khaled argued that a script could be using $1- in a /scid line and expecting it to be $null, I kindly demonstrated that this was non sense and that literally 0 mIRC script would do that or they would be wrong/incorrect/broken, but nothing did it. Then this comes up, it's not a bad change, I'm not against it, but objectively speaking it will lead to troubles, much more than my scid story!
I understand that although he want to preserve compatibility, sometimes you have to move forward (unicode being a nice example), but it's hard to see [your] very valid suggestion being turned down because of backward compatibilities and then seeing some compatibilities changed.

https://forums.mirc.com/ubbthreads.php/topics/222347/ !!


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Backward compatibility does not imply aesthetic compatibility. Aesthetic behavior will be changed by almost any update to mIRC ever, since aesthetic changes are required to do simple things like:

1. Add new options to dialogs
2. Include new confirm dialogs
3. Create dialogs / UX for new functionality
4. Support new unicode characters (like, say, Emoji)

You cannot expect mIRC to have the same aesthetic throughout its evolution. As long as functionality remains the same, there's no issue with changing aesthetics, even of script output.

If you can provide an example where a script would follow a different code path due to this change, please raise it as a backward compatibility concern.

Your issue with /scid is fundamentally different from $calc (though I agree it wouldn't have a large impact) because changing the expectation of $1 being non-null would change (non-aesthetic) script behavior if a script was incorrectly relying on it. Adding precision to $calc() would not change (non-aesthetic) behavior, even if a script was doing something "incorrect" with the number.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Apr 2004
Posts: 871
Sat Offline
Hoopy frood
Offline
Hoopy frood
Joined: Apr 2004
Posts: 871
Complaints about specific other issues really have no place in this thread.


Saturn, QuakeNet staff
Joined: Jul 2006
Posts: 4,185
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,185
I'm just talking about scripts, the idea of a poorly written script sending a message to a channel involving a $calc(), resulting in a number with decimals, is real.
It won't matter to these scripts's authors if you call it broken or not, they will call it broken, and that's what matter here, that's why Khaled tries to preserve comp.
Certainly I exaggerated the number of scripts touched by this, but I do think it will happen: people will report issue, maybe not in the form of a bug report, but certainly in the form of a Script & popups thread.
The point is that if you take a change that will change real behavior rather than aestetic, it's the same issue, you don't want to change it because of the consequences, this is the same, it's aestetic but this change will get people to ask 'how do i fix this' and we are going to say 'by using $round', which is (deep inside) not different from explaining people about unicode and code pages


@Sat yeah it was just like that, I'm not going to start a thread about all of my suggestions which were 'ignored' because of backward comp, they are a lot of them, and not just from me.

Last edited by Wims; 12/06/16 10:56 PM.

#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Originally Posted By: Wims
I'm just talking about scripts, the idea of a poorly written script sending a message to a channel involving a $calc(), resulting in a number with decimals, is real.


This is a misleading statement. Yes, a script may generate decimals with $calc, but only if the script was already generating decimals. Your statement makes it sound like the script would previously never have had decimals in the value. This would never be the case, even for a "poorly written" script.

It's important to understand what this change actually does: it increases precision for existing floating point values. It does not generate floating points for values that were previously only integers.

That's why this is compatible. Because if your script generates floats, you're already getting a certain precision-- this change simply adds more decimal places to an already existing float. It turns 3.131313 to 3.13131313131313 (or so). Scripters would not consider this broken unless they expected "exactly 6 decimals", but this wouldn't be a likely expectation-- in truth, they likely didn't care about the precision in the first place if they weren't using $round.

And again, this doesn't change anything functionally. If your bot all of a sudden prints out a few extra numbers to more accurately describe a value, it wouldn't have an impact on the ability to use the bot. The output might be "uglier", but it still works the same.

You're misrepresenting what "compatibility" means. With your definition, no change to mIRC could ever be made. Quite simply, this change is backwards compatible because all scripts will continue to function correctly (the correct result for the correct input).


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Jul 2006
Posts: 4,185
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,185
Yeah sorry, I did mean a script which would already send decimals, the idea being that the scripter didn't know he cared wink (edit: which you mentioned, didn't see that)
And yeah I know about it being aestetic, not really breaking comp, but like I said it's about the consequences. I'm the first one who wants mIRC to move forward!

Last edited by Wims; 12/06/16 11:04 PM.

#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
This is invalid. If the scripter doesn't care whether there could be decimals, then it follows that they don't care how many decimal places there are. You can't really have it both ways.

Consider the most obvious example, a !calc script, where mIRC just spits out the result of $calc() to a channel:

Code:
on *:TEXT:!calc *:#:msg # Result is: $calc($2-)


If the idea is that a number could be an integer (!calc 16/4) or a double (!calc 16/7), the scripter shouldn't care about the precision. If they did care about precision, they would have $round() to limit it.

The "worst case scenario" is that the scripter does care about precision, but wanted at most 6 decimal places, and then assumed that since $calc() currently ever only showed 6, there was no reason to use $round(). This is probably the case you are arguing, but the script still functions, it just looks different. The result is still technically correct, even if aesthetically less pleasing. This would be unlike your scid example, where a similar assumption could outright change the correctness of a script (e.g. cause you to kick the wrong person, go into an infinite loop, etc).


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Jul 2006
Posts: 4,185
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,185
I'm arguing about the consequences (like we both said, the scripter would be unaware that he cared, he would care after seeing how this change affect the display), again I'll repeat, I know it's not a broken behavior, that it's aestetic, but it doesn't matter if you do not call it broken, if this were touching a very large number of people and hundreds of post about this were to see the day in the script & popups section, it wouldn't be great, I'm arguing that we should prevent that, well now obviously you guys don't think it's going to happen, so no problem


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
It does matter whether you call it "broken". If the behavior continues to be correct and does not break the functionality of scripts, it shouldn't be called a breaking change, period. And if it's not a breaking change, it's not a backward compatibility issue.

And to be frank, the actual number of people this is likely to affect, even aesthetically, is extremely low. You're really not going to see "hundreds of posts" about this change. The cross section of people this affects is limited to scripts that deal with a large amount of irrational numbers and display them without $rounding.

This is already unlikely: considering that mIRC already displays up to 6 decimal places, you're not going to find many scripts that are displaying all 6 decimal places of a floating point value in a polished/distributed script. You're talking about a script that currently does this:

<+RPGBot> Wizard attacks using Magic Missile and deals 64.295829 damage!

Or one that does this:

<+ElectionBot> Candidate A has won the #CHANNEL election with 64.258724% of the vote!

Or even:

<+SpeedTestBot> You downloaded 422.875 mb in 38.291758 seconds at a rate of 11.043499 mb/s.

None of these is aesthetically pleasing in the first place, and if aesthetics mattered to these scripters/users, they likely would have already changed these values to truncate floats to a reasonable precision for display purposes. To be clear, neither of the above are using a reasonable precision for display purposes (usually 1-2 decimals). You're talking about a really small subset of scripters/users that (a) care about aesthetics enough to think 7+ decimal places is too much but also (b) don't care about aesthetics enough to have $rounded to (at most) 6 decimal places. Recall that ~14 decimal precision does not mean all floats will have 14 decimals. Many still won't (though it depends on the set of numbers being used).

Will this affects at least a few scripts? Probably. Will people notice? Maybe. Will those users consider this important enough to even bother trying to fix? Perhaps. Would this create a burden for the forum? I highly doubt it.



- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"

Link Copied to Clipboard