Здравствуйте, T4r4sB, Вы писали:

TB>Даже одна и та же формула в разных контекстах может выдать разный результат на одних входных данных.

что-то не верится, а пруфы будут?

Здравствуйте, sergii.p, Вы писали:

SP>что-то не верится, а пруфы будут?

Ну я могу найти ту давнюю тему.
А суть простая: расчёты велись в 4-байтном флоате, в одном месте оптимизатору хватило регистров сопроцессора чтоб хранить промежуточный результат, а в другом нет и он выгружал всё в память, в 4-байтный флоат, с потерей точности.
Короче нельзя закладываться в плавучке на точный результат. Я даже опасаюсь сравнивать с нулём переменную, которую явно инициализировал нулём, но это уже шиза конечно.

Здравствуйте, cppguard, Вы писали:

C>1.001 непредставимо в виде двоичной дроби. О чём речь? Или вопрос был про 0b1001?
Мда... Ты смотрнишь на деревья (пример) но не видишь леса.
Речь шла про дробную часть, которая в десятичном виде будет иметь нули после точки.
Ты когда выводишь дробную часть как int — эти нули протериваются. Т.е. там где у тебя должно было быть 1.0012345ёклмн будет выведено 1.12345ёклмн
Прочитай ещё раз спойлер в моём ответе.

Здравствуйте, B0FEE664, Вы писали:

C>>За тестирование спасибо. Насчёт переполнения — предполагается работа только с uint8_t и форматами чисел Q4.4 и Q1.7, остальное не интересует, поэтому я и не особо старался.
BFE>Я правильно понимаю, что:
BFE>Q4.4 — это две таблицы по 16 элементов.
BFE>Q1.7 — это 0 или 1 и таблица на 128 элементов.
BFE>?

Олдскул, но да, можно и так. Только есть ненулевая вероятность, что придётся uint16_t поддерживать.

Здравствуйте, CreatorCray, Вы писали:

CC>Мда... Ты смотрнишь на деревья (пример) но не видишь леса.
CC>Речь шла про дробную часть, которая в десятичном виде будет иметь нули после точки.
CC>Ты когда выводишь дробную часть как int — эти нули протериваются. Т.е. там где у тебя должно было быть 1.0012345ёклмн будет выведено 1.12345ёклмн
CC>Прочитай ещё раз спойлер в моём ответе.

Тогда формулировка максимально непонятная. Мог же просто сказать: "ведущие нули теряются"? Но вопрос вообще был в целом про подход. Я не знаток С++, и не знаю, как рассово верно нужно реализовывать такие вещи. Если нормально сразу числом отдавать, то можно просто через iomanip установить количество ведущих нулей. Если же надо по одной цифре отдавать, то другой подход. Собственно, об этом и был вопрос. В Java я одним кликом декомпилирую JDK и смотрю, как написаны фундаментальные вещи. В С++ просмотр исходников STL это боль и унижение и чтение кода вида __my_type__ SAFETY_MACRO(__name_stl_xxx__) (__type1__ __ANOTHER_SAFETY_MACRO__(__arg1__)).

Здравствуйте, cppguard, Вы писали:

C>Я не знаток С++, и не знаю, как рассово верно нужно реализовывать такие вещи.
А при чём тут С++?
Вопрос в другом: тебе это надо чтоб работало на девайсе где вообще поддержки float нету ни в каком виде, даже софтварном, что ты так извратился?
Ибо ведь куда проще конвертнуть в float/double и напечатать его.

C>В С++ просмотр исходников STL это боль и унижение
А зачем ты туда вообще смотришь? STL это пример плохого кода и как делать не стоит

C> и чтение кода вида __my_type__ SAFETY_MACRO(__name_stl_xxx__) (__type1__ __ANOTHER_SAFETY_MACRO__(__arg1__)).
Дадада, живые люди так не пишут.

Здравствуйте, CreatorCray, Вы писали:

CC>Вопрос в другом: тебе это надо чтоб работало на девайсе где вообще поддержки float нету ни в каком виде, даже софтварном, что ты так извратился?
CC>Ибо ведь куда проще конвертнуть в float/double и напечатать его.
Да, микроконтроллеры. Современный С++ со всеми его вычислениями на этапе компиляции позволяет писать низкоуровневый код чуть безопаснее. Всякие ништяки есть типа сoroutines, с помощью которых почти бесплатно реализуется кооперативная многозадачность. Программная поддержка float есть, но для неё генерируется слишком много инструкций, и мало того, что это медленно, так ещё и драгоценная память съедается.

C>>В С++ просмотр исходников STL это боль и унижение
CC>А зачем ты туда вообще смотришь? STL это пример плохого кода и как делать не стоит
Так стандарт в индустрии же?

Здравствуйте, T4r4sB, Вы писали:

SP>>что-то не верится, а пруфы будут?

TB>Ну я могу найти ту давнюю тему.
TB>А суть простая: расчёты велись в 4-байтном флоате, в одном месте оптимизатору хватило регистров сопроцессора чтоб хранить промежуточный результат, а в другом нет и он выгружал всё в память, в 4-байтный флоат, с потерей точности.

Это

Автор: netch80
Дата: 01.12.16

, наверно?
А ещё на хабре.

TB>Короче нельзя закладываться в плавучке на точный результат.

Вообще-то там где нет неожиданного внутреннего расширения и сужения — то есть для x86 это означает только SSE, без x87 FPU — именно этой проблемы уже нет, и, если оптимизатор сам ничего не накрутил — можно предполагать, что два идентичных по форме вычисления дадут одинаковый результат независимо от того, что было в регистрах, а что в памяти.
И даже с x87 можно получить аналогичное с доп. мерами компилятора (-ffloat-store для GCC), но это дороже.

TB> Я даже опасаюсь сравнивать с нулём переменную, которую явно инициализировал нулём, но это уже шиза конечно.

Для точных значений, гарантированно влезающих в самый узкий диапазон точности из использованных — точно шиза.

Здравствуйте, T4r4sB, Вы писали:

N>>Вот тут... в пределах корректных операций IEEE754 простые операции (арифметика плюс какой-нибудь sqrt) должны считаться везде одинаково, расхождения должны начаться где-то с sin, log* и дальше в трансцедентные функции. И то насчёт sin не уверен.
N>>Хотя, если где-то тупые реализации, ХЗ...
N>>Но это значит что вы сделали свои реализации — пусть с погрешностями, но одинаковые.

TB>А вот хрен. Расхождения зависят не только от режима компиляции.
TB>Даже одна и та же формула в разных контекстах может выдать разный результат на одних входных данных.
TB>Так что не доверяй плавучке

Если я правильно угадал в предыдущем комментарии, что ты имел в виду, то x87 FPU не соответствует строгому IEEE754, и проблемы возникают именно от этого — скрытых от программиста операций сужения точности. С SSE такого не возникает (или можно выключить, как флаг denormals-to-zero).

Но я согласен с тем, что для того, кто этого нюанса не знает, проблема может стать подлым ударом в спину.

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, T4r4sB, Вы писали:

SP>>>что-то не верится, а пруфы будут?

TB>>Ну я могу найти ту давнюю тему.
TB>>А суть простая: расчёты велись в 4-байтном флоате, в одном месте оптимизатору хватило регистров сопроцессора чтоб хранить промежуточный результат, а в другом нет и он выгружал всё в память, в 4-байтный флоат, с потерей точности.

N>Это

Автор: netch80
Дата: 01.12.16

, наверно?
N>А ещё на хабре.

У меня другая тема была, я рассчитывал, находится ли точка внутри выпуклой комнаты. Считал скалярные произведения и сравнивал с нулём, и внутри цикла одно и то же сравнение было положительное, а другое — отрицательное. И эпсилон тут бы не помог, сами понимаете, просто было бы, что одно сравнение "эпсилон-положительное", а другое "эпсилон-близкое".

Здравствуйте, cppguard, Вы писали:

C>Современный С++ со всеми его вычислениями на этапе компиляции позволяет писать низкоуровневый код чуть безопаснее.
А ты смотрел на ассемблер, который получается из твоего кода?

C>Программная поддержка float есть, но для неё генерируется слишком много инструкций, и мало того, что это медленно, так ещё и драгоценная память съедается.
Понятно. Ну тогда есть смысл изгалиться. Только я бы наверное делал форматирование сразу в строку а не городил бы эту борьбу с iostream.

C>Так стандарт в индустрии же?
Стандартная библиотека совершенно не гарантирует качества, она про одинаковость и доступность по умолчанию. Потому там дофига компромиссов и сложностей на ровном месте.

Здравствуйте, cppguard, Вы писали:

C>Здравствуйте, CreatorCray, Вы писали:

CC>>Вопрос в другом: тебе это надо чтоб работало на девайсе где вообще поддержки float нету ни в каком виде, даже софтварном, что ты так извратился?
CC>>Ибо ведь куда проще конвертнуть в float/double и напечатать его.
C>Да, микроконтроллеры. Современный С++ со всеми его вычислениями на этапе компиляции позволяет писать низкоуровневый код чуть безопаснее. Всякие ништяки есть типа сoroutines, с помощью которых почти бесплатно реализуется кооперативная многозадачность. Программная поддержка float есть, но для неё генерируется слишком много инструкций, и мало того, что это медленно, так ещё и драгоценная память съедается.

А как так вышло, что современный C++ платформой поддерживается, а float — нет? Так вообще бывает?

Здравствуйте, Alekzander, Вы писали:

A>А как так вышло, что современный C++ платформой поддерживается, а float — нет? Так вообще бывает?
Не совсем понимаю вопрос. Современный С++ можно хоть на калькуляторе поддерживать, а для аппаратное поддержки float нужны соответствующие инструкции процессора.

Здравствуйте, CreatorCray, Вы писали:

C>>Современный С++ со всеми его вычислениями на этапе компиляции позволяет писать низкоуровневый код чуть безопаснее.
CC>А ты смотрел на ассемблер, который получается из твоего кода?
Конечно =) А в чём вопрос? Мне не нравятся многие вещи в С++, но бинарник можно получить действительно почти такой же как на Си — "don't pay for what you don't use" во всей красе.

Здравствуйте, cppguard, Вы писали:

A>>А как так вышло, что современный C++ платформой поддерживается, а float — нет? Так вообще бывает?
C>Не совсем понимаю вопрос. Современный С++ можно хоть на калькуляторе поддерживать, а для аппаратное поддержки float нужны соответствующие инструкции процессора.

Я думаю, ты понимаешь вопрос, а не понимаешь, что меня удивляет. А удивляет меня, что под контроллер без FPU кто-то пишет компилятор современного C++ (какой, кстати? 17? 20?). Я бы дал голый Си и наказ не выёживаться.

Возможно, в этом есть какой-то смысл, но он от меня ускользает.

Здравствуйте, cppguard, Вы писали:

попробовал поправить код:

#include <iostream>

constexpr size_t pow(size_t base, size_t exp, size_t res = 1) {
    return exp > 0 ? pow(base, exp - 1, res * base) : res;
}

template<typename T, unsigned N>
class Q {
    T value;
public:
    Q(T value): value(value) {}
    T integral() const { return value >> N; }
    T fractional() const { return pow(5, N) * (value & ((1 << N) - 1)); }
};

constexpr size_t leading_zeros(auto v, size_t num) {
    return v == 0 ? num : leading_zeros(v / 10, num - 1);
}

template<typename T>
constexpr T remove_trailing_zeros(T v) {
    return v % 10 == 0 ? remove_trailing_zeros(v / 10) : v;
}

std::ostream& print_leading_zeros(std::ostream&  os, size_t n) {
    if(n != 0) { 
        os << "0";
        print_leading_zeros(os, n - 1);
    }
    return os;
}

template<typename T, unsigned N>
std::ostream& operator<< (std::ostream&  os, const Q<T, N>& q)
{
    os << static_cast<int>(q.integral()) << ".";
    print_leading_zeros(os, leading_zeros(q.fractional(), N));
    return os << static_cast<int>(remove_trailing_zeros(q.fractional()));
}

void println(auto v) {
    std::cout << v << std::endl;
}

int main(int argc, char *argv[]) {
    println(Q<int, 4>(0b101101));
    println(Q<int, 4>(0b101000)); // trailng zeros
    println(Q<int, 3>(0b101101));
    println(Q<int, 4>(0b100001)); // leading zeros
}

Вывод:

2.8125
2.5
5.625
2.0625

Здравствуйте, sergii.p, Вы писали:

SP>constexpr size_t pow(size_t base, size_t exp, size_t res = 1) {
SP> return exp > 0 ? pow(base, exp — 1, res * base) : res;
SP>}

Неоптимально, смотри алгоритм русского крестьянина для возведения в степень

Здравствуйте, cppguard, Вы писали:

C>>>со всеми его вычислениями на этапе компиляции
CC>>А ты смотрел на ассемблер, который получается из твоего кода?
C>Конечно =) А в чём вопрос?
Насколько много там было выполнено в compile time для этого кода?
Я там процитировал чутка больше чем следовало, пардон.

Здравствуйте, Alekzander, Вы писали:

A>А удивляет меня, что под контроллер без FPU кто-то пишет компилятор современного C++
Меня удивляет что тебя это удивляет.

A>Я бы дал голый Си и наказ не выёживаться.
И что, там от этого аппаратная поддержка float появится?

A>Возможно, в этом есть какой-то смысл, но он от меня ускользает.
Смысл в использовании на порядки более удобного и безопасного языка чем голый С.

Здравствуйте, T4r4sB, Вы писали:

TB>Неоптимально, смотри алгоритм русского крестьянина для возведения в степень

когда имеем дело с выводом в cout на спичках экономить бессмысленно (ещё и в ущерб читабельности)