|
|
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
maytonНе должно быть там ничего рандомного. Посмотрите как работает онлайн калькулятор для IEE 754 для 32-х битных вещественных чисел. http://www.h-schmidt.net/FloatConverter/ Спасибо за ссылку. Посмотрел. К сожалению, ответа на свой вопрос не нашел. Лучше бы я не смотрел, теперь вообще не ясно. например число 0.1 мантисса 123 или 2^-4 экспонента - 1.600000023841858 или 5033165 а ниже формула: The value of a IEEE-754 number is computed as: sign * (2^exponent) * mantissa И вот смотрю я на эти числа, и на формулу, и понимаю, что не понимаю как из мантиссы и экспоненты, подставив их в формулу получить хоть что-то близкое к 0.1. В 123 степень возводить двойку - явно многовато, а в -4 -- явно маловато. И что происходит с мантиссой и экспонентой при конвертации float->double тоже неясно. Каким-то образом новые разряды заполняются какими-то значениями, но откуда они берутся - непонятно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2014, 20:30 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
chabapok, у Генри Уоррена в 15 главе описывается IEEE. Книжку реально найти в pdf-формате бесплатно. Еще на сайте rsdn.ru был исходник конвертера. Можно посмотреть. К слову я тоже "пошагово" не знаю алгоритм преобразования числа в float. Знаю только общие принципы и неоторые хитрости касаемые этого типа данных. По поводу конвертации float->double. Начиная с процессоров 386DX все операции с плавающей точкой делаются в процессоре специальным модулем FPU (Floating Point Unit), который имеет 8 регистров по 80 бит (extended double), завёрнутых в кольцевой стек и ВСЕ операции расчётов с FP математикой происходят в нём. Причём float и double в вычислениях не участвуют а используются просто как усечённый формат для сериализации exdended double. Тоесть происходит кастинг, расчёты и еще раз кастинг обратно. Код: plaintext 1. Float вообще нет смысла использовать для хранения в виде переменных. Он - откровенно слабый. Его возможно пользуют как float[] или float[][] в некоторых графических и звуковых приложениях где нужно оперировать в оперативке большими массивами выборок звука в PCM (Pulse Code Modulation), или матрицами пикселов в LAB (для Photoshop к примеру). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2014, 23:46 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
mayton Код: plaintext 1. Увы и ах. Эра x87 канула в лету. Засилие C не дало развернуться типу Extended (не портабле видишь ли). И в наступившем эре SSE расчеты стали вестись c одинарной (4 байта), а с достижением прогресса - двойной точностью (8 байт). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2014, 10:44 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
Ура. И еще раз ура. Давайте только посмотрим какой код генерит JRE. Я приму эту позицию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2014, 10:58 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
maytonДавайте только посмотрим какой код генерит JRE. Как известно, JRE в этом смысле довольно консервативна и даже иногда искуственно повторяет ошибки старых процессоров в вычислениях по соображениям совместимости. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2014, 11:29 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
Сергей Арсеньев, ОК. Я понял. Тема интересная но подняли мы ее не в том форуме. Я-бы тоже хотел подискутировать на тему % использования SSE. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2014, 11:36 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
maytonFloat вообще нет смысла использовать для хранения в виде переменных. Это не важно. В вопросах оно есть. Кроме того, бывает в базе лучше хранить флоаты, например с целью экономии места. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2014, 17:36 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
про процессоры это конечно всё классно и интересно, но по поводу этого поста можете что-нибудь высказать? http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1073497&msg=15481944 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2014, 22:13 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
redwhite90, Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. Результат29.1f + 1.0f == 30.1f is true 29.1f + 1.0f == 30.1d is false 29.1f + 1.0d == 30.1d is false 29.1d + 1.0f == 30.1d is true 29.1d + 1.0f == 30.1f is false 29.1d + 1.0d == 30.1d is true 30.1f == 30.1d is false ((float)30.1d) == 30.1f is true ((double)30.1f) == 30.1d is false ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2014, 09:47 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
Сергей Арсеньев, давайте перейдём на С++. Это не будет нарушением топика. Просто нам в скоупе обсуждения IEEE арифметики удобнее будет использовать хардкорные кастинги C/C++ и достать бинарное значение float и double чтобы "подсмотреть" где погрешность. P.S. Блажкович не закрывай нас :) please. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2014, 17:11 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
maytonP.S. Блажкович не закрывай нас :) please. Вы мне льстите. Я тут не модерирую. Но с интересом слежу за темой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2014, 17:13 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
Ну ... ничего. Кольцо власти найдёт хозяина. А я пошёл искать ЖСС компиллятор под винду. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2014, 17:19 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
Зачем!??? Си не нужно. Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. Результат смотреть в шрифте monospace, там пробелы подгаданы чтобы выглядело красиво Лучше всего в какой-нибудь блокнот закопипастить Код: java 1. 2. 3. 4. 5. 6. 7. Отсюда видно, что при конвертации float->double новые разряды экспоненты забиваются нулями. Почему мне раньше показалось иначе - не знаю, видимо был в угаре. :) Отсюда так же видно, что печать работает по-разному для одинаковых чисел - в зависимости от того float оно или double Дальше мое ИМХО, т.е. могут быть ошибки: Тут самая первая единичка (которая там где -1) - это знак, дальше 11 бит (или 7 бит) экспонента, и все остальное - мантисса. старший бит экспоненты равен 0 (выводится как "-"). При этом, экспонента надо, чтобы могла быть как положительная, так и отрицательная. Поэтому, в стандарте принято записывать экспоненту, добавляя 127 или 1023 в зависимости от float оно или double. Поэтому, чтобы получить экспоненту, надо вычесть из представления экспоненты 127 или 1023. поэтому экспонента 1.0 равна 0. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2014, 22:42 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
Ну... я чесно говоря другое хотел посмотреть. У меня завис вопрос по FPU/SSE. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2014, 22:46 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
Сформулируйте пожалуйста ваш вопрос. А то вроде вкользь FPU/SSE упоминалось, но что именно вам неясно - неясно. :) насколько я понял, информация ниже может вам показаться интересной. gcc версия 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. Компилим без каких бы то ни было ключиков (gcc main.c) и дизассемблим (objdump -d a.out), получаем такое: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. как видно, используется 128-битный xmm, в который влазит два 64-битных дабла. откомпилим теперь тот же код с ключиком -mno-sse Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. тут видно, что заюзалось fpu ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2014, 00:05 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
У меня вот что. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. Гну-шный ассебмлер довольно странный. Не узнаю команд. Ну да ладно. Ожидал увидеть команду finit/fninit но не нашёл. Странно. Наверное для современных CPU ее можно скипать? Команды семейства fld* вроде бы принадлежат к FPU но выглядят странновато. Хм... И printf для long double как-то странно форматнул вывод. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. Компиллятор realgcc.exe (GCC) 4.5.2 под Windows. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2014, 00:45 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
Разные компиляторы с разными ключиками генерят разный код. Если у вас gcc-совместимый, можете попробовать ключик -msse2 ? Ваш код у меня юзает fpu только для long double. Ну так а ваш вопрос в чем? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2014, 01:00 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
кстати я не очень спец по fpu но разве finit не логичней, чтобы делалось при загрузке ядра? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2014, 01:02 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
chabapok, msse2 не повлиял на ассемблерный вывод. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2014, 11:21 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
В плане синусов-косинусов тоже странная ситуация. Я ожидал в коде видеть инструкции fsin/fcos/fsincos. Но гнушный компиллер внезапно вставил каллбеки куда-то. Причём для всех типов. Код: plaintext 1. 2. 3. 4. 5. 6. Определение вот Код: plaintext 1. 2. Еще кучерявее. Теперь мне уже интересен бенчмарк. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2014, 13:48 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
А это уже недостаток си. Ну или достоинство - смотря с позиции чего смотреть. У него синус - считается либой, под линукс даже надо линковать ее (ключик -lm). Может ли комплитор заинлайнить эту функцию? При динамической линковке? При статической? Теоретически, вроде может. Но на практике ни gcc ни clang этого не сделали. Синус, кстати, через sse тоже может считаться. По крайней мере, при статической линковке видно некую довольно большую функцию __sin_sse2. Может поэтому и не заинлайнило. у меня кстати gcc перед вызовом синуса делал какие-то манипуляции с xmm0, что говорит в пользу обсчета функции через sse. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2014, 14:19 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
как знал, что до синусов дело дойдет. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2014, 16:01 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
Спасибо. Замечательно. Вольный перевод, насколько я понял: несмотря на то, что на улице 2014, синус все еще считается приближенно, и есть несколько методов приближения, которые дают немножко разный результат. jvm старается посчитать правильней, тогда как FPU это делает в зависимоти от имплементации - или правильней, или быстрее(лажаясь уже в 5 знаке после запятой), причем в большинстве случаев - "быстрее". Так же есть серьезная проблема посчитать синус, если число сильно выходит за пределы [-пи/4, -пи/4], потому что надо делить на периодическую дробь, а размер периода не точный, значит будет накопление ошибки. При этом, если совсем неповезет, любитель считать на FPU может попасть в космос. К счастью jvm предпринимает меры, чтобы накопления ошибки не было. Всегда недоблюбливал радианы, и теперь наконец могу обосновать почему. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2014, 16:43 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
chabapokсинус все еще считается приближенно, и есть несколько методов приближения, которые дают немножко разный результат. jvm старается посчитать правильней, тогда как FPU это делает в зависимоти от имплементации - или правильней, или быстрее(лажаясь уже в 5 знаке после запятой), причем в большинстве случаев - "быстрее". Ну... он всегда считался приближённо. А как вы обнаружили расхождение? Особенно в части FPU/long double. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2014, 17:14 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
Как я обнаружил расхождение? Элементарно, Ватсон - двумя соощениями выше Сергей Арсеньев дал ссылку, я по ней сходил, прочитал что там написано по английски, и с трудом перевел. Вот так "я обнаружил расхождение"! :)) Впринципе, там очевидные вещи написаны по большей части, но я о них никогда не задумывался. Ну то есть получается, что вычисление синуса через call куда-то в дебри либы - навскидку правильней, а через fsin - быстрей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2014, 19:53 |
|
||
|
|

start [/forum/topic.php?fid=59&msg=38545475&tid=2127720]: |
0ms |
get settings: |
7ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
186ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
57ms |
get tp. blocked users: |
1ms |
| others: | 231ms |
| total: | 504ms |

| 0 / 0 |
