 |  | ||
 главная | избранное | настройки | об ALT-форуме |
Страницы форума: ← Назад | 1 … 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 … 600 | Дальше →
Арифметика | ||
G_Z | 23.05.10 03:00 / 03:01 www.parser.ru → | ответить → | | |
Арифметика | ||
$n1[-443704711] $n2[4294967296] ^eval(^n1.double[] % ^n2.double[]) = -443704711 Python, Google и даже Excel считают иначе — . MySQL, XSLT и калькулятор Windows придерживаются ответа «-443704711». Не совсем понимаю причину, ошибка из-за размера чисел? С double, выходит, толком не посчитать? | ||
| Misha v.3 | → G_Z [1] | 23.05.10 03:34 / 03:42 www.parser.ru → | ответить → | | |
весь сыр-бор из-за отрицательного делимого | ||
| в частности OpenOffice (который считает как и Excel) в своей справке приводит такую формулу: Dividend - Divisor * INT(Dividend/Divisor) но дело в том, что использовать их реализацию INT в этой формуле нельзя, т.к. он округляет в меньшую сторону (-1.3 -> -2). использовать надо TRUNC. да и если подумать логически, то парсерная реализация правильная, т.к. % (==MOD) возвращает _остаток_от_деления_. и т.к. с абсолютное значение делимого меньше делителя, то всё делимое и должно вернуться в виде результата функции. | ||
| G_Z | → Misha v.3 [2] | 23.05.10 03:44 www.parser.ru → | ответить → | | |
Дык | ||
Убираем отрицательность:$n1[443704711] $n2[4294967296] ^eval(^n1.double[] % ^n2.double[]) = 443704711 | ||
| Misha v.3 | → G_Z [3] | 23.05.10 03:46 www.parser.ru → | ответить → | | |
и? у гугла так-же :) | ||
| G_Z | → Misha v.3 [4] | 23.05.10 03:53 www.parser.ru → | ответить → | | |
Хм... | ||
$n1[-443704711] $n2[4294967296] ^eval(^n1.double[] - ^n2.double[] * ^math:floor(^n1.double[] / ^n2.double[])) = 3851262585 Это, как я понимаю аналог с их INT. | ||
| Misha v.3 | → G_Z [5] | 23.05.10 03:56 www.parser.ru → | ответить → | | |
да, это их аналог с INT. но к _остатку_от_деления_ это никакого отношения не имеет, imho. | ||
| G_Z | → Misha v.3 [6] | 23.05.10 04:00 www.parser.ru → | ответить → | | |
Мне важнее получить аналог | ||
| Дабы повторить алгоритм на Парсере. А такая арифметика — его часть. Спасибо за помощь. | ||
| G_Z | → G_Z [1] | 23.05.10 05:17 www.parser.ru → | ответить → | | |
Едем дальше… | ||
$n1[228452386] ^eval(^n1.double[] << 8) = -1645731328 MySQL и Python — 58483810816. Судя по тому, что число становится отрицательным, как бы не старший бит и обрезка. | ||
| Misha v.3 | → G_Z [8] | 23.05.10 05:50 www.parser.ru → | ответить → | | |
сдвиговые операции у p3 работают только для int, а диапазон значений int описан в документации | ||
| G_Z | → Misha v.3 [9] | 23.05.10 06:00 www.parser.ru → | ответить → | | |
Фигово… | ||
| Может это в документации явно указать? Лично я сэкономил бы три дня, зная, что упрусь в это. | ||
| Misha v.3 | → G_Z [10] | 23.05.10 06:16 www.parser.ru → | ответить → | | |
диапазон int-а в документации явно указан | ||
| G_Z | → Misha v.3 [11] | 23.05.10 06:20 / 06:22 www.parser.ru → | ответить → | | |
Не указано, что сдвиговые операции работают до int | ||
| Притом, что, как пишет PAF, «». Уж не знаю насколько сдвиговые операции можно считать числовыми вычислениями, но путаницу явно не описанные ограничения вносят. Остальные битовые операции тоже ограничены int'ом? | ||
| Misha v.3 | → G_Z [12] | 23.05.10 06:26 www.parser.ru → | ответить → | | |
| сдвиговые операции работают с int по моему вообще везде (посмотрите доку perl, python -- там они работают аналогично), т.к. особого смысла двигать биты у double -- нет. в p3 они работают с double, но при этом происходит неявное приведение типа к int, т.е. в случае больших double происходит потеря данных. то, что писал ПАФ -- почти корректно, т.к. формально сдвиговые операции относятся к _битовым_ операциям, а не к математическим (== числовые вычисления). | ||
| G_Z | → Misha v.3 [13] | 23.05.10 06:35 www.parser.ru → | ответить → | | |
| посмотрите доку perl, python -- там они работают аналогично Это не так: Python: >>> 1 << 100 1267650600228229401496703205376L MySQL: SELECT 2147483647 << 20 2251799812636672 В JavaScript — да, что указывают. | ||
| Misha v.3 | → G_Z [14] | 23.05.10 06:39 www.parser.ru → | ответить → | | |
L -- это разве не long? | ||
| SELECT 2 << 1 SELECT 2.1 << 1 возможно я некорректно выразился. я имел в виду, что эти операции работают только с целочислеными типами. теперь внимание вопрос: какие целочисленные типы есть у p3? | ||
| G_Z | → Misha v.3 [15] | 23.05.10 06:52 / 06:55 www.parser.ru → | ответить → | | |
Long | ||
| и к int не приводится. я имел в виду, что эти операции работают только с целочислеными типами За неимением большего, чем int целого приходится пользоваться double для операций с целыми числами. Лично для меня неожиданно, что битовые операции ограничены int'ом — в исходниках не копаюсь, а в документации не указано. Уж как работает, но плохо, что не описано, и приходится выяснять, потратив время на то, чего сделать нельзя в принципе. | ||
| Misha v.3 | → G_Z [16] | 23.05.10 07:54 / 08:04 www.parser.ru → | ответить → | | |
| предлагаю назначить виновным меня, т.к. я скрыл сию наиважнейшую информацию, не доступную ни в гугле ни в другом поисковике, от общественности. P.S. в принципе сделать можно, т.к. << без проблем заменяется умножением, а >> -- делением, но ведь это не важно, главное -- что найден виновный. P.P.S. Лично для меня неожиданно, что битовые операции ограничены int'ом — в исходниках не копаюсь, а в документации не указано. увы, в документации также не указано, что, например, операции '+', '-' итд ограничены числами, а ^math:sqrt() не умеет извлекать корни из отрицательных чисел. да и много чего ещё. P.P.P.S. три дня тратить на такую проблему -- не многовато-ли? | ||
| G_Z | → Misha v.3 [17] | 23.05.10 08:23 www.parser.ru → | ответить → | | |
| предлагаю назначить виновным меня, т.к. я скрыл сию наиважнейшую информацию, не доступную ни в гугле ни в другом поисковике, от общественности. К чему этот сарказм? Я где-то какие-то претензии высказывал, или что? Google'ом находится всё, или почти всё. Видимо, нынче это повод не задавать вопросов по языку в «форум поддержки» языка, прискорбно. Что ж, впредь не будут отвлекать контингент от важнейших вопросов правильной генерации XML и коллективных цитирований документации. P.S. в принципе сделать можно, т.к. << без проблем заменяется умножением, а >> -- делением, но ведь это не важно, главное -- что найден виновный. [внимательно смотрит] Я поинтересовался причиной явлений, которых не понимаю. Привёл пример тех же действий в других окружениях, которые дают другой результат. После прояснения предложил явно указать ограничения, пусть для кого-то и очевидные, в документации. Есть мнение, она именно для этого предназначена. Откуда эти пассажи про нахождение виноватого — мне не ясно. Если это следует из моих слов — убедительная просьба мне процитировать эти слова. три дня тратить на такую проблему -- не многовато-ли? Это часть переноса стороннего алгоритма, по большому счёту, «в лоб», чтобы заставить работать, и далее заняться разбором и оптимизацией. Три дня — время, которое ушло на перенос того, что Парсер не сможет посчитать и правильно было бы оставить частичную реализацию на Python или Perl и вызывать по необходимости. | ||
| Misha v.3 | → G_Z [18] | 23.05.10 08:39 www.parser.ru → | ответить → | | |
| ответ на вопрос был дан менее чем через час после его публикации, разве нет? наличие документации не гарантирует понимания сути проблемы и поиска решений, именно поэтому поисковики -- верный друг разработчика. например, если бы вы переносили ваш код из Excel в VB (вообще продукты одной малоизвестной компании) вы бы столкнулись с аналогичной проблемой в случае MOD. описать в документации абсолютно всё -- невозможно. то, что для одного является очевидным -- для другого оно таковым не является. где провести грань "очевидного" -- в общем случае неясно. но для меня очевидным является то, что использующий битовые операции понимает что они делают и с чем они работают (аналогично с тригонометрическими функциями и ещё много с чем). хотя я согласен, что иногда при переносе какого-либо кода приходится сталкиваться с чем-то, с чем ранее сталкиваться не приходилось, и частенько возникают проблемы. про "пассажи про виноватого": виноват (почему-то воспринял предложение про экономию 3 дней как претензию). был не прав. вспылил. | ||
| G_Z | → Misha v.3 [19] | 23.05.10 08:58 / 09:32 www.parser.ru → | ответить → | | |
| ответ на вопрос был дан менее чем через час после его публикации, разве нет? Так точно. За что я поблагодарил. если бы вы переносили Давно ли мы стали на «вы»? Может и столкнулся бы, но в настоящий момент столкнулся с Парсером, и задал вопрос там, где на него можно получить компетентный ответ. Ну, в надежде разъяснить вопрос локально, не выискивая какими типами ограничены другие языки и какими формулами вычисления руководствуются. то, что для одного является очевидным -- для другого оно таковым не является. где провести грань "очевидного" -- в общем случае неясно Да дело-то хозяйское. Указано, что — сложнейшая для понимания вещь. Следующему идиоту, по какой-либо причине не повторяющему каждый день, на протяжении 10 лет, курс алгебры и двоичной арифметики, даже такое обсуждение сможет помочь. Что до задачи — работать заставлю, время на неё не зря потрачено. Более того, ошибка наверняка обходима, реализации вычисления есть на разных языках, в том числе JavaScript. Легко может статься, что работа с подобными числами — допущенная мной ошибка, но расхождения мешали локализовать эту возможную ошибку сравнением результатов фрагментов кода. Сейчас сделал самым простым способом — вызовом работающего решения. | ||
| Misha v.3 | → G_Z [20] | 23.05.10 09:28 www.parser.ru → | ответить → | | |
добавил в исходники доки комментарий. | ||
| G_Z | → Misha v.3 [21] | 23.05.10 09:33 www.parser.ru → | ответить → | | |
Спасибо, надеюсь кому-нибудь будет полезен. | ||
| |||
 | |||