花弁

Orientation predicate Доброкодер 18 December 2016 (Sun) 02:49 No.46971

File: preds.gif
Gif, 21.70 KB, 577×647 - Click the image to expand

Здесь будет мой дневничок, посвященный написанию сабжа с помощью рациональных чисел из библиотеки GNU MP/MPIR.

Тем кто хочет ознакомиться с темой добро пожаловать сюда:
https://habrahabr.ru/post/138168/
Или на видео этого же чувака:
https://www.youtube.com/watch?v=ndimHVTnUMA

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

>>	Доброкодер 18 December 2016 (Sun) 02:56 No.46972 Особый кайф этой библиотеки состоит в том, что я не смог найти даже примитивных туториалов для даунов или популярных книг для чайников. Придется читать чертову документацию страницу за страницей.

>>	Доброкодер 18 December 2016 (Sun) 03:25 No.46973 Сделал тестовый cmake-скрипт, все собралось, можно приступать к ковырянию БЛЯ ЩА НА ДЕЛО ПОЙДЕМ, ОТВЕЧАЮ ТАКИЕ ТЕМЫ МУТИТЬ БУДЕМ, УХ ЧТО СЕЙЧАС НАЧНЕТСЯ, ВНАТУРЕ ДВИЖУХА ЩА БУДЕТ

>>	Доброкодер 18 December 2016 (Sun) 04:22 No.46974 Первая работающая программа. Как вы думаете сколько будет 0.23414*12.21736 в форме рационального числа? Правильный ответ: 7252413325258057258250800212775/2535301200456458802993406410752 Офигительно.

Доброкодер 18 December 2016 (Sun) 04:32 No.46975

File: d01.PNG
Png, 53.58 KB, 761×624

File: d02.PNG
Png, 55.36 KB, 807×634

>>46974
Немного неправильно написал. На самом деле это был не результат умножения этих чисел, а их конверсий в тип double. Если не конвертировать, то там другой результат был бы. Но у меня в программе входные данные будут в даблах -- так что это именно то что мне нужно.

>>	Доброкодер 18 December 2016 (Sun) 04:44 No.46976 >>46974 Чистые фракции будут 1787857919/625000000. На этом закончу и отправлюсь спать.

Доброкодер 19 December 2016 (Mon) 02:22 No.46983

Тем временем я реализовал этот предикат. По мере реализации стала очевидна потребность в написании более общего транслятора арифметических выражений из обычной формы в форму GMP-функций. Наверное, кто-то где-то уже это писал. Для SAGE или Mathematica. Может быть есть даже попен-сорс.

>>	Доброкодер 19 December 2016 (Mon) 02:52 No.46984 File: test.PNG Png, 13.27 KB, 767×460 - Click the image to expand Тест на адекватность алгоритма пройден четенько.

>>	Доброкодер 20 December 2016 (Tue) 02:01 No.46991 Сейчас затестирую два старых алгоритма, которые у меня стояли до этого. И посмотрю на результаты. А потом попробую их объеденить, чтобы новый работал только в самом узком месте.

>>	Доброкодер 24 December 2016 (Sat) 15:36 No.47005 Не очень понял (если вообще что-то понял), как оно получает корректный результат из уже некорректных вводных флоатов, но вангую, что всё равно всё сделано через егоры с терпимостями.

Доброкодер 26 December 2016 (Mon) 11:31 No.47015

>>47005

> как оно получает корректный результат из уже некорректных вводных флоатов

Верно подметил, что сами входные данные потенциально некорректны. И чем больше с ними совершено операций, пока они находятся внутри типа float -- тем более некорректны они становятся.

Однако, если не делать вышеописанных процедур, то количество мест в программе, где происходит какая-то дичь будет только множиться. Это устранение одной из головных болей.

>>	Доброкодер 27 December 2016 (Tue) 04:22 No.47017 >>47015 Вроде что-то понял. Инпуты некорректны, но вычисления над ними не будут наращивать эту некорректность, так? Минус, полагаю, в производительности.

>>	Доброкодер 27 December 2016 (Tue) 13:46 No.47022 Теперь это будет тред 754 стандарта. Настало время его наконец-то прочитать. Видео для интересующихся: https://www.youtube.com/watch?v=K5Y4-4SKaSA

>>	Доброкодер 28 December 2016 (Wed) 18:09 No.47025 Интересная статья по теме: https://habrahabr.ru/post/258483/ Стандарт читается очень тяжело. Т.к. написан казенным языком. Нужно крепко помолиться, чтобы продвинуться на новую страницу.

>>	Доброкодер 28 December 2016 (Wed) 18:42 No.47027 Отличная статья: http://smalltalk.gnu.org/blog/bonzinip/floating-point-decimal-conversion-not-so-easy Наконец-то стало понятно почему программы по печати float'ов могут напечатать разное для одного и того же числа.

nextafter Доброкодер 29 December 2016 (Thu) 21:37 No.47035

File: nextafter.PNG
Png, 25.96 KB, 716×224 - Click the image to expand

Посоны, посоветуйте свободную библиотеку, где есть аналог этого:
http://www.digitalmars.com/rtl/math.html#nextafter
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxbd00/rnextf.htm
http://en.cppreference.com/w/c/numeric/math/nextafter
https://opensource.apple.com/source/Libm/Libm-47/ppc.subproj/nextafter.c

Чтобы работало для binary32 float (одинарной точности) под intel. В той версии студии, что у меня есть (и изменить ее я не могу) этой функции нет. И писать самому мне ее очень не хочется.

>>	Доброкодер 29 December 2016 (Thu) 23:29 No.47036 Офигеть. В Apple пишут в новой версии libm пишут код сразу в ассемблере: https://opensource.apple.com/source/Libm/Libm-2026/Source/Intel/nextafterf.s.auto.html

>>	Доброкодер 30 December 2016 (Fri) 12:00 No.47037 File: printf.PNG Png, 42.34 KB, 749×728 - Click the image to expand Блин. Походу у майкрософт сломанный printf в части печати float. Он слишком рано округляет, хотя его этого делать не просили. Еще с этим теперь разбираться.

Доброкодер 30 December 2016 (Fri) 12:10 No.47038

File: 17.PNG
Png, 15.60 KB, 778×146 - Click the image to expand

>>47037
Так и есть.

> The VC++ CRT, regrettably, refuses to print floats or doubles with more than 17 digits of mantissa. 17 digits is enough to uniquely identify any float or double, but it is not enough to tell us precisely what value they contain.

>>	Доброкодер 02 January 2017 (Mon) 07:59 No.47049 >>47035 В glibc есть

Доброкодер 05 January 2017 (Thu) 01:11 No.47058

>>47038

> Так и есть.

> The VC++ CRT, regrettably, refuses to print floats or doubles with more than 17 digits of mantissa. 17 digits is enough to uniquely identify any float or double, but it is not enough to tell us precisely what value they contain.

не вполне так.
хотя это вопрос, в некотором смысле, философский.
вкратце, нет оснований думать, будто float or double "содержит" некоторое конкретное значение сверх того, которое его однозначно идентифицирует.