Почему C++ не может без потери данных сдвинуть запятую во float типе данных?

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

(мя это на скриншоте и показал)

Всё у тебя правильно считается, просто float имеет точность в 6 знаков, а ты пытаешься вывести 10 знаков вот и получаешь то что получаешь выходя за границы точности. Вместо %.10f ты не хотел написать %.1f ?

Да, в Блендере есть Python, но мне нужно решить задачу исключительно шейдерами. Текстовое представление числа вывести на экран «крутилкой» (слайдером) в шейдере. В шейдере ввел 12345 в текстовое поле и на экране появилось это же число. Это значительно сложнее чем реализовать в Пайтоне, так как в шейдерах нет таких возможностей как в Пайтон.

https://ibb.co/bdkSwGp

ТАК ШЕЙДЕРАМИ ИЛИ ГЕОНОДАМИ

Возможно, проще и эффективнее преобразовать число в строку

Да. Но. В шейдерах такой возможности нет - https://ibb.co/bdkSwGp

Есть только узлы (ноды) математики которые полностью полагаются на C++ код

Если короткий ответ: так надо для инженерных и научных вычислений, чтобы минимизировать ошибки вычислений и одновременно получать модели, более-менее адекватные окружающему нас миру, сложному и до конца непознаваемому. Если нужна абсолютная точность, не используй стандартные типы данных. Используй, например, алгебраические (символьные), в которых численная оценка происходит один раз в самом конце вычислений. Будет что-то типа решения школьной задачки на бумаге, но только выполняться будет компом.

float value = 0.56f; //тут у тебя float
    value = value * 100.0; // а тут у тебя 100 это double ты f забыл. 

Выводит 56.00000000000000000000000000000000000000000000000000

Тебе никогда в жизни такие числа не пригодятся. Не лезь в крайности, хочешь точности не суйся дальше дианазона точности типа для float 6 знаков для double 15 знаков (всех и до и после запятой) дальше лезешь лови приведение числа к наибольшему чётному при округлении (если не путаю) и то будешь всё равно ловить ошибки точности ибо ибо. Используй библиотеки для больших чисел числа там вообще как строки представляются и можешь хоть каждую песчинку в млечном пути пронумеровать

это не округление числа, а преобразование числа в строку

Да, спасибо всем огромное! Я это знал 15 лет назад, но уже всё это позабыл. Так уж устроен мозг )) Но вы мне все очень помогли. Я благодарен вам!

https://ibb.co/bdkSwGp

Прикольно. А умножить на 100 и поделить на 10 уже предлагали?

0.56 * 100 / 10

value = value * 100.0; // а тут у тебя 100 это double ты f забыл.

Угу, точно-точно. Ошибка вышла у меня ))

Я тебе на это отвечу 4 буквы и 3 цифры: IEEE 754

А теперь в другую сторону

Я это знал 15 лет назад, но уже всё это позабыл

До своего рождения что-ли? Вот это память. .

Не лезь в крайности, хочешь точности не суйся дальше дианазона точности типа для float 6

Ок. Начинаю это понимать ))) Спасибо. Буду искать обходные пути в моей задаче https://ibb.co/bdkSwGp

Да я вообще маленький ребёнок, с математикой туго. Так что… так..

картинка у меня не открывается. Вот https://youtu.be/U0U8Ddx4TgE думаю такой формат тебе будет «роднее». Есть стандарт для вещественных чисел он и указывает как и что будет считаться. Хочешь бесконечной точности используй библиотеки для длинных вычислений так и гугли

Текстовое представление числа вывести на экран «крутилкой» (слайдером) в шейдере. В шейдере ввел 12345 в текстовое поле и на экране появилось это же число.

Так объясни подробнее. Ты хочешь ввести 12345 и в зависимости от крутилки вывести 0.12345 0.012345 0.0012345?

Есть ли вообще в C++ возможность получить математикой 0.56 * 10.0 = 5.6 без округления?

Можно воспользоваться рациональными дробями. Ну, на пример, из буста (https://www.boost.org/doc/libs/1_78_0/libs/rational/rational.html)

rational<int> A(58,100), C = 10 *A;

Кстати, я устранил ошибку https://godbolt.org/z/soEGa8Maz

Но stdout показывает 56.00000000000000000000000000000000000000000000000000 при умножении 0.56 * 100.0

В Java такой же результат https://godbolt.org/z/sYqh1TPzx

Но уже стало понятно, что в двоичном представлении 100 и 10 это не простой сдвиг «запятой» и это ответ на мой вопрос - https://www.h-schmidt.net/FloatConverter/IEEE754.html

Вообщем, вычисления на компе весьма приблизительные и не соответствуют реальной математике из-за двоичной системы и преобразований «туда-сюда».

Там всего 4 цифры. И зачем плавающая точка вообще в этой задаче?

Я по заголовку сразу заподозрил, что речь про плавающую арифметику. Так оно и оказалось. Она не для этого, совсем.

Бери инты и рассматривай их как дроби с неким фиксированным знаменателем. В Форте, например, так и делали, там плавающей арифметики не было вообще. И ничего, астрономию на этом считали.

Затем, чтобы вводимое значение разобрать в «цикле» на составляющие - https://ibb.co/2N0jcQJ

Как можно видеть, там нет привычных циклов, строк, других типов данных и так далее. Есть система нодов и простейшая математика. Больше ничего нету. Всё бы ничего, всё классно получается, но не могу вывести точно число на экран. Вводим 59, на экране получаем 58 и это при двух разрядах, а на 6 разрядах уже совсем другие числа выходят.

А теперь в другую сторону

ну семен семеныч…

#include <stdio.h>

int main() {
int n = 1234;

int k[12] = {0};

int i = 0;
while(n >= 10){
    k[i] = n % 10; 
    n /= 10;
    i++;
}
k[i] = n;

for(i = 11; i>= 0; i--){
        printf("%d ", k[i]);
}

return 0;
}

0 0 0 0 0 0 0 0 1 2 3 4 

и экспонента-степень двойки

Вот и ответ автору :)

Python специально делался под подобные задачи.

Да, буду думать как эти ограничения обойти. Осталась одна идея всего, но я её не реализовал ещё. Это нужно несколько дней потратить, чтобы переписать все связи нодов на новый алгоритм. Текущий алгоритм был совершенный и бузпречный, работало как «надо» пока не вскрылась проблема с точностью при умножении на «целое» число.

Потому что тебе нужны десятичные типы для чисел. Такая х...я даже в 1С есть. Например, тебе может помочь ответ в этой теме: https://stackoverflow.com/questions/14096026/c-decimal-data-types

Мя знаю, как работает блендер =(
Подход неправильный, но при такой простой задаче проблему спрячет round, как уже говорил.
https://ibb.co/x3hBS1W

Вводим 59

А так? https://godbolt.org/z/9an43T9Wf

Для таких тредов надо раздел на форуме сделать - «Горе от ума»

На самом деле нет, тут подсказали уже, что дело было в округлении при принтах на экране. Если 0,56 * 10, то это не будет 5,6 в Пайтоне:

>>> a = 0.56
>>> a * 10
5.6000000000000005
>>> a * 10 == 5.6
False
>>>

Но в Бленедере, в шейдерах, будет 5.6!!!! при определённых условиях, но если добавить ещё одно любое вычисление в поток, то уже не будет выходить тоже значение, будет 5.59999999 и это не даёт возможности для сравнения https://developer.blender.org/T95164

при такой простой задаче проблему спрячет round

Спрячет то спрячет, но при этом и спрячет от меня то число, которое нужно вывести на экран ))) Хочешь вывести на экран 12345? А получишь 129999 )))))

Ты не поверишь, там можно от одного входа несколько связей протянуть. Одну округляем, вторая остаётся нетронутой.

в Пайтоне:

Всё верно, но и там есть в библиотеках decimal/number типы - используются очень широко.

https://docs.python.org/3/library/decimal.html

- в Цэ это гораздо более специальные случаи.

Но с питоньей точностью в float всё равно легче не париться, чем с вечно потерянными копейками в 1С.

Да, можно. Так и делаю. Но в этой конкретной задаче становится тяжело это сделать, так как нужно ещё многое другое учитывать и дебажить очень трудно на этом уровне. Там нет системы переменных куда это можно было бы «запомнить», циклов привычных ЯП. Но я подумаю ещё, как это сделать по другому.

Вообще, мне всё больше кажется, что никому решение задачи нафиг не сдалось - ТС вбрасывает, а остальным только дай повод посраться.

пока не вскрылась проблема с точностью при умножении на «целое» число.

Так у тебя основная проблема при делении, а не при умножении. У тебя 0.56 как получалось?

Если это строка, то нужно переходить на целочисленную арифметику.

Если это из 56.0/100, то надо менять порядок умножения и деления.

Опередил…

короче когда точность теряется, такие вот цепочки вычислений надо делать как можно короче

Да, но мне казалось, что 0,56 (короткое же?) можно легко преобразовать в 5,6 умножением на 10. Но оказалось без округления это невозможно, так как когда я ввожу 0,56 «ручками», где-то глубоко в системе оно записалось как 0,559999999999985.

А в итоге вон что оказалось:

>>> a = 0.56
>>> a
0.56
>>> a == 0.56
True
>>> a * 10 / 10
0.56
>>> a * 10
5.6000000000000005
>>>

Умножение и деление возвращает число в изначально введённое, а если просто умножение, то уже идёт «искажение» исходного числа.

Так тут, в Пайтоне число становится 5.6000000000000005, а в C++ совсем другое, меньше 5,6.

https://www.exploringbinary.com/the-answer-is-one-unless-you-use-floating-point/

Читай. Если не дойдёт - читай ещё раз

реальной математике

В «реальной» математике апельсин можно разрезать и собрать два

Кстати да, в реальности вообще можно потерять саму реальность ))) Коперфильду и им подобным фокусникам удаётся же как-то это делать ))

Спасибо за ссылку на интересный материал. Я уже всё понял в чём проблема.

Потому что некоторые десятичные вещественные числа представимы только бесконечными рядами двоичных дробей, а в остальном как вам и рекомендовали - смотрите айайай-754. Для полного понимания от себя рекомендую разобраться с тем как представляются числа, в т.ч. дробные в ВМ, а также глянуть первую главу книги Essential Mathematics for Games - в ней прям всё по теме представления чисел на ВМ. Ситуация типична для всех языков программирования для цифровых вычислительных машин, т.к. работают только с конечными формами двоичных чисел.

Да, это было бы отличным решением! Но проблема в том, что нет такой возможности в системе нодов Блендера, есть только «математика»

Вместо %.10f ты не хотел написать %.1f ?

Да это понятно. Действительно это так можно было бы сделать в коде ЯП, но в нодах несколько сложнее это всё сделать, так как запомнить исходное число и манипулировать дальше в потоке математикой ооочень сложно становится дебажить, сравнивать его с чем-то, а другое где-то хранить, где невозможно хранить )) Вообщем с этим большие трудности.