«Ну, тогда получается, что с Ваших позиций Знания тождественны Информации.»
Нет. Знания — это частный случай информации. Информация в общем смысле — это уменьшение энтропии. Т.е. неизвестности. Но она состоит из полезной информации и шума. Вот знания — это некий аналоги полезной информации. Выраженный в законе. Закон — это способ зашифровать информацию и потом возможно по закону ее восстановить. Наиболее существенные части полезной информации часто можно выразить какой-то закономерностью. Закономерность позволяет понять вид информации, при этом затратив на передачу информации гораздо меньше «байт».
«Теперь же по-Вашему получается, что Информация — это виртуальные модели.»
В моей интерпретации виртуальных моделей нет. Поэтому такая последовательность из двух умозаключений как-то выглядит не совсем правильной.
Если же просто находить что-то общее в двух интерпретациях, то вот оно. Знания — это модель реальных данных. Как любая модель, бумажная или математическая — всегда копирует у реального объекта только интересующие стороны. И модель всегда ущербна по сравнению с моделируемыми объектами. Она меньше, проще. Потому что она только выражает интересующие аспекты.
Знания — всегда модель.
Например, вы видите точки на графике некоторого процесса. Глазами приблизительно видите, что похоже на параболу. Вот, парабола с двумя коэффициентами выразит эти точки. Пусть они немного не попадают на нее. Но вы можете предположить, что суть процесса, с которого снимали показания — парабола. А отклонения — просто шум из-за неточности приборов. Всё множество точек свелось к двум числам. Ну и плюс несколько байт на выбор вида зависимостей.
Т.е. на практике, если бы не было Ньютона, все компьютеры можно было бы забить информацией о силе броска и координатах тела. Это была бы информация.
А знание — это закон, по которому движутся тела. Т.е. это способ сжать информацию. И чем лучше сжимается и с большей точностью, тем больше можно предполагать, что мы близки к закону. А если еще и этот закон работает на новых данных и предсказывает поведение — вот и знания.
Не знаю, насколько это правило будет всеобщим, но сейчас на вскидку, все методы поиска знаний к этому и сводятся.
Единственное, что знания нас интересуют — как полезная часть информации. Полезность — вещь субъективная. Зависит от целей. Датамайнинг ищет знания в идеале (и часто) без субъективных предположений. Просто находит, предлагает пользователю, а пользователь определяет, что полезно, а что нет. Польза его в том, что он находит иногда неожиданные вещи.
«Но из Вашего комментария ясно, что мауглёнок НЕ ПРИОБРЕТЁТ Знания»
Я вкладывал смысл в комментарий только тот, что не хочу даже думать о такой задаче. Ни связи, ни фундаментальности задачи не вижу.
Да и смысла тоже. Все мы когда-то были маугленками. И некоторые даже писали книги Ландау, не только могут изучить.
«Если мауглёнок сумеет самостоятельно овладеть знаниями, якобы имеющимися в книгах Эйнштейна или Ландпау, то для компа освоить это, как нечего делать»
Откуда такой вывод? «как нечего делать» — это как? Чтобы неявно полагать, что компьютер умнее маугленка (раз ему намного легче что-то выучить), надо вводить критерий количества ума.
Уже более века такой критерий придумать не могут. IQ — глючные попытки и рассчитаны только на человека.
Без критерия нельзя даже говорить, что цель не достигнута или достигнута.
Структуры в данном случае подразумевалось «структурированная информация». Не будем же к словам придираться? Мы говорим о компьютере и об информации, в нем хранящейся. Логично, что там других структур и нет.
Точных определений тоже наверное не найти. Есть только неточные. Данные — это просто информация. Знания — это вычленение некоторых «структур». Правил вывода, если это нечто вроде ПРОЛОГА. Причинно-следственные связи. Или вообще что угодно, которое присутствует в информации в неявном виде, но может быть полезно человеку.
Или можно назвать знаниями — способ сжатия информации с потерей. Т.е. вычленение полезной информации и отсеивание «шума».
Я не дам вам такого определения, чтобы покрыло все случаи. С т.з. датамайнинга — это неявная информация, присутствующая в данных, которая несет смысловую и возможно полезную нагрузку.
1. Про базы знаний в википедии есть. Я больше датамайнингом занимался. Но суть похожа. Датамайнинг — это загрузка данных, обычно из традиционной бд в нетрадиционную (как я описал), которая позволяет находить эти самые знания. Обычно, хранилищами данных называют. Днем работают на операционной СУБД (реляционной), потом сливаются данные в нереляционную, на которой работают анилитики. ОЛАП-кубы строят и т.д.
Но такие базы не обязаны каждый день перелопачивать все данные. Вполне возможны базы, которым инкрементально добавляют новые данные, и они в рантайме сразу же находят знания.
Знания — это структуры любого типа, которые могут быть полезны человеку. Например, такая система позволяет находить стратегии увеличения прибыли. Находит автоматически. Иногда может быть и бред с т.з. человека, но для того и нужен человек, чтобы принимать решения. В любом случае, она находит статистические закономерности (как пример), полезные человеку.
Маугленков ни разу не видел, видел только аналитиков и заказчиков. Которые понимают предоставляемые датамайнингом знания. Мне постановка самой задачи про маугленка никак не нравится. Не понимаю, причем маугленок к знаниям. Потому что тогда можно сказать, что Эйнштейн или Ландау — лохи, потому что ну никак маугленок, обладая только их книгами не поймет ни йоты. Значит знаний в их книгах и нет.
Там написано, что подразумевается под знаниями. Часто, это ассоциативные правила. Вот, как вариант — это поиск причинно-следственных связей в данных. Например, статистически считая условные вероятности. Можно найти, какие данные друг с другом связаны и направление связи.
Это уже знания. Добываются автоматически.
Будет грубо говоря в одной транзакции портрет мамы и звук «мама» — такая система (фантазирую), находит зависимость. Т.е. ассоциативные правила — это более общее понятие, чем те примеры, что автор приводит, претендуя на обобщение. Две колонки в таблице — чем не два канала? Три колонки — три канала информации. Колонка со временем позволяет находить временные последовательности.
И скептиком быть не надо по поводу новых СУБД. Ничего сверхестестсвенного в них нет. Конечно, наверное, далеко не все из них реализуют то, что декларируют. Но в общем. Суть такая. Задача поиска знаний отличается от задачи базы данных, с операционной деятельностью. Т.е. той, которая собирает данные. Такие мы и знаем обычно. На последние (обычные) БД требования в основном — массовая обработка различных маленьких транзакций. Такие СУБД рассчитаны на то, что к ним сотни и тысячи пользователей коннектятся и выполняют несложные запросы параллельно. Так эти СУБД и проектируются. Например, чаще всего они построчно хранят записи.
СУБД для поиска знаний — это такие БД, где не ожидается, что будет сотня пользователей. На них возлагается другое требование. Часто, за ночь, например, перебрать все данные и найти знаний. Поэтому там нет таких сложностей с транзакциями. И часто данные в таких базах хранятся в файлах колонками. Что позволяет целыми колонками загружать в память и разбивать на куски алгоритмы более оптимально.
У нас был недавно случай, когда заказчик захотел логировать любые действия пользователя. Это нормально. Ненормально, что он в логах еще захотел, чтобы указывалась причина действий пользователя.
Эта штука должна быть в коде выражена. Грубо говоря, зачем он что-то делает, исходит прямо из места в ГУИ, где он находился, когда выполнял действие. Т.е. он делает всегда то, что позволяет программа. А значит, если он находится в каком-то месте, то это и надо логировать.
Если же делать окошко, где он выражает свои причины, почему так поступает — это говорит о том, что логика приложения не доработана. Что часть логики выносится на пользователя. И смысла в этом особого нет, т.к. причины могут быть любые и с ними потом нельзя проводить никаких операций. Их нельзя сортировать, делать осмысленные выборки в рамках описания самой системы.
Так что не надо фантазировать на счет того, что должна знать программа по поводу причин пользователей. Пользователь делает с программой то, что она позволяет. Как задумал программист. Вне этого ничего и не должно быть. Никаких больше догадок выносить за пределы логики программы нельзя.
Без мужского шовинизма. Только факты.
Работал когда-то в школе, физику читал. А также в ВУЗе программирование. Я бы рад был, если бы было больше девушек, хороших специалистов. Но у них реально мозги не работают в эту сторону.
Есть исключения. Но они очень редки. На группу если одна хоть девушка хоть немного умеет соображать и пишет программы — это уже редкость. Настолько же редкость, насколько редкие парни, которые это не умеют.
И где это автор статьи видела много айтишниц? Работаю много лет в разных компаниях, программистку видел аж одну.
Вначале я до запятой, первый параметр массива написал так:
Convert.ToInt32(range.Item2 <= list.Count && range.Item1 < range.Item2)
Т.е. как раз условие, чтобы не вышли за пределы массива. И смоделировал потом сайнами. Но наверное конец рабочего дня, где-то ошибся. Точнее я смоделировал это условие так, как надо (надеюсь, не проверял только что), но то ли у меня четное (или нечетное) число элементов было, что проходил код. Решается эта бага замечательно. Вот в этой строчке надо так:
int midleIndex = (range.Item1 + range.Item2 — 1) / 2;
Если учитываем, что левая часть всегда не включается, то приводим рейджу с настоящими элементами.
Но кажется, я перемудрил. Если сделать поправку со средним индексом, то достаточно сделать такое условие:
Convert.ToInt32(range.Item1 < range.Item2)
прошу прощения за ошибки, если даже сейчас ошибаюсь. Все таки после рабочего дня немного не так соображается. Финальная версия, надеюсь верная:
Понятно, что можно добавлять 0.5, все в дабл конвертнется, а знак брать тогда тоже можно. И код даже проще будет. Но как-то не хотелось даблами пользоваться. Прихоть такая.
Внутри сайна есть ветвление и тоже это не очень чисто. А вот пользоваться массивом вместо ветвления и не называть его ветвлением — вполне честно. Понятно, что вызов такой его моделирует. Даже свич можно смоделировать. Но свич или иф — это структура кода, а здесь структура данных. Куда и функции примешались.
Наверное можно еще что-то сделать такое, что упростит этот код. С ходу не придумал.
Раз такое уже пошло, то и я свой код кину ))
Поломайте мозги.
Я для усложнения поставил себе задание — не использовать никакие ветвления и логические функции. На шарпе. Вот что получилось:
Как-то в частной беседе со своей знакомой, психологом.
Рисует на листке галочку. Две искривленные линии. Не предупреждая. И показывает мне и говорит:
— Что ты здесь видишь?
— ??? Галку
Он вздыхает, кладет листок на стол и говорит:
— Из тебя ничего не получится. Это тест на креативность. Чем более креативный человек, тем более причудливые вещи здесь видит. Кто-то облако, кто-то сердечко, а кто-то даже лошадь. Некреативные люди ни на что не способны в жизни.
Потом, немного подумав говорит:
— Но почему-то все математики видят только галку
…
меня это рассмешило. Говорю:
— Так математики и видят галку, потому что нарисованный объект наиболее соотвествует галке. Точные науки тем и отличаются, что стараются опираться на объективную информацию. А те, кто коней видят, пусть видят — на хрен мне нужна такая креативность.
К сожалению, многие программисты себя представляют творцами. И вместо анализа требований и четких правил — «придумывают» архитектуры, «строят» каркасы, вместо «перевода требований на язык программирования». Как-то безумие ТП распространяется на все сферы жизни, включая и точные науки и программирование )))
Странно. Это просто рассуждения, что закомментированный код теоретически может когда-то помочь. На практике — никогда. Если вы прямо сейчас отлаживаете программу, то возможно, комментируете вызов одной функции, заменяете на другой. Это в течении дня. Если задачу (кусок задачи) сделали — то код нужно чистить, потому что он не помогает. Код старых версий значительно ухудшает восприятие. Если вы сейчас смотрите на то, что сделано и на текущий функционал, то вникание в то, как было в прошлом или как кто-то когда-то хотел сделать — требует значительно больше усилий. Потом закомментированный код связан и возможно с отброшенными требованиями. Которые не всегда по коду читаются. И с другим кодом, который уже изменен.
И читать неудобно и раскомментировать очень опасно. Доверия коду, который месяц не компилировался — никакого. Проще действительно с нуля.
Постоянный рефакторинг и соответствие только текущим требованиям (всё остальное удаляется), позволяет держать код в относительной чистоте. Делать из файлов, где код, систему контроля версий — уже какая нечистоплотность с наглостью )))
У нас в проекте куча кода осталось в наследство. В БД где-то 1 к 6-ти кода который используется и кода, который вообще никому не известно что должен делать и используется ли. При этом разработка велась: авось понадобится. Если что-то не понадобилось, не удалялось. Если делали новую версию процедуры, старой добавляли в название Old
Можно провести некоторую аналогию — рефакторинг — это как уборка в квартире. Должна проводится постоянно. При меняющихся требованиях, меняется перестановка в квартире, ненужные вещи прячутся на чердак (балкон) и т.д. (система контроля версий). Все, кто так не делают, периодически ловят себя на желании переписать всё с нуля. Мол, дайте денег на новую квартиру, сто процентов больше мусорить не буду.
Один коллега недавно сказал одну вещь, мне показалась занимательной. Сказал, что если бы сейчас дали ему переписать систему, то она была бы просто супер.
Прослеживается аналогия с мусором и квартирой? Код не должен быть идеальным. Не должен быть абсолютно гибким. Код должен быть простым, соответствовать текущим требованиям. И быть в относительной чистоте, чтобы всегда была возможность перестроить под новые требования. И дополнительный функционал, который вдруг может понадобиться — не делает код более перестраиваемым. Наоборот. Дополнительный функционал — это дополнительные потенциальные баги. Это дополнительные издержки на поддержку и изменение тестов на него. И это дает гибкость только в предугаданном направлении, а в остальных сковывает
Думаю, возможность писать по разному и не связывать напрямую структуру кода и файлов — хорошая возможность.
Не так и напрягает создавать новый класс в новом файле. Иногда мелкие классы можно и в один впихнуть. Например, небольшие, имеющие одного предка и фабричный метод. Или перечисления.
Студия и так неплохо находит нужные классы, не обязательно отражать в файловой структуре
алгоритм для меня простой. Да, выбор имени — чуть ли не самая важная часть кодирования. Но. Код должен читаться легко и отражать смысл задачи. Поэтому если имя сложно придумать, первая мысль: я не очень-то хорошо понял задачу (не могу выразить мысль в коде). Далее, если выбор между коротким именем, но не очень понятным, и длинным, но понятным — приоритет длинному. Т.е думаю о другом программисте, который читает код. Пусть даже кусок предложения будет в имени.
Далее, если все же очень неудобные имена — вторая мысль: стоит расширить глосарий в проекте. Нужен какой-то термин.
Вы не поняли. Я подразумевал, что честно реляционным способом не реализуются.
А завести табличку с называнием Attribute и с колонками что-то вроде Name, Value, Type можно.
Или делают денормализацию — лишние колонки, которые пользуют, как захочется потом и сколько надо. Или делают табличку, в которой общий тип текстовый или какой-то, которые приводят потом к чему хотят.
По сути, это подобный хак, как и в ООП (шарп, джава) со статической типизацей был бы. Просто в языках таких всё на хаках, кругом императивщина. Поэтому там не так заметно, когда язык выворачивают. Создают новое свое измерение для типизации.
«В РСУБД плохо моделируются иерархические и/или рекуррентные системы»
Насколько я понимаю, моделируются просто, работают СУБД с такими вещами неэффективно. SQL плохо подходит.
Многие ко многим реализуются отдельной таблицей. Это не такой удар по предметной области. Просто помнить, что таблица не обязательно бывает сущностью, а может быть и связью. Иногда, эта связь по мере моделирования становится сущностью. Просто добавляются еще атрибуты. Поэтому суть размыта, где таблица связи и почему она не сущность.
Системы с произвольными атрибутами реляционно не реализуются. Но не согласен, что такие задачи сплошь и рядом. Представьте себе систему, написанную на объектно-ориентированном языке без БД. Аналог этой задачи — вы не знаете во время компиляции, сколько и какого типа полей у объекта будет. И вы будете формировать тип в рантайме. Еще тот фокус. Иногда надо. Но или на динамических языках пишут или просто пишут классы, которые будут потом атрибутами другого класса в списке, а им добавляют тип, который что-то вроде перечисления. Т.е. фактически не пользуются уже типизацей языка, а выворачивают его так, чтобы создать собственную динамическую типизацию.
Точно таким же хаком и в реляционной БД поступают, если такое нужно.
Нет. Знания — это частный случай информации. Информация в общем смысле — это уменьшение энтропии. Т.е. неизвестности. Но она состоит из полезной информации и шума. Вот знания — это некий аналоги полезной информации. Выраженный в законе. Закон — это способ зашифровать информацию и потом возможно по закону ее восстановить. Наиболее существенные части полезной информации часто можно выразить какой-то закономерностью. Закономерность позволяет понять вид информации, при этом затратив на передачу информации гораздо меньше «байт».
«Теперь же по-Вашему получается, что Информация — это виртуальные модели.»
В моей интерпретации виртуальных моделей нет. Поэтому такая последовательность из двух умозаключений как-то выглядит не совсем правильной.
Если же просто находить что-то общее в двух интерпретациях, то вот оно. Знания — это модель реальных данных. Как любая модель, бумажная или математическая — всегда копирует у реального объекта только интересующие стороны. И модель всегда ущербна по сравнению с моделируемыми объектами. Она меньше, проще. Потому что она только выражает интересующие аспекты.
Знания — всегда модель.
Например, вы видите точки на графике некоторого процесса. Глазами приблизительно видите, что похоже на параболу. Вот, парабола с двумя коэффициентами выразит эти точки. Пусть они немного не попадают на нее. Но вы можете предположить, что суть процесса, с которого снимали показания — парабола. А отклонения — просто шум из-за неточности приборов. Всё множество точек свелось к двум числам. Ну и плюс несколько байт на выбор вида зависимостей.
Т.е. на практике, если бы не было Ньютона, все компьютеры можно было бы забить информацией о силе броска и координатах тела. Это была бы информация.
А знание — это закон, по которому движутся тела. Т.е. это способ сжать информацию. И чем лучше сжимается и с большей точностью, тем больше можно предполагать, что мы близки к закону. А если еще и этот закон работает на новых данных и предсказывает поведение — вот и знания.
Не знаю, насколько это правило будет всеобщим, но сейчас на вскидку, все методы поиска знаний к этому и сводятся.
Единственное, что знания нас интересуют — как полезная часть информации. Полезность — вещь субъективная. Зависит от целей. Датамайнинг ищет знания в идеале (и часто) без субъективных предположений. Просто находит, предлагает пользователю, а пользователь определяет, что полезно, а что нет. Польза его в том, что он находит иногда неожиданные вещи.
Я вкладывал смысл в комментарий только тот, что не хочу даже думать о такой задаче. Ни связи, ни фундаментальности задачи не вижу.
Да и смысла тоже. Все мы когда-то были маугленками. И некоторые даже писали книги Ландау, не только могут изучить.
«Если мауглёнок сумеет самостоятельно овладеть знаниями, якобы имеющимися в книгах Эйнштейна или Ландпау, то для компа освоить это, как нечего делать»
Откуда такой вывод? «как нечего делать» — это как? Чтобы неявно полагать, что компьютер умнее маугленка (раз ему намного легче что-то выучить), надо вводить критерий количества ума.
Уже более века такой критерий придумать не могут. IQ — глючные попытки и рассчитаны только на человека.
Без критерия нельзя даже говорить, что цель не достигнута или достигнута.
Точных определений тоже наверное не найти. Есть только неточные. Данные — это просто информация. Знания — это вычленение некоторых «структур». Правил вывода, если это нечто вроде ПРОЛОГА. Причинно-следственные связи. Или вообще что угодно, которое присутствует в информации в неявном виде, но может быть полезно человеку.
Или можно назвать знаниями — способ сжатия информации с потерей. Т.е. вычленение полезной информации и отсеивание «шума».
Я не дам вам такого определения, чтобы покрыло все случаи. С т.з. датамайнинга — это неявная информация, присутствующая в данных, которая несет смысловую и возможно полезную нагрузку.
Но такие базы не обязаны каждый день перелопачивать все данные. Вполне возможны базы, которым инкрементально добавляют новые данные, и они в рантайме сразу же находят знания.
Знания — это структуры любого типа, которые могут быть полезны человеку. Например, такая система позволяет находить стратегии увеличения прибыли. Находит автоматически. Иногда может быть и бред с т.з. человека, но для того и нужен человек, чтобы принимать решения. В любом случае, она находит статистические закономерности (как пример), полезные человеку.
Маугленков ни разу не видел, видел только аналитиков и заказчиков. Которые понимают предоставляемые датамайнингом знания. Мне постановка самой задачи про маугленка никак не нравится. Не понимаю, причем маугленок к знаниям. Потому что тогда можно сказать, что Эйнштейн или Ландау — лохи, потому что ну никак маугленок, обладая только их книгами не поймет ни йоты. Значит знаний в их книгах и нет.
Там написано, что подразумевается под знаниями. Часто, это ассоциативные правила. Вот, как вариант — это поиск причинно-следственных связей в данных. Например, статистически считая условные вероятности. Можно найти, какие данные друг с другом связаны и направление связи.
Это уже знания. Добываются автоматически.
Будет грубо говоря в одной транзакции портрет мамы и звук «мама» — такая система (фантазирую), находит зависимость. Т.е. ассоциативные правила — это более общее понятие, чем те примеры, что автор приводит, претендуя на обобщение. Две колонки в таблице — чем не два канала? Три колонки — три канала информации. Колонка со временем позволяет находить временные последовательности.
И скептиком быть не надо по поводу новых СУБД. Ничего сверхестестсвенного в них нет. Конечно, наверное, далеко не все из них реализуют то, что декларируют. Но в общем. Суть такая. Задача поиска знаний отличается от задачи базы данных, с операционной деятельностью. Т.е. той, которая собирает данные. Такие мы и знаем обычно. На последние (обычные) БД требования в основном — массовая обработка различных маленьких транзакций. Такие СУБД рассчитаны на то, что к ним сотни и тысячи пользователей коннектятся и выполняют несложные запросы параллельно. Так эти СУБД и проектируются. Например, чаще всего они построчно хранят записи.
СУБД для поиска знаний — это такие БД, где не ожидается, что будет сотня пользователей. На них возлагается другое требование. Часто, за ночь, например, перебрать все данные и найти знаний. Поэтому там нет таких сложностей с транзакциями. И часто данные в таких базах хранятся в файлах колонками. Что позволяет целыми колонками загружать в память и разбивать на куски алгоритмы более оптимально.
У нас был недавно случай, когда заказчик захотел логировать любые действия пользователя. Это нормально. Ненормально, что он в логах еще захотел, чтобы указывалась причина действий пользователя.
Эта штука должна быть в коде выражена. Грубо говоря, зачем он что-то делает, исходит прямо из места в ГУИ, где он находился, когда выполнял действие. Т.е. он делает всегда то, что позволяет программа. А значит, если он находится в каком-то месте, то это и надо логировать.
Если же делать окошко, где он выражает свои причины, почему так поступает — это говорит о том, что логика приложения не доработана. Что часть логики выносится на пользователя. И смысла в этом особого нет, т.к. причины могут быть любые и с ними потом нельзя проводить никаких операций. Их нельзя сортировать, делать осмысленные выборки в рамках описания самой системы.
Так что не надо фантазировать на счет того, что должна знать программа по поводу причин пользователей. Пользователь делает с программой то, что она позволяет. Как задумал программист. Вне этого ничего и не должно быть. Никаких больше догадок выносить за пределы логики программы нельзя.
Работал когда-то в школе, физику читал. А также в ВУЗе программирование. Я бы рад был, если бы было больше девушек, хороших специалистов. Но у них реально мозги не работают в эту сторону.
Есть исключения. Но они очень редки. На группу если одна хоть девушка хоть немного умеет соображать и пишет программы — это уже редкость. Настолько же редкость, насколько редкие парни, которые это не умеют.
И где это автор статьи видела много айтишниц? Работаю много лет в разных компаниях, программистку видел аж одну.
Вначале я до запятой, первый параметр массива написал так:
Convert.ToInt32(range.Item2 <= list.Count && range.Item1 < range.Item2)
Т.е. как раз условие, чтобы не вышли за пределы массива. И смоделировал потом сайнами. Но наверное конец рабочего дня, где-то ошибся. Точнее я смоделировал это условие так, как надо (надеюсь, не проверял только что), но то ли у меня четное (или нечетное) число элементов было, что проходил код. Решается эта бага замечательно. Вот в этой строчке надо так:
int midleIndex = (range.Item1 + range.Item2 — 1) / 2;
Если учитываем, что левая часть всегда не включается, то приводим рейджу с настоящими элементами.
Но кажется, я перемудрил. Если сделать поправку со средним индексом, то достаточно сделать такое условие:
Convert.ToInt32(range.Item1 < range.Item2)
прошу прощения за ошибки, если даже сейчас ошибаюсь. Все таки после рабочего дня немного не так соображается. Финальная версия, надеюсь верная:
как-то работает
Понятно, что можно добавлять 0.5, все в дабл конвертнется, а знак брать тогда тоже можно. И код даже проще будет. Но как-то не хотелось даблами пользоваться. Прихоть такая.
Внутри сайна есть ветвление и тоже это не очень чисто. А вот пользоваться массивом вместо ветвления и не называть его ветвлением — вполне честно. Понятно, что вызов такой его моделирует. Даже свич можно смоделировать. Но свич или иф — это структура кода, а здесь структура данных. Куда и функции примешались.
Наверное можно еще что-то сделать такое, что упростит этот код. С ходу не придумал.
Поломайте мозги.
Я для усложнения поставил себе задание — не использовать никакие ветвления и логические функции. На шарпе. Вот что получилось:
Конечно, я не показываю пример, как надо писать на шарпе. Надеюсь, кому-то станет интересно почитать такой функционально-матричный подход.
Рисует на листке галочку. Две искривленные линии. Не предупреждая. И показывает мне и говорит:
— Что ты здесь видишь?
— ??? Галку
Он вздыхает, кладет листок на стол и говорит:
— Из тебя ничего не получится. Это тест на креативность. Чем более креативный человек, тем более причудливые вещи здесь видит. Кто-то облако, кто-то сердечко, а кто-то даже лошадь. Некреативные люди ни на что не способны в жизни.
Потом, немного подумав говорит:
— Но почему-то все математики видят только галку
…
меня это рассмешило. Говорю:
— Так математики и видят галку, потому что нарисованный объект наиболее соотвествует галке. Точные науки тем и отличаются, что стараются опираться на объективную информацию. А те, кто коней видят, пусть видят — на хрен мне нужна такая креативность.
К сожалению, многие программисты себя представляют творцами. И вместо анализа требований и четких правил — «придумывают» архитектуры, «строят» каркасы, вместо «перевода требований на язык программирования». Как-то безумие ТП распространяется на все сферы жизни, включая и точные науки и программирование )))
И читать неудобно и раскомментировать очень опасно. Доверия коду, который месяц не компилировался — никакого. Проще действительно с нуля.
Постоянный рефакторинг и соответствие только текущим требованиям (всё остальное удаляется), позволяет держать код в относительной чистоте. Делать из файлов, где код, систему контроля версий — уже какая нечистоплотность с наглостью )))
У нас в проекте куча кода осталось в наследство. В БД где-то 1 к 6-ти кода который используется и кода, который вообще никому не известно что должен делать и используется ли. При этом разработка велась: авось понадобится. Если что-то не понадобилось, не удалялось. Если делали новую версию процедуры, старой добавляли в название Old
Можно провести некоторую аналогию — рефакторинг — это как уборка в квартире. Должна проводится постоянно. При меняющихся требованиях, меняется перестановка в квартире, ненужные вещи прячутся на чердак (балкон) и т.д. (система контроля версий). Все, кто так не делают, периодически ловят себя на желании переписать всё с нуля. Мол, дайте денег на новую квартиру, сто процентов больше мусорить не буду.
Один коллега недавно сказал одну вещь, мне показалась занимательной. Сказал, что если бы сейчас дали ему переписать систему, то она была бы просто супер.
Прослеживается аналогия с мусором и квартирой? Код не должен быть идеальным. Не должен быть абсолютно гибким. Код должен быть простым, соответствовать текущим требованиям. И быть в относительной чистоте, чтобы всегда была возможность перестроить под новые требования. И дополнительный функционал, который вдруг может понадобиться — не делает код более перестраиваемым. Наоборот. Дополнительный функционал — это дополнительные потенциальные баги. Это дополнительные издержки на поддержку и изменение тестов на него. И это дает гибкость только в предугаданном направлении, а в остальных сковывает
Думаю, возможность писать по разному и не связывать напрямую структуру кода и файлов — хорошая возможность.
Не так и напрягает создавать новый класс в новом файле. Иногда мелкие классы можно и в один впихнуть. Например, небольшие, имеющие одного предка и фабричный метод. Или перечисления.
Студия и так неплохо находит нужные классы, не обязательно отражать в файловой структуре
Далее, если все же очень неудобные имена — вторая мысль: стоит расширить глосарий в проекте. Нужен какой-то термин.
А завести табличку с называнием Attribute и с колонками что-то вроде Name, Value, Type можно.
Или делают денормализацию — лишние колонки, которые пользуют, как захочется потом и сколько надо. Или делают табличку, в которой общий тип текстовый или какой-то, которые приводят потом к чему хотят.
По сути, это подобный хак, как и в ООП (шарп, джава) со статической типизацей был бы. Просто в языках таких всё на хаках, кругом императивщина. Поэтому там не так заметно, когда язык выворачивают. Создают новое свое измерение для типизации.
Насколько я понимаю, моделируются просто, работают СУБД с такими вещами неэффективно. SQL плохо подходит.
Многие ко многим реализуются отдельной таблицей. Это не такой удар по предметной области. Просто помнить, что таблица не обязательно бывает сущностью, а может быть и связью. Иногда, эта связь по мере моделирования становится сущностью. Просто добавляются еще атрибуты. Поэтому суть размыта, где таблица связи и почему она не сущность.
Системы с произвольными атрибутами реляционно не реализуются. Но не согласен, что такие задачи сплошь и рядом. Представьте себе систему, написанную на объектно-ориентированном языке без БД. Аналог этой задачи — вы не знаете во время компиляции, сколько и какого типа полей у объекта будет. И вы будете формировать тип в рантайме. Еще тот фокус. Иногда надо. Но или на динамических языках пишут или просто пишут классы, которые будут потом атрибутами другого класса в списке, а им добавляют тип, который что-то вроде перечисления. Т.е. фактически не пользуются уже типизацей языка, а выворачивают его так, чтобы создать собственную динамическую типизацию.
Точно таким же хаком и в реляционной БД поступают, если такое нужно.