If you can handle the rounding correctly you
could let (**)/2 behave as floating point pow(),
you wouldn’t see a difference to (^)/2 in less
than 1‰ (promille) cases. But currently there is
a systematic error somewhere which creates a
discrepancy in more than 50% of the cases.
See also here:
Rounding error in (**)/2
https://swi-prolog.discourse.group/t/rounding-error-in-2/5795
And you could gain some speed, because
SWI-Prolog (**)/2 is not really Math.pow(), its
slower than a Math.pow() based (**)/2:
/* SWI-Prolog 8.5.17 */
?- time((between(1,1000000,N), float(N)**10.0 =\= float(N**10), fail; true)).
% 2,000,000 inferences, 0.953 CPU in 0.954 seconds (100% CPU, 2098361 Lips)
true.
/* Jekejeke Prolog 1.5.4 */
?- time((between(1,1000000,N), float(N)**10 =\= float(N^10), fail; true)).
% Threads 453 ms, GC 3 ms, Up 466 ms (Current 09/21/22 19:14:43)
true.
But maybe the above figures look better with the new (**)/2 ?
In many cases above the result doesn’t fit in smallint. Not
sure why its slower, possibly no speed up with new smallint
fastpath for (**)/2 since it doesn’t fit. But the slogan could be,
by allowing less than 1‰ (promille) and eradicating the 50%
discrepancy, you get double the speed. Or you eradicate only
the 50% discrepancy, and don’t do a speed up. i.e. Only fix
(**)/2 somehow but do not switch to Math.pow().