- 1
- 2
- 3
- 4
import math
print math.pow(2,64) //1.84467440737e+19
print pow(2,64) //18446744073709551616
print 2**64 //18446744073709551616-
Python / Говнокод #16358
−422
http://ideone.com/kmGrBa
http://ideone.com/otSgCP
Говно в обоих версиях калькулятора.Запостил:
3.14159265,
16 Июля 2014
Follow us!
http://ideone.com/dLuwMI
Ха-ха-ха. Оценил.
slowfix
степень здесь не причем, и говно не калькуляторское
http://ideone.com/sodov8
print 3.2*3 # 9.6
print 3.2*3 == 9.6 # False
Вот мы и поймали тебя, Петя Содов!
print pow(2,64)==math.pow(2, 64) TRUE
1000000000000000001.0 == 1000000000000000002.0 TRUE
Если никому сходе не режет глаз плавающая запятая, ну что поделать - у вас еще всё впереди.
Зачем?
Подчёркиваю.
math.fabs() converts its argument to float if it can
abs(x)
Return the absolute value of a number.
Затем, что math - это... питоноблядская эмуляция сишкоблядской стандартной либы:
It provides access to the mathematical functions defined by the C standard.
...
Except when explicitly noted otherwise, all return values are floats.
abs - fabs
divmod - fmod
Там логично всё. Но вот от pow у меня НЕКОНСИСТЕНТНОСТЬ.
>It provides access to the mathematical functions defined by the C standard.
Немного куцо выглядит. Много функций не хватает. Где например fma? Где round?
C89, вестимо.
Понятно. Но уже прошло джва десятка лет, сменилось джве версии сишки и джве версии питона.
Меня не сколько импорт, затирающий имена без предупреждений раздражает, сколько неявное приведение к float.
ЕМНИП в C89 сигнатура функции выглядит так:
>double pow (double a, double b)
Что обычный pow и делает - если один из аргументов флоат, то результат будет флоат.
pow(3,64) по сигнатуре не подходит к сишной функции - почему он должен вернуть double?
А эти люди даже написали в Python Zen:
Explicit is better than implicit.
Выглядит как издевательство.
> pow(3,64) по сигнатуре не подходит к сишной функции
Так в сишке же нет перегрузок! Поэтому все отлично подходит: инты кастанутся в даблы да вызовется. Флоаты тоже кастанутся в даблы.
Неявно! Они ж могли просто оставить точно такой же pow (совместимость с math.h), аргументируя борьбой с неявным.
И сделать fpow, если сильно хотелось.
А масла в огонь подливает отличная справка.
Ни слова о float.
Но в реале то x**y, не эквивалентен math.pow(x,y)
И в сишке Wconversion ругнётся, если не при конверте в double, так при сохранении результата в int.
Вот простая строка, меняющая всё:
from math import *
__builtin__.pow
Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: No module named __builtin__
Во втором работало, да.
Потому что builtins.pow короче чем __builtin__.pow
Это как using namespace в крестах. С одной стороны писать меньше, а с другой - раскладывает грабли на дороге.
А полный импорт неймспейса - зло, хотя и заманчиво. Мало ли чего там подсунут кроме этого math.pow()...
математические хуи такие математические...
Ну если нам нужен один хуй - то да. А если 1001 то лучше показать какие хуи нинужоны
То код - ёбаное говнище. Зачем тебе столько top-level классов/функций/переменных в одном модуле?
> то лучше показать какие хуи нинужоны
Если компилятор умеет материться на конфликты, как тот же хаскель - да, соглашусь. А если, как питон, молча затирает первые и оставляет самый последний - нет, не лучше.
Ну ладно, сколько функций ты готов экспортировать руками?
Импортировать же.
Если честно, то после крестов-бустов меня совсем не напрягает писать math.pow() после import math. И from math import pow, fabs тоже не напрягает. Так что сколько надо будет по задаче - столько и импортну. А from math import * я оставлю ленивым экстремалам, жрите свой кактус сами.
P.S.
Да, карликовый лев попутал меня
На вкус и цвет...
Ты просто никогда не налетал на эти косяки...
И 146%, что Пи после вчерашнего батхёрта тоже больше никогда не будет юзать from че-то import * :)
Я вообще против введения такого синтаксиса в языки. Он может позволять меньше думать при написании, но сильно мешает читать (и, соответственно, ревьюить) код.
В Go молодцы ребята, сделали обязательноую явную квалификацию при вызове всех функций из других модулей. Респект.
Хачкель является ярким примером: открываешь типичные исходники, а там 100500 неквалифицированных импортов, и хер знает, где смотреть сигнатуры и доки используемых функций. Ненавижу тех, кто так делает. Благо, есть механизмы, чтобы сделать читабельно.
В жаве import static * тоже недолюбливаю. Дело даже не в том что оно в таких ситуация выдаёт ошибку со словом ambigous.
Просто без IDE совсем непонятно из какого класса/пакета пришёл метод.
Конечно я его частенько использую, много либ заточены именно на него.
>typedef boost::asio::ssl::stream<boost::asio::ip ::tcp::socket> ssl_socket;
Но вот в жабе я пару лет назад придумал для себя улучшенный импорт с алиасом. Причем с ограничением неймспейса по методу/классу:
Предпочитаю это import static *
Может кто-то додумался до этого раньше, но я на просторах интернета и в книжках не встречал такого.
Про то и речь. Фанатики могут сколько угодно кричать "возьмите ИДЕ нищеброды", только вот они будут пищать как девчонки, когда придёт пора ревьюить код в типичном ревью-туле в браузере.
Разработчики жабы не учли естественной потребности в алиасах, которые были в крестах с незапамятных времён, в итоге имеем унылое нечитабельное говно со звёздочками либо сотни однострочных импортов. Про отсутствие тайпдефов я вообще молчу.
Олсо, не совсем понял хак с алиасом. Можно ещё пример?
http://ideone.com/urrN0b
Если писать короткие методы - всё на виду. Не надо прыгать вверх класса.
В 5-ой жабе сделали, только никому не сказали :)
Можно завести "статический" класс /com/my/module.java (именно с маленкой буквы), и запихать в него все родственные интерфейсы, енумы и классы.
Это позволяет имитировать явную квалификацию имён модулей без указания полного имени пакета.
Оно даже на DSL становится похоже.