- 1
- 2
- 3
- 4
- 5
- 6
# 2017991 => 20/17/99
# 658581 => 65/85
# 6585 => 65
id = id[:(len(id)%2) - 2]
subfolders = ''.join([(i and i % 2 == 0 and '/' or '') + x for i, x in enumerate(id)])-
Python / Говнокод #12850
−99
В 4 часа утра написал такой вот щит. Можно по вашему мнению это как-то упросить?
Запостил:
sbb,
04 Апреля 2013
Follow us!
>>> '/'.join([''.join(l) for l in zip(s[::2], s[1::2])])
'09/89/22'
мне что-то кроме
ничего в голову не лезет
че это?
Не корысти ради, а из любви к исскуству.
какая гадость, наоборот же, не хватает функциональщины: intercalate "/" . init . splitEvery 2
С этого момента поподробнее: вход / что по-вашему выдаст / что по-вашему должна?
Должно: 10/16/15
Получили из-за init : 10/16
-pedantic
шланг 3.2: source.cpp:12:13: warning: variable length arrays are a C99 feature [-Wvla]
г-ацетилцистеин 4.8.0: source.cpp:12:10: warning: ISO C++ forbids variable length array [-Wvla]
В продакшене этому, конечно, не место.
в продакшене
не пойму отчего прямо сейчас в бубунтовском gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-2ubuntu1) линковка с порядком опций g++ -L ... -llib1 -llib2 -o result objects нихера не работает - не находит никаких символов из указанных библиотек, а с порядком опций g++ -L ... -o result objects -llib1 -llib2 всё нормально
чудеса какие то
вот сейчас экспериментирую с bleeding-edge и удивляюсь
> std::get_temporary_buffer<char>(group_si ze);
>
> if (buf.second < group_size) {
> std::return_temporary_buffer(buf.first);
> throw std::runtime_error("Can't allocate temporary buffer");
Лол, get_temporary_buffer не обязан выдавать тебе весь запрошенный буфер даже при достаточных ресурсах, так что ты заюзал компилятороспицифичную вещь
P.S. Эх, с VLA очень удобно получается...
Вот и мне не нравится, что стандартные алгоритмы не имеют версии ограничиные размером всех источников и приемников. По мне так лишний камень в огород безопасности С++.
По уму он должен пару итераторов возвращать, чтобы можно было проверить, какая последовательность кончилась раньше. Но мне было лень писать лишние буквы.
на перле, как понял:
почему никто сверху не пользуется жадностью регулярок, я не понимаю.
было бы короче.
я бы не стал на этом останавливаться... действительно, какая разница: интерпретировать цикл или рекурсию? (а поддержки tco нема) etc
> Ну так есть же рядом тест
Смотрю на поля cumtime для test_regex и test_for и вижу, что здесь регулярки не нужны. А куда надо?
Чтобы понять, что в цикле происходит разбивка на части и аггрегация, нам нужно читать и понимать что делает код, а не что должен делать. Это более затратная операция, которая чревата ошибками вызваными невнимательностью.
Врезультате мы получили соизмеримые результаты по времени - ну так чего эще хочется?
Вы хотите оптимизировать? Питон позволяет расширения на Си - если так сильно хочется, напишите на си и подключите.
>Вы хотите оптимизировать? Питон позволяет расширения на Си - если так сильно хочется, напишите на си и подключите.
Понятнее? Все ебанулись штоле со своими регулярками, пёрлом, крестами и итераторами:?
Сука, блядь, в школу, немедленно. Изучать цикл фор. Пиздец...
>но уровень "интуитивности" и "читабельности" вашего питона
Будто бы пёрл лучше? Такое же говно.
http://ideone.com/jZWel5
Знаю String.Join некошерно, надо было Aggregate
А те, кто делал аггрегацию в цикле - остануться за бортом (т.как они уже написали алгоритм так, что он должен быть линейным).
2. Абстракция тредов останется в далеком прошлом, вместе с ХМЛ, Явой и 64-битными системами.
3. Регулярные выражения будут развиваться и дополнятся новыми классами. После того как расширение предложеное Микрософтом будет принято в новой версии ПОСИКС - регулярные выражения смогут описывать рекурсивные грамматики. А через год - не только рекурсивные, но и контексто-зависимые. В дальнейшем в стандарт добавят ПОС-тэггинг, систему выведения типов для естесственных языков и много других плюшек. Регулярные выражения станут неотъемлимой частью детских книжек и школьных учебников по литературе.
Если они начнут пилить четвертую до полураспада второй - то и ее уже не переживет ;)
Лисп - в меньшей степени, а вот такие, в которых синтаксис языка создавал какие-то договоренности по поводу функционирования системы (типа, как в Эрланге реализованы потоки, или как уже вышеупомянутый цикл for в куче языков) - вымрут как фортрановские встроенные функции предназначавшиеся только для печати на матричный принтер.
Открытому стандарту придёт пиздец.
>расширение предложеное Микрософтом
EEE
>Если НВидия доведет дело до победного конца, и эти компутеры будут продавать в качестве обычных ПК
Это только в ваших мечтах. А люди в реальном мире будут десятилетиями писать фор.
5. Компания Уолт Дизней подарит Китайской Народной Республике дочернее предприятие Лукас Филмз. Врезультате в течение года появится сразу тринадцать новых полноформатных эпизодов саги, проливающих свет на благородное происхождение джедаев из потомков династии Минь, вовремя принявших сторону Гоминьдана в народно-освободительной войне.
Объясняю. В данном примере самым важным куском и одновременно бутылочным горлышком, является работа с памятью.
Никакая нвидиа, никакой интерпретатор лиспа, никакой AssParallel и никакой майкрософт не ускорит memcpy и миллионом суперкомпьютеров.
Latency памяти в сотни раз выше процессорной. Это основы.
Тут это где? На говнокоде?
Уже десятилетие кормят нас анонсами всяких "перспективных" Z-RAM, TRAM итп.
А толку то? DRAM по-прежнему рулит. Попытка интела поюзать Rambus закончилась известно чем.
А толку?
>да, я готов заплатить эту сумму за память
Где ты возьмешь столько? На Хацкиле денег не платят, только борщ.
> быстродействие L2.
Поделишься ссылочкой, где можно купить пару гиг SRAM с быстродействием L2 всего лишь по цене компа? ;)
>если будет
>Один же комп мне мамка уже купила.
Лол, с этого и надо было начинать.
Полагаю при этом они не будут совместимы по синтаксису с регэксами в Python 4 и 3. Потому код придется переписывать но новую версию.
Суть Питона тм
Зачем здесь это виндоблядство?
В моём показательном варианте ровно один недостаток - строки в жс немутабельные.
Очевидно оно заменяется массивом, буфером или указателем на b.
А потом
memcpy(b+bi,a+i,n) или там sb.append(a.subString(i,i+n))
Если интересно.
Задачка, которая проще и главное понятнее описывается на обычном языке чем на всех убернавороченных пифонах, хацкилях, регулярках и примкнувших к ним крестах.
Ну кстати пример Романа, несмотря на крестоблядство мне понравился. Человек думает чуть шире - делая код универсальным.
как по мне, большинство извращений на треде по двум причинам: (А) народ слишком сильно (предварительно) оптимизирует и (Б) чем выше уровень языка, тем сложнее в нем работать с простыми вещами как символ или строка.
на перле можно было бы и по другому написать, как на ц/крестах, без регулярок (не тестировал):
но народу же хочется все в одну неотлаживаемую строку впихнуть...
ЗЫ к слову, в перле регулярками с извращениями точно можно в одну строку впихнуть.
И чтоб понять оную потребуется больше времени чем три очевидных строки с циклом.
> большинство извращений на треде по двум причинам
a) sicp и функциональщина головного мозга. reusable,reusable,reusable. combination and abstraction. functions.
б) выебоны
в) готовые либы совсем отучили думать головой
В итоге вся изобретательность идёт на комбинацию готовых компонентов (в особо запущенных случаях создается целый reusable велосипед).
>чем выше уровень языка, тем сложнее в нем работать с простыми вещами как символ или строка.
Неправда это.
>warn "$id ".join('/',@subfolders);
Всё ваши варианты с join - джва прохода, пусть даже там ленивый итератор, всё-равно будет лишний цикл.
Все ваши варианты без join - хоть и один проход, все равно будет лишний if в цикле.
:)
Зря вы так. Это уже сто раз проходили.
Боюсь представить сколько ifов и прочего оверхеда будет в регэксе.
вообще то это была "шутка" на тему "premature optimization is the root of all evil." (c) Donald Knuth.
И поэтому надо писать эзотерический код?
1. += должен проверять типы параметров. Это много условий. (функция генерик).
2. Нужно проверять не изменилось ли значение len - т.как язык таких гарантий не дает.
3. + аналогично += должен проверять типы параметров.
4. Динамический резолвинг свойств substr и length - при чем каждый раз, как они встречаются в коде во время выполнения.
5. - тоже ведь должен определить типы аргументов.
6. Ну и в конце концов - присваивание и резолвинг объекта к которому применяется свойство - тоже должны и на null проверить, и на то, что выражению слева разрешено присваивать.
Возможна временная ситуация, когда более общий код, в котором программист не задает явно стратегию выполнения не оптимизирован (Питон никто особо и не пытался оптимизировать), а код, в котором операции делаются на низком уровне работает лучше т.как его было в данный момент легче оптимизировать (т.как он больше похож на целевое представление).
Но эта ситуация такой вечно не останется. Тому пример Явовский JIT, который через много лет научился хорошо компилировать. Со всякими хитрыми оптимизациями и т.п.
>1. += должен проверять типы параметров.
>Это много условий. (функция генерик).
Единственная проблема моего кода += (копирование в новую переменную, о чем вы не сказали) описана тут:
http://govnokod.ru/12850#comment174324
...
> Динамический резолвинг свойств substr и length
>пример Явовский JIT, который через много лет научился хорошо компилировать.
js давно компилируется. Даже убогий ie научился. Я уже где-то вам сообщал об этом немаловажном факте, ломающем всю вашу аргументацию.
Если вам интересно об этом узнать по-подробнее, рекомендую к прочтению: Types and Programming Languages, Benjamin C. Pierce, ISBN 0-262-16209-1 или более новое издание, если есть. (Книга представляет собой пособие для студентов вузов факультетов информатики, автор - преподаватель или преподавал в MIT).
Человек, кстати сказать, поборник и потворник статической типизации.
Один раз компилируется и потом работает нативно - в этом суть JIT.
Если объект не менялся, а меняться он никак не мог, потому что строки иммутабельны подтверждать ничего не надо. И ссылка на объект тоже не меняется.
Именно потому ВНЕЗАПНО js делает по скорости всякие путхоны
http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=v8&lang2=pyt hon3
А вот теперь, вы то этого, конечно, напробовались в жизни, и знаете прекрасно - чего бы это я стал напоминать. Но, так, на всякий случай: когда вы работаете с компилятором Лиспа, то вы во время разработки получаете от него информацию нужную для понимания того, как компилятор понял вашу программу, и как ему можно "помочь", чтобы он сгенерировал лучший код.
Но вот если вы думаете, что это хоть в какой-то степени возможно применить к ж. скрипту - вы сильно заблуждаетесь. В языке нет достаточно средств для того, чтобы выразить компилятору, что именно нужно сделать с кодом. А это бывает необходимо в любой нетривиальной ситуации.
Питон никто не пытался оптимизировать. Возможно ли его лучше оптимизировать чем ж. скрипт? - вот это другой вопрос, на который я бы ответил утвердительно. И особенно это случится, когда в нем будут аннотации типов (описание http://www.python.org/dev/peps/pep-3107/). В Питоне нет таких тяжело запущенных случаев, которы встречаются в ж. скрипте, таких как неявные конвертации. Но есть и недостатки (неявный вызов методов), которые мешают однозначному выведению типов.
А вы отвечаете про что-то совсем другое.
>> Аннотации аргументов функций ввели в третьей ветке
> А вы отвечаете про что-то совсем другое.
ну да, ну да.
PyPy
Кроме ПиПи есть еще Питон который компилириуется в Си исходный код, ну а потом - это уже Си программа. (Так Ютуб начинали).
Cyton
Stackless Python
У меня дежавю, но, кмк, все уже сообщали и не по разу. А воз и ныне там.
Надеюсь, про пифон вы не делаете вывод из пары неоптимальных примеров? А с хацкилем что не так, предвосхищая вброс про библиотеку легко пишется, если бы не было: splitEvery _ [] = []; splitEvery n xs = chunk : splitEvery n rest where (chunk, rest) = splitAt n xs
btw, задача "сделать !@#$ато" записывается намного проще на естественном языке
Нет. Не делаю. Тут же важно кто и как на нем пишет, потом уже сам язык.
На самом деле это скорее хаскель-код, написанный на крестах. Фактически, там реализована "сопрограмма", перекачивающая группы символов из входной последовательности в выходную. По сути вывод начинается ещё до того, как достигается конец входной строки.
Для решения задачки это лютый оверкилл, идея приносит профит только на длинных последовательностях, но меня неотвратимо тянет к подобным вещам...
Оно же итератор, оно же ленивый список. Как там "любая достаточно сложная программа на С содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Lisp"
> но меня неотвратимо тянет к подобным вещам...
Потому и понравилось - проход один (хотя не знаю может питонвское re тоже ленивое?)
Я тоже везде такой подход стараюсь использовать. Еще кстати задолго до того как впервые увидел ленивые фп языки.
Это осознание силы ленивого кода пришло из io потоков.
А так говно, да. Страшное.
Ну и какая у них там сила? Неужели закрытие потока до завершения чтения всех данных из-за лени? Кулстори, бро
Тогда может так?