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.
Can you provide an example that does not use $base2() or any other custom identifiers? I need to test this with built-in identifiers.
$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.
Yes, using any form of big num or float is always going to be slower. MAPM seems to be quite fast compared to the other libraries I tested, so if I decide to switch to a different bigfloat library at some point, bigfloat may end up being even slower.
