Когда я был маленький и учил C++, я очень радовался, что там можно переопределить operator,() так, чтобы (x, y) обозначало скалярное произведение векторов x и y. Потому что всякие математики его часто именно так обозначают, а не точечкой и не треугольными скобочками. Правда, скобочки тут не нужны, но из-за приоритета всё равно нужны. P.S. не делайте так :/
Класс ссылается на определение Цермелло, а множество — на определение, данное Кантором. Термин класс относится к теории множеств, а множество — к наивной теории множеств.
В ZFC нет никаких классов, классы есть например в NBG, а в наивной теории множеств эти понятия считаются одним и тем же. Вы очень сильно путаетесь в этой теме.
Нуу эээ даа, первая часть статьи разжёвывает тот факт, что линейным классификатором нельзя выклассифицировать лесенку. Хотя бы потому, что побитное среднее арифметическое двух опознаваемых картинок было бы в этом случае такой же опознаваемой картинкой. А среднее арифметическое двух зеркальных лесенок — это невнятный градиент из чёрного в серое.
Поэтому навешивают активационную функцию, например сигмоиду, после чего начинает иметь какой-то смысл композиция классификаторов (а то композиция линейных функций — это линейная функция, не интересно), после чего городят композицию классификаторов.
Для этого наглядного учебного примера — достаточно. Для ненаглядных™ задач из реальной жизни, к которым применяются нейросеточки — не достаточно. Хотя иногда тоже достаточно, если нейросеточки не к месту применяются.
Смотря какие веса и какой порог. В целом мне кажется разумным, что на почти белой картинке скорее нарисована картина "Война в Крыму, всё в дыму, ничего не видно", чем "Лесенка".
Второй вопрос
Записать "векторно". Между w и x скалярное произведение спряталось (подразумевается в этой записи). А b — это бывший threshold, его просто в левую часть перенесли.
Третий
Смотря чему равно b, оно может быть и отрицательным, тем более что его только что из правой части перенесли.
Clang-Tidy отличается от Clang static analyzer (также известного под названием scan-build) наличием проверок стиля.
Чуть разверну. Clang-Tidy включает в себя Clang Static Analyzer (также известного как clang --analyze, как scan-build и под видом менюшки Product->Analyze в Xcode и Analyze->Clang Static Analyzer в QtCreator) посредством clang-tidy -checks=clang-analyzer-* и дополняет его собственными проверками, как стилистическими, так и несложным bug-finding-ом на уровне синтаксиса.
Я проспал момент, почему эти два анализатора вообще существуют отдельно, но сейчас у них сильно разная "философия" (Analyzer старается, насколько это возможно, искать только "реальные баги" и таким образом не сильно отвлекать разработчиков, а Tidy собирает под себя все мыслимые и немыслимые стилистические проверки) и немного разные фичи (Analyzer никак не может включить в себя проверки из Tidy — только наоборот; у Tidy мало интеграции с известными IDE, зато есть приятные fixit-ы; а в собственных проверках Tidy не используется движок "символьного выполнения" программы, на котором в Analyzer'е реализованы его самые хитрые и уважаемые проверки).
Хмм. Следует ли из вышесказанного что в циклах, в которых мы не хотим создавать такие замыкания, var i будет работать чуть быстрее, чем let i, ведь интерпретатору не надо создавать новую переменную i на каждой итерации?
Производительность JS это, конечно, мутно, но я не настоящий сварщик.
Угу, очень милая и затягивающая игра. Дизайн юнитов а-ля Master of Orion не вполне взелетел с точки зрения спортивного баланса — огромное дерево стало быстро распадаться на изолированные ветки, из которых нужно выбрать небольшой набор того, чем ты будешь пользоваться, а дизайн юнитов быстро превращался из мириад возможных юнитов в небольшое число действительно удачных, и в итоге получается что-то не очень сильно отличающееся от обычной RTS с фракциями. Но в целом такой дизайн конечно привлекателен, а в синглплеере ещё и невероятно затягивает возможностью проживать долгие и медленные игры.
Наверное могу попробовать сочинить статейку на хабропесочницу про нынешнее положение дел в этой опенсорсной игрухе и показать как для неё написать хеллоуворлдный AI на языке JavaScript (чтобы не играть самому), кому-нибудь интересно?
Ребята, как вы осиливаете настройку USE-флагов? Что включить, что выключить.
Вот в вашей любимой софтине появился новый флаг, который включает приятную вам новую фичу, но он выключен по умолчанию. Как вы вообще догадаетесь, что такая фича есть, и что вы хотите включить флаг?
Из названия USE-флага почти ничего не понятно. К примеру, у видеоплеера mpv есть простенький собственный GUI, и внимательное чтение описалова даже в целом расскажет тебе, чот он включается флагом
Спойлер
lua
А если бы я впервые увидел бы mpv, сидя на gentoo, то я ж ни за что ж бы не догадался бы, что такая фича вообще есть.
А если каждый флаг так осиливать, то это очень сильно увеличивает временные затраты на поддержку, разве нет? И к тому же думать надо, оказывается. Мне кажется, что я упускаю что-то очевидное.
Ну ребята… Дело ж не в Истине, дело в деньгах, как всегда. Вы можете сколько угодно доказывать, что срабатывание истинное, но чинить его от этого не побегут, и хвалить инструмент ваш тоже не обязательно побегут.
У вас bug-finding tool. Пользователь вкладывает в неё деньги (за тул) и время (разработчика, т.е. деньги всё равно менеджера) и получаешь на выходе баги (то есть багрепорты — хотя иногда и таки баги, если багрепорт был ошибочным, а его починили, или же если программист допустил ещё более серьёзную ошибку, пока фиксил не шибко критичное срабатывание).
Баги можно искать и предотвращать кучей разных способов. Другими статическими анализаторами и линтерами, динамическими инструментами, обвешиваясь автоматическими тестами и ручным тестированием, усилением ревью кода, повышением квалификации сотрудников, наконец разбором багрепортов от пользователей. Обвешиваться всеми инструментами обычно нет времени или денег.
Так вопрос-то в чём: Почему программист потратит время с большей пользой, разгребая тысячу найденных ПВС-Студией непроверенных маллоков, чем если, например, починит десяток реальных падений, уже задевших пользователя?
Если программист свободный и счастливый и обладает вечной жизнью и ему не нужно пахать на хлеб насущный, то да, он может рассуждать об истине и лжи, и думать, что вот это срабатывание истинное, вот это — ложное. Всё равно он не будет рад срабатываниям вида "Вы на воздушном шаре" (анекдот), не будет вносить premature optimizations, но в целом он будет рад повысить качество кода.
Если программист замучанный, ему каждый день говорят, что завтра релиз, разъярённые пользователи уже катят заряженные зажигательными слезами катапульты к стенам его офиса, а на нём уже и без того десятки конкретных багов, которые надо не искать а фиксить, то в его пирамиде Маслоу, увы, не найдётся места анализатору, который учит его повышать качество кода и проверять маллоки. Но в вышеупомянутой пирамиде всё равно найдётся место анализатору X, который выдаёт десяток очень серьёзных срабатываний, пусть даже в половине случаев ложных, и кроме этого ничего не говорит. Потому что анализатор X потратит очень мало его времени, а может быть как раз и вскроет причину тех дроидов багов, которых он ищет.
Поэтому мне норм называть ложными только те срабатывания, в которых анализатор несёт откровенный бред (в лучшем случае при попытке извлечь хоть какую-то пользу из symbolic execution, наверное, их и будет процентов 10-15). Но, по моим полудиванным представлениям:
Должен быть режим, выдающий только критичные для читателя срабатывания, в которых анализатор максимально уверен, которым не требуется никакая настройка для нормальной работы. В идеале оный должен быть по умолчанию, или, во всяком случае, максимально на виду. Можно сделать много слоёв критичности или разветвлённое дерево (для кого-то code style критичнее чем security, для кого-то нет).
Пользователь желает знать, какие сорта ложных срабатываний имеются, на каких паттернах кода они проявляются (от этих ваших макросов до, может быть (от балды, пальцем в небо говорю), недопиленной поддержки какой-нибудь конструкции из C++11 или какого-нибудь gcc extension в вашем самописном (же?) парсере/AST), чтобы прикинуть, есть ли эти паттерны в его коде. Также как подавить разные классы мешающих срабатываний. Правильный, честный (а не температура по больнице) ответ на вопрос про "процент ложных срабатываний", как мне кажется, лежит именно в этой области.
Пользователь желает знать, какие виды багов ваш метод находит хорошо, а для каких багов лучше воспользоваться другим методом. Это вопрос про false negatives, изучать его тяжело, но вы, видимо, можете смотреть, какие баги у ваших пользователей выживают и потом всплывают другим способом.
Как сделать программу проще для анализа? — то есть на каком коде анализатор путается и опускает руки? — вы можете это оформить это в виде советов.
Такого рода инфа в идеале отбросит скепсис и вызовет к вам кучу уважухи. Ваш агрессивный выпад "в Тайзене куча багов" порождает довольно большой спектр вопросов и недоумения, и вопрос про ложные срабатывания — это ну некий простой способ обобщить это настроение, но прямолинейный ответ "15%" явно не исчерпывает.
Менеджер, желающий внедрять анализатор, тоже в идеале должен бы не сам решать, ориентируясь только на температуру по больнице и marketing bullshit, а передать на нижние уровни иерархии вышеупомянутую инфу для осмысления и выслушать их фидбэк, нужно оно или нет.
Итого — нет смысла гордиться числом срабатываний, или даже числом истинных срабатываний (Истина мало кому нужна, увы, на хабре полностью уместна, да). Срабатываний должно быть столько, сколько пользователь сам желает увидеть.
Короче не знаю, настанет ли момент, когда я буду счастливым пользователем E, раньше благодаря вашим усилиям. Само DE очень приятно на десктопе, люблю его, но заочно — увы, много падений. Там вроде даже тайлинг милый завезли за последнее время. Вы нашли много проблем, да, стиль ужасный много где, да, для opensource это безобразие ящитаю, но не могу отделаться от ощущения, что легендарный rasterman наверняка мог бы потратить время с большей пользой. Однако не мне его судить (вас сколько угодно, хе-хе-хе), и за найденные баги спасибо.
В целом мораль очень простая: кто делает вещи — тот и прав. Если ты вкладываешь время и силы в проект, то этим ты доказываешь, что ты являешься одним из немногих людей, кому важна жизнь проекта, и тогда к твоему мнению лучше прислушатсья, и в случае конфликта тебе должны бы уступать. Особенно если ты мэйнтейнер и вкладываешь в том числе и кучу нервов, тебя лучше беречь.
Если ты форкаешь чужой проект с целью перехватить власть и направить его в другом направлении, то тем самым можешь доказать, что этот проект тебе важнее, чем текущим мэйнтейнерам. Успешный форк, который действительно в исторической перспективе жизнеспособнее исходного проекта, будет доказательством, что твои слова не были пустыми, и тогда хороший мэйнтейнер снимет шляпу и порадуется, что его дело стало ещё живее чем прежде, и что он ошибался в нужности своих вещей и идей.
Если ты ноешь, какой проект плохой и как разработчики его делают неправильно и руки растут у них не оттуда, пишешь об этом на багтрекер, на форумы, в рассылку, на википедию, в спортлото, или даже форкаешь но не рассчитываешь силы и забрасываешь форк — это никак не доказывает что тебе важна жизнь проекта, сколько бы ты ни утверждал обратное в этом процессе. Ну может чуть и важна, но твоё место гораздо скромнее, и в твоём положении надо сидеть тише и быть более благодарным за хотя бы то, что уже есть и делается, и твоё мнение не должно, вообще говоря, учитываться. Но может учитываться, если оно вдруг верное. Описанный человек (сейчас скорее обсуждаю статью и историю как описана в статье, но не пытаюсь судить что там было на самом деле) не понимает что имеет смысл только делиться и не имеет смысла требовать, и поэтому ведёт себя неадекватно.
Есть то, что есть. Причиной существования проекта являются люди, у людей есть принципы, благодаря которым и в соответствии с которым они этот проект делают. Если твой маленький патчик не принимают, потому что он не соответствует этим принципам этих людей, то увы: ведь если принципы будут нарушены, то у проекта станет меньше причин к существованию, люди будут вкладывать в него меньше времени и сил, а ты этого не хочешь, и это важнее для тебя, чем твой патчик. Или предложи сообществу себя как человека, вкладывающего силы, и свои принципы взамен, в равном количестве на примере форка или в меньшем на примере просто активного участия в имеющемся проекте. Почини чей-нибудь ещё патч, чтобы у мэйнтейнера было время починить твой, например.
Желание не достаточно просто выразить, его нужно доказывать делом, в том числе самому себе, чтобы не было случаев когда я что-то хочу, но на самом деле ничего для этого не делаю. Обманывать людей, заставляя их делать то, что тебе не так уж и важно на самом деле — нехорошо.
Основная причина проблем с оптикой — близорукости, дальнозоркости или астигматизма — это генетика. Неблагоприятные условия внешней среды, особенно при длительной работе на близком расстоянии, важны в детстве, когда развитие организма ещё не завершено.
В институте (хорошем, техническом) больше половины в очках. На работе (программистом) больше половины в очках. На улице, в тесном метро/электричке/автобусе, хоть бы один очкарик попался за всю дорогу. Неужели нас, любивших в детстве читать книжки втайне от родителей под одеялом с фонариком, настолько ничтожно мало, что даже меньше чем настолько редких проблем с генетикой?
Соглашусь, что представлять себе запутанности и туннельные эффекты — это круто и весело и чуть ли не самый кайф от Вашей находки.
Но для состязательной онлайн игры гораздо лучше раскрыть (или хотя бы разрешить раскрывать) эту информацию в интерфейсе сразу, чем потом гонять читеров, делающих себе хитрый удобный интерфейс, в котором эта информация всё равно будет показана. Потому что преимущество наглядного владения этой информацией огромное, особенно при игре с шахматными часами.
Хмм. То есть Вы шифруете строчку, применяя к ней несколько раз Wolfram rule номер такое-то.
Почти все правила необратимы. Вы не сможете расшифровать своё сообщение, даже зная правило, которым оно зашифровано. Кроме редких случаев навроде Rule 90, которое унылый XOR соседей (это где точка разбегается как треугольник Серпинского).
Более того, неясно, сколько будет коллизий (интуиция game of life подсказывает, что очень много), и насколько они будут равномерно встречаться, если мы хотим просто использовать этот алгоритм как хэш.
Если бы даже у нас не кончился порох этих проблем не было, правил всего 256, и перебрать их будет очень легко. Нужно будет либо прогонять очень много поколений, либо использовать правила с большим числом соседей — это к вопросу о быстродействии алгоритма.
Но за интерес к клеточным автоматам — спасибо! >_<
Когда я был маленький и учил C++, я очень радовался, что там можно переопределить
operator,()так, чтобы(x, y)обозначало скалярное произведение векторовxиy. Потому что всякие математики его часто именно так обозначают, а не точечкой и не треугольными скобочками. Правда, скобочки тут не нужны, но из-за приоритета всё равно нужны. P.S. не делайте так :/В ZFC нет никаких классов, классы есть например в NBG, а в наивной теории множеств эти понятия считаются одним и тем же. Вы очень сильно путаетесь в этой теме.
Нуу эээ даа, первая часть статьи разжёвывает тот факт, что линейным классификатором нельзя выклассифицировать лесенку. Хотя бы потому, что побитное среднее арифметическое двух опознаваемых картинок было бы в этом случае такой же опознаваемой картинкой. А среднее арифметическое двух зеркальных лесенок — это невнятный градиент из чёрного в серое.
Поэтому навешивают активационную функцию, например сигмоиду, после чего начинает иметь какой-то смысл композиция классификаторов (а то композиция линейных функций — это линейная функция, не интересно), после чего городят композицию классификаторов.
Для этого наглядного учебного примера — достаточно. Для ненаглядных™ задач из реальной жизни, к которым применяются нейросеточки — не достаточно. Хотя иногда тоже достаточно, если нейросеточки не к месту применяются.
В примере в самом начале не сказано откуда взялись коэффициенты, просто сказали: "давайте для примера рассмотрим такие-то коэффициенты".
А потом объясняется, что коэффициенты можно считать, например, методом градиентного спуска, минимизируя ошибку на выборке.
Ась?
P.S. Я тут ни при чём и никакие коэффициенты не выбирал, просто мимо проходил.
Смотря какие веса и какой порог. В целом мне кажется разумным, что на почти белой картинке скорее нарисована картина "Война в Крыму, всё в дыму, ничего не видно", чем "Лесенка".
Записать "векторно". Между w и x скалярное произведение спряталось (подразумевается в этой записи). А b — это бывший threshold, его просто в левую часть перенесли.
Смотря чему равно b, оно может быть и отрицательным, тем более что его только что из правой части перенесли.
Чуть разверну. Clang-Tidy включает в себя Clang Static Analyzer (также известного как
clang --analyze, какscan-buildи под видом менюшки Product->Analyze в Xcode и Analyze->Clang Static Analyzer в QtCreator) посредствомclang-tidy -checks=clang-analyzer-*и дополняет его собственными проверками, как стилистическими, так и несложным bug-finding-ом на уровне синтаксиса.Я проспал момент, почему эти два анализатора вообще существуют отдельно, но сейчас у них сильно разная "философия" (Analyzer старается, насколько это возможно, искать только "реальные баги" и таким образом не сильно отвлекать разработчиков, а Tidy собирает под себя все мыслимые и немыслимые стилистические проверки) и немного разные фичи (Analyzer никак не может включить в себя проверки из Tidy — только наоборот; у Tidy мало интеграции с известными IDE, зато есть приятные fixit-ы; а в собственных проверках Tidy не используется движок "символьного выполнения" программы, на котором в Analyzer'е реализованы его самые хитрые и уважаемые проверки).
Попробуйте также: https://llvm.org/docs/OptBisect.html
Хмм. Следует ли из вышесказанного что в циклах, в которых мы не хотим создавать такие замыкания,
var iбудет работать чуть быстрее, чемlet i, ведь интерпретатору не надо создавать новую переменнуюiна каждой итерации?Производительность JS это, конечно, мутно, но я не настоящий сварщик.
Угу, очень милая и затягивающая игра. Дизайн юнитов а-ля Master of Orion не вполне взелетел с точки зрения спортивного баланса — огромное дерево стало быстро распадаться на изолированные ветки, из которых нужно выбрать небольшой набор того, чем ты будешь пользоваться, а дизайн юнитов быстро превращался из мириад возможных юнитов в небольшое число действительно удачных, и в итоге получается что-то не очень сильно отличающееся от обычной RTS с фракциями. Но в целом такой дизайн конечно привлекателен, а в синглплеере ещё и невероятно затягивает возможностью проживать долгие и медленные игры.
Наверное могу попробовать сочинить статейку на хабропесочницу про нынешнее положение дел в этой опенсорсной игрухе и показать как для неё написать хеллоуворлдный AI на языке JavaScript (чтобы не играть самому), кому-нибудь интересно?
Как написать математическую статью по-английски — имхо даже если вы не тащите матан и не поймёте примеры, для технических текстов эта брошюрка всё равно лютый зашибенчик.
Вот в вашей любимой софтине появился новый флаг, который включает приятную вам новую фичу, но он выключен по умолчанию. Как вы вообще догадаетесь, что такая фича есть, и что вы хотите включить флаг?
Из названия USE-флага почти ничего не понятно. К примеру, у видеоплеера mpv есть простенький собственный GUI, и внимательное чтение описалова даже в целом расскажет тебе, чот он включается флагом
А если бы я впервые увидел бы mpv, сидя на gentoo, то я ж ни за что ж бы не догадался бы, что такая фича вообще есть.
А если каждый флаг так осиливать, то это очень сильно увеличивает временные затраты на поддержку, разве нет? И к тому же думать надо, оказывается. Мне кажется, что я упускаю что-то очевидное.
Ну ребята… Дело ж не в Истине, дело в деньгах, как всегда. Вы можете сколько угодно доказывать, что срабатывание истинное, но чинить его от этого не побегут, и хвалить инструмент ваш тоже не обязательно побегут.
У вас bug-finding tool. Пользователь вкладывает в неё деньги (за тул) и время (разработчика, т.е. деньги всё равно менеджера) и получаешь на выходе баги (то есть багрепорты — хотя иногда и таки баги, если багрепорт был ошибочным, а его починили, или же если программист допустил ещё более серьёзную ошибку, пока фиксил не шибко критичное срабатывание).
Баги можно искать и предотвращать кучей разных способов. Другими статическими анализаторами и линтерами, динамическими инструментами, обвешиваясь автоматическими тестами и ручным тестированием, усилением ревью кода, повышением квалификации сотрудников, наконец разбором багрепортов от пользователей. Обвешиваться всеми инструментами обычно нет времени или денег.
Так вопрос-то в чём: Почему программист потратит время с большей пользой, разгребая тысячу найденных ПВС-Студией непроверенных маллоков, чем если, например, починит десяток реальных падений, уже задевших пользователя?
Если программист свободный и счастливый и обладает вечной жизнью и ему не нужно пахать на хлеб насущный, то да, он может рассуждать об истине и лжи, и думать, что вот это срабатывание истинное, вот это — ложное. Всё равно он не будет рад срабатываниям вида "Вы на воздушном шаре" (анекдот), не будет вносить premature optimizations, но в целом он будет рад повысить качество кода.
Если программист замучанный, ему каждый день говорят, что завтра релиз, разъярённые пользователи уже катят заряженные зажигательными слезами катапульты к стенам его офиса, а на нём уже и без того десятки конкретных багов, которые надо не искать а фиксить, то в его пирамиде Маслоу, увы, не найдётся места анализатору, который учит его повышать качество кода и проверять маллоки. Но в вышеупомянутой пирамиде всё равно найдётся место анализатору X, который выдаёт десяток очень серьёзных срабатываний, пусть даже в половине случаев ложных, и кроме этого ничего не говорит. Потому что анализатор X потратит очень мало его времени, а может быть как раз и вскроет причину тех
дроидовбагов, которых он ищет.Поэтому мне норм называть ложными только те срабатывания, в которых анализатор несёт откровенный бред (в лучшем случае при попытке извлечь хоть какую-то пользу из symbolic execution, наверное, их и будет процентов 10-15). Но, по моим полудиванным представлениям:
Такого рода инфа в идеале отбросит скепсис и вызовет к вам кучу уважухи. Ваш агрессивный выпад "в Тайзене куча багов" порождает довольно большой спектр вопросов и недоумения, и вопрос про ложные срабатывания — это ну некий простой способ обобщить это настроение, но прямолинейный ответ "15%" явно не исчерпывает.
Менеджер, желающий внедрять анализатор, тоже в идеале должен бы не сам решать, ориентируясь только на температуру по больнице и marketing bullshit, а передать на нижние уровни иерархии вышеупомянутую инфу для осмысления и выслушать их фидбэк, нужно оно или нет.
Итого — нет смысла гордиться числом срабатываний, или даже числом истинных срабатываний (Истина мало кому нужна, увы, на хабре полностью уместна, да). Срабатываний должно быть столько, сколько пользователь сам желает увидеть.
Короче не знаю, настанет ли момент, когда я буду счастливым пользователем E, раньше благодаря вашим усилиям. Само DE очень приятно на десктопе, люблю его, но заочно — увы, много падений. Там вроде даже тайлинг милый завезли за последнее время. Вы нашли много проблем, да, стиль ужасный много где, да, для opensource это безобразие ящитаю, но не могу отделаться от ощущения, что легендарный rasterman наверняка мог бы потратить время с большей пользой. Однако не мне его судить (вас сколько угодно, хе-хе-хе), и за найденные баги спасибо.
Угу, и в целом ситуацию с NDA полезно понимать. Можно ли писать статьи на хабр про работу :)
Математика не говорит что отрицательные числа есть. Она их изучает :)
В целом мораль очень простая: кто делает вещи — тот и прав. Если ты вкладываешь время и силы в проект, то этим ты доказываешь, что ты являешься одним из немногих людей, кому важна жизнь проекта, и тогда к твоему мнению лучше прислушатсья, и в случае конфликта тебе должны бы уступать. Особенно если ты мэйнтейнер и вкладываешь в том числе и кучу нервов, тебя лучше беречь.
Если ты форкаешь чужой проект с целью перехватить власть и направить его в другом направлении, то тем самым можешь доказать, что этот проект тебе важнее, чем текущим мэйнтейнерам. Успешный форк, который действительно в исторической перспективе жизнеспособнее исходного проекта, будет доказательством, что твои слова не были пустыми, и тогда хороший мэйнтейнер снимет шляпу и порадуется, что его дело стало ещё живее чем прежде, и что он ошибался в нужности своих вещей и идей.
Если ты ноешь, какой проект плохой и как разработчики его делают неправильно и руки растут у них не оттуда, пишешь об этом на багтрекер, на форумы, в рассылку, на википедию, в спортлото, или даже форкаешь но не рассчитываешь силы и забрасываешь форк — это никак не доказывает что тебе важна жизнь проекта, сколько бы ты ни утверждал обратное в этом процессе. Ну может чуть и важна, но твоё место гораздо скромнее, и в твоём положении надо сидеть тише и быть более благодарным за хотя бы то, что уже есть и делается, и твоё мнение не должно, вообще говоря, учитываться. Но может учитываться, если оно вдруг верное. Описанный человек (сейчас скорее обсуждаю статью и историю как описана в статье, но не пытаюсь судить что там было на самом деле) не понимает что имеет смысл только делиться и не имеет смысла требовать, и поэтому ведёт себя неадекватно.
Есть то, что есть. Причиной существования проекта являются люди, у людей есть принципы, благодаря которым и в соответствии с которым они этот проект делают. Если твой маленький патчик не принимают, потому что он не соответствует этим принципам этих людей, то увы: ведь если принципы будут нарушены, то у проекта станет меньше причин к существованию, люди будут вкладывать в него меньше времени и сил, а ты этого не хочешь, и это важнее для тебя, чем твой патчик. Или предложи сообществу себя как человека, вкладывающего силы, и свои принципы взамен, в равном количестве на примере форка или в меньшем на примере просто активного участия в имеющемся проекте. Почини чей-нибудь ещё патч, чтобы у мэйнтейнера было время починить твой, например.
Желание не достаточно просто выразить, его нужно доказывать делом, в том числе самому себе, чтобы не было случаев когда я что-то хочу, но на самом деле ничего для этого не делаю. Обманывать людей, заставляя их делать то, что тебе не так уж и важно на самом деле — нехорошо.
В институте (хорошем, техническом) больше половины в очках. На работе (программистом) больше половины в очках. На улице, в тесном метро/электричке/автобусе, хоть бы один очкарик попался за всю дорогу. Неужели нас, любивших в детстве читать книжки втайне от родителей под одеялом с фонариком, настолько ничтожно мало, что даже меньше чем настолько редких проблем с генетикой?
Но для состязательной онлайн игры гораздо лучше раскрыть (или хотя бы разрешить раскрывать) эту информацию в интерфейсе сразу, чем потом гонять читеров, делающих себе хитрый удобный интерфейс, в котором эта информация всё равно будет показана. Потому что преимущество наглядного владения этой информацией огромное, особенно при игре с шахматными часами.
Хмм. То есть Вы шифруете строчку, применяя к ней несколько раз Wolfram rule номер такое-то.
Почти все правила необратимы. Вы не сможете расшифровать своё сообщение, даже зная правило, которым оно зашифровано. Кроме редких случаев навроде Rule 90, которое унылый XOR соседей (это где точка разбегается как треугольник Серпинского).
Более того, неясно, сколько будет коллизий (интуиция game of life подсказывает, что очень много), и насколько они будут равномерно встречаться, если мы хотим просто использовать этот алгоритм как хэш.
Если бы даже
у нас не кончился порохэтих проблем не было, правил всего 256, и перебрать их будет очень легко. Нужно будет либо прогонять очень много поколений, либо использовать правила с большим числом соседей — это к вопросу о быстродействии алгоритма.Но за интерес к клеточным автоматам — спасибо! >_<
И ещё хорошо бы закавычить
*.png, иначе командаfindбудет вести себя неожиданно, если в текущей папке есть хотя бы один.png-файл.