Это давно не новость. Когнитивные группы, кластеры, модели «малого мира» и т.п.
Верно, но тоже не новость. Достаточно даже активации всего двух нейронов («сердцевинных») кластера для вызова всего последующего каскада восприятия.
Вот они, проблемы отсутствия профильного образования! Несколько месяцев строишь велосипед, потому что не смог придумать ключевое слово, чтобы его нагуглить.
Это очень спорное утверждение. Эффективность синапса может быть связана с его характеристикой как «время жизни синапса».
О, кстати, а можете рассказать поподробнее? Я в курсе, что есть нейрогенез и образование новых связей, и понимаю, что они так-же могут «умирать». Но подробно этот вопрос не изучал, т.е. я не в курсе когда и как это происходит. Буду благодарен за статьи или какие-то другие источники информации.
Проблема в том, что сигналы бывают очень разные. Не только активирующие, но и наоборот пассивирующие нейроны. И вообще не имеющие никакого отношения собственно к сигналу, а только меняющие состояние нейронов или даже частей нейронов. Все это вы зря пропускаете.
Я еще напишу про регуляцию. Это будет отдельная статья. Выброс нейромедиаторов (и не только их) в «свободный доступ» важная штука, без которой не сложить картинку. И про понижение силы связей — тоже.
Суть статьи, а вернее серии — сделать обзор. Есть вот это, вот это, и еще это, если очень грубо приближать — оно работает вот так. Пока работает — будем пользоваться этим приближением. Перестанет работать — детализируем.
Для этой статьи и объяснения концепции «связной подсети» хватило только усиления связей и L-LTP. А вот для объяснения того, почему что-то вообще фиксируется L-LTP — уже не хватит. Или для объяснения того, как мозг «отстраивает» связи сам, решая какую-то задачу. Для этого понадобятся дополнительные сущности, и вот когда они будут нужны — я их и опишу)
Вываливать сразу тонну информации — не стоит. Это стандартная ошибка человека, который более-менее разобрался в вопросе и «уложил его в голове», при объяснении другим людям. Тебе все очевидно. Только ты потратил год, на то, чтобы это стало «очевидно», а теперь пытаешься пересказать все за полчаса)
Ух, перечитал свой комментарий, в 2 часа ночи я просто мастер объяснений.
И что это значит? Объект «стул», который я увидел, и о котором подумал, в памяти представлены разными нейронными блоками? Тогда, как они сопоставляются?
Короче, первичная зрительная кора — один огромный FrameBuffer. Можно считать 1 объект. Его можно «разложить на примитивы». Сделать что-то вроде преобразования растр->вектор. Как вы понимаете, после этого можно работать с примитивами. Например, представлять линию под углом, простой трансформацией «линии». Тем же методом «наложить текстуру».
Главный мой вопрос тут в том, как масштабируется эта схема. Например, в классическом ООП я могу создать любое разумное (ограниченное ресурсами) количество экземпляров какого-то объекта, они будут размещены в памяти по разным адресам, и манипулировать ими можно независимо. А тут всё выглядит так, как будто у меня есть один статический объект (физически представленный конкретными нейронами) и никаких других его экземпляров создать нельзя.
Сейчас попробую зайти через программирование. Короче, это как динамически создавать новые объекты из примитивов.
Представьте, хм… Слоно-зебру. Я серьезно, попробуйте.
Если я правильно понимаю процесс, у вас должно было получиться что-то содержащее самые яркие характеристики слона и зебры. Например, большой слон с хоботом, раскрашенный как зебра, или зебра с хоботом/ногами/туловищем слона, ну в общем — комбинация из «примитовов слона» и «примитивов зебры».
И когда вы представляете 4 стула, у вас происходит примерно то-же самое.
Есть 4. А 4 — это абстракция, означающая что у вас есть что-то одного «класса», но разных «инстансов». Представьте «4». Получилось 4 «чего-то». Шариков, коробочек, не важно.
А теперь на место «чего-то» — вы подставляете результат вычисления шаблона «стул». Стул, кстати, не обязан быть одинаковым, у вас есть куча информации о разных стульях.
Или наоборот, можно представить 1 стул, и начать его подгонять под шаблон «4», докидывая новые стулья.
Т.Е. мозг не «хранит 4 стула», пока вы о них не думаете. Но когда вы попробуете их представить, он начнет вычислять результат.
Очень грубая аналогия, но надеюсь, суть передал)
PS
Про внимание из комментария ниже — в первом приближении это просто фильтр, завязанный на текущий контекст (объясню позже, как это выглядит). Т.Е. пока вы «думаете о стульях», вы обрубаете левые сигналы, которые со стульями не связаны и не обрабатываете их.
Отличное замечание.
Дело в том, что зрительная кора разделена на области.
Есть первичная — туда поступают данные с глаз. Это то, что вы видите. Можно сказать, набор пикселей. Они для разных стульев будут разными.
А дальше идёт поступенчатая обработка изображения. Выделение контуров, обработка положения в пространстве, распознавание образов и прочие штуки высокого уровня, которые позволяют вам заметить, что вы видите 4 похожих объекта и отнести их в категорию стульев.
Врятли в первом этапе учавствует долговременная или кратковременная память, учитывая то, сколько информации проходит через первичную зрительную кору. Строй я мозг, я бы так делать не стал)
Насчёт представить — все немного сложнее. Если бы тут было простое "обратное преобразование" — можно было бы "увидеть стулья", как часть изображения с глаз. Этого не происходит, и тут есть два варианта:
Внутренний сигнал слишком слаб, чтобы хоть как-то помешать внешнему. — это мне кажется наиболее вероятным.
В первичную визуальную кору вообще нельзя отправить сигнал изнутри. Только самоактивация (например, в полной темноте) и сигналы с фоторецепторов. — Такой вариант нельзя исключать. Возможно, что сигнал доходит только до "высоких уровней" зрительной коры, не спускаясь на первичный.
Тут есть один интересный момент: эмоции не сами по себе возникают. Они — результат обработки информации о сигналах с органов чувств и о собственном состоянии мозга. И могут активироваться по разному.
Если перед вами пролетит кирпич — у вас по короткой дуге пройдет рефлекторный импульс на моторные реакции, и, как я понимаю, выброс различных вещей вроде адреналина не потребует «осознания» ситуации. Вот потом, когда кирпич уже давно пролетел, включится все остальное)
Но эмоции срабатывают не только в «стрессовых» ситуациях, как выше. Например, вы вполне можете испытать сильную эмоцию от того, что ошиблись. Скажем, купили что-то втридорога и узнали об этом постфактум. Или наоборот, вы долго над чем-то работали и добились результата — здесь идет удовлетворение, и оно тоже требует осознания, т.е. сначала мозг обработает это внутри, а потом врубит механизмы регуляции.
Про штуки второго рода, а так же «мотивацию», и то как все это коррелирует со связями между нейронами — я подготовлю отдельную статью. А еще там будет про зависимости)
Не совсем вас понял. В статье написано — в реальном мозге «весовые коэффициенты» связей меняются на лету, как нейромедиаторами и их аналогами, так и L-LTP, и скорее всего еще кучей других вещей, о которых мы пока не в курсе. И про стимуляцию электрическими импульсами извне — тоже написал.
Про нейропластичность — поясните пожалуйста. Не понимаю, как возможность выращивать новые связи и нейроны… Эм, летит в мой огород?
В начале статьи — дисклеймер, что это обзорная статья. В конце статьи — уточнение, что все в нее не влезло, потому что иначе она будет на 100к символов. Именно поэтому здесь нет например LTD, утечки заряда с нейронов и т.д.
Это уже лет 5 как общий ресурс, где в том числе поднимаются темы:
Куда завести трактор.
Куда поехать поработать.
Что интересного есть в устройстве города/древних развалин/пирамид/…
Управление компанией, в т.ч. не IT.
Психология и психиатрия.
И огромное количество других «не технических» тем.
Даже хабы специальные есть: Урбанизм, Управление компанией, Мозг и т.д.
Сейчас будет минутка гипотез, к которым надо относиться критично. Они ничем не подтверждены, но звучат на мой вкус здраво.
Я тут качал нейробиологию, и есть такая забавная штука, что связи в мозге могут ослабевать.
Ну, т.е. помимо того, что между нейронами можно усилить связь, таким образом «записав данные», есть и обратные механизмы ослабления связей. (Вообще все немного сложнее, если кому нибудь интересно послушать объяснение на пальцах — могу написать статью).
И есть наблюдение, что существует корреляция, между хорошим самочувствием, что человек узнал что то новое. Ну, узнал в широком смысле — фильм посмотрел, в отпуск в новый город съездил, книгу прочитал.
И вот мне стало интересно, если запись новой информации ощущается «хорошо», то не может ли «плохо» означать то, что мозг решил почистить неиспользуемое?)
Интересно, кто-нибудь пытался провести тесты, что у выгоревших и людей в депрессии (и после) с долговременной памятью, и не ощущают ли они себя после как «я как новенький и все вокруг такое классное», а то что было до депрессии как «это было очень давно, уже не вспомнить»? И если это внезапно так, то не потому ли от выгорания и депрессии страдают те, кто переваривает огромные потоки информации?
У меня есть подозрение, что большинство пользуется этой шкалой бинарно.
5 — нет замечаний, все ок, и приложение оказалось не закрытым когда я взял телефон в руки. Или водитель помог с сумкой. Или еще что-то такое.
1 — водитель сотворил жесть.
А все остальные варианты — просто никто не ставит. Ну вот кто будет пытаться понять, если водитель слушает музыку слишком громко — три ему ставить или четыре? Довез и довез.
Если нужны релевантные данные — стоит делать бинарные, ну максимум с тремя вариантами ответа вопросы. Но несколько.
Например:
В салоне хорошо пахло?
Водитель был вежлив?
И так далее.
А на шкалах 1-5 или 1-10 или 1-100 люди теряются. И бьют по краям.
Поддерживаю.
Долго убивался почему-же андроид такой. Потом понял, что задача решаемая разработчиками — сохранить приложение в том виде, в каком оно было даже после убиения от нехватки памяти.
И если попробовать написать это самому с нуля, то получатся activity и fragment. И в последних обновлениях с Jetpack их как раз довели до ума.
Ой, agile и шум вокруг него это вообще больное.
Я просто не понимаю, почему для идеи, «если что-то нельзя аппроксимировать линейно, давайте посчитаем линейными малые кусочки и получим почти ту кривую что нам нужна», сделали:
1) Манифест.
2) Пропаганду в формате «Это спасение вашего проекта».
3) Специальных тренеров.
И более того, приправили очень спорными, совершенно неоднозначно понимаемыми вещами формата:
«Best architectures, requirements, and designs emerge from self-organizing teams» — Где вообще существует self-organizing team в природе? Хоть один проект, у истоков которого не стоял 1 человек, который все организовал, а «самоорганизованная команда». Нет, конечно, если такую найти, она действительно будет поставлять нам все самое лучшее. Но я таких не встречал. Иначе зачем вообще нужны эти лычки, «сеньор», «лид», «архитектор», «директор компании», если все, волшебным образом «самоорганизоваться» должны?)
«Close, daily cooperation between business people and developers»
«Face-to-face conversation is the best form of communication (co-location)»
— кажется, все те ребята, которые строят замки ПО в своем мозгу уже высказались на тему того, когда их рушат через Face-to-face и митинги.
Эта статья в формате .zip:
Требования — меняются. Поэтому нельзя работать так, будто требования не меняются.
Давайте разрабатывать небольшими кусками, и считать, что на этих небольших кусках требования не меняются.
Короче, «продифференцируем» разработку ПО, и найдем минимальную часть требований, которую можно сделать waterfall'ом. Тогда, в случае если путь по которому мы должны идти — поменялся — мы поменяемся вместе с ним, и потеряем максимум этот небольшой кусочек, а не узнаем об этом закончив проект.
В базовый класс и к его наследникам. А дальше у тех могут быть другие базовые классы (здравствуй, множественное наследование).
Согласен. Привык думать о наследовании, как о направленной иерархии, без возможности «скрещивать» потомков. Если такая есть в конкретной имплементации — окей, не дерево.
Ну вот вы бы не стали, а я пользуюсь.
Не возникает проблемы, с тем, что не помните где уже были, на больших объемах данных?
Если быть совсем точным, я пользуюсь графом, потому что во-первых, я пользуюсь не только наследованием, а во-вторых, даже наследование (точнее, имплементация) — не обязательно дерево.
Я говорил про ваш конкретный пример, с переходом в базовый класс. В это примере, вроде как, не может быть циклов в иерархии, и поэтому там дерево.
В обобщенном случае поиска по каким-то узлам и связям (например по использованиям) циклы могут быть, и да, тогда это не дерево, а просто граф.
Но я бы не стал пользоваться для поиска графом с циклами. Я слишком глупый для этого. Оперативка слишком маленькая для всяких DFS в циклических структурах. Через 5 минут я уже забуду, что в этом классе я уже был. И если путь меня опять приведет к нему, я зайду туда, пойму что такое уже видел, что ищу не там, и меня это весьма разочарует.
То есть в подавляющем большинстве случаев.
Мы вроде как и начинали с того, что когда у вас есть возможность воспользоваться мапой — это хорошо. Когда нет — это плохо, вот тогда может пригодиться дерево.
На вскидку, пример из жизни — вам приходит новый человек и вам надо познакомить его с проектом:
Вот здесь у нас классы для extension функций и утилит, а вот тут транспорт лежит, а вот здесь — наши экраны приложения, а каждый экран — это…
Мне было бы странно показывать новому коллеге 1000+ файлов с кодом в одном каталоге. Возможно я недостаточно продвинутый, но если бы мне такое показали — я бы прифигел. Даже если бы мне обещали, что угадать, как называется нужный тебе файл, очень легко. Обычно это легко тому, кто этот проект писал, а не мне, который вообще не в курсе что тут происходит)
Ну вот есть конкретный опыт, состоящий в том, что при поиске в проекте, в котором есть инструментальная поддержка, я подавляющее большинство случаев ищу объекта по связям. Ну то есть, если мне надо найти контроллер, название которого я не знаю, я возьму базовый класс для всех контроллеров и посмотрю всех его наследников, а не буду перебирать все компоненты, в которых потенциально могут быть контроллеры, в поисках папочки controllers, в которой может быть есть нужный мне контроллер.
Так вы же и тут пользуетесь иерархической структурой. Просто другой. Не папочками, наследованием. И да, согласен, если у вас есть элемент в иерархии, в который вы можете перейти за O(1), и который при этом находится близко к искомому — это эффективно. Для того чтобы это описать, можно просто перейти из плоскости в объем, и описывать не только иерархическую структуру папочек, но и наследования. И разумеется есть некоторая вероятность за O(1) попасть в «ближайшего соседа». А потом можно добавить еще одну размерность — это будут использования. Я вот например частенько помню, что «кажется, я использовал нужную мне штуку воот в том классе» и затем ищу ее в нем.
И есть некий поддерживающий опыт, состоящий в том, что я (почти) перестал пользоваться папками в почте, предпочитая им поиск.
Пытаетесь вспомнить смысл того что было в письме и перебираете «ключи»? Это вы имели ввиду под «возможными ключами»?
Согласен — отличное решение, когда вы примерно можете предположить что ищете. Думал о том, что было бы круто, если в поиске IDE была галочка «синонимы», чтобы самому их в мозгу не перебирать.
Речь шла только о том, что когда попытка использовать мапу через названия провалена (т. е. когда вы не знаете как назвали то, что вы ищете), то бродить по дереву лучше чем по списку.
Я составил модель и математически доказал что любое семантическое дерево будет лучше списка при решении этой задачи, если оно удовлетворяет таким условиям:
У вас дофига файлов.
Вы назвали папки не абы как и человек может выбрать из них нужную.
У вас нет пустых папок или папок с 1 элементом.
lair, как я его понял, утверждает что я слишком упрощаю, и в реальном случае это не работает. При этом сам он тоже поддерживает идею раскладывания по папкам.
Но это моё понимание того, что он говорит, так что я могу ошибаться.
Мы выяснили, что нельзя полагать что люди никогда не ошибаются в выборе, и что открыть папку стоит больше времени, чем прочитать название. Я говорю, что на ассмиптотике это не скажется, но не против того, что на малых величинах это меняет картину.
Я предлагаю просто дополнить формулу этими двумя параметрами и оценить их в эксперименте. У него есть какие-то возражения, из его опыта, но пока я их не понял.
Понимаете, вы смотрите на это дерево с точки зрения абстрактной структуры данных. А я — с точки зрения разработчика или архитектора, которому описывать, как это дерево заполняется и как в нем искать.
Мне кажется, что одно другому не мешает. Или вы думаете, что я этим так интересуюсь в академических целях, а не потому, что меня чертовски волнует вопрос «когда создавать новый уровень иерархии»? Просто я знаю, что я, со своими наблюдениями — ошибаюсь. А вот за математикой я такого не замечал. Всегда работает. Так что проверить интуитивный вывод математической прикидкой мне кажется очень здравой идеей. Иногда можно получить даже больше чем планировал.
Затем, что:
(а) переделывать потом дороже
(б) такой стартовый шаблон
Но если генерализовать подход «переделывать дороже» — вы получите избыточную архитектуру. Согласитесь, такое случается. Вам, например не мозолит глаз MVC-шная иерархия, для задачи формата «посеттить константную строку в текстовое поле»? Когда создается 3 интерфейса и 3 имплементации, просто потому что такой шаблон, и «если нам когда-то потребуется расширить класс».
И знаете что интересно. В половине случаев ничего не расширяется. Но получив задачу «обновить строку», человек продирается сквозь чертову кучу шаблонного и абсолютно ненужного кода, потому что забыл как называлась константа в ресурсах, и теперь хочет узнать название.
Короче, мне кажется, что ленивая инициализация изменений будет выигрывать. Это интуитивное предположение, не претендую на истинность.
Вы известную фразу про «1+1» слышали?
Видимо, нет) Поделитесь.
Понимаете ли, мне интересно, и я в свое время нашел ответ: папку надо создавать в тот момент, когда вы можете объяснить стороннему разработчику, по какому критерию объект надо искать в этой папке (или, соответственно, в этой папке не искать). Ну то есть у него есть объект X, перед ним папка A, и я могу хоть как-то формализовать для него (разработчика) критерий, по которому он может себе сказать, надо ему эту папку открывать, или нет (естественно, вырожденные критерии мы не рассматриваем).
А теперь попробуйте это формализовать математически.
Вы составляете предикаты «принадлежности объекта узлу», и такой предикат должен существовать для каждой пары «лист»-«промежуточный узел»? И, учитывая что это должно работать всегда, и эффективно, то скорее всего, у вас есть сет качественных признаков объекта, а каждый промежуточный узел образуется понятием, которое включает в себя все, что свойственно элементам внутри него. Иными словами — любой промежуточный узел в вашей иерархии это некое обобщенное свойство всех листов ему принадлежащих.
В таком случае, на каждой развилке человек может сделать правильный выбор.
Ну так уже указывал же: стоимость выбора (операции сравнения) в каждом узле может отличаться, вероятность ошибки ненулевая — и тоже разная в каждом узле.
Ну, можно просто провести эксперимент, и понимая общую зависимость подобрать недостающие константы. Ну, знаете, так новые физические законы открывают и все такое.
Но не зная как выглядит зависимость — вообще фиг что подберешь)
Вот они, проблемы отсутствия профильного образования! Несколько месяцев строишь велосипед, потому что не смог придумать ключевое слово, чтобы его нагуглить.
О, кстати, а можете рассказать поподробнее? Я в курсе, что есть нейрогенез и образование новых связей, и понимаю, что они так-же могут «умирать». Но подробно этот вопрос не изучал, т.е. я не в курсе когда и как это происходит. Буду благодарен за статьи или какие-то другие источники информации.
Я еще напишу про регуляцию. Это будет отдельная статья. Выброс нейромедиаторов (и не только их) в «свободный доступ» важная штука, без которой не сложить картинку. И про понижение силы связей — тоже.
Суть статьи, а вернее серии — сделать обзор. Есть вот это, вот это, и еще это, если очень грубо приближать — оно работает вот так. Пока работает — будем пользоваться этим приближением. Перестанет работать — детализируем.
Для этой статьи и объяснения концепции «связной подсети» хватило только усиления связей и L-LTP. А вот для объяснения того, почему что-то вообще фиксируется L-LTP — уже не хватит. Или для объяснения того, как мозг «отстраивает» связи сам, решая какую-то задачу. Для этого понадобятся дополнительные сущности, и вот когда они будут нужны — я их и опишу)
Вываливать сразу тонну информации — не стоит. Это стандартная ошибка человека, который более-менее разобрался в вопросе и «уложил его в голове», при объяснении другим людям. Тебе все очевидно. Только ты потратил год, на то, чтобы это стало «очевидно», а теперь пытаешься пересказать все за полчаса)
Короче, первичная зрительная кора — один огромный FrameBuffer. Можно считать 1 объект. Его можно «разложить на примитивы». Сделать что-то вроде преобразования растр->вектор. Как вы понимаете, после этого можно работать с примитивами. Например, представлять линию под углом, простой трансформацией «линии». Тем же методом «наложить текстуру».
Сейчас попробую зайти через программирование. Короче, это как динамически создавать новые объекты из примитивов.
Представьте, хм… Слоно-зебру. Я серьезно, попробуйте.
Если я правильно понимаю процесс, у вас должно было получиться что-то содержащее самые яркие характеристики слона и зебры. Например, большой слон с хоботом, раскрашенный как зебра, или зебра с хоботом/ногами/туловищем слона, ну в общем — комбинация из «примитовов слона» и «примитивов зебры».
И когда вы представляете 4 стула, у вас происходит примерно то-же самое.
Есть 4. А 4 — это абстракция, означающая что у вас есть что-то одного «класса», но разных «инстансов». Представьте «4». Получилось 4 «чего-то». Шариков, коробочек, не важно.
А теперь на место «чего-то» — вы подставляете результат вычисления шаблона «стул». Стул, кстати, не обязан быть одинаковым, у вас есть куча информации о разных стульях.
Или наоборот, можно представить 1 стул, и начать его подгонять под шаблон «4», докидывая новые стулья.
Т.Е. мозг не «хранит 4 стула», пока вы о них не думаете. Но когда вы попробуете их представить, он начнет вычислять результат.
Очень грубая аналогия, но надеюсь, суть передал)
PS
Про внимание из комментария ниже — в первом приближении это просто фильтр, завязанный на текущий контекст (объясню позже, как это выглядит). Т.Е. пока вы «думаете о стульях», вы обрубаете левые сигналы, которые со стульями не связаны и не обрабатываете их.
Отличное замечание.
Дело в том, что зрительная кора разделена на области.
Есть первичная — туда поступают данные с глаз. Это то, что вы видите. Можно сказать, набор пикселей. Они для разных стульев будут разными.
А дальше идёт поступенчатая обработка изображения. Выделение контуров, обработка положения в пространстве, распознавание образов и прочие штуки высокого уровня, которые позволяют вам заметить, что вы видите 4 похожих объекта и отнести их в категорию стульев.
Врятли в первом этапе учавствует долговременная или кратковременная память, учитывая то, сколько информации проходит через первичную зрительную кору. Строй я мозг, я бы так делать не стал)
Насчёт представить — все немного сложнее. Если бы тут было простое "обратное преобразование" — можно было бы "увидеть стулья", как часть изображения с глаз. Этого не происходит, и тут есть два варианта:
Если перед вами пролетит кирпич — у вас по короткой дуге пройдет рефлекторный импульс на моторные реакции, и, как я понимаю, выброс различных вещей вроде адреналина не потребует «осознания» ситуации. Вот потом, когда кирпич уже давно пролетел, включится все остальное)
Но эмоции срабатывают не только в «стрессовых» ситуациях, как выше. Например, вы вполне можете испытать сильную эмоцию от того, что ошиблись. Скажем, купили что-то втридорога и узнали об этом постфактум. Или наоборот, вы долго над чем-то работали и добились результата — здесь идет удовлетворение, и оно тоже требует осознания, т.е. сначала мозг обработает это внутри, а потом врубит механизмы регуляции.
Про штуки второго рода, а так же «мотивацию», и то как все это коррелирует со связями между нейронами — я подготовлю отдельную статью. А еще там будет про зависимости)
Про нейропластичность — поясните пожалуйста. Не понимаю, как возможность выращивать новые связи и нейроны… Эм, летит в мой огород?
В начале статьи — дисклеймер, что это обзорная статья. В конце статьи — уточнение, что все в нее не влезло, потому что иначе она будет на 100к символов. Именно поэтому здесь нет например LTD, утечки заряда с нейронов и т.д.
Объяснение получится большое, пришлось разбить.
Куда завести трактор.
Куда поехать поработать.
Что интересного есть в устройстве города/древних развалин/пирамид/…
Управление компанией, в т.ч. не IT.
Психология и психиатрия.
И огромное количество других «не технических» тем.
Даже хабы специальные есть: Урбанизм, Управление компанией, Мозг и т.д.
Я даже не знаю, как вы это пропустить ухитрились)
Я тут качал нейробиологию, и есть такая забавная штука, что связи в мозге могут ослабевать.
Ну, т.е. помимо того, что между нейронами можно усилить связь, таким образом «записав данные», есть и обратные механизмы ослабления связей. (Вообще все немного сложнее, если кому нибудь интересно послушать объяснение на пальцах — могу написать статью).
И есть наблюдение, что существует корреляция, между хорошим самочувствием, что человек узнал что то новое. Ну, узнал в широком смысле — фильм посмотрел, в отпуск в новый город съездил, книгу прочитал.
И вот мне стало интересно, если запись новой информации ощущается «хорошо», то не может ли «плохо» означать то, что мозг решил почистить неиспользуемое?)
Интересно, кто-нибудь пытался провести тесты, что у выгоревших и людей в депрессии (и после) с долговременной памятью, и не ощущают ли они себя после как «я как новенький и все вокруг такое классное», а то что было до депрессии как «это было очень давно, уже не вспомнить»? И если это внезапно так, то не потому ли от выгорания и депрессии страдают те, кто переваривает огромные потоки информации?
5 — нет замечаний, все ок, и приложение оказалось не закрытым когда я взял телефон в руки. Или водитель помог с сумкой. Или еще что-то такое.
1 — водитель сотворил жесть.
А все остальные варианты — просто никто не ставит. Ну вот кто будет пытаться понять, если водитель слушает музыку слишком громко — три ему ставить или четыре? Довез и довез.
Если нужны релевантные данные — стоит делать бинарные, ну максимум с тремя вариантами ответа вопросы. Но несколько.
Например:
В салоне хорошо пахло?
Водитель был вежлив?
И так далее.
А на шкалах 1-5 или 1-10 или 1-100 люди теряются. И бьют по краям.
Долго убивался почему-же андроид такой. Потом понял, что задача решаемая разработчиками — сохранить приложение в том виде, в каком оно было даже после убиения от нехватки памяти.
И если попробовать написать это самому с нуля, то получатся activity и fragment. И в последних обновлениях с Jetpack их как раз довели до ума.
С последнего апдейта uptime 52 дня. Работает как часы.
Raspberry pi 3b. Raspbian.
Версия hass — 0.103.5.
Я просто не понимаю, почему для идеи, «если что-то нельзя аппроксимировать линейно, давайте посчитаем линейными малые кусочки и получим почти ту кривую что нам нужна», сделали:
1) Манифест.
2) Пропаганду в формате «Это спасение вашего проекта».
3) Специальных тренеров.
И более того, приправили очень спорными, совершенно неоднозначно понимаемыми вещами формата:
«Face-to-face conversation is the best form of communication (co-location)»
— кажется, все те ребята, которые строят замки ПО в своем мозгу уже высказались на тему того, когда их рушат через Face-to-face и митинги.
Требования — меняются. Поэтому нельзя работать так, будто требования не меняются.
Давайте разрабатывать небольшими кусками, и считать, что на этих небольших кусках требования не меняются.
Короче, «продифференцируем» разработку ПО, и найдем минимальную часть требований, которую можно сделать waterfall'ом. Тогда, в случае если путь по которому мы должны идти — поменялся — мы поменяемся вместе с ним, и потеряем максимум этот небольшой кусочек, а не узнаем об этом закончив проект.
Согласен. Привык думать о наследовании, как о направленной иерархии, без возможности «скрещивать» потомков. Если такая есть в конкретной имплементации — окей, не дерево.
Не возникает проблемы, с тем, что не помните где уже были, на больших объемах данных?
Я говорил про ваш конкретный пример, с переходом в базовый класс. В это примере, вроде как, не может быть циклов в иерархии, и поэтому там дерево.
В обобщенном случае поиска по каким-то узлам и связям (например по использованиям) циклы могут быть, и да, тогда это не дерево, а просто граф.
Но я бы не стал пользоваться для поиска графом с циклами. Я слишком глупый для этого. Оперативка слишком маленькая для всяких DFS в циклических структурах. Через 5 минут я уже забуду, что в этом классе я уже был. И если путь меня опять приведет к нему, я зайду туда, пойму что такое уже видел, что ищу не там, и меня это весьма разочарует.
Мы вроде как и начинали с того, что когда у вас есть возможность воспользоваться мапой — это хорошо. Когда нет — это плохо, вот тогда может пригодиться дерево.
На вскидку, пример из жизни — вам приходит новый человек и вам надо познакомить его с проектом:
Вот здесь у нас классы для extension функций и утилит, а вот тут транспорт лежит, а вот здесь — наши экраны приложения, а каждый экран — это…
Мне было бы странно показывать новому коллеге 1000+ файлов с кодом в одном каталоге. Возможно я недостаточно продвинутый, но если бы мне такое показали — я бы прифигел. Даже если бы мне обещали, что угадать, как называется нужный тебе файл, очень легко. Обычно это легко тому, кто этот проект писал, а не мне, который вообще не в курсе что тут происходит)
Так вы же и тут пользуетесь иерархической структурой. Просто другой. Не папочками, наследованием. И да, согласен, если у вас есть элемент в иерархии, в который вы можете перейти за O(1), и который при этом находится близко к искомому — это эффективно. Для того чтобы это описать, можно просто перейти из плоскости в объем, и описывать не только иерархическую структуру папочек, но и наследования. И разумеется есть некоторая вероятность за O(1) попасть в «ближайшего соседа». А потом можно добавить еще одну размерность — это будут использования. Я вот например частенько помню, что «кажется, я использовал нужную мне штуку воот в том классе» и затем ищу ее в нем.
Пытаетесь вспомнить смысл того что было в письме и перебираете «ключи»? Это вы имели ввиду под «возможными ключами»?
Согласен — отличное решение, когда вы примерно можете предположить что ищете. Думал о том, что было бы круто, если в поиске IDE была галочка «синонимы», чтобы самому их в мозгу не перебирать.
Суть, кратко:
Речь шла только о том, что когда попытка использовать мапу через названия провалена (т. е. когда вы не знаете как назвали то, что вы ищете), то бродить по дереву лучше чем по списку.
Я составил модель и математически доказал что любое семантическое дерево будет лучше списка при решении этой задачи, если оно удовлетворяет таким условиям:
У вас дофига файлов.
Вы назвали папки не абы как и человек может выбрать из них нужную.
У вас нет пустых папок или папок с 1 элементом.
lair, как я его понял, утверждает что я слишком упрощаю, и в реальном случае это не работает. При этом сам он тоже поддерживает идею раскладывания по папкам.
Но это моё понимание того, что он говорит, так что я могу ошибаться.
Мы выяснили, что нельзя полагать что люди никогда не ошибаются в выборе, и что открыть папку стоит больше времени, чем прочитать название. Я говорю, что на ассмиптотике это не скажется, но не против того, что на малых величинах это меняет картину.
Я предлагаю просто дополнить формулу этими двумя параметрами и оценить их в эксперименте. У него есть какие-то возражения, из его опыта, но пока я их не понял.
Мне кажется, что одно другому не мешает. Или вы думаете, что я этим так интересуюсь в академических целях, а не потому, что меня чертовски волнует вопрос «когда создавать новый уровень иерархии»? Просто я знаю, что я, со своими наблюдениями — ошибаюсь. А вот за математикой я такого не замечал. Всегда работает. Так что проверить интуитивный вывод математической прикидкой мне кажется очень здравой идеей. Иногда можно получить даже больше чем планировал.
Но если генерализовать подход «переделывать дороже» — вы получите избыточную архитектуру. Согласитесь, такое случается. Вам, например не мозолит глаз MVC-шная иерархия, для задачи формата «посеттить константную строку в текстовое поле»? Когда создается 3 интерфейса и 3 имплементации, просто потому что такой шаблон, и «если нам когда-то потребуется расширить класс».
И знаете что интересно. В половине случаев ничего не расширяется. Но получив задачу «обновить строку», человек продирается сквозь чертову кучу шаблонного и абсолютно ненужного кода, потому что забыл как называлась константа в ресурсах, и теперь хочет узнать название.
Короче, мне кажется, что ленивая инициализация изменений будет выигрывать. Это интуитивное предположение, не претендую на истинность.
Видимо, нет) Поделитесь.
Вы составляете предикаты «принадлежности объекта узлу», и такой предикат должен существовать для каждой пары «лист»-«промежуточный узел»? И, учитывая что это должно работать всегда, и эффективно, то скорее всего, у вас есть сет качественных признаков объекта, а каждый промежуточный узел образуется понятием, которое включает в себя все, что свойственно элементам внутри него. Иными словами — любой промежуточный узел в вашей иерархии это некое обобщенное свойство всех листов ему принадлежащих.
В таком случае, на каждой развилке человек может сделать правильный выбор.
Ну, можно просто провести эксперимент, и понимая общую зависимость подобрать недостающие константы. Ну, знаете, так новые физические законы открывают и все такое.
Но не зная как выглядит зависимость — вообще фиг что подберешь)