Thanks for the feedback.
#1. Just mentioning now before it's too late to change to consider a change.
I experimented with both %var.bf and %bf.var and prefered the current naming method with .bf at the end, which also works out nicely with %.bf.
#2 -switch for /hdec /hinc + $hget(table,item).bf
I experimented with different ways of supporting bigfloats. In the end, I chose to avoid making changes to commands, identifiers, and the scripting language in general. This means not adding switches, options, properties, and so on. Bigfloat should just work and, currently, you can make it work just by using /bigfloat [on|off] or by using a %var.bf.
#3 Yay, $round in bigfloat mode is much better at rounding '5' the correct direction, and my simplistic example on wikichip doesn't fail in bigfloat mode.
I honestly have no idea whether this is the correct behaviour. What you are seeing is due to the way MAPM handles precision and rounding. Specifically, in this case, it is due to modf(), used in the rounding function to get the fraction. The Visual C++ modf(), TTMath modf(), MAPM modf(), and likely modf() in other libraries, all return slightly different fractions. The number 0.05 is being returned as:
Visual C++:
0.049999999999999822000000000000
TTMath:
0.049999999999999996000000000000
MAPM:
0.050000000000000003000000000000
IEEE 754 Floating Point (
https://baseconvert.com/ieee-754-floating-point):
32bit: 0.0500000007450580596923828125
64bbit: 0.05000000000000000277555756156289135105907917022705078125
If I decide to switch to a different bigfloat library at some point, the results will likely be different.
I do not plan to add support for this unless someone adds it to the MAPM library.
#5 $calc ^ operator fails
It looks like a bug in the MAPM pow() function. It was not calculating the required amount of precision correctly. I have changed it and it looks like it is working as expected now.
#6 $base() rounding/dropped digits
This again looks like a precision issue in the MAPM library. It was using one less digit of precision than necessary in some contexts. Fixing this seems to resolve this issue and hopefully other issues.
I do not plan to update commands/identifiers that are not directly involved in calculations.
#8 $rand $rands.
But JSF64 returns just a single uint_64, so I wasn't sure if the BF results are obtained by appending several JSF outputs together until the underlying pseudo-random results is >= the requested range size.
Yes, this is how I implemented it.
Whatever is happening with $rand in BF mode, it's causing the time for $rand(1,9) to increase 7x
Ha! I was trying to be smarter than I am and was using a convoluted method for determining the required bits based on the range size. Fixed for the next beta.
#9 $pi Returns the value of the mathematical constant pi to 20 decimal places.
I have changed $pi so that, in bigfloat mode, it includes 50 decimal places.
In BF mode the $calc() operator ^ causes a GPF when the return value is too long.
Fixed next beta.
Looks like I spoke a little too soon about $round being golden. While $calc outputs a fraction up to length 30, it looks like $round can only output length 20.
That's a maximum length I left in the $round() identifier by mistake. Fixed next beta.
Please hold off making new feature suggestions for now. I would really like to make sure this feature is working correctly before making any more changes.
Please also hold off any more bug reports until the next beta, as it includes quite a few fixes.
