Switching between double, single and half

[samhatfield]

Currently it is quite convenient to switch between double and half precision, simply by changing RPE_DEFAULT_SBITS between 10 and 52 and toggling RPE_IEEE_HALF. Even though there is a performance hit from using the emulator instead of native double precision floats, this means I don't have to modify the code to compare these two scenarios or keep duplicate functions.

Is there a way to use the emulator in single precision mode? I asked Peter if I can just change RPE_REAL_KIND to RPE_SINGLE_KIND here, rebuild the library, and then set RPE_ACTIVE to false, but he suggested that there might be unexpected side effects.

This would be very convenient, as I've found maintaining two or more different versions of functions to be an absolute pain so far.

Thanks in advance.

[ajdawson]

You can try switching the RPE_REAL_KIND and RPE_ALTERNATE_KIND, this should be OK. There will still be a cast to double precision for truncate_significand, but the result will be (implicitly) cast back to single if RPE_REAL_KIND = RPE_SINGLE_KIND. However, since these are module parameters they can only be changed at compile time, and therefore you'd need to recompile the emulator. There may be unexpected difficulties with this, I don't consider it supported behaviour at the current time.

The better option would be to introduce a single precision emulation mode (like half precision) that does a range check on the resulting truncated number (exactly as for half precision). This could be controlled by a RPE_IEEE_SINGLE option. Do you want to have a go at implementing this @samhatfield?

The even better option? More generally we should have a think about emulating the exponent as well as the significand. You could then choose a combination arbitrarily and we wouldn't need the PRE_IEEE_HALF mode anymore. We can discuss this further if it would be useful. Ping @dueben.

[samhatfield]

Feel free to close this for now. I did briefly consider implementing the RPE_IEEE_SINGLE option as you suggested, but my preferred solution in the end was to use templating to write 'master' precision-agnostic versions of functions/subroutines and have Python automatically generate double, (native) single and reduced precision versions. These are then combined under the same interface.