|
|
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
возможно без компилятора предсказать результат выполнения такого выражения? Код: java 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2014, 21:14 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
забыл ник, научишь? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2014, 21:25 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
вроде как если дробная часть без потерь переводится в 2 СС, то будет тру, а в остальных случаях по разному. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2014, 21:35 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
redwhite90, У меня такой результат: Код: java 1. 2. redwhite90возможно без компилятора предсказать результат выполнения такого выражения?С типом double не получится. (имхо) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2014, 21:46 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
Usman, вроде как по последней значащей цифре мантиссы это определяется( хотя не уверен) во всяком случае эта версия объясняет разные результаты для float и double. P.S. Код: java 1. 2. 0.5 переводится в 2 СС без потерь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2014, 21:53 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
rdm, да, проблема та, но это не ответ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2014, 22:04 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
вам уже намекнули что правильный ответ такой - Числа с вещественной точкой сравнивать через == нельзя Точка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2014, 23:19 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
redwhite90, дело в том что дробно-десятичная константа не мапиться в double и float как один к одному. Там будет аппроксимация дробной части к наиболее близкому числу. Поэтому само по себе присвоение уже имеет дефект точности. Чтобы избежать дефектов сравнения договорились сравнивать как Код: java 1. Где эпсилон ты сам задаёшь как критерий точности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2014, 23:25 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
mayton, забыл_ник я это знаю. просто был вопрос в тесте такой...могу предположить, что и на scjp такой может быть. собственно ответ там данный, что если реально без потерь перевести дробную часть в двоичную систему счисления - будет тру - я не смог опровергнуть. А если нет, то оказывается тоже иногда будет true. Хочу узнать возможно ли в уме прикинуть когда true, когда false ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2014, 00:49 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
В уме трудно прикинуть чему будет равно 1.0/3.0 в float, double представлении, поэтому заниматься этим не стоит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2014, 00:57 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
redwhite90, Как я унал недавно на quizful, чтобы узнать, представляется ли десятичная дробь конечной двоичной, нужно перевести ее в обычную дробь, сократить и посмотреть является ли знаменатель степенью двойки. И сама степень скажет сколько дробных разрядов надо. 0.3 = 3/10 - конечным не получается 1/10 - тоже т.е. ни 0.3 не будет точным, ни 0.1 в итоге изза последнего разряда оно не сойдется и будет false из примеров ниже, 0.5 = 5/10 = 1/2 -- число запишется точно Сумма пяти 0.1 будет округлена до 0.5 скорей всего, так что true ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2014, 01:04 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
chabapok, ну а 0.2 - не переводится в 2 сс, но результат true ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2014, 02:35 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
redwhite90, Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2014, 08:53 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
redwhite90, 0.2 = 2/10 = 1/5 5 не степень двойки, значит конечным числом не представляется А true тут не при чем. Это уже к сложению относится - надо смотреть чего там с младшим разрядом получится. Хз как это посмотреть. Но в тестах должно даваться то, что можно в уме предугадать. (не знаю можно ли понять тут, лично я понять не могу) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2014, 12:22 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
Usmanredwhite90, Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. если честно не понял, что я должен тут увидеть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2014, 13:26 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
chabapokredwhite90, 0.2 = 2/10 = 1/5 5 не степень двойки, значит конечным числом не представляется А true тут не при чем. Это уже к сложению относится - надо смотреть чего там с младшим разрядом получится. Хз как это посмотреть. Но в тестах должно даваться то, что можно в уме предугадать. (не знаю можно ли понять тут, лично я понять не могу) источник вопроса http://www.quizful.net/TestStoreAction.viewQuestion?question=UOcsHuSsfIa2#5558656655373698788 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2014, 13:27 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
redwhite90если честно не понял, что я должен тут увидеть.Увидеть разницу! Код: java 1. 2. 3. 4. 5. 6. 7. 8. Код: java 1. 2. 3. 4. 5. 6. 7. 8. P.S. Хотелось донести тот факт, что BigDecimal работает с вещественными числами намного предсказуемее . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2014, 13:40 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
UsmanХотелось донести тот факт, что BigDecimal работает с вещественными числами намного предсказуемее . тяжело не согласиться ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2014, 19:13 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
redwhite90источник вопроса... вот тут еще можно похожий вопрос посмотерть - www.quizful.net/TestStoreAction.viewQuestion?question=BM85bA43XmMK ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2014, 15:57 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
chabapok, пожалуй даже сюда запостю: авторpublic class Main { Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. ответ: 1: Float.valueOf(value) дает 29.1f. Далее 29.1f приводится к double т.к. 1.0 имеет тип double (по-умолчанию все литералы с плавающей точкой имеют тип double). Получаем 29.100000381469727d. Соответственно (Float.valueOf(value) + 1.0)=30.100000381469727d. И в результате (Float.valueOf(value) + 1.0) == 30.1 равно false. 2: Аналогично п.1 только без приведения float к double, все переменные типа double. (Double.valueOf(value) + 1.0) дает 30.1d. И в результате (Double.valueOf(value) + 1.0) == 30.1 равно true. 3: Деление float на ноль не дает ArithmeticException (только деление целого типа на ноль даст ArithmeticException), для таких случаев в классе Float даже определена константа: public static final float POSITIVE_INFINITY = 1.0f / 0.0f; Причем если заглянуть в исходники метода java.io.PrintStream#println(float), то становится ясно что float превращается в строку с помощью метода String.valueOf(float), который POSITIVE_INFINITY преобразует в "Infinity". 4: Аналогично п.3. } Что скажете? разве правда? Если даже следовать его логике, то 29.1 не переводится в двоичную CC => 29.1 +1 не равно 30.1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2014, 14:15 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
redwhite90, для меня это такая же тайна, покрытая мраком. Правил перевода float -> double я не нашел, но судя по личным тестам, "новые" биты заполняются рандомными значениями. Реверс-инженирингом не получается понять чего оно так работает, а документации не нашел. причем, по всей видимости, тут java вообще не при чем, надо смотреть стандарт IEEE-754 Пока я не могу обьяснить почему оно так работает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2014, 15:40 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
Не должно быть там ничего рандомного. Посмотрите как работает онлайн калькулятор для IEE 754 для 32-х битных вещественных чисел. http://www.h-schmidt.net/FloatConverter/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2014, 15:45 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
У этого формата нет запрещённых комбинаций но есть маска при которой число являеся Не-числом (Nan) двух подвидов и бесконечность (Infinity) со знаками "+" и "-" Тоесть из 4 млрд состояний float числа небольшая часть будут иметь смысл. И область допустимых значений на всём диапазоне - неравномерна. Тоесть чем больше число - тем грубее идёт шаг. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2014, 17:36 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#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 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
chabapok jvm старается посчитать правильней, Правда их "правильный" sin(Pi) еще чуть дальше от 0 чем "неправильный". :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2014, 20:00 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
Сергей Арсеньев, я не очень спец в fpu, но насколько я смог, вышло как-то так: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. Результат: 1.224646799147353207e-16 1.224606353822377258e-16 Действительно, второе число ближе к нулю. И java считает по первому вариану. Хотя по вашей ссылке написано что java точнее. Странно. Видимо, sse не точное. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2014, 02:49 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
В math.h число определено с double precision Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. Думаю что недостаток младших разрядов (нехватка точности по сравнению с long double) фактически нам говорит о том что в радианах M_PI это не развёрнутый 180 угол (против часовой стрелки от оси OX) а слегка уменьшенный угол вида 180-epsilon. Я не знаю как работает численный метод который расчитывает синус в FPU (скорее всего это расчёт суммы ряда Тейлора или Лорана) но аргумент перед подачей нормализуют (приводят к [ -M_PI/2.0 , M_PI/2.0 ]) и уже на этой операции мы можем иметь дефект аргумента. Тоесть мы получаем не синус нуля а синус epsilon. IMHO ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2014, 14:46 |
|
||
|
предсказуем ли результат?
|
|||
|---|---|---|---|
|
#18+
maytonаргумент перед подачей нормализуют (приводят к [ -M_PI/2.0 , M_PI/2.0 ]) и уже на этой операции мы можем иметь дефект аргумента. IMHO насколько я понял из той ссылки, FPU не может на этапе приведения вычитать математическое пи, поэтому приводит тоже по своей упрощенной формуле, которая на больших числах приведет нас в космос. То есть, считая sin(M_PI) у нас M_PI не математическое, но и приведение к диапазону не использует математиически точное пи. В этом случае логично было бы предположить, что FPU должно было вычесть свое PI своей максимальной точности, которое равно M_PI, но тогда получился бы точно ноль. Причем, M_PI-atan(1)*4 дает 0, это намекает, что M_PI задефайнено с максимальной точностью. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2014, 14:52 |
|
||
|
|

start [/forum/topic.php?all=1&fid=59&tid=2127720]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
158ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
70ms |
get tp. blocked users: |
1ms |
| others: | 228ms |
| total: | 493ms |

| 0 / 0 |
