А откуда вы взяли определение «дерева», которое используется в реальной задаче распределения объектов во время разработки ПО, а не как структура данных?
Эм. Дерево — это связный граф, без циклов. Вы предложили набор отдельных списков. Он не связный. Это лес.
И, да, дерево, с одним элементом у каждого родителя — это… список. Список, конечно технически является деревом. Но, мне кажется, что исходя из контекста диалога, можно было понять, что я не предлагаю строить дерево так, чтобы в глубину получать списки. В этом суть дерева, как структуры данных — не быть списком.
Да нет, не абсурдно. Поймите, это дерево состоит из синтаксических элементов. Возьмем какой-нибудь дурацкий MVC. Верхний уровень: ui. Под ним три элемента: models, views, controllers. Добавляем первую триаду: в каждом элементе появилось по одной имплементации. Абсурдная ситуация?
Ну, как сказать. Если у вас 1 модель, 1 view и 1 контроллер — да. Зачем создавать папки для одного элемента? Даже судя по моему графику, без штрафа на переход, это имеет смысл только ближе к 8 элементам.
Вы, конечно, доказали математически всю асимптотику. Проблема в том, как доказать, что ваша математическая модель, в рамках которой вы что-то доказали, совпадает с реальной задачей.
В том-то и дело, что я знаю, что разбиение на папки работает. Но оно работает по совокупности моего опыта, а ни одна математическая модель, включая вашу, так и не учитывает всех нюансов этого опыта. И, что хуже, ни одна математическая модель не может сказать, как надо разбивать на папки в конкретном случае.
Вы кажется не понимаете зачем математика нужна. Если я определил как действует сложение — мне не нужно проверять, что оно работает на слонах, черепахах, яблоках, карандашах и так далее. Я вывел правило по которому работает реальность.
Разумеется, при выводе я идеализировал некоторые вещи. Например, предположил, что люди не ошибаются в выборе папки. Или что открыть папку ничего не стоит. Вы можете указать мне на них, я могу уточнить свою модель.
Добавить в нее поправку на открытие папки, добавить шанс ошибки. И я откажусь от своего утверждения про то, что она лучше списка, если мы найдем реальное ограничение, которое может изменить ассимптотику хотя-бы на множитель.
Но пока мы его не нашли — моя гипотеза, судя по всему, неплоха. Найдем — выкинем и запилим новую. Ньютоновская механика тоже не учитывала релятивистские эффекты. И ничего, до сих пор пользуемся.
Если что-то не соответсвует опыту — так давайте поработаем, и уточним мою модель. Вам самому не интересно узнать, в какой момент нужно создавать папку? Мне вот очень интересно, поэтому я тут и сижу.
Повторимый эксперимент, соотносимый с реальным опытом разработчика.
Конкретнее, пожалуйста. Если вы не придумали этот эксперимент — у вас пока нет критерия фальсификации. А пока вы мне не описали эксперимент — я не могу сказать, действительно ли он хорош)
Поржал.
Нет, серьезно?) Вам настолько не терпится доказать мне что-то, что вы, кхм решили подогнать под определение «дерева» заранее абсурдную структуру? Вы предлагаете как контрпример создавать папки с 1 ребенком?) Нет, я думал написать, то в папке должно быть минимум 2 элемента, но решил что это излишне, ибо ни один дурак не будет так делать. Это, кхм, абсурдно, даже исходя из интуиции. Вашим образом можно доказать что поиск одного элемента в случае папок стремится к бесконечности) Кстати, моя формула это тоже учитывет, ибо предел логарифма по основанию k где k стремится к 1 — стремится к бесконечности. Можете снять ограничения с графиков, что я вам скинул, да посмотреть — там есть поведение в таком случае))
Да, если создавать папки с одним элементом, или, кхм, пустые папки рядом (на случай если вам и это нужно указать отдельно) — искать в такой структуре будет дольше чем в списке) Какой вы молодец, что догадались.
Итак, скажу прямо — у папки обязательно должно быть минимум 2 ребенка.
Нет, вам серьезно не понятно, что если список — это вырожденное дерево, то поиск в любой структуре, кхм, промежуточной, между деревом и списком, ассимптотически по сложности тоже будет лежать между поиском в дереве и поиском в списке?) Даже, если строить дерево «над» списком.
Знаете, учитывая ваш последний аргумент, у меня уже складываается впечатление, что ваша цель — доказать мне, что я не прав, любыми абсурдными методами, даже после того, как я математически показал всю ассимптотику.
Притом вы даже не стараетесь. Вы могли сказать «Эй, парень, но для перехода по папкам требуется намного больше времени, это же кликнуть на папку и ждать пока она откроется. А поскольку файлов у нас не бесконечность, надо смотреть как ведет себя функция в таких условиях на сравнительно небольших числах» — и я бы добавил множитель, и мы бы посмотрели как ведет себя функция (спойлер — с таким условием, при маленьком количестве файлов разбивать их на папки действительно нельзя).
Мне нравится с вами дискутировать. Несмотря на то, что иногда у вас иногда не очень с аргументами — в целом, вы неплохой собеседник. У вас хотя-бы есть достаточно терпения.
Но если вы заранее для себя определили, что «разбиение на папки — не работает», какой смысл убеждать вас в обратном? Если вы не будете пытаться вместе со мной ответить на вопрос «а работает ли?», чем я собственно тут и занимаюсь, а уже заранее записали для себя «верный» ответ, и теперь на каждое свидетельство против вашего убеждения ищете отмазку? Каков критерий для фальсификации вашей гипотезы?
Хм, в статье сказано, что срисовывали саму девушку, заказавшую рисунок себя в таком антураже. А значит, тут есть еще и такая статья:
Статья 152.1. Охрана изображения гражданина
1. Обнародование и дальнейшее использование изображения гражданина (в том числе его фотографии, а также видеозаписи или произведения изобразительного искусства, в которых он изображен) допускаются только с согласия этого гражданина. После смерти гражданина его изображение может использоваться только с согласия детей и пережившего супруга, а при их отсутствии — с согласия родителей. Такое согласие не требуется в случаях, когда:
1) использование изображения осуществляется в государственных, общественных или иных публичных интересах;
2) изображение гражданина получено при съемке, которая проводится в местах, открытых для свободного посещения, или на публичных мероприятиях (собраниях, съездах, конференциях, концертах, представлениях, спортивных соревнованиях и подобных мероприятиях), за исключением случаев, когда такое изображение является основным объектом использования;
3) гражданин позировал за плату.
2. Изготовленные в целях введения в гражданский оборот, а также находящиеся в обороте экземпляры материальных носителей, содержащих изображение гражданина, полученное или используемое с нарушением пункта 1 настоящей статьи, подлежат на основании судебного решения изъятию из оборота и уничтожению без какой бы то ни было компенсации.
3. Если изображение гражданина, полученное или используемое с нарушением пункта 1 настоящей статьи, распространено в сети «Интернет», гражданин вправе требовать удаления этого изображения, а также пресечения или запрещения дальнейшего его распространения.
Получается вообще интересная штука. Если мы портрет человека считаем воспроизведением музейного экспоната, то как быть с правом человека на свой собственный портрет?)
PS
Мне всегда было интересно, как пишутся законы, если для них можно элементарным образом составить нерешаемую в рамках их описания проблему?)
Мне кажется, дело было так: Кто-то из девелоперов решил проверить как работает пушсервис, и либо перепутал инстанс, либо случайно пометил пуш как broadcast.
Сам так случайно однажды отправил «test» паре тысяч человек. Три раза. Кто — же знал, что инстанс помеченный «QA» в старой версии приложения использовался как основной)
Красный график — линейная сложность. В среднем поиск в списке займет x/2 итераций.
Фиолетовый график — Охренительно плохой случай, когда мы можем создать всего n папок и распихать элементы по ним примерно одинаково. Т.Е. у нас есть линейная зависимость количества детей узла, от количества элементов. Спойлер — даже в таком варианте оно уделает линейный случай, начиная с n = 2.
Черный график — случай, когда мы можем нормально составить иерархию, как я описывал, т.е. у каждого узла ровно n детей.
А теперь немного математической магии: Все ваши описания неидеальности моего метода находятся в промежутке от моего худшего случая, до лучшего. Вообще все. Что бы вы не придумали, какую бы схему дерева не предложили — ее график зажат между графиками худшего и лучшего случая. Даже если вы захотите «добавить штраф» к выбору папки, он не изменит ассимптотику.
И мой худший случай — это когда ни для каких элементов нельзя выделить признак, по которому их можно сгруппировать. И тогда у нас все в одной папке — т.е. сложность ассимптотически x/2.
Даже если вы в этой папке, создадите подпапку и положите в нее всего 2 элемента — вы не измените сложность. Вы добавили 1 переход в глубину. Добавили один выбор элемента из двух. т.е. два шага. Вы уменьшили основной список на 2 элемента. Теперь вам нужно пройти 1 список из n-2 элементов, и если в нем не найдется нужный элемент (что произойдет с вероятностью 2/общее количество элементов) — вам придется сделать еще 2 шага. Средняя сложность (матожидание сложности, ведь матожидание это тоже самое что среднее для бесконечной выборки) — n-1/2 + 2*2/n. Кажется, последним членом можно принебречь, он стремится к нулю на бесконечности. Если вы создадите еще одну такую папку — у вас появится лес из 2 папок по два элемента, в который вы придете с вероятностью 4/n. И в этом лесу вы потратите 1 + 1 шаг. И опять за счет малой вероятности того, что ваш элемент находится в этом дереве — его вклад в среднее — стремится к нулю. Если вы сделаете так еще раз — получите вероятность 6/n в лесу из трех мини деревьев. Количество шагов в нем — 1.5+1. Я прикинул формулу для расчета среднего количества шагов в таком случае — она зеленая в ссылке выше. Параметры k и p — это количество папок и количество элементов в папке. Разумеется, смотреть нужно с момента когда x>k*p, до этого там будет какой-то бред ибо мы пытаемся создать папки для несуществующих элементов. И ассимптотика в этом случае все еще линейная.
Итого — вы не сможете придумать разбиение, когда способ с папками работает хуже чем линейно, отличаясь не константой, а хотя-бы множителем. И это наши худшие случаи. В других случаях кроме этого он работает за меньшее время, чем время поиска по обычному спику. В любых.
Так что там не будет работать в реальности?) Если вы сейчас в этой самой реальности, не сможете придумать контрпример, в котором разбиение на папки будет отличаться в худшую сторону хотя-бы множителем?)
Нет, не всегда будет так. Число элементов на уровне дерева определяется не математическими ограничениями, а семантикой
Так, я кажется понял в чем проблема: Я говорю, если строить дерево вот с такими ограничениями, то поиск ассимптотически стремится к логарифму.
Вы говорите о том, что если строить дерево по другому, то не будет? — Согласен, если строить дерево по другому — то может и не будет.
Если в бинарное дерево поиска пихать элементы строго в порядке их убывания/возрастания и не балансировать — то там тоже не получится логарифм для поиска, оно в список выродится. Его можно «строить не правильно». Однако, если принять, что мы не строим дерево «специально не правильно», а раскидываем элементы случайно, в среднем у нас получается logN.
… но количество операций на уровне зависит от числа элементов на уровне, а не от глубины дерева. Поэтому общее число операций изменилось.
Да, и я дал вам формулу, от числа детей узла — p и количества листьев — n.
… где n — не число элементов в изначальном множестве, а число элементов плюс число промежуточных узлов.
Впрочем, интереснее то, какой случай средний
.
Ага, только число промежуточных узлов, для случая когда у нас поиск идет линейно — равно 1. Все лежит в одном домене. И я даже добавил эту единицу в формулу)
Средний случай, как и в случае бинарного дерева определяется тем, что при бесконечном числе вставок дерево будет заполняться равномерно.
Неа, нельзя — по крайней мере, пока не показано явно, что вес этих операций пренебрежим по сравнению с остальными.
При оценке ассимптотики на бесконечности — можно забивать на множители. Вот если количество элементов в одном домене — функция от количества листьев — тогда да, нельзя.
О малых n я отдельно упомянул, и сказал, что в этом случае на множитель забить нельзя. Как и в случае, когда на малых n квадратичные сортировки уделывают quick.
Вы же понимаете, что это не то же самое n, которое число элементов, среди которых мы ищем?
На примере: вот у вас есть восемь элементов (например, для простоты, классов). Если они все принадлежат к одной группе (например, домену), то у вас добавляется всего один узел — domain, и n=9. Но если у вас домен побит (внутри себя) на два поддомена (sales и purchases), то у вас n=11. А если из этих классов половина относится к UI (по тем же поддоменам), то вы получаете n=14. Но при этом количество элементов кода, среди которых идет поиск, все равно 8!
Блин, вот это я налажал. Да, вы правы, нельзя брать количество узлов, надо считать от листьев.
Интересно, сильно ли это меняет ситуацию? Вот ваше количество элементов — 8.
Вот мы разбили их на два поддомена — каждый по 4. И еще разок — теперь у нас 2+4+8 элементов в дереве. А шагов по уровням сколько, для навигации до нужного элемента?
1+1+1 = 3. Если я не ошибаюсь, это логарифм от 8 по двум?)
И, кажется это всегда будет так, учитывая что на следующем уровне дерева можно расположить в p раз больше элементов, чем на предыдущем. Т.Е. картину не особо меняет. Кажется, константу добавит, плюс один шаг нужен вглубь нужен.
Окей, формула: p/2*(logp(n)+1).
Ну, да, кстати, логично. Чтобы перейти в 1 файл в 1 папке нужно 2 шага — открыть папку, открыть файл.
Аналогичное рассуждение применимо и к высоте дерева — она определяется не числом элементов, а исключительно принятой конвенцией. Если мы добавим еще два поддомена, эффективно увеличив число элементов вдвое, глубина дерева не изменится.
В этом и фича. Вы добавили еще элементов — глубина не изменилась, количество шагов все еще зависит от глубины дерева. Вы добавили еще элементов, и они перестали влезать на последний уровень дерева?
Добавьте пару элементов в иерархию увеличив глубину — теперь влезут, а количество шагов по уровням увеличится всего на 1.
А все потому, что семантическая иерархия (а в другой ваш поиск работать не будет) — это не поисковое дерево, к нему не применима привычная асимптотика.
Да, я согласен, что у меня не дерево поиска. Поэтому я и не стал говорить, что это «логарифм по 2, потому что это дерево поиска», а занялся прикидками.
Еще вас, как мы только что выяснили, интересует структура дерева.
Бинарное дерево тоже умеет вырождаться в список. И быть несбалансированным. Именно поэтому есть средний и худший случай. У меня тоже есть худший, и он тоже, как ни странно O(n)
В том-то и дело, что мы, на самом деле, не знаем, какой алгоритм поиска.
Например, вы исходите из предположения, что время поиска на каждом уровне имеет одну и ту же константу при линейной асимптотике (и это та же константа, что и происке нужного объекта перебором). Но это не так — вы на каждом уровне сравниваете разные характеристики объекта (в примере выше на первом уровне вам надо понять, ui это или domain, на втором — sales или purchases), и принятие этого решения не сводится к константе
На достаточно большом дереве на это можно забить. На маленьком — да, имеет вес. Но врятли это что-то большее чем константный множитель на шаге выбора из детей узла.
У обычных алгоритмов есть похожие «девиации» поведения, когда сортировка вставками уделывает quickSort на мелких данных за счет констант. А еще архитектура проца роль играет в том, какие операции исполняются эффективнее. И ничего, живем как-то, и почему-то все еще учитываем при написании кода вычислительные сложности, не смотря на, простите за каламбур, сложности)
Вот только не по всему множеству, а по возможным ключам. А потом по использованиям возможных ключей. И с неточными совпадениями.
И из какой шляпы вы сейчас достали возможные ключи?)
Ну то есть незаметно добавить еще допущений. Не описав их, конечно же.
Расскажите хотя бы откуда вы логарифм взяли.
Так, может я реально ошибся с логарифмом. Ща прикину. Ну, окей, на каждой папке, которая является узлом дерева у нас есть список следующих узлов. Обозначим количество узлов за n, среднее число узлов в списке за p. Глубина дерева получится порядка logp(n), заходим в первый узел- среднее время выбора следующего — p/2, идем в следующий узел, повторяем logp(n) раз, потому что это глубина дерева. Итого — в среднем p/2*logp(n), где p среднее количество узлов в списке связей каждого узла, а n — количество узлов. Если P не является функцией от N, то на больших N можно им вообще принебрегать, логарифмическая ассимптотика не поменяется. Если является — окей, не логарифм, а f(n)*logf(n)(n), где f(n)<n (потому что если равно, то это все равно что все пихать в один узел).
Проблема с этими экспериментами состоит в том, что они далеки от реальности.
В частности, вы предполагаете, что в папках ошибок нет… а почему?
И это отличная идея, для еще одного эксперимента!
… и сколько из этих параметров вам известно?
Ну, меня интересует с какой вероятностью допускаются ошибки при наименовании, для того, чтобы посмотреть какой вклад они вносят в матожидание. Кажется, на этом все.
Или вы опять пытаетесь утверждать, что нельзя посчитать сложность поиска в абстрактной структуре данных, не зная конкретный искомый элемент?) Да — нельзя. Дать оценку в зависимости от количество элементов структуры и того, как выглядит на ней алгоритм поиска — можно.
Мда. Для начала я не понимаю о каких величинах вы говорите. Или не величинах.
Во вторых — если для каких-то объектов можно определить отношение НЕравенства и сложение — тадам, это уже величина.
В третьих, матстат работает с такими штуками как качественные признаки. Признаюсь, ошибся словом, сейчас посмотрел. Количественная величина, качественный признак.
Значит, ваш подход не применим к задаче «что такое хорошо структурированный код», или к задаче «какой код легко модифицировать» — потому что нельзя сводить «легко модифицируемый код» к «коду, в котором легко искать».
Конечно нельзя. Я описал лишь одну из подзадач модификации. Самую простую и очевидную. И раз 5 написал, что не претендую на то, что в комментарии могу так взять и описать математически весь процесс работы с кодом.
То, что одна из подзадач может быть описана математически — свидетельство в пользу того, что задача целиком тоже может быть так описана. Не доказательство. Свидетельство. Вы понимаете концепцию оценки вероятности гипотезы исходя из свидетельств?
Ээээ… я не понимаю, что такое «ненулевая вероятность того, что файл можно найти за логарифм». Временные сложности так не работают.
(и откуда вообще взялся логарифм?)
Временные сложности не работают в случаях, когда у нас есть вероятность ошибки в алгоритме. А в реальности, особенно когда алгоритмы выполняют люди — ошибки есть. Поэтому если мы моделируем процесс с ошибками, то придется подрубить матстат к обычной теории вычислительной сложности.
… в моем случае вообще нет файлов. Это если быть точным.
Я не понимаю, почему «мой» поиск гарантированно вырождается в линейный, а ваш — нет.
Так вы опишите формально «ваш поиск» и «ваше условие». Свяжите его с математикой.
Ваше определение:
Нет. Это код, в котором элемент назван так, чтобы из требований можно было предположить, как этот элемент называется. Дальше работает инструмент поиска, которому плевать на раскладку по файликам и папочкам.
Что вы понимаете под «предположить», под «элементом кода», под «инструментом поиска», как вы получили отсутствие коллизий «предположений»?
Я из этого совсем не четко сформулированного определения предположил, что вы решили сделать Map. Потому что по вашему описанию, у вас есть функция предположения, которая из какого-то элемента требований получает название элемента кода.
Т.Е. ваш «элемент требований» является ключем, «название элемента кода» — значением, и ключ отображается в значение за счет функции «предположить»
Я говорю о том, что если вы укажете неверный ключ — плохо будет. Придется искать перебором. А люди по моим наблюдениям часто указывают неверный ключ.
То есть вы можете посчитать (и доказать) временную сложность поиска файла, соответствующего объекту из требований?
Я могу составить модель процесса поиска файла, и да, посчитать и доказать ее сложность от различных начальных параметров.
Чтобы показать что она работает в реальности — придется проводить эксперимент. Знаете, ну, как все нормальные ученые делают.
Сформулировать гипотезу, вывести следствия, верифицировать, указать условия, при котором мы считаем гипотезу разрушенной, сделать эксперимент на это, и таким образом показать фальсифицируемость.
Например, если мы поставим эксперимент формата: мы даем одной группе людей код, где есть определенный нами мэппинг из требований, а другой группе — тот же код, но все термины из требований заменяем на рандомные строки той же длины. Если люди в обоих группах будут искать какие-то элементы одинаковое время — откажусь от теории что нужен мэппинг.
Второй эксперимент — возьмем обфусцированный код из первого эксперимента, но теперь вернем нормальные названия для папок. Опять сравним время на поиск.
Если люди без папок не будут сильно проигрывать — признаю что не прав.
Тем, что мы — вроде бы — говорим не о предпочтениях, а об измеримом экономическом эффекте.
Процитирую вас же:
Отдельный смешной вопрос состоит в том, можно ли вообще говорить о «корреляции» между понятиями, которые вообще-то не являются случайными величинами (и вообще не являются величинами).
Так что об экономическом эффекте я в этой ветке не говорю, вы же сами обозначили эту ветку как «отдельную».
Я обсуждаю матстат, корреляцию и математические подходы для определения всякой нечеткой фигни, вроде «нравится», «качественно», «полезно», чтобы в дальнейшем с нею работать математическими же методами.
А измеримый экономический эффект — вроде как вполне измерим и является величиной даже по вашим критериям, зачем тащить его сюда? Для этого обсуждения есть основная ветвь.
Желтое, синие и абрикосовое — тоже величины, только они называются атрибутивными!)
Ладно, шучу.
А почему вы уверены, что нельзя построить множество? Знаете, есть такая штука, теория потребления. И в ней есть «отношение предпочтения». Строится только на том, что человек может сравнить вещи. Не численно выразить разницу — просто сравнить.
Абстрактный потребитель, абстрактные вещи.
Еще там же, есть определение функции полезности. Тоже для абстрактного потребителя, на абстрактных товарах, и т.д.
А теория игр оперирует с абстрактными выигрышами. Они тоже заданы через оценку самим участником игры, вроде как. Если я правильно помню, то например в «Теории игр и экономическом поведении» Фон-неймана и Моргенштерна, оно введено как раз через отношение предпочтения и полезность.
Чем же так сильно отличается ситуация с предпочтениями когда дело касается ПО?)
Я пытаюсь вам сказать, что ваше утверждение «Есть корреляция. Ее давно заметили писатели и дизайнеры.» (а) неверно и (б) даже если бы было верно, неприменимо к комментарию, на который вы отвечаете.
Мы все это время говорим о том, что не одинаково понимаем слово корреляция?)
Да, можно. В матстатистике есть возможность оперировать с качественными а не количественными величинами. Вроде цвета глаз — его числом не выразишь, да и не зачем. Просто об этом не написано на первой строке в Википедии)
Что значит по вашему «не является величиной»? Все что можно ощутить является как минимум альтернативной величиной — ощущение есть или его нет)
Почему код, который получается благодаря вашему подходу выше, хорошо структурированный?
Я перечитал свои сообщения. Я понимаю их нормально и не вижу там подмены понятий. Как не вижу и того, что утверждаю, что так можно получить «хорошо структурированный код». Только если вырвать эти слова из середины одной из фраз.
Я весьма точно определил область в которой я применил этот термин в тот момент. Там есть конкретная задача, и конкретное определение хорошей структуры в контексте этой задачи.
Как это доказать?
Легко. Предположим мы совершили ошибку и обозвали файл не так. В моем случае существует ненулевая вероятность того, что файл можно найти за логарифм. В вашем случае — она стремится к нулю, т.е. поиск гарантированно вырождается в линейный.
Я говорю, что он достаточен для решения проблемы поиска. Это не «тоже», это другое.
И я с вами полностью согласен, если есть идеальный мэппинг — древовидная структура организации не нужна. Если он не идеален, то весь вопрос в том, насколько.
Объективная величина для сравнения появится тогда, когда у вас будет не абстрактный алгоритм, для которого можно посчитать, а конкретный алгоритм, применимый к данному случаю, и его входные данные. А в случае с «поиском объекта для модификации» у вас нет ни того, ни другого.
Вы не правы. Конкретным должен быть только алгоритм.
Входные данные — могут быть абстрактны. Вы же можете сказать, сколько конкретный бинарный поиск, занимает шагов на абстрактном сортированом массиве длины N, ища абстрактное значение. Разумеется не численно, но ассимптотику оценки дать можете.
Временной сложности чего? Поиска? А почему не минимизации временной сложности написания кода? А если двукратное уменьшение временной сложности поиска возможно только двадцатикратным увеличением временной сложности написания — тоже будем поиск оптимизировать?
Нет, просто для «написания» я не могу сходу придумать алгоритм. Повторю свой предыдущий пост, где уже говорил, что не претендую на носителя сокровенного знания «как сделать код проще»:
Не утверждал, что знаю точно «как» это сделать, но предложил один из подходов, который мне показался перспективным.
В том-то и дело, что каким-то. На деле вы никогда не будете знать, обожжетесь ли вы, пихнув руку в новый чайник, и какая тогда польза от этого знания?
Как минимум вы не будете пихать руки в ваш собственный чайник, после того как он провел достаточно времени на плите. А еще вы можете заинтересоваться результатами и в процессе долгого и упроного труда, описывая кучу наблюдаемого вами вывести термодинамику и обобщить на все чайники в мире.
У меня сложилось ощущение, что вы пытаетесь мне сказать, что у меня нет знания про все чайники, а я говорю о том, что чайники познаваемы)
И вы вроде даже согласились с познаваемостью чайника, что и являлось целью моего первого комментария.
Я лишь сказал, что корреляция есть, судя по тому, что ее можно почувствовать. Значит в поиске объяснения этой корреляции есть смысл.
А формулу — да, согласен довести до конечной формулы было бы неплохо.
Но надо довести.
Физика начиналась не с формул. Физика начиналась с того, что люди замечали какую-то зависимость. У Архимеда не было формулы, он предметы в воду пихал и заметил интересную штуку — они по разному вытесняют воду. Это он позднее сформулировал в закон, который лишь через много лет обрел привычный нам вид формулы.
Математика начиналась не с формул. Она началась с того, что какой-то гений дошел до того, что камушки и яблоки можно связать через свои действия, и их у них появляется общая характеристика, которую мы называем «количество».
Ни одна область не начиналась с формулы. Они начинались с наблюдений. С проблем. С вопросов.
Когда я вам говорю, что модуль написан качественно — у вас какая картина в голове возникает? Какие ожидания от такого кода?
Когда вы говорите, что код «не качественный» — как именно вы это понимаете?
Вот с этих вопросов я бы и начал.
Полностью согласен с необходимостью исследования, готов быть в первых рядах)
Сначала расскажите, где циклическая зависимость в вашем примере была.
Я отвечал на ваш пример:
но знаете, что будет ответом на вопрос «что такое хорошо структурированный код»? «Тот, который легче модифицировать».
И вел к тому, что разрешить цикл: «легко модифицируемый код — это код хорошо структурированный, а хорошо структурированный код это тот, который легко модифицировать» — можно, если понять что значит модифицировать. Не более. Не утверждал, что знаю точно «как» это сделать, но предложил один из подходов, который мне показался перспективным.
А папочки — это тоже предположения, не более того.
Да, но матожидание времени поиска, в случае ошибок, они уменьшат. На большее не претендуют.
Как мы видим, мой и ваш выводы не совпадают. У кого здравый смысл здравее?
Что веселее, о структуре кода это еще ничего не говорит. Только о распределении кода по файлам.
А помоему они похожи) Вы ведь тоже говорите о том, что нужен мэппинг из системы теминов требований, в термины кода. Во всяком случае, я понимаю ваше определение так.
И да, внутри файликов все еще сложнее, я так сходу не придумаю — слишком тупой.
А толку-то?
Объективная величина для сравнения.
Более подходящий по какому критерию?
Минимизации временной сложности.
Именно. А вы, еще не разобравшись в формулировке задачи, уже утверждаете, что корреляция давно найдена.
Я утверждал, что разницу можно почувствовать, и это свидетельство в пользу существования зависимости, если вы хотите более точное определение.
Можно поставить чайник греться и переодически пихать в него руку. Можно заметить, что с течением времени, ощущения при пихании руки меняются. И понять, что время стояния чайника каким-то образом коррелирует с тем, обожжетесь вы пихнув в него руку, или нет. И знание термодинамики не является для этого необходимым. Но если вы хотите точно знать, начиная с какого момента вам обожжет руку — вам нужно знать термодинамику, параметры руки, воды, чайника… Но это уже не корреляция.
Вы про чайник Рассела слышали?
Впрочем, мне не кажется, что задача принципиально не формулируема, мне всего лишь кажется, что я до сих пор не видел ни одной формальной формулировки.
Ой, согласен, прозвучало не очень. Извините.
Я лишь имел ввиду, что может у вас имеются какие-то соображения на тему принципиальной невозможности, а я их не знаю.
Но прозвучало, как «я прав, ибо вы не докажете что я не прав» — грубовато и я этого не хотел.
И я полностью согласен насчет отсутствия нормальной формулировки.
Переформулирую:
Дайте определение тому, что значит «модифицировать код в соответствии с требованиями» и вы поймете, как можно сравнивать его структуру с точки зрения сложности модификации. Или наоборот, сможете строго доказать, что эта задача не решаема.
Нет. Это код, в котором элемент назван так, чтобы из требований можно было предположить, как этот элемент называется. Дальше работает инструмент поиска, которому плевать на раскладку по файликам и папочкам.
Не понял — это вы мой первый пункт из вывода, своими словами перепечатали, или свое новое определение даете? Если перепечатали, то да, вы почти поняли. Только ваши предположения не всегда будут давать верный результат, и поэтому для подстраховки можно использовать папочки. Но если у вас все идеально, то, как вы верно заметили это излишне.
Нет.
Вам показалось.
Простите, но на это мне не ответить.
Добавьте подробностей. Расскажите, почему циклическая зависимость в моем примере осталась.
Или где я ошибся, переводя задачу поиска по проекту, в задачу абстрактного поиска в структуре данных?
Я даже не понял, какие выводы вы сделали, не говоря уже о том, чему они соответствуют.
Вывод об оптимальной структуре для поиска, с учетом вышеизложенной модели. Обозначен словом «вывод».
А почему вы думаете, что эта декомпозиция одинакова для всех?
А это отличный вопрос. Ответ — я так не думаю. Я лишь утверждаю, что зная алгоритм, можно посчитать сложность от его входных параметров.
Иными словами я не утверждаю, что можно определить «идеальную» декомпозицию. Я не знаю, можно ли и гадать не буду. Я лишь говорю о том, что можно сравнить несколько вариантов и выбрать более подходящий для решения конкретной задачи. И вопрос в том, чтобы сформулировать задачу. Потому что пока мы ее не сформулировали, мы перебираем вслепую, и не можем как-то подтвердить или опровергнуть наши интуитивные выводы.
И да, если вам кажется, что задача принципиально не формулируема, и именно поэтому все останется в рамках цикла бессмысленных слов определяющих друг-друга — вы не могли бы это доказать?
Эм. Дерево — это связный граф, без циклов. Вы предложили набор отдельных списков. Он не связный. Это лес.
И, да, дерево, с одним элементом у каждого родителя — это… список. Список, конечно технически является деревом. Но, мне кажется, что исходя из контекста диалога, можно было понять, что я не предлагаю строить дерево так, чтобы в глубину получать списки. В этом суть дерева, как структуры данных — не быть списком.
Ну, как сказать. Если у вас 1 модель, 1 view и 1 контроллер — да. Зачем создавать папки для одного элемента? Даже судя по моему графику, без штрафа на переход, это имеет смысл только ближе к 8 элементам.
Вы кажется не понимаете зачем математика нужна. Если я определил как действует сложение — мне не нужно проверять, что оно работает на слонах, черепахах, яблоках, карандашах и так далее. Я вывел правило по которому работает реальность.
Разумеется, при выводе я идеализировал некоторые вещи. Например, предположил, что люди не ошибаются в выборе папки. Или что открыть папку ничего не стоит. Вы можете указать мне на них, я могу уточнить свою модель.
Добавить в нее поправку на открытие папки, добавить шанс ошибки. И я откажусь от своего утверждения про то, что она лучше списка, если мы найдем реальное ограничение, которое может изменить ассимптотику хотя-бы на множитель.
Но пока мы его не нашли — моя гипотеза, судя по всему, неплоха. Найдем — выкинем и запилим новую. Ньютоновская механика тоже не учитывала релятивистские эффекты. И ничего, до сих пор пользуемся.
Если что-то не соответсвует опыту — так давайте поработаем, и уточним мою модель. Вам самому не интересно узнать, в какой момент нужно создавать папку? Мне вот очень интересно, поэтому я тут и сижу.
Конкретнее, пожалуйста. Если вы не придумали этот эксперимент — у вас пока нет критерия фальсификации. А пока вы мне не описали эксперимент — я не могу сказать, действительно ли он хорош)
Нет, серьезно?) Вам настолько не терпится доказать мне что-то, что вы, кхм решили подогнать под определение «дерева» заранее абсурдную структуру? Вы предлагаете как контрпример создавать папки с 1 ребенком?) Нет, я думал написать, то в папке должно быть минимум 2 элемента, но решил что это излишне, ибо ни один дурак не будет так делать. Это, кхм, абсурдно, даже исходя из интуиции. Вашим образом можно доказать что поиск одного элемента в случае папок стремится к бесконечности) Кстати, моя формула это тоже учитывет, ибо предел логарифма по основанию k где k стремится к 1 — стремится к бесконечности. Можете снять ограничения с графиков, что я вам скинул, да посмотреть — там есть поведение в таком случае))
Да, если создавать папки с одним элементом, или, кхм, пустые папки рядом (на случай если вам и это нужно указать отдельно) — искать в такой структуре будет дольше чем в списке) Какой вы молодец, что догадались.
Итак, скажу прямо — у папки обязательно должно быть минимум 2 ребенка.
Нет, вам серьезно не понятно, что если список — это вырожденное дерево, то поиск в любой структуре, кхм, промежуточной, между деревом и списком, ассимптотически по сложности тоже будет лежать между поиском в дереве и поиском в списке?) Даже, если строить дерево «над» списком.
Знаете, учитывая ваш последний аргумент, у меня уже складываается впечатление, что ваша цель — доказать мне, что я не прав, любыми абсурдными методами, даже после того, как я математически показал всю ассимптотику.
Притом вы даже не стараетесь. Вы могли сказать «Эй, парень, но для перехода по папкам требуется намного больше времени, это же кликнуть на папку и ждать пока она откроется. А поскольку файлов у нас не бесконечность, надо смотреть как ведет себя функция в таких условиях на сравнительно небольших числах» — и я бы добавил множитель, и мы бы посмотрели как ведет себя функция (спойлер — с таким условием, при маленьком количестве файлов разбивать их на папки действительно нельзя).
Мне нравится с вами дискутировать. Несмотря на то, что иногда у вас иногда не очень с аргументами — в целом, вы неплохой собеседник. У вас хотя-бы есть достаточно терпения.
Но если вы заранее для себя определили, что «разбиение на папки — не работает», какой смысл убеждать вас в обратном? Если вы не будете пытаться вместе со мной ответить на вопрос «а работает ли?», чем я собственно тут и занимаюсь, а уже заранее записали для себя «верный» ответ, и теперь на каждое свидетельство против вашего убеждения ищете отмазку? Каков критерий для фальсификации вашей гипотезы?
Получается вообще интересная штука. Если мы портрет человека считаем воспроизведением музейного экспоната, то как быть с правом человека на свой собственный портрет?)
PS
Мне всегда было интересно, как пишутся законы, если для них можно элементарным образом составить нерешаемую в рамках их описания проблему?)
Сам так случайно однажды отправил «test» паре тысяч человек. Три раза. Кто — же знал, что инстанс помеченный «QA» в старой версии приложения использовался как основной)
Поиграйтесь сами:
www.desmos.com/calculator/tkfwa8r8tp
Красный график — линейная сложность. В среднем поиск в списке займет x/2 итераций.
Фиолетовый график — Охренительно плохой случай, когда мы можем создать всего n папок и распихать элементы по ним примерно одинаково. Т.Е. у нас есть линейная зависимость количества детей узла, от количества элементов. Спойлер — даже в таком варианте оно уделает линейный случай, начиная с n = 2.
Черный график — случай, когда мы можем нормально составить иерархию, как я описывал, т.е. у каждого узла ровно n детей.
А теперь немного математической магии: Все ваши описания неидеальности моего метода находятся в промежутке от моего худшего случая, до лучшего. Вообще все. Что бы вы не придумали, какую бы схему дерева не предложили — ее график зажат между графиками худшего и лучшего случая. Даже если вы захотите «добавить штраф» к выбору папки, он не изменит ассимптотику.
И мой худший случай — это когда ни для каких элементов нельзя выделить признак, по которому их можно сгруппировать. И тогда у нас все в одной папке — т.е. сложность ассимптотически x/2.
Даже если вы в этой папке, создадите подпапку и положите в нее всего 2 элемента — вы не измените сложность. Вы добавили 1 переход в глубину. Добавили один выбор элемента из двух. т.е. два шага. Вы уменьшили основной список на 2 элемента. Теперь вам нужно пройти 1 список из n-2 элементов, и если в нем не найдется нужный элемент (что произойдет с вероятностью 2/общее количество элементов) — вам придется сделать еще 2 шага. Средняя сложность (матожидание сложности, ведь матожидание это тоже самое что среднее для бесконечной выборки) — n-1/2 + 2*2/n. Кажется, последним членом можно принебречь, он стремится к нулю на бесконечности. Если вы создадите еще одну такую папку — у вас появится лес из 2 папок по два элемента, в который вы придете с вероятностью 4/n. И в этом лесу вы потратите 1 + 1 шаг. И опять за счет малой вероятности того, что ваш элемент находится в этом дереве — его вклад в среднее — стремится к нулю. Если вы сделаете так еще раз — получите вероятность 6/n в лесу из трех мини деревьев. Количество шагов в нем — 1.5+1. Я прикинул формулу для расчета среднего количества шагов в таком случае — она зеленая в ссылке выше. Параметры k и p — это количество папок и количество элементов в папке. Разумеется, смотреть нужно с момента когда x>k*p, до этого там будет какой-то бред ибо мы пытаемся создать папки для несуществующих элементов. И ассимптотика в этом случае все еще линейная.
Итого — вы не сможете придумать разбиение, когда способ с папками работает хуже чем линейно, отличаясь не константой, а хотя-бы множителем. И это наши худшие случаи. В других случаях кроме этого он работает за меньшее время, чем время поиска по обычному спику. В любых.
Так что там не будет работать в реальности?) Если вы сейчас в этой самой реальности, не сможете придумать контрпример, в котором разбиение на папки будет отличаться в худшую сторону хотя-бы множителем?)
Так, я кажется понял в чем проблема: Я говорю, если строить дерево вот с такими ограничениями, то поиск ассимптотически стремится к логарифму.
Вы говорите о том, что если строить дерево по другому, то не будет? — Согласен, если строить дерево по другому — то может и не будет.
Если в бинарное дерево поиска пихать элементы строго в порядке их убывания/возрастания и не балансировать — то там тоже не получится логарифм для поиска, оно в список выродится. Его можно «строить не правильно». Однако, если принять, что мы не строим дерево «специально не правильно», а раскидываем элементы случайно, в среднем у нас получается logN.
Да, и я дал вам формулу, от числа детей узла — p и количества листьев — n.
.
Ага, только число промежуточных узлов, для случая когда у нас поиск идет линейно — равно 1. Все лежит в одном домене. И я даже добавил эту единицу в формулу)
Средний случай, как и в случае бинарного дерева определяется тем, что при бесконечном числе вставок дерево будет заполняться равномерно.
При оценке ассимптотики на бесконечности — можно забивать на множители. Вот если количество элементов в одном домене — функция от количества листьев — тогда да, нельзя.
О малых n я отдельно упомянул, и сказал, что в этом случае на множитель забить нельзя. Как и в случае, когда на малых n квадратичные сортировки уделывают quick.
Блин, вот это я налажал. Да, вы правы, нельзя брать количество узлов, надо считать от листьев.
Интересно, сильно ли это меняет ситуацию? Вот ваше количество элементов — 8.
Вот мы разбили их на два поддомена — каждый по 4. И еще разок — теперь у нас 2+4+8 элементов в дереве. А шагов по уровням сколько, для навигации до нужного элемента?
1+1+1 = 3. Если я не ошибаюсь, это логарифм от 8 по двум?)
И, кажется это всегда будет так, учитывая что на следующем уровне дерева можно расположить в p раз больше элементов, чем на предыдущем. Т.Е. картину не особо меняет. Кажется, константу добавит, плюс один шаг нужен вглубь нужен.
Окей, формула: p/2*(logp(n)+1).
Ну, да, кстати, логично. Чтобы перейти в 1 файл в 1 папке нужно 2 шага — открыть папку, открыть файл.
В этом и фича. Вы добавили еще элементов — глубина не изменилась, количество шагов все еще зависит от глубины дерева. Вы добавили еще элементов, и они перестали влезать на последний уровень дерева?
Добавьте пару элементов в иерархию увеличив глубину — теперь влезут, а количество шагов по уровням увеличится всего на 1.
Да, я согласен, что у меня не дерево поиска. Поэтому я и не стал говорить, что это «логарифм по 2, потому что это дерево поиска», а занялся прикидками.
Бинарное дерево тоже умеет вырождаться в список. И быть несбалансированным. Именно поэтому есть средний и худший случай. У меня тоже есть худший, и он тоже, как ни странно O(n)
На достаточно большом дереве на это можно забить. На маленьком — да, имеет вес. Но врятли это что-то большее чем константный множитель на шаге выбора из детей узла.
У обычных алгоритмов есть похожие «девиации» поведения, когда сортировка вставками уделывает quickSort на мелких данных за счет констант. А еще архитектура проца роль играет в том, какие операции исполняются эффективнее. И ничего, живем как-то, и почему-то все еще учитываем при написании кода вычислительные сложности, не смотря на, простите за каламбур, сложности)
Я абсолютно серьезно, если есть — давайте, это же революцию в коммуникациях совершит.
И из какой шляпы вы сейчас достали возможные ключи?)
Так, может я реально ошибся с логарифмом. Ща прикину. Ну, окей, на каждой папке, которая является узлом дерева у нас есть список следующих узлов. Обозначим количество узлов за n, среднее число узлов в списке за p. Глубина дерева получится порядка logp(n), заходим в первый узел- среднее время выбора следующего — p/2, идем в следующий узел, повторяем logp(n) раз, потому что это глубина дерева. Итого — в среднем p/2*logp(n), где p среднее количество узлов в списке связей каждого узла, а n — количество узлов. Если P не является функцией от N, то на больших N можно им вообще принебрегать, логарифмическая ассимптотика не поменяется. Если является — окей, не логарифм, а f(n)*logf(n)(n), где f(n)<n (потому что если равно, то это все равно что все пихать в один узел).
И это отличная идея, для еще одного эксперимента!
Ну, меня интересует с какой вероятностью допускаются ошибки при наименовании, для того, чтобы посмотреть какой вклад они вносят в матожидание. Кажется, на этом все.
Или вы опять пытаетесь утверждать, что нельзя посчитать сложность поиска в абстрактной структуре данных, не зная конкретный искомый элемент?) Да — нельзя. Дать оценку в зависимости от количество элементов структуры и того, как выглядит на ней алгоритм поиска — можно.
Во вторых — если для каких-то объектов можно определить отношение НЕравенства и сложение — тадам, это уже величина.
В третьих, матстат работает с такими штуками как качественные признаки. Признаюсь, ошибся словом, сейчас посмотрел. Количественная величина, качественный признак.
Конечно нельзя. Я описал лишь одну из подзадач модификации. Самую простую и очевидную. И раз 5 написал, что не претендую на то, что в комментарии могу так взять и описать математически весь процесс работы с кодом.
То, что одна из подзадач может быть описана математически — свидетельство в пользу того, что задача целиком тоже может быть так описана. Не доказательство. Свидетельство. Вы понимаете концепцию оценки вероятности гипотезы исходя из свидетельств?
Временные сложности не работают в случаях, когда у нас есть вероятность ошибки в алгоритме. А в реальности, особенно когда алгоритмы выполняют люди — ошибки есть. Поэтому если мы моделируем процесс с ошибками, то придется подрубить матстат к обычной теории вычислительной сложности.
Так вы опишите формально «ваш поиск» и «ваше условие». Свяжите его с математикой.
Ваше определение:
Что вы понимаете под «предположить», под «элементом кода», под «инструментом поиска», как вы получили отсутствие коллизий «предположений»?
Я из этого совсем не четко сформулированного определения предположил, что вы решили сделать Map. Потому что по вашему описанию, у вас есть функция предположения, которая из какого-то элемента требований получает название элемента кода.
Т.Е. ваш «элемент требований» является ключем, «название элемента кода» — значением, и ключ отображается в значение за счет функции «предположить»
Я говорю о том, что если вы укажете неверный ключ — плохо будет. Придется искать перебором. А люди по моим наблюдениям часто указывают неверный ключ.
Я могу составить модель процесса поиска файла, и да, посчитать и доказать ее сложность от различных начальных параметров.
Чтобы показать что она работает в реальности — придется проводить эксперимент. Знаете, ну, как все нормальные ученые делают.
Сформулировать гипотезу, вывести следствия, верифицировать, указать условия, при котором мы считаем гипотезу разрушенной, сделать эксперимент на это, и таким образом показать фальсифицируемость.
Например, если мы поставим эксперимент формата: мы даем одной группе людей код, где есть определенный нами мэппинг из требований, а другой группе — тот же код, но все термины из требований заменяем на рандомные строки той же длины. Если люди в обоих группах будут искать какие-то элементы одинаковое время — откажусь от теории что нужен мэппинг.
Второй эксперимент — возьмем обфусцированный код из первого эксперимента, но теперь вернем нормальные названия для папок. Опять сравним время на поиск.
Если люди без папок не будут сильно проигрывать — признаю что не прав.
Процитирую вас же:
Так что об экономическом эффекте я в этой ветке не говорю, вы же сами обозначили эту ветку как «отдельную».
Я обсуждаю матстат, корреляцию и математические подходы для определения всякой нечеткой фигни, вроде «нравится», «качественно», «полезно», чтобы в дальнейшем с нею работать математическими же методами.
А измеримый экономический эффект — вроде как вполне измерим и является величиной даже по вашим критериям, зачем тащить его сюда? Для этого обсуждения есть основная ветвь.
В общем, SRP нарушаете)
Ладно, шучу.
А почему вы уверены, что нельзя построить множество? Знаете, есть такая штука, теория потребления. И в ней есть «отношение предпочтения». Строится только на том, что человек может сравнить вещи. Не численно выразить разницу — просто сравнить.
Абстрактный потребитель, абстрактные вещи.
Еще там же, есть определение функции полезности. Тоже для абстрактного потребителя, на абстрактных товарах, и т.д.
А теория игр оперирует с абстрактными выигрышами. Они тоже заданы через оценку самим участником игры, вроде как. Если я правильно помню, то например в «Теории игр и экономическом поведении» Фон-неймана и Моргенштерна, оно введено как раз через отношение предпочтения и полезность.
Чем же так сильно отличается ситуация с предпочтениями когда дело касается ПО?)
Мы все это время говорим о том, что не одинаково понимаем слово корреляция?)
Что значит по вашему «не является величиной»? Все что можно ощутить является как минимум альтернативной величиной — ощущение есть или его нет)
Я перечитал свои сообщения. Я понимаю их нормально и не вижу там подмены понятий. Как не вижу и того, что утверждаю, что так можно получить «хорошо структурированный код». Только если вырвать эти слова из середины одной из фраз.
Я весьма точно определил область в которой я применил этот термин в тот момент. Там есть конкретная задача, и конкретное определение хорошей структуры в контексте этой задачи.
Легко. Предположим мы совершили ошибку и обозвали файл не так. В моем случае существует ненулевая вероятность того, что файл можно найти за логарифм. В вашем случае — она стремится к нулю, т.е. поиск гарантированно вырождается в линейный.
И я с вами полностью согласен, если есть идеальный мэппинг — древовидная структура организации не нужна. Если он не идеален, то весь вопрос в том, насколько.
Вы не правы. Конкретным должен быть только алгоритм.
Входные данные — могут быть абстрактны. Вы же можете сказать, сколько конкретный бинарный поиск, занимает шагов на абстрактном сортированом массиве длины N, ища абстрактное значение. Разумеется не численно, но ассимптотику оценки дать можете.
Нет, просто для «написания» я не могу сходу придумать алгоритм. Повторю свой предыдущий пост, где уже говорил, что не претендую на носителя сокровенного знания «как сделать код проще»:
Как минимум вы не будете пихать руки в ваш собственный чайник, после того как он провел достаточно времени на плите. А еще вы можете заинтересоваться результатами и в процессе долгого и упроного труда, описывая кучу наблюдаемого вами вывести термодинамику и обобщить на все чайники в мире.
У меня сложилось ощущение, что вы пытаетесь мне сказать, что у меня нет знания про все чайники, а я говорю о том, что чайники познаваемы)
И вы вроде даже согласились с познаваемостью чайника, что и являлось целью моего первого комментария.
Это лучшее что случилось с человечеством)
А формулу — да, согласен довести до конечной формулы было бы неплохо.
Но надо довести.
Физика начиналась не с формул. Физика начиналась с того, что люди замечали какую-то зависимость. У Архимеда не было формулы, он предметы в воду пихал и заметил интересную штуку — они по разному вытесняют воду. Это он позднее сформулировал в закон, который лишь через много лет обрел привычный нам вид формулы.
Математика начиналась не с формул. Она началась с того, что какой-то гений дошел до того, что камушки и яблоки можно связать через свои действия, и их у них появляется общая характеристика, которую мы называем «количество».
Ни одна область не начиналась с формулы. Они начинались с наблюдений. С проблем. С вопросов.
Когда я вам говорю, что модуль написан качественно — у вас какая картина в голове возникает? Какие ожидания от такого кода?
Когда вы говорите, что код «не качественный» — как именно вы это понимаете?
Вот с этих вопросов я бы и начал.
Полностью согласен с необходимостью исследования, готов быть в первых рядах)
Я отвечал на ваш пример:
И вел к тому, что разрешить цикл: «легко модифицируемый код — это код хорошо структурированный, а хорошо структурированный код это тот, который легко модифицировать» — можно, если понять что значит модифицировать. Не более. Не утверждал, что знаю точно «как» это сделать, но предложил один из подходов, который мне показался перспективным.
Да, но матожидание времени поиска, в случае ошибок, они уменьшат. На большее не претендуют.
А помоему они похожи) Вы ведь тоже говорите о том, что нужен мэппинг из системы теминов требований, в термины кода. Во всяком случае, я понимаю ваше определение так.
И да, внутри файликов все еще сложнее, я так сходу не придумаю — слишком тупой.
Объективная величина для сравнения.
Минимизации временной сложности.
Я утверждал, что разницу можно почувствовать, и это свидетельство в пользу существования зависимости, если вы хотите более точное определение.
Можно поставить чайник греться и переодически пихать в него руку. Можно заметить, что с течением времени, ощущения при пихании руки меняются. И понять, что время стояния чайника каким-то образом коррелирует с тем, обожжетесь вы пихнув в него руку, или нет. И знание термодинамики не является для этого необходимым. Но если вы хотите точно знать, начиная с какого момента вам обожжет руку — вам нужно знать термодинамику, параметры руки, воды, чайника… Но это уже не корреляция.
Ой, согласен, прозвучало не очень. Извините.
Я лишь имел ввиду, что может у вас имеются какие-то соображения на тему принципиальной невозможности, а я их не знаю.
Но прозвучало, как «я прав, ибо вы не докажете что я не прав» — грубовато и я этого не хотел.
И я полностью согласен насчет отсутствия нормальной формулировки.
Переформулирую:
Дайте определение тому, что значит «модифицировать код в соответствии с требованиями» и вы поймете, как можно сравнивать его структуру с точки зрения сложности модификации. Или наоборот, сможете строго доказать, что эта задача не решаема.
Не понял — это вы мой первый пункт из вывода, своими словами перепечатали, или свое новое определение даете? Если перепечатали, то да, вы почти поняли. Только ваши предположения не всегда будут давать верный результат, и поэтому для подстраховки можно использовать папочки. Но если у вас все идеально, то, как вы верно заметили это излишне.
Простите, но на это мне не ответить.
Добавьте подробностей. Расскажите, почему циклическая зависимость в моем примере осталась.
Или где я ошибся, переводя задачу поиска по проекту, в задачу абстрактного поиска в структуре данных?
Вывод об оптимальной структуре для поиска, с учетом вышеизложенной модели. Обозначен словом «вывод».
А это отличный вопрос. Ответ — я так не думаю. Я лишь утверждаю, что зная алгоритм, можно посчитать сложность от его входных параметров.
Иными словами я не утверждаю, что можно определить «идеальную» декомпозицию. Я не знаю, можно ли и гадать не буду. Я лишь говорю о том, что можно сравнить несколько вариантов и выбрать более подходящий для решения конкретной задачи. И вопрос в том, чтобы сформулировать задачу. Потому что пока мы ее не сформулировали, мы перебираем вслепую, и не можем как-то подтвердить или опровергнуть наши интуитивные выводы.
И да, если вам кажется, что задача принципиально не формулируема, и именно поэтому все останется в рамках цикла бессмысленных слов определяющих друг-друга — вы не могли бы это доказать?