From WikiChip
Editing mirc/commands/bigfloat

Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.

This page supports semantic in-text annotations (e.g. "[[Is specified as::World Heritage Site]]") to build structured and queryable content provided by Semantic MediaWiki. For a comprehensive description on how to use annotations or the #ask parser function, please have a look at the getting started, in-text annotation, or inline queries help pages.

Latest revision Your text
Line 24: Line 24:
 
/while ()
 
/while ()
 
When these compare the $v1 and $v2 terms, being in .bigfloat mode causes the comparison to not be in doubles mode. For example, since doubles mode only keeps the most significant 53 bits, if() and while() both think that 2^53 and 2^53+1 are the same number. However this shows that /bigfloat mode is able to see them as different, and the 'match bigfloat' message does not display:
 
When these compare the $v1 and $v2 terms, being in .bigfloat mode causes the comparison to not be in doubles mode. For example, since doubles mode only keeps the most significant 53 bits, if() and while() both think that 2^53 and 2^53+1 are the same number. However this shows that /bigfloat mode is able to see them as different, and the 'match bigfloat' message does not display:
//var -s %a.bf 2 ^ 53 , %b.bf %a.bf + 1 , %a %a.bf , %b %b.bf , %x $bigfloat , %y.bf $bigfloat, %z $bigfloat , %foo $bigfloat %anything.bf $bigfloat | if (%a.bf == %b.bf) echo -a match bigfloat | if (%a == %b) echo -a match doubles
+
//var -s %a.bf 2 ^ 53 , %b.bf %a.bf + 1 , %a %a.bf , %b %b.bf | if (%a == %b) echo -a match doubles | if (%a.bf == %b.bf) echo -a match bigfloat
Note how each individual varset was in bigfloat mode only if %anything.bf is used, as evidenced by x y z being set to $false $true $false. Using %varname.bf only affects each individual command, so while the 1st if() jumps into bigfloat mode due to using a varname ending with '.bf', that has no effect on the following command. Using %varname.bf only the *remainder* of the command, which was why %foo was set to $false $true. Since "/bigfloat off" is the only way to disable bigfloat mode, there's no way to jump-out-of bigfloat mode for the remainder of that command once %anything.bf has triggered bigfloat mode, so the following shows $false $true $true:
 
//echo -a $bigfloat %varname.bf $bigfloat %varname.bx $bigfloat
 
The /bigfloat ON|OFF used in the command parm behaves as if a child alias and has no effect on the outer(parent) command, so the following echoes are "$false $false" and "$true $true"
 
//echo -a %varname.bx $bigfloat $left($findfile(.,*,1,bigfloat on ),0) $bigfloat
 
//echo -a %varname.bf $bigfloat $left($findfile(.,*,1,bigfloat off),0) $bigfloat
 
 
var/set math:
 
var/set math:
 
note how %a.bf causes accurate result beyond doubles range, while the %a.bx variable only has 53 bits accuracy - though using the /bigfloat ON command would have enabled both.
 
note how %a.bf causes accurate result beyond doubles range, while the %a.bx variable only has 53 bits accuracy - though using the /bigfloat ON command would have enabled both.
Line 57: Line 52:
 
//echo -a $base($base($sha1(abc),16,10),10,16) same as... | echo -a $upper($sha1(abc))
 
//echo -a $base($base($sha1(abc),16,10),10,16) same as... | echo -a $upper($sha1(abc))
  
The scope of bigfloat mode is that the called alias inherits the mode setting from the parent, but the parent is not affected by any changed setting in the child alias. And, enabling /bigfloat ON is only in effect for the duration of that alias until using /bigfloat off, so it's not a global setting that can be applied to all scripts without placing /BIGFLOAT ON at the beginning of each child alias and in each ON EVENT handler. For example, the next alias is called from the editbox...
+
The scope of bigfloat mode is that the called alias inherits the mode setting from the parent, but the parent is not affected by any changed setting in the child alias. And, enabling /bigfloat ON is only in effect for the duration of that script, so it's not a global setting that can be applied to all scripts without placing /BIGFLOAT ON at the beginning of each alias and in each ON EVENT handler. For example, the next alias is called from the editbox...
  
 
alias bftestsub { var %mode $bigfloat | bigfloat $1 | return $qt(%mode -> $bigfloat) }
 
alias bftestsub { var %mode $bigfloat | bigfloat $1 | return $qt(%mode -> $bigfloat) }
Line 82: Line 77:
 
Another is that you may need to verify the actual results to see if the bigfloat output is appropriate for your script, such as how in normal doubles mode it knows that $log2(2) is 1, but in .bigfloat mode it thinks the answer is 0.999999999999999985890799396948
 
Another is that you may need to verify the actual results to see if the bigfloat output is appropriate for your script, such as how in normal doubles mode it knows that $log2(2) is 1, but in .bigfloat mode it thinks the answer is 0.999999999999999985890799396948
  
While this is named 'bigfloat' it also allows improved accuracy for extremely large 'bigintegers', though calculations can sometimes be very slow when some parameters are huge. However the speed of scripts can be affected by how well the operations can be supported by the MAPM package that is geared toward long and precise fractions, but doesn't have an optimized method for some simple things like bitwise math operations. Also, some functions like $powmod are intended for usage in bigfloat mode, and does not provide accurate math in doubles mode when some parameters are as small as sqrt(2^53). For example, (odd^positive mod even) must always be odd, but the following example returns an even-number result while in doubles mode, but the 3rd powmod being identical to the 1st powmod returns the correct result due to the 2nd powmod having been jumped into bigfloat mode due to using a varname ending with .bf
+
While this is named 'bigfloat' it also allows improved accuracy for extremely large 'bigintegers', though calculations can sometimes be very slow when some parameters are huge. However the speed of scripts can be affected by how well the operations can be supported by the MAPM package that is geared toward long and precise fractions, but doesn't have an optimized method for some simple things like bitwise math operations. Also, some functions like $powmod are intended for usage in bigfloat mode, and does not provide accurate math when some parameters are as small as sqrt(2^53).
//var -s %base.bf 3 , %base %base.bf , %exp 46 , %modulus 2 ^ 32 | echo -a $powmod(%base,%exp,%modulus) $bigfloat $powmod(%base.bf,%exp,%modulus) $bigfloat $powmod(%base,%exp,%modulus)
+
 
 
By careful use of %variable.bf mixed with bigfloat on/off, you can get benefits from both systems, by obtaining accurance for some commands that need it, while skipping the slowdown for commands that don't.
 
By careful use of %variable.bf mixed with bigfloat on/off, you can get benefits from both systems, by obtaining accurance for some commands that need it, while skipping the slowdown for commands that don't.
  
Line 106: Line 101:
  
 
//var -s %a.bf $calc(2^256-1) , %a.bx %a.bf , %b.bf $xor(%a.bf,3) , %c.bf $xor(%a.bf,3,256) , %d.bf $xor(%a.bf,3,96) , %e.bf $xor(%a.bf,3,65) , %f.bx $xor(%a.bx,3,512) , %g.bf $xor(-3,3,512)
 
//var -s %a.bf $calc(2^256-1) , %a.bx %a.bf , %b.bf $xor(%a.bf,3) , %c.bf $xor(%a.bf,3,256) , %d.bf $xor(%a.bf,3,96) , %e.bf $xor(%a.bf,3,65) , %f.bx $xor(%a.bx,3,512) , %g.bf $xor(-3,3,512)
 +
</source>
  
Being in bigfloat mode also affects $numbits, which cannot return larger than 32 in non-bigfloat mode:
 
//echo -a $numbits($calc(2^53)) shows 32 because $bigfloat is false but %null.bf $numbits($calc(2^53)) shows 54 because $bigfloat is true
 
</source>
 
 
== Compatibility ==
 
== Compatibility ==
 
{{mIRC compatibility|7.72}}
 
{{mIRC compatibility|7.72}}

Please note that all contributions to WikiChip may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see WikiChip:Copyrights for details). Do not submit copyrighted work without permission!

Cancel | Editing help (opens in new window)