- 1
2/3-
Python / Говнокод #13904
−100
ПИТОНОПРОБЛЕМЫ ;)
P.S. Да, я читал доки. Не меня в них тыкать носом.Запостил:
bormand,
07 Октября 2013
Говнокод: по колено в коде.
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
© 2008-2024 «Говнокод.ру»
Обратная связь | Лицензионное соглашение | 
Follow us!
Follow us!
>Не меня в них тыкать носом.
А кого? Есть предложения?
вам идёт ваш ник
Ещё вопрос кому он больше идет.
А чё. Переносимо.
Всех предупредили заранее. Но и не минусовал, т.к. 2/3 намёк (не знаю борманд осознанно так написал) что третья версия делит вторую.
2/float(3) Это вроде-бы к 2 версии относиться.
я правильно понимаю что проблема в том что на питоне 2 это 0, на 3ке это 0.6(6)?
медленно начинаю понимать почему перл с самого начала в лоб все подобное во флоаты автоматом конвертит.
Это тоже не фонтан. Мне больше всего нравится, как это сделано в Haskell. Числовые литералы там полиморфны, и выражение 2/3 будет иметь тип из класса Fractional (Float или Double в зависимости от контекста). Если же тип точно известен и это Int или Integer, оператор / для них не определён, нужно явно конвертировать во float. Для деления с остатком есть div, mod и divMod.
Подход OCaml с отдельными набороми операторов меня слегка бесит.
пахнет лиспом.
честно скажу что как оно в перле точно я не ковырял. но мое впечатление что деление всегда конвертит во флоат. все остальные операции - только если происходит переполнение. официально даже и разницу узнать нельзя, внутренее представление числа int или float. все таки как бы не математический язык: вычисление выражений делается тупой интерпретацией и уже производительность наталкивает на мысли.
Даже комплексные числа? :(
Проблемы с семантикой деления решаются примерно так:
Что делает это очень многословным, но с другой стороны, как правило можно ограничиться только указанием типов аргументов, компилятор сам выберет нужную реализацию.
попробуй:
на 5.8/5.10: первая `IV` - это int value, вторая `NV` - это "number" value (aka float).
Причем не только div и mod, которые округляют вниз (что удобно для всяких тайлов), но и rem с quot'ом, которые округляют к нулю (аля интелоделение).
P.S. В питоне тоже сделали div, но назвали его, имхо, стремно: "//". Имхо, div был бы наглядней, чем эти джве палки.
Типы-то разные, делить нельзя.
А неявные преобразования запрещены нафиг.
И это хорошо.
Ээ покажи мне язык, который себя по другому ведет. В новых питонах от этой сишной хуйни с привязкой к типам решили избавиться и сделать логичный, калькуляторный div.
>>в задней части тела
В спине?
В затылке.
:O
Яваскрипт, похапешечка?
> сишной хуйни
Да на сишке это еще не так страшно было... в сишкоподобных языках тип же заранее известен, и деление или всегда флоатовое, или всегда целочисленное. А тут оно зависит от данных: ввел юзер 2.0 - флоаты, ввел 42 - инты. Что вызывает батхерты и заставляет делать лишние касты во флоат.
> В новых питонах
Ну вот в третьем да, все нормально.
>Яваскрипт, похапешечка?
/0. Слабая типизация не нужна.
>А тут оно зависит от данных: ввел юзер 2.0 - флоаты, ввел 42 - инты. Что вызывает батхерты и заставляет делать лишние касты во флоат.
Батхерты такого рода оно вызывает у мудачья, использующего input() вместо raw_input(). Алсо, from __future__ import четотам.
Ну числа же не только из консолечки читают...
Может быть мы пишем библиотечную функцию, которая принимает некое число, и потом что-то с ним делает. И юзер вместо положенного флоата передает туда int.
input() = eval(raw_input). Продолжать? Из тройки его в таком виде убрали.
> __future__, конечно же, ниасилили
Это более-менее подходит если ты пишешь 2.x код, ориентируясь на возможный переход на 3-ку. Для портирования существующего легаси это бесполезно.
added __past__ for legacy code support
Он от этого просто так не поломается, т.к. код из двойки просто так на тройке не запустится хотя бы из-за print, а те, кто портируют - такие нюансы знают (google: различие между двойкой и тройкой)
То, что вам кажется проблемами, на самом деле - хуйня собачья и верхушка айсберга, который вы по незнанию не видите. Сразу видно, что ничего не портировали. Например, пропал "".(en|de)code('hex'), его запиздочили в codecs. bytes внезапно! сделали массивом интов, а не символов. Пропал оператор форматирование "%s" % "a". "".format() для байтов не работает.
Я прочитал последний Dive into Python, там в деталях описано, как происходит портирование. Это вызвало у меня такой батхёрт, что я просто для личных целей продолжаю пользоваться 2.x, игнорируя 3.x.
Ну и вообще странно, что вещи из топика нету в 2to3.
Что-то такое есть :) Но твой батхерт имеет мало общего с реальностью, т.е. у людей, реально работающими с этим, батхерт вызывает другое.
Ну и насчет 2to3 - фитон - не жавка, где в эклипсе можно методы мышкой перетаскивать. Тут в статике вообще нихуя не работает.
именованые кортежи, аннотации и другой подобный сахар?
конструктивно: все-таки, где раньше было реализовано?
мило.
от недостатка шлюх желать трахать все, хоть эл.розетку.
2.0: http://ideone.com/h4CzMm
3.0: http://ideone.com/DyXhyk
В тройке решили сделать более интуитивное поведение. А для целых чисел сделали специальный оператор // (хотя, имхо, лучше бы они назвали его div, а не этой фигней с двумя палками).
>фитон
/0
Целочисленное деление - изобретение байтоёбов.
сейчас уже важно распараллелирование на ядра, нежели отставание байткода от нативного.
как никогда актуально знание алгоритмов, их сложность и тактикак assParallel (простите, не удержался)
оффтоп: мне сегодня доказывали, что расспареливование на низком уровне дискредитирует всю 20-летнюю теорию сложности алгоритмов, ибо это вносит хаос в однопотоковый подсчет сложности
Впрочем, тем временем в проекте PyPy ставят эксперименты с транзакционнной памятью, которая новыми процессорами будет поддерживаться аппаратно. Поживем - увидим.
С учётом того, что сложность алгоритмов обычно оперирует ассимптотикой количества требуемых операций (или ячеек памяти), то этот тезис выглядит очень спорно. От того, что операции выполняются на разных ядрах, их кол-во ассимптотически не изменяется, так ведь?
По счастливому совпадению из меньшего кол-во операций в случае однопоточной программы часто следует меньшее время выполнения (и то не всегда верно, т.к. сильно влияют факторы вроде локальности данных). В многопоточной программе это работает ещё реже, но, тем не менее, это слабо влияет на классический анализ сложности.
Медленная шина для передачи туда-сюда, и разное адресное пространство CPU и GPU замедлят такой код раз в сто.
Это чисто царский подход - юноши-максималиста, оценивающего сырую мощь, а не схему в целом.
Поэтому имеет смысл кинуть на GPU over 100000 действий. Опять же не панацея.
Будь у вас хоть миллионы ядер - не разложите вы, на существующей алгоритмической базе, огромное простое число на множители и не поломаете открытую криптографию.
И то что оставалось от гипотезы Гольдбаха не докажете экспериментально - тупым перебором до числа Виноградова. Хотя казалось бы сейчас компьютеры жутко скоростные, не то что 1937 год.
А всё потому что для полного перебора энергии понадобилось бы больше чем есть в Солнечной системе.
Кстати всех поздравляю - наконец-то, совсем недавно тернарную доказал другой выходец со славянской земли; теперь уже окончательно и бесповоротно.
"В 2013 году тернарная гипотеза Гольдбаха была окончательно доказана Харальдом Гельфготтом" wiki
>Будь у вас хоть миллионы ядер - не разложите вы, на существующей алгоритмической базе, огромное простое число на множители и не поломаете открытую криптографию.
Класс сложности известен + простая арифметика? Или это твой коллега по шараге тоже изобрел?
Ядра - количественное улучшение, максимум на порядок.
Алгоритмы - качественное, они позволят решать задачи, на брутфорс для которых ранее потребовалось бы невообразимое количество энергии (то есть нерешаемые в принципе).
Экстенсивное vs Интенсивное. Так понятно?
А вообще, мощности разве еще не растут экспоненциально?
Но теоретической базы посчитать пока что не очень. Вся имеющаяся теория более-менее сводится к CSP (Communicating Sequential Processes), но там еще далеко до моделей производительности.
Но как в последнее время все образованное сообщество метнулось производительность считать не в тиках, а в копировании данных (communication avoiding), то это создает совсем другую картину мира, в которой большая О вместе с фитой становятся менее актуальными.
Это к чему? Сложность "предсказывает" кол-во операций по отношению к размерности задачи, скорость - пройденное расстояние по отношению к прошедшему времени.
в книжках никто не знает на чем ты поедешь, а понять относительные величины легко можно и сравнив сложности, не прибегая к скорости - от москвы до питера 700км, а до продуктового магазина - 100м
софистика
Т.е. если сравнивать со скоростью, имеем что из нескольких точек А, Б, В... вышло сколько-то поездов и все вместе проехали 386 километров. Такая деконструкция бессмысленна, и мерять общее пройденное расстояние не зная как минимум сколько поездов всего было - просто бессмысленное занятие.
[GCC 4.7.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 2/3
0
>>> 2/3.
0.6666666666666666
>>> from __future__ import division
>>> 2/3
0.6666666666666666
>>> 2//3
0
P.S. Хотя с // они опять накосячили - если один из аргументов флоат, то он какого-то хуя возвращает float, хотя подразумевается целый результат. 2.0 // 3 = 0.0, хотя должно возвращать просто 0, ну или на крайний случай исключение.
У меня горит, потому что я на это нарвался, когда выкладывал этот гк :) Впрочем виноват тут скорее я сам, т.к. понадеялся на интуитивное поведение (/ всегда возвращает флоат, аля паскаль), и доку по делению прочитал только после того, как наткнулся на эту говнофичу деления.
Почему это поведение для тебя интуитивное? В сишкообразных языках это всегда было как в си.
Ну как минимум жабаскрипт себя так ведет. И легче предсказать результат.
> В сишкообразных языках это всегда было как в си.
Еще раз. Не надо сюда приплетать сишкообразные языки. У них, практически у всех, типы разруливаются во время компиляции (в жс нет - но в нем / всегда флоат). И там я всегда знаю заранее, когда / это целочисленное деление, а когда нет.