- 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)])
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
−99
# 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)])
В 4 часа утра написал такой вот щит. Можно по вашему мнению это как-то упросить?
myaut 04.04.2013 15:21 # +1
>>> '/'.join([''.join(l) for l in zip(s[::2], s[1::2])])
'09/89/22'
theli 04.04.2013 15:27 # +1
мне что-то кроме
ничего в голову не лезет
guest 04.04.2013 23:27 # 0
guest 05.04.2013 15:41 # 0
guest 05.04.2013 16:11 # +4
LispGovno 04.04.2013 19:17 # 0
че это?
wvxvw 04.04.2013 20:03 # +4
Не корысти ради, а из любви к исскуству.
sbb 04.04.2013 23:21 # 0
anonimb84a2f6fd141 04.04.2013 23:41 # 0
guest 04.04.2013 23:57 # +2
какая гадость, наоборот же, не хватает функциональщины: intercalate "/" . init . splitEvery 2
LispGovno 05.04.2013 13:32 # 0
guest 05.04.2013 15:33 # 0
С этого момента поподробнее: вход / что по-вашему выдаст / что по-вашему должна?
LispGovno 05.04.2013 15:38 # −1
Должно: 10/16/15
Получили из-за init : 10/16
guest 05.04.2013 15:41 # +2
LispGovno 05.04.2013 15:53 # −1
sbb 05.04.2013 16:05 # 0
bot-minurast 05.04.2013 22:47 # 0
roman-kashitsyn 05.04.2013 11:46 # +1
roman-kashitsyn 05.04.2013 13:29 # 0
defecate-plusplus 05.04.2013 13:31 # +4
roman-kashitsyn 05.04.2013 15:40 # 0
defecate-plusplus 05.04.2013 15:46 # 0
-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]
roman-kashitsyn 05.04.2013 15:50 # 0
В продакшене этому, конечно, не место.
defecate-plusplus 05.04.2013 15:51 # 0
в продакшене
roman-kashitsyn 05.04.2013 15:53 # 0
defecate-plusplus 05.04.2013 17:57 # 0
не пойму отчего прямо сейчас в бубунтовском 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 всё нормально
чудеса какие то
roman-kashitsyn 05.04.2013 18:05 # +1
defecate-plusplus 05.04.2013 18:08 # 0
вот сейчас экспериментирую с bleeding-edge и удивляюсь
roman-kashitsyn 05.04.2013 18:23 # 0
LispGovno 05.04.2013 13:34 # 0
bot-minurast 05.04.2013 22:52 # 0
roman-kashitsyn 05.04.2013 23:05 # 0
roman-kashitsyn 06.04.2013 20:09 # +3
LispGovno 06.04.2013 20:50 # 0
> 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 не обязан выдавать тебе весь запрошенный буфер даже при достаточных ресурсах, так что ты заюзал компилятороспицифичную вещь
roman-kashitsyn 06.04.2013 21:21 # 0
LispGovno 06.04.2013 21:30 # 0
roman-kashitsyn 06.04.2013 21:37 # −2
P.S. Эх, с VLA очень удобно получается...
LispGovno 06.04.2013 22:14 # 0
roman-kashitsyn 06.04.2013 22:35 # 0
roman-kashitsyn 06.04.2013 23:03 # +1
LispGovno 06.04.2013 23:15 # 0
Вот и мне не нравится, что стандартные алгоритмы не имеют версии ограничиные размером всех источников и приемников. По мне так лишний камень в огород безопасности С++.
roman-kashitsyn 06.04.2013 23:18 # +2
roman-kashitsyn 06.04.2013 23:34 # +2
По уму он должен пару итераторов возвращать, чтобы можно было проверить, какая последовательность кончилась раньше. Но мне было лень писать лишние буквы.
LispGovno 06.04.2013 20:55 # 0
roman-kashitsyn 06.04.2013 21:24 # 0
Dummy00001 05.04.2013 03:15 # +4
на перле, как понял:
почему никто сверху не пользуется жадностью регулярок, я не понимаю.
wvxvw 05.04.2013 11:10 # +1
было бы короче.
Vindicar 05.04.2013 11:43 # 0
wvxvw 05.04.2013 12:07 # +1
guest 05.04.2013 13:30 # 0
я бы не стал на этом останавливаться... действительно, какая разница: интерпретировать цикл или рекурсию? (а поддержки tco нема) etc
wvxvw 05.04.2013 13:43 # +2
guest 05.04.2013 15:23 # +1
> Ну так есть же рядом тест
Смотрю на поля cumtime для test_regex и test_for и вижу, что здесь регулярки не нужны. А куда надо?
wvxvw 05.04.2013 16:06 # +2
Чтобы понять, что в цикле происходит разбивка на части и аггрегация, нам нужно читать и понимать что делает код, а не что должен делать. Это более затратная операция, которая чревата ошибками вызваными невнимательностью.
Врезультате мы получили соизмеримые результаты по времени - ну так чего эще хочется?
Вы хотите оптимизировать? Питон позволяет расширения на Си - если так сильно хочется, напишите на си и подключите.
3.14159265 05.04.2013 16:22 # +4
>Вы хотите оптимизировать? Питон позволяет расширения на Си - если так сильно хочется, напишите на си и подключите.
Понятнее? Все ебанулись штоле со своими регулярками, пёрлом, крестами и итераторами:?
Сука, блядь, в школу, немедленно. Изучать цикл фор. Пиздец...
>но уровень "интуитивности" и "читабельности" вашего питона
Будто бы пёрл лучше? Такое же говно.
wvxvw 05.04.2013 16:44 # 0
3.14159265 05.04.2013 16:52 # +1
http://ideone.com/jZWel5
Знаю String.Join некошерно, надо было Aggregate
wvxvw 05.04.2013 18:06 # 0
А те, кто делал аггрегацию в цикле - остануться за бортом (т.как они уже написали алгоритм так, что он должен быть линейным).
roman-kashitsyn 05.04.2013 18:09 # 0
wvxvw 05.04.2013 18:10 # 0
roman-kashitsyn 05.04.2013 18:19 # 0
wvxvw 05.04.2013 18:27 # 0
2. Абстракция тредов останется в далеком прошлом, вместе с ХМЛ, Явой и 64-битными системами.
3. Регулярные выражения будут развиваться и дополнятся новыми классами. После того как расширение предложеное Микрософтом будет принято в новой версии ПОСИКС - регулярные выражения смогут описывать рекурсивные грамматики. А через год - не только рекурсивные, но и контексто-зависимые. В дальнейшем в стандарт добавят ПОС-тэггинг, систему выведения типов для естесственных языков и много других плюшек. Регулярные выражения станут неотъемлимой частью детских книжек и школьных учебников по литературе.
roman-kashitsyn 05.04.2013 18:34 # +1
bormand 05.04.2013 18:42 # 0
Если они начнут пилить четвертую до полураспада второй - то и ее уже не переживет ;)
wvxvw 05.04.2013 18:53 # 0
Лисп - в меньшей степени, а вот такие, в которых синтаксис языка создавал какие-то договоренности по поводу функционирования системы (типа, как в Эрланге реализованы потоки, или как уже вышеупомянутый цикл for в куче языков) - вымрут как фортрановские встроенные функции предназначавшиеся только для печати на матричный принтер.
3.14159265 05.04.2013 19:46 # +1
Открытому стандарту придёт пиздец.
>расширение предложеное Микрософтом
EEE
>Если НВидия доведет дело до победного конца, и эти компутеры будут продавать в качестве обычных ПК
Это только в ваших мечтах. А люди в реальном мире будут десятилетиями писать фор.
LispGovno 05.04.2013 23:09 # 0
wvxvw 05.04.2013 19:19 # 0
5. Компания Уолт Дизней подарит Китайской Народной Республике дочернее предприятие Лукас Филмз. Врезультате в течение года появится сразу тринадцать новых полноформатных эпизодов саги, проливающих свет на благородное происхождение джедаев из потомков династии Минь, вовремя принявших сторону Гоминьдана в народно-освободительной войне.
3.14159265 05.04.2013 19:51 # +3
Объясняю. В данном примере самым важным куском и одновременно бутылочным горлышком, является работа с памятью.
Никакая нвидиа, никакой интерпретатор лиспа, никакой AssParallel и никакой майкрософт не ускорит memcpy и миллионом суперкомпьютеров.
Latency памяти в сотни раз выше процессорной. Это основы.
wvxvw 05.04.2013 20:07 # 0
3.14159265 05.04.2013 20:10 # +2
Vindicar 05.04.2013 23:00 # 0
LispGovno 05.04.2013 23:12 # 0
3.14159265 06.04.2013 16:41 # +1
Тут это где? На говнокоде?
Уже десятилетие кормят нас анонсами всяких "перспективных" Z-RAM, TRAM итп.
А толку то? DRAM по-прежнему рулит. Попытка интела поюзать Rambus закончилась известно чем.
А толку?
>да, я готов заплатить эту сумму за память
Где ты возьмешь столько? На Хацкиле денег не платят, только борщ.
LispGovno 06.04.2013 17:06 # +1
bormand 06.04.2013 17:10 # +1
> быстродействие L2.
Поделишься ссылочкой, где можно купить пару гиг SRAM с быстродействием L2 всего лишь по цене компа? ;)
3.14159265 06.04.2013 17:13 # 0
>если будет
>Один же комп мне мамка уже купила.
Лол, с этого и надо было начинать.
guest 06.04.2013 17:49 # +4
3.14159265 05.04.2013 18:20 # +2
Полагаю при этом они не будут совместимы по синтаксису с регэксами в Python 4 и 3. Потому код придется переписывать но новую версию.
Суть Питона тм
roman-kashitsyn 05.04.2013 18:24 # +2
anonimb84a2f6fd141 06.04.2013 21:42 # −2
bormand 05.04.2013 16:46 # +1
Зачем здесь это виндоблядство?
3.14159265 05.04.2013 17:51 # −1
В моём показательном варианте ровно один недостаток - строки в жс немутабельные.
Очевидно оно заменяется массивом, буфером или указателем на b.
А потом
memcpy(b+bi,a+i,n) или там sb.append(a.subString(i,i+n))
wvxvw 05.04.2013 12:40 # +1
Если интересно.
3.14159265 05.04.2013 16:06 # +1
Задачка, которая проще и главное понятнее описывается на обычном языке чем на всех убернавороченных пифонах, хацкилях, регулярках и примкнувших к ним крестах.
Ну кстати пример Романа, несмотря на крестоблядство мне понравился. Человек думает чуть шире - делая код универсальным.
Dummy00001 05.04.2013 17:12 # +3
как по мне, большинство извращений на треде по двум причинам: (А) народ слишком сильно (предварительно) оптимизирует и (Б) чем выше уровень языка, тем сложнее в нем работать с простыми вещами как символ или строка.
на перле можно было бы и по другому написать, как на ц/крестах, без регулярок (не тестировал):
но народу же хочется все в одну неотлаживаемую строку впихнуть...
ЗЫ к слову, в перле регулярками с извращениями точно можно в одну строку впихнуть.
3.14159265 05.04.2013 17:42 # +1
И чтоб понять оную потребуется больше времени чем три очевидных строки с циклом.
> большинство извращений на треде по двум причинам
a) sicp и функциональщина головного мозга. reusable,reusable,reusable. combination and abstraction. functions.
б) выебоны
в) готовые либы совсем отучили думать головой
В итоге вся изобретательность идёт на комбинацию готовых компонентов (в особо запущенных случаях создается целый reusable велосипед).
>чем выше уровень языка, тем сложнее в нем работать с простыми вещами как символ или строка.
Неправда это.
>warn "$id ".join('/',@subfolders);
Всё ваши варианты с join - джва прохода, пусть даже там ленивый итератор, всё-равно будет лишний цикл.
Dummy00001 05.04.2013 17:54 # 0
Все ваши варианты без join - хоть и один проход, все равно будет лишний if в цикле.
:)
3.14159265 05.04.2013 17:55 # 0
Зря вы так. Это уже сто раз проходили.
Боюсь представить сколько ifов и прочего оверхеда будет в регэксе.
Dummy00001 05.04.2013 18:04 # 0
вообще то это была "шутка" на тему "premature optimization is the root of all evil." (c) Donald Knuth.
3.14159265 05.04.2013 18:07 # 0
И поэтому надо писать эзотерический код?
wvxvw 05.04.2013 21:11 # 0
1. += должен проверять типы параметров. Это много условий. (функция генерик).
2. Нужно проверять не изменилось ли значение len - т.как язык таких гарантий не дает.
3. + аналогично += должен проверять типы параметров.
4. Динамический резолвинг свойств substr и length - при чем каждый раз, как они встречаются в коде во время выполнения.
5. - тоже ведь должен определить типы аргументов.
6. Ну и в конце концов - присваивание и резолвинг объекта к которому применяется свойство - тоже должны и на null проверить, и на то, что выражению слева разрешено присваивать.
Возможна временная ситуация, когда более общий код, в котором программист не задает явно стратегию выполнения не оптимизирован (Питон никто особо и не пытался оптимизировать), а код, в котором операции делаются на низком уровне работает лучше т.как его было в данный момент легче оптимизировать (т.как он больше похож на целевое представление).
Но эта ситуация такой вечно не останется. Тому пример Явовский JIT, который через много лет научился хорошо компилировать. Со всякими хитрыми оптимизациями и т.п.
3.14159265 05.04.2013 21:17 # +1
>1. += должен проверять типы параметров.
>Это много условий. (функция генерик).
Единственная проблема моего кода += (копирование в новую переменную, о чем вы не сказали) описана тут:
http://govnokod.ru/12850#comment174324
...
> Динамический резолвинг свойств substr и length
>пример Явовский JIT, который через много лет научился хорошо компилировать.
js давно компилируется. Даже убогий ie научился. Я уже где-то вам сообщал об этом немаловажном факте, ломающем всю вашу аргументацию.
wvxvw 05.04.2013 21:41 # 0
Если вам интересно об этом узнать по-подробнее, рекомендую к прочтению: Types and Programming Languages, Benjamin C. Pierce, ISBN 0-262-16209-1 или более новое издание, если есть. (Книга представляет собой пособие для студентов вузов факультетов информатики, автор - преподаватель или преподавал в MIT).
Человек, кстати сказать, поборник и потворник статической типизации.
3.14159265 05.04.2013 21:45 # +1
Один раз компилируется и потом работает нативно - в этом суть JIT.
Если объект не менялся, а меняться он никак не мог, потому что строки иммутабельны подтверждать ничего не надо. И ссылка на объект тоже не меняется.
Именно потому ВНЕЗАПНО js делает по скорости всякие путхоны
http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=v8&lang2=pyt hon3
wvxvw 05.04.2013 23:27 # 0
А вот теперь, вы то этого, конечно, напробовались в жизни, и знаете прекрасно - чего бы это я стал напоминать. Но, так, на всякий случай: когда вы работаете с компилятором Лиспа, то вы во время разработки получаете от него информацию нужную для понимания того, как компилятор понял вашу программу, и как ему можно "помочь", чтобы он сгенерировал лучший код.
Но вот если вы думаете, что это хоть в какой-то степени возможно применить к ж. скрипту - вы сильно заблуждаетесь. В языке нет достаточно средств для того, чтобы выразить компилятору, что именно нужно сделать с кодом. А это бывает необходимо в любой нетривиальной ситуации.
Питон никто не пытался оптимизировать. Возможно ли его лучше оптимизировать чем ж. скрипт? - вот это другой вопрос, на который я бы ответил утвердительно. И особенно это случится, когда в нем будут аннотации типов (описание http://www.python.org/dev/peps/pep-3107/). В Питоне нет таких тяжело запущенных случаев, которы встречаются в ж. скрипте, таких как неявные конвертации. Но есть и недостатки (неявный вызов методов), которые мешают однозначному выведению типов.
roman-kashitsyn 05.04.2013 23:51 # +1
wvxvw 05.04.2013 23:55 # 0
А вы отвечаете про что-то совсем другое.
roman-kashitsyn 06.04.2013 07:27 # 0
>> Аннотации аргументов функций ввели в третьей ветке
> А вы отвечаете про что-то совсем другое.
ну да, ну да.
roman-kashitsyn 06.04.2013 07:40 # +5
PyPy
LispGovno 06.04.2013 10:55 # 0
wvxvw 06.04.2013 11:24 # 0
Кроме ПиПи есть еще Питон который компилириуется в Си исходный код, ну а потом - это уже Си программа. (Так Ютуб начинали).
LispGovno 06.04.2013 10:57 # +3
Cyton
Stackless Python
anonimb84a2f6fd141 06.04.2013 21:43 # 0
LispGovno 06.04.2013 22:18 # 0
eth0 06.04.2013 20:51 # +2
У меня дежавю, но, кмк, все уже сообщали и не по разу. А воз и ныне там.
guest 05.04.2013 20:30 # 0
Надеюсь, про пифон вы не делаете вывод из пары неоптимальных примеров? А с хацкилем что не так, предвосхищая вброс про библиотеку легко пишется, если бы не было: splitEvery _ [] = []; splitEvery n xs = chunk : splitEvery n rest where (chunk, rest) = splitAt n xs
btw, задача "сделать !@#$ато" записывается намного проще на естественном языке
3.14159265 05.04.2013 20:41 # 0
Нет. Не делаю. Тут же важно кто и как на нем пишет, потом уже сам язык.
roman-kashitsyn 06.04.2013 20:26 # +3
На самом деле это скорее хаскель-код, написанный на крестах. Фактически, там реализована "сопрограмма", перекачивающая группы символов из входной последовательности в выходную. По сути вывод начинается ещё до того, как достигается конец входной строки.
Для решения задачки это лютый оверкилл, идея приносит профит только на длинных последовательностях, но меня неотвратимо тянет к подобным вещам...
3.14159265 06.04.2013 20:37 # 0
Оно же итератор, оно же ленивый список. Как там "любая достаточно сложная программа на С содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Lisp"
> но меня неотвратимо тянет к подобным вещам...
Потому и понравилось - проход один (хотя не знаю может питонвское re тоже ленивое?)
Я тоже везде такой подход стараюсь использовать. Еще кстати задолго до того как впервые увидел ленивые фп языки.
Это осознание силы ленивого кода пришло из io потоков.
А так говно, да. Страшное.
LispGovno 06.04.2013 20:46 # −3
Ну и какая у них там сила? Неужели закрытие потока до завершения чтения всех данных из-за лени? Кулстори, бро
roman-kashitsyn 06.04.2013 20:50 # 0
Vindicar 05.04.2013 09:31 # +1
Тогда может так?
guest 05.04.2013 13:25 # 0
sbb 05.04.2013 14:02 # 0
guest 05.04.2013 14:45 # +2
sbb 05.04.2013 15:42 # 0