Thanks for the feedback.

Quote
Your list of identifiers affected by BF mode included $min $max, and since they behave like the various modes of $sorttok I assume that is also counted.
Fixed. The sorting routine used by $min() $max() and $sorttok() had not been updated to handle big floats. I have also updated this for /filter when sorting numbers.

Quote
This is a case where my suggested digits parameter for $calc and $log could help obtain good results without needing to wrap $round() around the output
I would prefer not to make changes to existing identifiers in this way. I could technically add a rounding parameter to every number-related feature. The $round() identifier is meant to handle this.

Quote
2 types of BF mode $powmod() gpf crashes
By the gods. This took time to track down. It is, as far as I can tell, a bug in the MAPM library. I reverted the few changes I made to the library to test this and it is happening in the original library.

It was due to MAPM returning ever-increasing decimal places when calculating "base = base * base % modulus" as it iterated through the while loop. Since the "base" variable is instantianted at the beginning of the loop, the more calculations performed on it, the more decimal places accrued. At a certain point, they started doubling in length with each iteration, resulting in thousands of decimal places.

This is happening in the m_apm_multiply() function. This function calls a M_apm_normalize() at the end to strip away trailing zeros but it does not adjust the decimal places to a length that is reasonable for the calculation. I have added code to this function so that it truncates the decimal places in the result to a reasonable size based on the inputs. This resolves the freeze issue. Let's see how this works out in the next beta.

Quote
So, if this is going to be used in doubles mode, the user needs to be warned that using this in doubles mode can easily return bad results when the modulus exceeds sqrt(2^53), such as (odd,anything,even) returning an impossible even result $powmod(3,46,$calc(2^32)).
This is an issue with all calculations prior to bigfloat. It is not specific to $powmod().

Quote
$calc ^
Quote
Possible partial fix for $calc ^
Quote
$calc_^_operator
Fixed.

Quote
//var -s %mersenne_twister.bf $calc(2^19937 -1)
Fixed. This was happening due to mIRC thinking the result was longer than the maximum string length. In such cases, it returns zero.

Quote
Big Integer
There are no plans to add support for this just yet. I am focusing on bigfloat.

Quote
Updated parameter checking on $gcd and $lcm
I am allowing a single number and floats for both of these.

My unit tests script for bigfloat is getting pretty large now. I have included the tests you've provided in your recent posts. If you have any other tests cases that you think would be useful, let me know and I will add them to the script.

Please hold off testing bigfloats in the current beta for now, as the next beta should resolve a number of issues.

These changes will be in the next beta.