Стоит обратиться к ранее эмпирически выведенным фактам:
- среда программирования Arduino IDE. Int занимает 2 байта и является точной копией short int. Если работать именно с платформой Arduino Nano - float=double=4Б - double ведёт себя как float, с соответствующей точностью;
- среда программирования Qt v.5.3. Функция pow() способна корректно вернуть значение только до 53 степени - далее результат искажается - пришлось писать свою функцию unsigned long long. В Qt v.5.15 данный баг убран. В интернете есть сообщение о том, что какая-то другая среда программирования допускает использование в pow() только до ~22 степени двойки;
- операционная система. В Windows long занимает 4Б (синоним int), в Linux - 8Б (синоним long long). Это привело к хлопку пердака.

Заинтересовался точностью хранения данных в double и long double разных сред программирования. Как начал с Qt - так и закончил: по сравнению с BCB v.6.0 - ни число в переменную засунуть нормально не может (ясно, что нужно подписать ".0", - но это лишние телодвижения, коих в Qt великое множество), ни использовать её в циклах (а это совсем беда: при анализе погрешностей long double только такой тип данных в циклах и использовался в BCB).

Думал использовать функцию pow() для понимания точности хранения данных - и в процессе наткнулся совсем на другое. Во всех нормальных C-подобных языках: переменные с плавающей точкой имеют маленькую погрешность - что порождает проблему их сравнения, например, с целочисленными переменными. Что сделали Qt v.5.15: избавились от этой погрешности при сравнении чисел. Число 2⁶⁴-1 в double и unsigned long long - сравниваются с помощью != корректно. Но убив погрешность при сравнении - они убили и точность сравнения. У double можно отнять любое число до 1024 включительно или прибавить до 2048 включительно - и "равенство" будет упорно соблюдаться. Невозможно убрать то, что существует на физическом уровне при хранении мантиссы в RAM, - в Qt решили тупо это скрыть (как и отмазались при получении времени выполнения исходного кода).

Qt - говно.