Парадокс демона таков: если демон Лапласа был бы создан, то он был бы материален. И если демон умел бы рассчитывать за 1 минуту состояние мира через 2 минуты от начала расчета, то он знал бы и своё следующее состояние (ведь он материален и является частью этого мира), таким образом он бы знал состояние мира через 3 минуты. Но зная состояние мира через 3 минуты, он знал бы и своё состояние, поэтому знал бы состояние мира через 4 минуты, и так далее. Получается, что за минуту работы демон Лапласа узнал бы всю будущую историю Вселенной.
Я, занимаюсь разработкой принципиально новой архитектуры процессора на реактивном (событийном) принципе. Мне кажется здесь пропущен важный момент в цепочке рассуждений. Причем это характерно для императивного мышления. Давайте рассуждать вместе со мной. Ибо есть об чем. Состояние мира (или памяти компьютера) это будем считать определено. Событие определим как изменение состояния. Думаю, это не вызовет возражений. Для определения события (изменения памяти) необходимо провести некий анализ. Т.е. в общем случае (философском) это анализ некого высказывания на истинность. В случае с памятью компьютера это анализ выражения. В обоих случаях это метаоперация. Т.е. семантически на другом иерархическом уровне семантики (Кому интересно Семантическая концепция истины . А. Тарский). Частным случаем этого факта метаоперации является использование конвейерной обработки переходов с операцией сравнения. Но, я хотел бы обратить ваше внимание на сам момент возникновения необходимости анализа! В императивной парадигме этот момент наступает при попадании команды сравнения в процессор. Это так естественно, что мы не обращаем на это внимания. Команды выполняются последовательно, ну и это аксиома. Хотя в мире (и в моей архитектуре компьютера) происходят изменения состояния параллельно. Вот классический пример высказывания "Снег белый". И что б убедиться в истинности этого высказывания мы должны проделать какие-то действия. Например, выглянуть в окно (выполнить адресацию). Как проводить анализ на истинность этого высказывания я не буду останавливаться. Я хочу обратить внимание именно на наличие еще одного факта который нас обязал выполнять анализ. Т.е. что необходим некий побудительный мотив для анализа состояния. (Я этот мотив назвал подписка). Это один пробел в цепи рассуждений о машине, но есть и второй. А есть ли смысл в каких-то действиях после того, как мы определим снег на белость? Ведь если нет, то может и не было смысла в нашем анализе. Так вот наличие смысла в анализе тоже определяется подпиской на результат анализа! Это второй момент. А теперь возвращаемся к демону Лапласа. Есть два логических пробела. А какое состояние мира заставило вычислить состояние мира через 2 минуты, и заставит ли новое состояние мира опять заниматься новым вычислением? Большая просьба, тех, кто не понял не минусовать. Ибо и так в минусах и не могу ничего опубликовать.
В тему совершенствования файловой системы, хочу обратить внимание что имена столбцов с типами это есть описание атрибутов класса. А каждая строка это объект класса. Некоторые методы визуализируются как вычисляемые. Таким образом, описание таблицы - это и есть описание класса. Содержание базы данных это массивы (один из видов группирования в моей терминологии) элементов класса. Получаем универсальное определение файла. Не везде содержимое файла именно массивы объектов. Случается и по одному элементу. Но, суть такая. Структура файлов это описание классов (отличных от системных) содержащихся в файле и далее сами объекты. (в группах либо по одному) Никаких расширений. JSON вещь хорошая, но есть и лучше предложения. Такой файл не нуждается в расширениях, можно загружать универсально и, если хорошо подумать, так же универсально визуализировать в различных видах, и, о чудо, универсально редактировать! А если еще лучше подумать то, эта же засада что загружает и редактирует становится и браузером и транслятором. Но, это еще надо добавить мыслей не в тему структуры файла, а в другой теме.
Что тут не понять? Ясный пень в ФБК работали не дети. Данные были выкрадены продажным сотрудником. И это заявила сама ФБК по результатам внутреннего расследования. С именем и фамилией предателя. И даже с суммой и на что потрачены тридцать сребреников. Эта тема чисто для обосрать и посеять сомнения. Предсказываю еще более глубокие минуса. Глядя как не нравится предыдущий мой пост. Ну, не нравится кому-то вера в то, что есть и порядочные люди и их большинство. И что это нормально.
Проблема высосана из пальца и решена сто лет назад. Конкуренция на рынке и наличие технически и юридически грамотного персонала. Если глав. врач берет откаты, то проблема политическая. Кто его там держит. В любом другом случае покупай оборудование там, где выгодно. Ну, и научись договариваться. Думать надо в любом случае. На то и голова дана.
Искусство не может быть напрасным. И не важно из чего. Композиторы из семи нот чудеса создают. Я вот над другим задумался. А правильно ли что мы при создании компьютера в логику уперлись? Интуитивно, да и опять же логично, а как же говорить за результат если без логики? Но, есть фундаментальный недостаток для эффективности компьютера работающего на логике. Логика последовательна. Мы не можем сделать вывод, пока не проанализируем предикат. Ну, и И/ИЛИ тоже дают результат на следующем шаге после анализа входов. Компьютер будущего должен работать параллельно. И обращаться к логике, тогда, когда это актуально. А актуальность вариативна. Т.е. анализ на актуальность можно (и нужно) распараллелить. Такой подход заставит писать "программы" не в длину, а в глубину. Да и программа будет состоять из "логичных" частей к которым мы будем обращаться по мере надобности. Ну, как мозг работает. Тут много плюсов возникает. Например, логичные части не надо по сто раз переписывать. Они не зависят от хотелок заказчика. Сори, это размышления на скорую руку. Но, есть чем продолжить. Если интересно.
Посмотрел. Интересно. Но, влияние классической архитектуры сильное. Практически тоже самое. У меня совсем другой принцип. Начнем с того что 4 вида адресации. И память на в виде массива, а множество концептов (объектов) единой структуры. Можно представить как граф с вершинами концептами, и ветвями-переходами подписками (адресация). Напоминает нейро сеть. Ну, и так же выполняется. Можно рассматривать вершины как перцептроны, а ветви-адресации как синапсы со значениями –параметрами в качестве значений. Классическая архитектура провоцирует написание программ «в длину». Предлагаемая архитектура предполагает формировать иерархическую систему, и заставляет мыслить более структурно. Как показывает практика, к этому надо привыкать Т.е. и команды и данные имеют единый формат и выполнение начинается с адресации.
1.Работа машины заключается в адресации концепта, инициирующие процессы, реализующие его внутренний функционал, и формирующий адресацию к внешним концептам, если они оформили эту адресацию в виде подписки на событие интересующее внешний концепт. Т.е. Инициация взаимодействия в руках внешнего концепта, с применением механизма подписок. При этом сам концепт сохраняет свою структуру и свой собственный функционал (иммутабельность).
2.Взаимодействие с концептом облегчается единой структурой и полной информацией о себе. Т.е. концепт полностью содержит в себе имена, хелпы, типы атрибутов и свой состав. Потому легко визуализируется при необходимости организовать с ним взаимодействие.
3.Т.е. Организация протокола и управления универсальна. Концепт представляет собой прозрачный «черный» ящик, о котором можно получить полную информацию и организовать взаимодействие.
4.При такой структуре легко организуется иерархическая структура, где верхний уровень использует функционал концептов нижнего уровня, сам при этом генерируя внешнее представления являясь концептом.
Соглашение об именах старо как само программирование. Я еще помню метки в ассемблерах м1, м2 и в VB6 там элементы управления должны иметь первые три буквы соглашения. Тут идея серьезней за расширение определения типа и влияние на формирование кода. Но, пока я писал я еще круче идею продумываю. В двух словах расширение типов, возможно, имеют свои отличия для взаимодействия с другими .. скажем так, понятиями. Может и их подвязать..
Если всё делать не тяп-ляп, то мне кажется, что может не хватить жизни одного человека, что-бы всё это закончить.
Так и не хватает. Хотя концептуально уже все есть. Но, на классической архитектуре работают миллиарды людей. И наработана куча методов и приемов. Хоть семи пядей во лбу все невозможно придумать.
а в языке должна быть возможность оптимизации кода, если его производительность оказалась недостаточной.
В классической архитектуре да. Я не особенно парюсь по этому поводу. Во-первых, я оставляю возможности для оптимизации самого процессора. Все предусмотреть не возможно. Пусть допиливают уже когда все стабильно заработает. Во-вторых, я больше надеюсь на распараллеливание. У меня можно в динамическом режиме добавлять сколько угодно процессоров, и, возможно, шин. А для того применения что я уже готов реально предложить вполне достаточно и существующих процессоров.
За типы хочу сказать. Я тоже за сильную типизацию, но статическая типизация меня не устраивает. У меня динамические вызовы и проверка параметров должна выполняться на лету. Я подумал что добавлять пользовательские типы можно непосредственно в имена. Допустим если мы хотим, как в языке ADA, создать пользовательский тип яблоки и тип ящики то определить их, допустим как байт, а в имя добавить какую-то букву со знаком что б случайно не сложить ящики с яблоками. Или не перепутать параметры в функции! По моему красивая идея. Идентификаторы начинающиеся с $А это яблоки, а $B это ящики)) И, проверка на типы это одно, а участвовать в выражениях это хрена!
Согласен. Кстати, цель она ж и подсказывает. И выбор становится понятным. А то аргумент "мне так понравилось" не убедительно звучит. Для чего морока с типами? Ну, и многое другое. Не зная цели не понятно стоит добавлять фишку какую-то или она лишняя. Ну, и заценить выбор нельзя со стороны. Автор, оно, конечно, автор. А все-таки соотносить надо с целью.
Привет! Я думал что я один такой сумасшедший. Я вот дольше тружусь. Больше 25 лет. Правда я и задачу себе поставил покруче. Создать новый процессор, под него систему и язык. Уж очень мне не нравится классическая архитектура. Прочитал внимательно обе статьи. Вопросов и замечаний и тем для пообщаться масса. Но, главный вопрос -" А есть ли смысл в оптимизации?". Неужто принципиально насколько быстрее/медленнее что-то выполнится? Если задача решается в приемлемое для пользователя время, то и бог с ним. Мне кажется важнее стоимость создания и сопровождение созданного программистом. А это время и сложность перехода от постановки задачи, до формулирования в терминах (языке) доступном для компьютера. Ну, и сопровождение. В смысле редактирования, отладка, изменение функционала при изменении ТЗ. И почти Булгаковское удовлетвори все хотелки заказчика в будущем. Вообщем, пиши. С удовольствием пообщаюсь. Достойный труд всегда уважаю.
Мне кажется, что этика и мораль это свод правил для человека основанный на опыте человечества для эффективного выживания и развития цивилизации. Основой этих правил предсказание будущего эффекта от тех или иных поступков человека. Т.е. в основе этих правил лежит предсказание будущего. Конечно, в статистическом смысле. Ибо производитель автомобиля как бы заранее виновен в том, что кто-то погибнет от его производства. Это я молчу за изобретателей оружия. Там вообще можно морализировать до бесконечности. Но, мой спич не о том. Для роботов нет, и не может быть морали, пока мы не наберем статистику что б решать как их действия отразятся на будущее. Правила Азимова просты, что б хлопать в ладоши, читать книги и снимать фильмы. Для практической реализации они мало пригодны.
Я сказал то, что сказал. Есть теоретическое определение арифметики Пеано. Однозначно правильная теория. Однако на практике мы можем ее применить к чему угодно. И тогда 2+2 у нас может оказаться не 4. Теорию надо еще правильно применять.
Все что вы написали это интересно, и даже познавательно. Однако я хочу отметить не правильное применение понятий. Теория это множество утверждений полученных из их подмножества утверждений называемых аксиомами, правилами логического вывода. Т.е. теория подтверждает сама себя, и больше ничего не нужно для утверждения теории. Она даже может не подтверждаться физическими опытами. Хотя это случается в случае ошибок в логическом выводе.
То, о чем вы написали это гипотезы, а не теории. Гипотезы, могут и не подтверждаться практикой.
Парадокс демона таков: если демон Лапласа был бы создан, то он был бы материален. И если демон умел бы рассчитывать за 1 минуту состояние мира через 2 минуты от начала расчета, то он знал бы и своё следующее состояние (ведь он материален и является частью этого мира), таким образом он бы знал состояние мира через 3 минуты. Но зная состояние мира через 3 минуты, он знал бы и своё состояние, поэтому знал бы состояние мира через 4 минуты, и так далее. Получается, что за минуту работы демон Лапласа узнал бы всю будущую историю Вселенной.
Я, занимаюсь разработкой принципиально новой архитектуры процессора на реактивном (событийном) принципе. Мне кажется здесь пропущен важный момент в цепочке рассуждений. Причем это характерно для императивного мышления. Давайте рассуждать вместе со мной. Ибо есть об чем. Состояние мира (или памяти компьютера) это будем считать определено. Событие определим как изменение состояния. Думаю, это не вызовет возражений. Для определения события (изменения памяти) необходимо провести некий анализ. Т.е. в общем случае (философском) это анализ некого высказывания на истинность. В случае с памятью компьютера это анализ выражения. В обоих случаях это метаоперация. Т.е. семантически на другом иерархическом уровне семантики (Кому интересно Семантическая концепция истины . А. Тарский). Частным случаем этого факта метаоперации является использование конвейерной обработки переходов с операцией сравнения. Но, я хотел бы обратить ваше внимание на сам момент возникновения необходимости анализа! В императивной парадигме этот момент наступает при попадании команды сравнения в процессор. Это так естественно, что мы не обращаем на это внимания. Команды выполняются последовательно, ну и это аксиома. Хотя в мире (и в моей архитектуре компьютера) происходят изменения состояния параллельно. Вот классический пример высказывания "Снег белый". И что б убедиться в истинности этого высказывания мы должны проделать какие-то действия. Например, выглянуть в окно (выполнить адресацию). Как проводить анализ на истинность этого высказывания я не буду останавливаться. Я хочу обратить внимание именно на наличие еще одного факта который нас обязал выполнять анализ. Т.е. что необходим некий побудительный мотив для анализа состояния. (Я этот мотив назвал подписка). Это один пробел в цепи рассуждений о машине, но есть и второй. А есть ли смысл в каких-то действиях после того, как мы определим снег на белость? Ведь если нет, то может и не было смысла в нашем анализе. Так вот наличие смысла в анализе тоже определяется подпиской на результат анализа! Это второй момент. А теперь возвращаемся к демону Лапласа. Есть два логических пробела. А какое состояние мира заставило вычислить состояние мира через 2 минуты, и заставит ли новое состояние мира опять заниматься новым вычислением? Большая просьба, тех, кто не понял не минусовать. Ибо и так в минусах и не могу ничего опубликовать.
В тему совершенствования файловой системы, хочу обратить внимание что имена столбцов с типами это есть описание атрибутов класса. А каждая строка это объект класса. Некоторые методы визуализируются как вычисляемые. Таким образом, описание таблицы - это и есть описание класса. Содержание базы данных это массивы (один из видов группирования в моей терминологии) элементов класса. Получаем универсальное определение файла. Не везде содержимое файла именно массивы объектов. Случается и по одному элементу. Но, суть такая. Структура файлов это описание классов (отличных от системных) содержащихся в файле и далее сами объекты. (в группах либо по одному) Никаких расширений. JSON вещь хорошая, но есть и лучше предложения. Такой файл не нуждается в расширениях, можно загружать универсально и, если хорошо подумать, так же универсально визуализировать в различных видах, и, о чудо, универсально редактировать! А если еще лучше подумать то, эта же засада что загружает и редактирует становится и браузером и транслятором. Но, это еще надо добавить мыслей не в тему структуры файла, а в другой теме.
Хочется думать что я не ошибся что хороших людей больше. Просто хамы активней минусуют. Вынесли в минуса. Ну, смотрите и радуйтесь на свой результат.
Что тут не понять? Ясный пень в ФБК работали не дети. Данные были выкрадены продажным сотрудником. И это заявила сама ФБК по результатам внутреннего расследования. С именем и фамилией предателя. И даже с суммой и на что потрачены тридцать сребреников. Эта тема чисто для обосрать и посеять сомнения. Предсказываю еще более глубокие минуса. Глядя как не нравится предыдущий мой пост. Ну, не нравится кому-то вера в то, что есть и порядочные люди и их большинство. И что это нормально.
Я не понимаю темы вообще. Даже если открыто лежит. Не твое-не трогай. Бывает что ширинка расстегнута. Зачем об этом много слов.
Проблема высосана из пальца и решена сто лет назад. Конкуренция на рынке и наличие технически и юридически грамотного персонала. Если глав. врач берет откаты, то проблема политическая. Кто его там держит. В любом другом случае покупай оборудование там, где выгодно. Ну, и научись договариваться. Думать надо в любом случае. На то и голова дана.
Искусство не может быть напрасным. И не важно из чего. Композиторы из семи нот чудеса создают. Я вот над другим задумался. А правильно ли что мы при создании компьютера в логику уперлись? Интуитивно, да и опять же логично, а как же говорить за результат если без логики? Но, есть фундаментальный недостаток для эффективности компьютера работающего на логике. Логика последовательна. Мы не можем сделать вывод, пока не проанализируем предикат. Ну, и И/ИЛИ тоже дают результат на следующем шаге после анализа входов. Компьютер будущего должен работать параллельно. И обращаться к логике, тогда, когда это актуально. А актуальность вариативна. Т.е. анализ на актуальность можно (и нужно) распараллелить. Такой подход заставит писать "программы" не в длину, а в глубину. Да и программа будет состоять из "логичных" частей к которым мы будем обращаться по мере надобности. Ну, как мозг работает. Тут много плюсов возникает. Например, логичные части не надо по сто раз переписывать. Они не зависят от хотелок заказчика. Сори, это размышления на скорую руку. Но, есть чем продолжить. Если интересно.
Можно считать азбукой!)
Мне всегда казалось что шахматы это скучно. Хоть и играл еще с детства и даже пробовал в уме играть в стройотряде. Не вставляло.
Посмотрел. Интересно. Но, влияние классической архитектуры сильное. Практически тоже самое. У меня совсем другой принцип. Начнем с того что 4 вида адресации. И память на в виде массива, а множество концептов (объектов) единой структуры. Можно представить как граф с вершинами концептами, и ветвями-переходами подписками (адресация). Напоминает нейро сеть. Ну, и так же выполняется. Можно рассматривать вершины как перцептроны, а ветви-адресации как синапсы со значениями –параметрами в качестве значений. Классическая архитектура провоцирует написание программ «в длину». Предлагаемая архитектура предполагает формировать иерархическую систему, и заставляет мыслить более структурно. Как показывает практика, к этому надо привыкать Т.е. и команды и данные имеют единый формат и выполнение начинается с адресации.
1.Работа машины заключается в адресации концепта, инициирующие процессы, реализующие его внутренний функционал, и формирующий адресацию к внешним концептам, если они оформили эту адресацию в виде подписки на событие интересующее внешний концепт. Т.е. Инициация взаимодействия в руках внешнего концепта, с применением механизма подписок. При этом сам концепт сохраняет свою структуру и свой собственный функционал (иммутабельность).
2.Взаимодействие с концептом облегчается единой структурой и полной информацией о себе. Т.е. концепт полностью содержит в себе имена, хелпы, типы атрибутов и свой состав. Потому легко визуализируется при необходимости организовать с ним взаимодействие.
3.Т.е. Организация протокола и управления универсальна. Концепт представляет собой прозрачный «черный» ящик, о котором можно получить полную информацию и организовать взаимодействие.
4.При такой структуре легко организуется иерархическая структура, где верхний уровень использует функционал концептов нижнего уровня, сам при этом генерируя внешнее представления являясь концептом.
Соглашение об именах старо как само программирование. Я еще помню метки в ассемблерах м1, м2 и в VB6 там элементы управления должны иметь первые три буквы соглашения. Тут идея серьезней за расширение определения типа и влияние на формирование кода. Но, пока я писал я еще круче идею продумываю. В двух словах расширение типов, возможно, имеют свои отличия для взаимодействия с другими .. скажем так, понятиями. Может и их подвязать..
Под Мультиклет подходит.
Не знаком за подробности. Можно пообщаться.
Судя по Википедии тоже автоматика, космос. И для ИИ отлично подходит.
Если всё делать не тяп-ляп, то мне кажется, что может не хватить жизни одного человека, что-бы всё это закончить.
Так и не хватает. Хотя концептуально уже все есть. Но, на классической архитектуре работают миллиарды людей. И наработана куча методов и приемов. Хоть семи пядей во лбу все невозможно придумать.
а в языке должна быть возможность оптимизации кода, если его производительность оказалась недостаточной.
В классической архитектуре да. Я не особенно парюсь по этому поводу. Во-первых, я оставляю возможности для оптимизации самого процессора. Все предусмотреть не возможно. Пусть допиливают уже когда все стабильно заработает. Во-вторых, я больше надеюсь на распараллеливание. У меня можно в динамическом режиме добавлять сколько угодно процессоров, и, возможно, шин. А для того применения что я уже готов реально предложить вполне достаточно и существующих процессоров.
За типы хочу сказать. Я тоже за сильную типизацию, но статическая типизация меня не устраивает. У меня динамические вызовы и проверка параметров должна выполняться на лету. Я подумал что добавлять пользовательские типы можно непосредственно в имена. Допустим если мы хотим, как в языке ADA, создать пользовательский тип яблоки и тип ящики то определить их, допустим как байт, а в имя добавить какую-то букву со знаком что б случайно не сложить ящики с яблоками. Или не перепутать параметры в функции! По моему красивая идея. Идентификаторы начинающиеся с $А это яблоки, а $B это ящики)) И, проверка на типы это одно, а участвовать в выражениях это хрена!
Согласен. Кстати, цель она ж и подсказывает. И выбор становится понятным. А то аргумент "мне так понравилось" не убедительно звучит. Для чего морока с типами? Ну, и многое другое. Не зная цели не понятно стоит добавлять фишку какую-то или она лишняя. Ну, и заценить выбор нельзя со стороны. Автор, оно, конечно, автор. А все-таки соотносить надо с целью.
Привет! Я думал что я один такой сумасшедший. Я вот дольше тружусь. Больше 25 лет. Правда я и задачу себе поставил покруче. Создать новый процессор, под него систему и язык. Уж очень мне не нравится классическая архитектура. Прочитал внимательно обе статьи. Вопросов и замечаний и тем для пообщаться масса. Но, главный вопрос -" А есть ли смысл в оптимизации?". Неужто принципиально насколько быстрее/медленнее что-то выполнится? Если задача решается в приемлемое для пользователя время, то и бог с ним. Мне кажется важнее стоимость создания и сопровождение созданного программистом. А это время и сложность перехода от постановки задачи, до формулирования в терминах (языке) доступном для компьютера. Ну, и сопровождение. В смысле редактирования, отладка, изменение функционала при изменении ТЗ. И почти Булгаковское удовлетвори все хотелки заказчика в будущем. Вообщем, пиши. С удовольствием пообщаюсь. Достойный труд всегда уважаю.
Исчезли все сразу, это вряд ли случайность. Но, мне такая закономерность нравится.
Мне кажется, что этика и мораль это свод правил для человека основанный на опыте человечества для эффективного выживания и развития цивилизации. Основой этих правил предсказание будущего эффекта от тех или иных поступков человека. Т.е. в основе этих правил лежит предсказание будущего. Конечно, в статистическом смысле. Ибо производитель автомобиля как бы заранее виновен в том, что кто-то погибнет от его производства. Это я молчу за изобретателей оружия. Там вообще можно морализировать до бесконечности. Но, мой спич не о том. Для роботов нет, и не может быть морали, пока мы не наберем статистику что б решать как их действия отразятся на будущее. Правила Азимова просты, что б хлопать в ладоши, читать книги и снимать фильмы. Для практической реализации они мало пригодны.
Я сказал то, что сказал. Есть теоретическое определение арифметики Пеано. Однозначно правильная теория. Однако на практике мы можем ее применить к чему угодно. И тогда 2+2 у нас может оказаться не 4. Теорию надо еще правильно применять.
Все что вы написали это интересно, и даже познавательно. Однако я хочу отметить не правильное применение понятий. Теория это множество утверждений полученных из их подмножества утверждений называемых аксиомами, правилами логического вывода. Т.е. теория подтверждает сама себя, и больше ничего не нужно для утверждения теории. Она даже может не подтверждаться физическими опытами. Хотя это случается в случае ошибок в логическом выводе.
То, о чем вы написали это гипотезы, а не теории. Гипотезы, могут и не подтверждаться практикой.