BF Feedback on 2nd beta
Looks like the issue of dropping a digit when translating certain numbers to %hexlen >= 26 is fixed, but the hex result are still 93% inaccurate and higher in that example for %hexlen 27 and greater.
And, the examples are still wrong for 2^103 2^120 and longer.
I think the issue is like I mentioned earlier, where they have a m_apm_integer_pow and m_apm_integer_pow_nr, and the m_apm_integer_pow_nr (not rounding) might be slower, but it doesn't return inaccurate results which appear somewhere around 2^103. I don't understand what m_apm_integer_pow is doing, but I see the subroutine using m_apm_iround which indicates that it plans to be inaccurate at larger, and this is probably affecting $base() since the %hexlen 27 errors are creeping in at close to the range where ^ fails.
If there's a big speed in difference, then perhaps an early check of $log(base^exponent) to see which algorithm should be used if exponent is an integer and it's it's not obvious from the base/exponent combo.
--
The M_pow_mod function for modular exponentiation that I was asking if could be made an identifier, but was mentioned only in function.ref - somehow I missed them having a slightly different spelling in filename mapm_pwr3.c as m_apm_powmod.
However their m_apm_powmod appears to be not what I'm looking for, because it looks to be of the rounding variety, and would probably not return correct results eventually, as I see it also using m_apm_iround same as m_apm_integer_pow does, and the comment inside it makes it look like it's intentionally supporting fractions.
--
However, when using the demo bf_modpow() alias I posted which mimics my proposed recreation of the assumed missing mod_pow function by modifying m_apm_integer_pow_nr, and use it with an absurdly huge modulus that's intended to not affect the 2^120 result, it does produce the correct result though it wastes a lot of time doing modular divisions that aren't needed:
//var -s %good.bf $bf_modpow(2,120,$str(9,120)) , %nope.bf $calc(2^120)
* Set %good.bf to 1329227995784915872903807060280344576
* Set %nope.bf to 1329227995784915872903807060280000000
If their rounding-modpow is close enough in behavior to their rounding-integer-pow, it probably still returns inaccurate for close to roundedmodpow(2,120,number larger than 2^120), but is instead designed to not bomb out at roundedmodpow(10,10360,modulus)
--
$rand(1,9) is down to 190% time factor in BF mode, so that looks like the kind of overhead seen from going into BF mode, as I see it from other small numbers like $base(100,10,36), so scripts may need to be judicious rather than always using /bigfloat on all the time.
