сравнение десятичного числа Python
Место, где alloca() особенно опасен, чем malloc(), - это ядро - ядро типичной операционной системы имеет фиксированное пространство стека, жестко запрограммированное в одном из его заголовков; это не так гибко, как стек приложения. Выполнение вызова alloca() с необоснованным размером может привести к сбою ядра. Некоторые компиляторы предупреждают использование alloca() (и даже VLA в этом отношении) при определенных параметрах, которые должны быть включены при компиляции кода ядра - здесь лучше выделять память в куче, которая не фиксируется аппаратно кодированный предел.
3 ответа
К вопросу 1, это действительно то поведение, которое мы разработали - правильное или неправильное, каким бы оно ни было (извините, если это сбивает ваш вариант использования, но мы пытались быть общими!).
В частности, давно сложилось так, что каждый объект Python мог подвергаться неравенству при сравнении с любым другим - объекты типов, которые не являются t действительно сопоставимые - произвольно сравнивать (последовательно в данном прогоне, не обязательно по прогонам); Основным вариантом использования была сортировка разнородного списка для группировки элементов в нем по типу.
Исключение было введено только для комплексных чисел, что сделало их несопоставимыми ни с чем - но это было еще много лет назад, когда мы иногда были бесцеремонными о взломе совершенно хорошего пользовательского кода. В настоящее время мы гораздо строже относимся к обратной совместимости в основной версии (например, по строке 2. * и отдельно по строке 3. * , хотя несовместимость составляет допускается от 2 до 3 - действительно, в этом весь смысл , имеющего a 3. * , что позволяет нам исправлять прошлые проектные решения даже несовместимыми способами).
Произвольные сравнения оказались больше проблем, чем они того стоят, что привело пользователей в замешательство; а группировку по типу теперь можно легко получить, например, с помощью аргумента key = lambda x: str (type (x)) для sort ; поэтому в Python 3 сравнения между объектами разных типов, если сами объекты специально не разрешают это в методах сравнения, действительно вызывают исключение:
>>> decimal.Decimal('2.0') > 1.2
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unorderable types: Decimal() > float()
Другими словами, в Python 3 это ведет себя именно так, как вы думаете; но в Python 2 это не так (и никогда не будет ни в каком Python 2. * ).
Re 2, все будет в порядке, но посмотрите gmpy я надеюсь, что это интересный способ преобразования чисел типа double в дроби бесконечной точности с помощью деревьев Фарея. Если цены, с которыми вы имеете дело, точны не более чем с точностью до центов, используйте '%.
Сравнение "больше чем" работает, потому что по умолчанию оно работает для всех объектов.
>>> 'abc' > 123
True
Десятичное число является правильным только потому, что оно правильно соответствует спецификации. Был ли спек правильным подходом - это отдельный вопрос. :)
Только обычные предостережения при работе с числами с плавающей запятой, которые кратко резюмируются: остерегайтесь крайних случаев, таких как отрицательный ноль, +/- бесконечность и NaN, не проверяйте равенство (связанное со следующей точкой), и рассчитывайте, что математика будет немного неточной.
>>> print (1.1 + 2.2 == 3.3)
False
Если это «правильно» - это вопрос мнения, но причина отсутствия автоматического преобразования существует в PEP, и было принято такое решение. Предостережение в основном заключается в том, что вы не всегда можете точно преобразовать между float и decimal. Следовательно, преобразование не должно быть неявным. Если вы в своем приложении знаете, что у вас никогда не бывает достаточно значимых чисел, чтобы это могло повлиять на вас, создание классов, допускающих такое неявное поведение, не должно быть проблемой.
Кроме того, одним из основных аргументов является то, что варианты использования в реальном мире не существует. Вероятно, будет проще, если вы будете везде использовать просто Decimal.