The mk_pf function of the rnalib.c-file, which is used to scale energy values of type int into a partition function value, sometimes gets called with non-int values.
I discovered this when working on PR #156, during which one Github Action kept failing due to a test not successfully completing. What ended up solving this problem was to check whether the mk_pf input value had a remainder equal to 0: trunc(x) == x.
This should not be necessary though, since the energy values this function scales are (supposedly) all int values (32 bits), which get converted to double values (64 bits, 52 bit mantissa) when they are passed to mk_pf. So since the mantissa of a 64-bit double can easily fit all possible 32-bit int values, every possible 32-bit int value can be represented as a double with a remainder of exactly 0. This means there can't be any loss of precision during the int-to-double conversion (unless g++ decided that double values should be less than 64 bits/8 bytes, in which case we could have loss of precision errors), which raises the question why some values that are passed to mk_pf are apparently not int values (or have a non-zero remainder)?
The
mk_pffunction of the rnalib.c-file, which is used to scale energy values of typeintinto a partition function value, sometimes gets called with non-intvalues.I discovered this when working on PR #156, during which one Github Action kept failing due to a test not successfully completing. What ended up solving this problem was to check whether the
mk_pfinput value had a remainder equal to 0:trunc(x) == x.This should not be necessary though, since the energy values this function scales are (supposedly) all
intvalues (32 bits), which get converted todoublevalues (64 bits, 52 bit mantissa) when they are passed tomk_pf. So since the mantissa of a 64-bitdoublecan easily fit all possible 32-bitintvalues, every possible 32-bitintvalue can be represented as adoublewith a remainder of exactly 0. This means there can't be any loss of precision during theint-to-doubleconversion (unless g++ decided thatdoublevalues should be less than 64 bits/8 bytes, in which case we could have loss of precision errors), which raises the question why some values that are passed tomk_pfare apparently notintvalues (or have a non-zero remainder)?