Bigfloat feedback on 4rd beta.

  • So yes, scripts will need to determine the appropriate length of fraction to wrap $round() around some results, so in this situation they need to use $round to limit the precision to maybe 10 digits or so.

    //var -s %a.bf $beta $log2(2)

    * Set %a.bf to 1743 0.99999999999999999489848895823
    * Set %a.bf to 2385 0.999999999999999985890799396948
    .
  • Just confirming that negative exponents still gpf's the powmod, but floats as exponent are $int(parm2)
    .
  • /bigfloat -dN

    This setting you mentioned in other thread, since there's no backwards compatibility against a beta, instead of adding a $bigfloat().digits property, another option could be that the identifier could change from $true $false, and could be 0=doubles.mode and a number indicating the digits setting. That is, assuming it wouldn't be possible to set it to -d0.
    .
  • $calc(^) $base() padding

    Yay, at first stab I also am not able to find inaccurate integer results, including strings longer than $maxlenl.

    However now that there is improved accuracy, it exposes the padding issue I referred to last time, where zeropad has max 100, and I hadn't examined far enough to find that the precision parameter has max 10 digits.

    Formerly it didn't matter in doubles mode that zeropad had a max of 100 digits because the accuracy was 53 bits. At first I thought I'd happened to have stumbled across a current error in the $base calculation that wasn't stamped out, but it turned out that a large $powmod result translated to base16 was accurate, but wasn't being zeropad'ed to the length used in Parm4.

    Likewise for floats, with $base now able to return 30 digit fractions, using the precision parameter to shorten the 30 digits to any other number cannot result in a fraction longer than 10.

    The current workaround for the $base zeropad limit for integers is to use the example string manipulation below. If the string is a float instead of an integer, the string manipulation is only slightly more complex.

    For those wanting fractions from $base, it depends on what kind of results they want. From outbase=10 results it appears that the intent of $base is to always return truncated integers rather than rounding them, so if needing outbase=10 fractions rounded, the script should probably avoid using the $base precision parameter, and use $round instead.

    //var -s %a.bf $sha512(test9) | var %b.bf $base(%a.bf,16,10) | var -s %c.bf $base(%b.bf,10,16,$len(%a.bf)) | if ($len(%c.bf) < $len(%a.bf)) var -s %d.bf $str(0,$calc($v2 - $v1)) $+ %c.bf | echo -a $len(%a.bf) vs $len(%c.bf) vs $len(%d.bf)

    * 128 vs 127 vs 128

    //var -s %a.bf 1. $+ $str(5,31) , %b.bf $base(%a.bf,10,10) , %c.bf $base(%a.bf,10,10,1,20) , %d.bf $round(%b.bf,29) | echo -a $len($gettok(%b.bf,2,46)) vs $len($gettok(%c.bf,2,46)) vs $len($gettok(%d.bf,2,46))

    * 30 vs 10 vs 29

    //echo -a $base(1.999999,10,10,2,1) = 01.9
    .
  • lcm/gcd fractions/single-parm

    I don't plan to use single parm or fractions, so I was just defining the 'official' way that gcd and lcm work, where they're the result of 2+ integers, so fractions need not apply. And in .bf mode I can't get the error conditions to return anything other than the correct 0 result except from using a single parameter containing a float.

    In doubles mode, I'm not sure exactly what it's doing, because for $gcd(1.5,2.5) it recognizes that they're both integer multiples of 0.5, but for $gcd(1.6,2.4) it doesn't recognize that they're both integer multiples of 0.8

    If I had to define rules for how GCD can support fractions, I would probably assume that I should look to see which is the longer fraction, then determine what is the 10^n multiplier that makes both fractions into integers. Then I'd calculate GCD against the modified integer pair, and if the result is 1, then the result should be either 0, or do like for other cases where it would return result=1/multiplier. So for $gcd(1.6,2.4) it would use multiplier=10 to make both numbers be integers, and then get the result of $gcd(16,24)=8, and then return 8/multiplier = 0.8. But for changing gcd(1.98,1.99) where gcd(198,199)=1, the result would either be 0 or 1/multiplier aka 0.01. Though that would return a lot of 0.01's.

    As for how lcm is handling float inputs in doubles mode, it looks like it's using the shortcut of $abs(A*B)/$gcd(A,B), and when the GCD result is zero there can be some weirdly huge numbers due to $calc(number / approximately zero) similar to...

    //var -s %a.bf $tan(270).deg
    * Set %a.bf to 26971635138473917813752774720289175420.00639833942873200535778279421

    So because $gcd(1.6,2.4) is returning zero, $lcm(1.6,2.4) is doing some rounding against (1.6 * 2.4 / close-to-zero) and ending up with 8646911284551352. And $lcm(1.98,1.99) is probably doing something similar to end up with 17745083251765228.

    The wolframalpha link at the top lets you input for other kind of math problems, and their LCM and GCM commands both seem to return results as I previously described, but they refuse to return results for 1 input or if either input is not integer. In the input box at the above link, it lets you paste math like

    gcd(15,25)
    lcm(2,3,4,5,6,7,8,9)

    ... and they won't return a result for $gcd(1.5) $gcd(1.5,3) $gcd(1.5,4.5)
    .
  • $powmod syntax

    Likewise, Wolfram has a 'powermod' function that returns results as I described earlier for all combos of positive/negative/zero parameters. They also handle negative exponents the way I described, making 'powermod(A,-1,B)' be the same as the $ModInverse(A,B) of the mod_inverse function found in OpenSSL, but I know floats come first.