За недетерминированную машину и за не алгоритмы

Вместо ленты МТ машина Кузьмина представляет собой перечислимое множество концептов (ячеек) и порождаемое множество управляющих устройств (можно считать их головками, кому это удобно) назначение которых — адресация (активация) концептов. Номер концепта назывем адресом. Одна головка может адресоваться только к одному концепту.

Состоянием обладает не головка, а концепт. Наряду с понятием «состояние» иногда будем применять понятие «событие». Ибо событие это переход из одного состояния в другое и обычно именуется по названию нового состояния. Исходя из этого можем отметить сразу 5 событий концептов- адресация, адресация для чтения, адресация для записи, адресация для выполнения, адресация для инициализации. Устройства могут перемещаться (адресоваться) к любому концепту и порождаться подписками, как и концепты могут порождаться адресацией с инициализацией. По выполнению адресации устройство (шина) освобождается.

Работа машина заключается в адресации (активации) концепта и, возможно, изменения состояния адресуемого концепта (например, при адресации для записи). На этом функция головки завершается.

Каждый концепт может иметь подписки на события. Подписка это адрес (адреса, потому как может быть несколько подписок на одно событие) к которому осуществляется переход при активации концепта и при истинности соответствующего события. Таким образом, адресация концепта может породить лавину подписок.

Функционирование машины заключается в адресации концептов, которые остаются иммутабельными.

Управление конкретной машиной осуществляется добавлением/удалением подписок.

Программирование заключается в создании множества концептов и оформлении подписок для необходимого функционала.

У читателя правомерно возникает вопрос, а нахрена это все? Есть МТ. Найти невыполнимые задачи для нее согласно теореме о полноте затруднительно. И вообще нет проблем. А вот, однако, есть. Дело в том, что Маши́на Тью́ринга (МТ) — абстрактный исполнитель (абстрактная вычислительная машина). Была предложена Аланом Тьюрингом в 1936 году для формализации понятия алгоритма. А не все задачи удобны ( я не говорю разрешимы) для решения алгоритмами. И вот я хочу показать нечто новое. Название которому я дал А-ритмы. И вместо блок-схем А-схемы. Смотрим программу счетчика электроэнергии.

@ Byte (Interval, Count) Class ElectricMeter #Класс с параметрами времени в миллисекундах и счетчик суммирования"

New | {Timer T (Interval) ! | { Tick Timer.Start} # Создание таймера, создание подписки, сохранение счетчика."

{ ‘ Создание свойств

Byte Counter :: Count #Количество тиков таймера до секунды при инициализации"

:= -=1 #Ведем счетчик. При каждой записи вычитаем 1″

Null {Counter =Count) Value =(Voltage/Counter)* (Electricity/Counter)} #При событии 0, формируем счет и восстанавливаем значение счетчика. Как произведение средних значений тока и напряжения."

‘ Определение атрибутов Voltage, Electricity и Value

Float { Voltage := @( Float X ) Voltage += X # Суммирование значения при событии Write"

=: 0 # При чтении обнуляем счет."

Electricity := @( Float X ) Electricity + =X # Суммирование значения при событии Write"

=: 0 # При чтении обнуляем счет."

Value 0 ‘Начальное значение

:= @( Float X ) Value+ X #Значение счетчика наращиваем при записи«.

}

‘ По каждому тику ведем счетчик, читаем значение тока и напряжения по физическому адресу порта и суммируем

Void Tick :[Move Counter ,0 Move Voltage, «vvvv» Move Electricity ,"eeee«]

}

Объект создается из класса с параметрами значения интервала времени и значения счетчика (Interval, Count).

При создании объекта событием выполнение «|» запускается таймер с значением интервала.

Класс состоит из атрибутов Counter, Voltage, Electricity и Value назначение которых, соответственно вести счетчик тиков, значений напряжения, тока и значения энергии.

Функционал определяется событиями. Итак по порядку:

Счетчик Counter по событию инициализации "::«получает начальное значние (Count), при событии Запись «:=» (независимо от того какое значение записывается) вычитает 1 (т.е. Ведет счет) и по событию Null вычисляет значение для суммирования Value.

Атрибуты Voltage и Electricity при записи суммируют записываемые значения напряжения и тока и при чтении обнуляются. Событие чтения «=:» инициируется выражением по событию Null атрибута Counter

Атрибут Value только суммирует значения по событию запись «:=».

По каждому событию Tick одновременно (о чем говорят квадратные скобки) выполняется запись в атрибуты Counter, Voltage и Electricity.

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Найкращі коментарі пропустити

За недетерминированную машину и за не алгоритмы

— хороший тост

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

С самого первого поста по этой теме автор приводит, кажется, один единственный пример кода про этот самый счётчик (вбейте в поиск по форуму «Определение атрибутов Voltage, Electricity и Value» и найдёте их все).

В комментариях к этому посту, в кои-то веки, стал наклевываться ещё один пример, про сортировку, но тут выяснилось, что сортировки не будет, так как нет атомарного swap.

Возможно за пределами счётчика электричества there would be dragons, и ничего не работает...

Вы провели ошеломительную работу. Только зачем? Если вы разобрались в этом примере, могли б попросить еще.

При изучении питона мне не надо было просить примеры у Ван Россума, haskell выучил я без личных обращений к Саймонам (одному и второму), ocaml зашёл без личных обращений к Ксавье, и так далее.

Так что как-то даже в голову не пришло, представляете?

При изучении питона мне не надо было просить примеры у Ван Россума...

Почитай там список авторов и организации в которых они работали.

Какое это имеет отношение к предложению просить у автора языка примеры для изучения этого языка?

Какое это имеет отношение к предложению просить у автора языка примеры для изучения этого языка?

Прямое. Наличие времени. Что б придумать один пример, который демонстрирует какой-то момент надо 10 штук придумать и перепробовать. В работе и в коллективе это делается автоматически. Людей много, задач много. Только выбирай подходящее.

Я понял. Но если у вас на это нету времени (хоть и есть прямая заинтересованность), то откуда ж ему взяться у других?

Зачем рекламировать свой язык, у которого ни сайта, ни репозитория, ни доступной документации, и один пример кода вместо всего этого?

Зачем рекламировать свой язык, у которого ни сайта, ни репозитория, ни доступной документации, и один пример кода вместо всего этого?

А я советуюсь. Обсуждаю. Получаю замечания. За умные благодарю. Может кто-то что подскажет. А одновременно и рассказываю. Никаких тайных задач не стоит.

В бизнесе решает скорость разработки, затем дешевизна. Мощности ЭВМ уже не решают. RAM самый дешевый ресурс, а CPU постоянно дешевеют и мощнеют по закону Мура. Платформы типа .NET/Java работают медленно, зато бизнес-код на них пишется быстро. Вам задали вполне разумные вопросы о жизнеспособности разработки в контексте того, что вы представляете ее как некую революционную вещь. Если вы покажете реализацию типичных проблем народного хозяйства как альтернативу решению тех же проблем с помощью других средств как более «быструю», я вам буду аплодировать.

Если вы покажете реализацию типичных проблем народного хозяйства как альтернативу решению тех же проблем с помощью других средств как более «быструю», я вам буду аплодировать.

Именно так. Я ж и говорю в области автоматики и ИИ. И «быстрее» именно в этом смысле. Закон Мура только уже не работает. Тяжко стало удваиваться.

мощнеют по закону Мура.

Уже нет, закон Мура все. Уперся в физические константы.

Но а как же распараллеливание? Больше ядер на cpu, более параллельный код ? Больше кеш проца, быстрее шина памяти ?

А закон Мура тут при чем?

количество транзисторов, размещаемых на кристалле интегральной схемы, удваивается каждые 24 месяца.

Где здесь про кеш, параллельность, ядра и шину?

В следующем посте вы изложите доказательсво теоремы Ферма?

Навпаки, було б дуже корисно.
Можливо, вам вдалося б знайти значно простіше доведення.
Ну або принаймні спробували б свій інструмент на справді складній задачі — це була б дійсно вражаюча демонстрація.
До купи пропоную задачу трьох тіл, а якщо це дуже просто, то хоча б чотирьох.

До купи пропоную задачу трьох тіл, а якщо це дуже просто, то хоча б чотирьох.

Не вопрос. Если так нужно присылай 30 000грн сюда 5457 0822 2615 2226 я сразу же займусь. Торг не уместен.

А может это вам нужно людям доплачивать, за то, что они тратят время чтение вашей абракадабры?

Улыбнуло)) Извини, я советую ориентироваться по тем, кто понимает. И скромнее будь.

Мне кажется, автор перестал принимать прописанный ему врачом галоперидол.

Напиши задачи которые нормальным программированием не решаются, а решаются только твоим.

Напиши задачи которые нормальным программированием не решаются, а решаются только твоим.

Что значит «нормальным программированием»? Императивным? А декларативное программирование нормальное? Функциональное типа Lisp или Nemerle нормальное? А логическое типа Prolog? Я тебе просто напомню теорему о полноте МТ. А так как, моя машина вполне реализует МТ, то если задача решается МТ, то у меня тоже решается. Вопрос в возможностях и вкусах. Собственно, язык это инструмент. Как и любой инструмент он удобен для решения какого то класса задач.

Что такое теорема о полноте? О какой полноте идет речь? Вы дважды уже упомянули эту теорему, но нигде не даете ее утверждения.

То есть полнота по Тьюринга, оке. А что же тогда такое теорема о полноте по Тьюринга? И с чего это вдруг

У читателя правомерно возникает вопрос, а нахрена это все? Есть МТ. Найти невыполнимые задачи для нее согласно теореме о полноте затруднительно. И вообще нет проблем.

Невычислимых проблем — вагон и малая телега. То, что Вы с ними не сталкивались — это не значит, что они редки. Я Вам даже больше скажу — их бесконечно раз больше, чем вычислимых проблем. Любая невычислимая функция, любое невычислимое число (это частный случай невычислимый функций) — примеры невычислимых задач. Их комбинации также будут скорее всего невычислимыми задачами. Еще примеры: задача Остановки, Колмогоровская сложность, константа Хайтина и другие.

Та в курсе за невычислимые. Не правильно сформулировал ответ. Спасибо за замечания. Приятно, что появились знающие люди. А то начал на автомате агрессивно отвечать. Малость достали «специалисты». Если кто-то понял об чем речь, я уже не напрасно писал. Спасибо. Я исправлюсь)

Наверное люди хотят увидеть пример решения прикладной проблемы этим подходом. Мне тоже будет интересно, честно, но чтобы рядом была имплементация на уже знакомых подходах.
Мне это напомнило модель акторов (actor model) либо же что-то вроде EAP (event-oriented programming). А так в целом не совсем понял тоже 8)

Я понимаю. И благодарен всем за критику и примеры. К сожалению, я ж как то работаю и глубоко вникать во все вопросы не могу. Давайте устроим конференцию. Вы подготовите вопросы, я тоже подготовлюсь и часик-другой пообщаемся. Так будет проще и понятней, чем урывками писать..

Несколько раз пытался понят как оно должно работать. Сдался. Даже brainfuck выглядит понятнее

Несколько раз пытался понят как оно должно работать. Сдался.

Да. Сильно отличается. Надо мозги настроить по другому. Но, именно так работает и сам мозг да и реальные физические процессы. Не в подряд команда за командой как в программе написано)) Потому для автоматики и ИИ это самое то, что нужно.

Не в подряд команда за командой как в программе написано))

А чем Simula, Erlang и Akka не угодили?

Тому що чим робиратись в чужому, краще вигадати своє. І нехай вже інші розбираються.

brainfuck повний по-тюрінгу доречі.

За недетерминированную машину и за не алгоритмы

— хороший тост

Как раз при первом знакомстве с родственниками невесты.
При удачном стечении обстоятельств и странной реакции на тост оно же станет последним

Я правильно розумію, що це все — en.wikipedia.org/wiki/Actor_model, тільки незрозумілими словами і з ім’ям автора?

Я правильно розумію, що це все

Не правильно. А вот какие слова тебе не знакомы? Адресация? Подписка? В твоей ссылке больше не знакомых слов. Моя работа ближе к фундаментальным понятиям. Да и термин всего один. Подписка. Все что ты показал это легко следует из моей работы. А вот наоборот сказать нельзя.

машина Кузьмина представляет собой перечислимое множество концептов (ячеек) и порождаемое множество управляющих устройств (можно считать их головками, кому это удобно) назначение которых — адресация (активация) концептов. Номер концепта назывем адресом. Одна головка может адресоваться только к одному концепту.

В перекладі на людську мову з «концепт» (ячейка пам’яті), «головки» (актор?), «активація» (звернення до пам’яті),

Устройства могут перемещаться (адресоваться) к любому концепту и порождаться подписками

«Актори можуть отримувати доступ до будь-якої ячейки пам’яті і створюватись підписками.»

Але так усім зрозуміло, нічого нового-цікавого, і нема що назвати іменем себе улюбленого.

Моя работа ближе к фундаментальным понятиям

Extraordinary claims require extraordinary evidence.

«головки» (актор?)

Потік виконання.
Наскільки я розумію, відносно акторів тут:
1) ослаблені умови, а саме, код з одного концепта може по шині даних напряму лізти в пам’ять іншого концепта. Про race conditions автор не розуміє, чи не хоче розуміти.
2) замість надсилання меседжів конкретному адресату використовується підписка. Наскільки легко читати код через observer’и хто робив той знає.

1) ослаблені умови, а саме, код з одного концепта може по шині даних напряму лізти в пам’ять іншого концепта. Про race conditions автор не розуміє, чи не хоче розуміти.

Забудь про свои акторы. никакой код никуда не лезет. Актор и головка разные вещи. За сообщения тоже забудь. В этом и прелесть, что на другой концепт ничего не передается. Только активация. Задолбали, если по честному своими акторами.. Уже раз 200 сказал что ничего подобного.

В этом и прелесть, что на другой концепт ничего не передается. Только активация.

А в примере с сортировкой массива концептов когда активированный концепт меняется значением с соседним концептом — он тоже к соседу не лезет? Запись значения — это активация, и смена концептов местами — это тоже активация? И это активация двух сразу? И во время активации у них старые или новые значения?

А в примере с сортировкой массива концептов когда активированный концепт меняется значением с соседним концептом — он тоже к соседу не лезет?

C кодом не лезет. Только адресация с параметром. А функционал только тот, что задан подписками. Для безопасности это огромный плюс. А извне адресация умная. Внутри тоже. Но, бонус в том, что снаружи без этого «ума» хрен адресуешься.

Ну вот пример с сортировкой, да?
Есть массив концептов со значениями от 0 до 100. Сортированный изначально. Есть подписки на изменение значения концепта, которые меняют его местами с соседом, если он оказывается не на своем месте в порядке сортировки (это было вот тут dou.ua/...​campaign=31012022#2335351 ). Есть параллельно работающие шины, которые выполняют действия по подписке.

Итак, меняем местами значения концептов 0 и 100. Подписки срабатывают, и массив начинает самопересортировываться в 2 потока: 0 сам ползет из конца в начало, 100 ползет из начала в конец. И все бы ничего, но у массива есть средний элемент. И тут начинается самое интересное:
[..., 49, 100, 50, 0, 51, ...]
Элементы со значениями 100 и 0 по подписке одновременно видят, что они не на своем месте и одновременно меняются местами с элементом 50:
[..., 49, 50, ?, 50, 51, ...]
Вот что там будет вместо ? это как повезет, но у нас в массиве уже 2 элемента со значением 50. Хотя изначально такой был 1.

Итак, меняем местами значения концептов 0 и 100. Подписки срабатывают, и массив начинает самопересортировываться в 2 потока

Вообще говоря, не в два потока, а число потоков растет в степени 2, если требуется перестановка.

Вот что там будет вместо ? это как повезет, но у нас в массиве уже 2 элемента со значением 50. Хотя изначально такой был 1.

Не важно что там будет, после перестановки будет повторная проверка.

Не важно что там будет, после перестановки будет повторная проверка.

в смислі не важливо? одне число пропало, друге роздвоїлось — дані зіпсовані, толку там вже щось перевіряти.

И тебе спасибо! Предлагаю конференцию сделать.

Это все неважно. Это вы не понимаете просто.
Что важно — что это Машина Кузьмина.

Ну, как. Там очень недолго в центральной ячейке будут 100 и 1 одновременно (но ёмкость же до 255, они поместятся), а слева — 50, и справа — тоже 50.

На следующем такие 1 меняется местами с левым 50, 10 меняется местами с правым 50, и все снова ок: по центру у нас 50, слева 1, а справа — 100! Элементарно же!

Ну, акторы знают все, а ваши определения знаете только вы :) Без обид, но концепция не понятна. Можно аналог какой-то реализовать на любом из популярных языков рядом? Java/C#/JS/C++ ?

Та никаких обид. Даже наоборот моя искренняя благодарность. Если что-то не понятно, то я ж в основном и виноват. Потому предлагаю сделать конференцию, для вопросов и ответов. Если будет хотя бы пять человек, то сделаю отдельную тему для вопросов. Это будет правильно. Ибо отвечать урывками это не уважение к интересующимся.

Актор и головка разные вещи.

Актор — це концепт. У вас тупо актори. Я можу перекласти вашу мову на акторів — усю)

на другой концепт ничего не передается. Только активация.

Навіть якщо так — у акторів теж не обов’язково щось передається у обробник події, він може бути і без параметрів. Тільки чому б не передавати ще якісь іммутабельні параметри?

І от звідки у вас у запису

Float { Voltage := @( Float X ) Voltage += X # Суммирование значения при событии Write"

береться Х, якщо нічого не передається? Наче типова подія із параметром.

Актор — це концепт. У вас тупо актори. Я можу перекласти вашу мову на акторів — усю)

Объясняю разницу. У меня все что есть в машине-концепты. Названо так по единой структуре. И данные и инструкции это тоже концепты и единой структуры. Изначально я их называл объектами. Философски это правильно. Но, надо было подчеркнуть отличие. А отличие в том, что концепты обладают субъектностью. И могут проявлять инициативу. Все, что в машине-единой структуры. Это принципиально потому как единая структура позволяет ориентироваться снаружи о содержании. В частности обращаться и формировать адрес. И, следовательно управлять. Обращаем внимание на название машины. Там есть слово «Управляемая». Это принципиально. И скорее слово «Актор» более искусственное чем концепт.

береться Х, якщо нічого не передається? Наче типова подія із параметром.

Принципиальная разница. Событие это понятие имеющее самостоятельный семантический смысл. У него нет параметров. К событию могут быть оформлены подписки, вот подписки могут иметь параметры для адресации концептов. Кстати, предусмотрена динамическая проверка на тип параметров и даже проверка сигнатуры.

Float { Voltage := @( Float X ) Voltage += X # Суммирование значения при событии Write"

Это пример концепта Voltage в котором определен параметр необходимый при его адресации для записи. При адресации этого же концепта Voltage для чтения, это значение, кажется обнуляется. Событие происходит в другом месте. В том, где происходит операция присваивания, или команда Move. В железе это происходит адресация, а потом на шину выставляется значение. Которое тоже концепт и идет с типом.. По которому и идет проверка. Т.е. при разной адресации запускаются разные подписки. Подписки в широком смысле. Не обязательно ж там чисто адрес, а может стоять группа команд или адресов.

Так а в чому у акторів функціонально не так? Так, щоб це можна було б перевірити, а не філософськи. Можна сказати, що все є концепт, бо це концептуально, але концептуально — це значення не має.

Там есть слово «Управляемая». Это принципиально.

А актори — некеруємі, ага) Бо слова нема. Все там гаразд, можна підписуватись, відписуватись кому треба на шо треба і коли треба.

Это пример концепта Voltage в котором определен параметр необходимый при его адресации для записи.

Це приклад актора Voltage. Його обробник події «запис» має необхідний параметр.

При адресации этого же концепта Voltage для чтения, это значение, кажется обнуляется.

При виконанні обробника події «читання», цього ж актора, це значення, здається, обнуляється.

Событие происходит в другом месте.

Ну як і у акторів — подія десь там, але вона викликає низку реакцій у підписників.

группа команд

— це нове у вас поняття. Що таке команда? До чого вона доступ має?

значение. Которое тоже концепт и идет с типом.

У акторів теж можна іншого актора через подію передати. І можна одне значення у актора загорнути. Тільки зазвичай так само не треба і тільки збивати з толку буде, як і тут.

Кстати, предусмотрена динамическая проверка на тип параметров и даже проверка сигнатуры.

А чому не статична? Ну, як воно для акторів у типізованих мовах. Зручніше ж. А то може якась адресація вкрай рідко буде і її не протестять. Навіть реалізовувати цю перевірку не обов’язково.

Знаешь кого занудой называют? Кому легче отдаться чем объяснить что болит голова. Называй Акторами. Мне уже надоело объяснять.

А чому не статична? Ну, як воно для акторів у типізованих мовах. Зручніше ж. А то може якась адресація вкрай рідко буде і її не протестять. Навіть реалізовувати не обов’язково.

Потому что машина управляемая и адресацию и подписки можно оформлять извне. Нет этапа трансляции и связывания адресов. Параметры тоже концепты и идут вместе с типами, и могут тоже подписки иметь. Это другая архитектура машины, а не пакет разработанный коллективом в 100 человек и весом в 200 мб. У меня система занимает 14 кб. А транслятор сейчас 70кб. Разницу ощутил? Сдуру можно собрать и 1000 программистов и написать чего-то покруче. Я говорю что моя система проще!!!

Мне уже надоело объяснять.

Так ви ж не пояснюєте — ви тільки понтуєтесь і кажете «ні, там все не так, там все гарно».

Разницу ощутил?

Між чим і чим, що ті системи вміють і ваша? Робить ваша зараз приблизно ніфіга, на відміну від. Незалежних оцінок, описів і порівнянь її нема, на відміну від. Вона може хоч 0 займати. Є емулятор якийсь скачати погратись/потестити? Є доки, тести, приклади? Дебажити її як?

выставляется значение. Которое тоже концепт и идет с типом.

До речі, як це узгоджується із

на другой концепт ничего не передается

Коли ви отут передаєте концепт X у концепт Voltage?

Коли ви отут передаєте концепт X у концепт Voltage?

Void Tick :[Move Counter ,0 Move Voltage, «vvvv» Move Electricity ,"eeee«]
Команда Move Voltage, «vvvv» читает значение с порта «vvvv» и записывает по адресу Voltage чем порождает событие адресации с параметром. Эта команда находится в группе команд в квадратных скобках(параллельного запуска) запускаемой по событию Tick

Цікаво, чим зараз займається автор бази даних FVMas?
www.sql.ru/...​er-baz-dannyh-chto-dalshe

Ох, у меня прямо олдскулы свело.

Очень показательный кстати топик. Тоже все начиналось как «моя СУБД самая СУБД, ораклу до неё далеко, моя в 10 раз быстрее, и шифрует на ходу и вообще».

В конце концов автор выложил что-то для «пощупать» и оказалось, что это библиотека на С, которая умеет читать и писать файлы в самопальном формате и итерироваться по их записям, и все.

«Практика — критерий истины» и все такое

«Практика — критерий истины» и все такое

Вы не точно цитируете и теряете смысл.
Общественная практика-критерий истины. Т.е. практика не ограниченная ни во времени, ни в личностях. Так, например, Ваша личная практика не есть критерий.

Равно как и ваша, да?

С точки зрения читабельности человеком это поделие прямо кричит «убей меня, сожги, а пепел высыпь курам»

бо цап-відбувайло це не їстиме, будуть кури

Согласен что не привычно. Как мозги станут на место будет легче чем обычное программирование. Хотя это при наличии мозгов. )) Конечно, писать команду за командой можно не напрягать этот орган.

Ну вот одна из основных идей, которые вывели на лидирующее место сначала Джаву, а затем — Питон — это что мозги нужны для понимания задачи и поиска алгоритма ее решения, а не для борьбы с кодом и рантаймом.
Чем меньше мозгов тратишь на язык — тем больше их останется на что-то полезное: в частности чтобы сделать то, ради чего ты за компьютер садился, и за что заказчик деньги платит.

а затем — Питон — это что мозги нужны для понимания задачи и поиска алгоритма ее решения, а не для борьбы с кодом и рантаймом.

Все правильно. Для того и привел пример счетчика электроэнергии. Куда уж проще. Вот попробуй решить ее на питоне или жаве. Да хотя бы алгоритм попробуй нарисовать. И увидишь как проще. Не говоря уже за интеграцию. Подключение моего счетчика вывести показания куда угодно доступно даже пользователю. Всего то подписаться на событие Value.Change и хоть в облако. До 16-ти пользователей в текущей реализации)) Интегрируй все что хочешь и какие хочешь приборы вообще без программирования. А тебе надо будет написать программу, добавить туда код счетчика, оттранслировать вместе и создать загрузочный файл что б связать адреса. А у меня все устройства работают самостоятельно в распределенной сети и не требуют вообще никакого вмешательства. Можно даже удаленно создать необходимые подписки и система заработает как хочешь сейчас.

Для того и привел пример счетчика электроэнергии. Куда уж проще. Вот попробуй решить ее на питоне или жаве.

А разве это не банальное AOP? Что там сложного, это же не реальное время с unknown side effects.
www.baeldung.com/spring-aop
docs.spring.io/...​pect-oriented-programming

А разве это не банальное AOP? Что там сложного, это же не реальное время с unknown side effects.

Было б странно, если б я в качестве примера предлагал сложное. Но, ты попробуй сделать проще..

На Жабе не решишь, потому что используемые контроллеры не потянут жабу. А вот на С, а то и на ассемблере — пожалуйста.

Чисто с формальной точки зрения на жабе — говно вопрос. Просто чтобы поднять окружение Жабы нужно больше ресурсов, чем есть у контроллеров. Хотя некоторые версии жаб вроде мобильной для древних телефонов — достаточно скромны. Но против С они так себе.

Система строится из 2-х уровней. Нижний пишется на С и/или ассемблер и реализует концептную машину. Там не много. 16 типов данных, 16 команд и 16 событий работающих с концептами. Архитектура тоже не сложная. Описание в начале топика. Структура концептов единая. Так что не очень сложно. Нижний уровень грузит уже все определения, и концепты для выполнения верхнего уровня. Так что верхний уровень не зависит от типа контроллера. Вся разница в верху. Транслятор и отладчик работает с верхним уровнем. И двоичный код в этом же формате. Прошлая версия верхнего уровня системы вместе с хелпами и текстами была 14 кб. Если убрать хелпы и текст будет вообще 1,5 кб. А это можно сделать ибо все ж есть на отладчике.

На гітхабі є?

Меня там никогда и не было. А так же на сайтах поисков работы.

Как мозги станут на место будет легче чем обычное программирование.

Боюсь, что в этом суть разработки языков программирования — чтобы людям было понятно. Машина поймёт (при помощи программиста) что угодно, что можно формально детерминировать. А вот переделать людей — задача тяжёлая и безнадёжная с точки зрения дохода.

Вон, посмотри как долго людей с русского на украинский переводят. Три десятилетия. Правда 1 не очень умный человек буквально за несколько месяцев сделал то, чего граммарнаци не смогут и за 100 лет, но с программированием так не работает.

Если порог входа высокий, считай это дело неподъёмным. Странно, что это не было проверено сразу ещё до начала разработки. Сам не знаешь — спросил бы, понинтересовался, что определяет популярность.

Ты прав. Но, из того что будут трудности и понадобится много времени не следует что не надо делать, если это перспективное дело. Я начинал программирование очень давно и знаю как тяжело идет перенастройка мозгов. И понимаю проблемы. К тому же есть еще одна проблема коммуникативности. Личная. Вот смотрю на блогеров и удивляюсь. Как они могут часами трепаться ни о чем перед микрофоном и камерой наедине высасывая темы из ничего.

надо делать, если это перспективное дело

В том-то и дело, что если.

В том-то и дело, что если.

Вот это к чему? Есть аргументы так говори. Таких Кассандр здесь как ... Ну, много здесь таких..

Я объяснил: с точки зрения экономики требование переучить людей — самое дорогое из возможных. И чем глубже требуется переучивание, тем дороже это стоит, и в ответ на линейный рост количества убитых священных коров зарплата растёт квадратично.

Грубо говоря, на твой продукт нет потребителя. Людям как биологическому и социальному виду он не подходит. Если считаешь иначе — найди хотя бы второго пользователя.

Я объяснил: с точки зрения экономики требование переучить людей — самое дорогое из возможных. И чем глубже требуется переучивание, тем дороже это стоит,

Опять ты прав, но бизнес модель другая. Достаточно 3-4 инженеров для разработки линейки устройств. Так они по ходу и научатся. И на рынок железо предложить. С совсем другим уровнем возможностей чем кто-то в мире может предложить. А как быстро освоят подход остальные программисты это следующий этап. Как я уже говорил за пару лет вполне реально выйти на мировой рынок. Но, пару лет надо будет потрудится.. Или год. Пока первые доходы пойдут.

Или ничего не делать — чем не вариант? Повторюсь, твой подход не подходит людям не потому что неправильный. Неправильные люди. Их мозги уже шаблонированы естественными языками, и десятилетиями их изучения и ежедневного применения. Потому все «птичьи» языки — убыточны.

Концепт надо было начинать не с теории графов, а с того, что хотят люди. Потому что денег могут дать только люди. Да, это неправильно. Но деньги.

Можете описать фундаментальные алгоритмы на вашем языке ?
например, quick sort, binary search, bubble sort, deykstra etc ?

Ну, могу интересное что-то сделать. Что б была разница заметна. Тут такая фишка что визуально текст воспринимается по старой привычке. Потому надо сначала азы рассказать, и потом примеры. Предлагаю конференцию сделать. Просьба высказаться на эту тему.

— Утром bubble sort, вечером — конференция.
— А может наоборот?
— Можно! Но bubble sort вперед

Где хранятся невыполненные активации?
Поясняю:
Есть Концепты А1 и А2.
Есть остальные концепты Бх для х от 0 до У.
Каждый концепт класса Б при создании подписывается на изменения обоих концептов класса А. Обработчик подписки изменяет один или оба концепта класса А.
В результате как только концепт А1 или А2 изменится, очень быстро начнет расти количество запланированных на будущее активаций концептов группы Б, и каждая из этих активаций будет добавлять еще У активаций в запланированные.

Не так работает.))

Где хранятся невыполненные активации?

Нигде не хранятся. Активация это факт адресации к концепту и больше ничего.

Каждый концепт класса Б при создании подписывается на изменения обоих концептов класса А

Не так. Подписка как бы имеет две стороны. Первая сторона -это событие которое его запускает. Т.е. не концепт, а одно из событий этого концепта. Причем анализ на событие происходит при активации. Нет активации-ничего не происходит. Вторая сторона это адрес концепта который активируется по истинности события, на которое есть подписка. Если событие произошло, у него нет подписки, то ничего не происходит. Именно такая схема позволяет управлять функционалом, не изменяя концепт. Срабатывание идет не по возникновению события, а по наличию подписки у этого события. Сторонний концепт, может организовать подписку к событию конкретного концепта, но не может его изменить. И активировать созданной подпиской только свое состояние. Т.е. организовать синхронизацию с каким то событием стороннего концепта. Правда с параметрами)). Мы далеко ушли, хорошие вопросы. За структуру концепта я еще не говорил. Но и так понятно, что у концепта есть атрибуты, императивная часть и события. Из изменяемого только атрибуты. Активаций будущих не бывает)) Но, тупо организованный подписки способны начудить. Так можно и программу с дуру зациклить. Есть такая тема «отладка» называется)

Ну вот 100 концептов подписаны на изменение одного концепта. И в обработчике подписки каждый из них еще раз меняет этот самый концепт, на который он подписан. Что будет? Все 100 одновременно его поменяют, каждый по-своему, или они выстроятся в очередь, пытаясь его изменить? И когда каждый его изменит 1 раз в рамках соей подписки, получится что было 100 изменений, и теперь каждый концепт по подписке должен активироваться еще 99 раз.

Все 100 одновременно его поменяют, каждый по-своему, или они выстроятся в очередь, пытаясь его изменить?

Да давно понял твой вопрос. Могу даже обобщить до уровня самовозбуждения. Ты не понял мой ответ. События имеют семантический смысл. Это первое. Т.е. Не любое изменение состояния порождает событие. Например, событие можно определить как сравнение значений двух атрибутов. Ясный пень что не любое изменение этих атрибутов порождает это событие. Хочу заметить, это один из фокусов что позволяют параллелизм. Как бы есть оправданная надежда что формулировка событий имеет какую-то цель, которая фильтрует не содержательные изменения состояния. Второй уровень фильтра-подписки. Даже если событие произошло, если нет подписки ничего не происходит. Потому самовозбуждение лавины запросов возможно только при не правильной формулировке событий и подписок, задача которых в режиме параллельной работы не реагировать на не интересующие изменения.

Так вот вопрос же — где хранится лавина среагировавших, но не выполнившихся подписок?
Если поняли вопрос — почему не хотите ответить?

Так вот вопрос же — где хранится лавина среагировавших, но не выполнившихся подписок?

Ответил. Нигде не хранится. В самой архитектуре заложено. Загляни еще раз. После адресации и активации шина освобождается. Анализ на события (состояние) не меняет содержимое памяти по этой причине может выполняться параллельно. Не выполнившиеся подписки это фактически адресации. Вот там, где были там и хранятся. Просто на них не передается адресация для выполнения.

Ну когда событий произошло 100 одновременно, и каждое требует активации данного концепта — сколько раз он активируется?

Ну когда событий произошло 100 одновременно, и каждое требует активации данного концепта — сколько раз он активируется?

Естественно, что тоже 100. У меня подозрение что у тебя есть задача, которую ты формулируешь в терминах акторов. У тебя мозги настроены на этот инструмент, а у меня на мой. Давай плясать от задачи. Так будет легче прийти к пониманию и вопроса и ответа. Ты даешь задачу, я рисую решение в моей парадигме.

Я захожу не от задачи, а от поиска проблем. Как только мы нашли проблему, и придумали ее решение — то начинаем лучше понимать, зачем нужен инструмент. А вот если проблем не нашли — то скорее всего, плохо искали.

Я захожу не от задачи, а от поиска проблем.

Имеешь право.

Если поняли вопрос — почему не хотите ответить?

Я продумал эту архитектуру вплоть до реализации в железе. Потому иногда переключаюсь с железячной терминологии адресация, освобождение шины на программную. Активация, освобождение. Так что, извини. Спрашивай дальше. Я буду стараться отвечать.

Спрашиваю дальше. Сколько концептов одновременно поддерживается железом? Сколько активаций одновременно поддерживается железом?

Сколько концептов одновременно поддерживается железом?

Этот зависит от размера памяти, столько и концептов. Ибо

Сколько активаций одновременно поддерживается железом?

Сколько шин памяти столько и максимально концептов может адресоваться.

Ну вот а что делать, когда одновременно сработало больше подписок, чем есть шин памяти? Кто разрулит эту ситуацию и как?

Ну вот а что делать, когда одновременно сработало больше подписок, чем есть шин памяти?

Ты не отследил порядок. Пока нет адресации нет и анализа на событие. Такого не может быть.

ну кто-то адресовал (изменил) что-то. А на это что-то подписаны 1000000 концептов. Что будет?

ну кто-то адресовал (изменил) что-то. А на это что-то подписаны 1000000 концептов. Что будет?

Ты опять за рыбу гроши. Адресуется концепт. Состояния на которые можно подписаться, имеют семантический смысл (имя), называются событиями. Не все состояния определены как события, а избранные. допустим превышение верхней или нижней границы, размер или еще что-то называемые событиями. Обычно определение события имеют вид выражения над атрибутами. Так вот подписка осуществляется не к концепту, а к событию. В общем случае подписка осуществляет адресацию к контенту какого-то концепта представляющих исполняемую группу концептов и, возможно, с параметром. Хотя возможно и к атрибуту или к событию, которые тоже являются контентом, какого-то (или этого же) концепта. Если в активированном концепте произошло событие имеющее 100000 подписок, то теоретически все одновременно должны адресоваться. Но, не уверен, что в настоящее время существует память со столькими шинами. Но, принцип реализуем если подключенные концепты по интерфейсу Lan или другому. Кстати, это принцип универсального протокола в моей системе. Прерывания не нужны. По протоколу сразу идет адресация концепта. Считай по прерыванию (без прерывания) приходит вектор прерывания и сразу по нему идет адресация. Просьба отличать к чему подписка (событие) и что подписано (адрес перехода).

Ну так весь же вопрос — что оно на практике будет делать, когда шин не хватит?

Ну так весь же вопрос — что оно на практике будет делать, когда шин не хватит?

Боюсь показаться не оригинальным. Но, как вариант, можно поставить в очередь))

Так вот где эта очередь, кто ею управляет, и как система начинает себя вести, когда эта очередь переполняется?

Так вот где эта очередь, кто ею управляет, и как система начинает себя вести, когда эта очередь переполняется?

Не понял. Это что проблема? Классика жанра. Как у обычных компьютеров. Стек, свопинг..

Стек и свопинг — это операционая система, а не железо. А тут предлагается все такое в железе. Вот как оно в железе должно работать?

Аналогично)) Система предусматривается. Вопросы распределения памяти, создания и удаления концептов. Управление подписками. Система команд. Структура концепта, описание типов данных.. Там не очень много, но система есть. Собственно, это основная часть моей работы. Как и транслятор. Все настраиваемое. И типы данных и система команд. Потому необходимо описание всей этой чепухи.

Ок, только там много человеко-лет работы обычно.

Теперь зайдем с другой стороны. Есть счетчик квартиры, на нем видно потребление. Есть четыре датчика расхода электричества на разных фазах. Датчики подписаны на общие часы. Каждую секунду часы щелкают, все четыре датчика получают нотификацию и начинают одновременно добавлять к значению счетчика то, сколько данный датчик насчитал расхода за секунду.

Счетчик будет работать корректно?

Ок, только там много человеко-лет работы обычно.

Так я и работаю не один десяток лет. Если б ты видел первый вариант)) Там еще теги были..

Есть четыре датчика расхода электричества на разных фазах.

Если это проверка, то зря. Зачем 4 датчика. Для трехфазного лишнее и вообще так не делают. Умное слово нотификация вообще неуместно. Если хочешь сделать, я расскажу как надо.

Нет, я про ru.wikipedia.org/wiki/Состояние_гонки
И я не хочу сделать — я подсказываю, почему идея окажется нерабочей после того, как уже будут вложены деньги и силы в железо.

Спасибо, конечно, за заботу. Но, математических и концептуальных проблем у меня нет.

Ну тогда будет физическая проблема. Когда в каждой квартире стоит свой счетчик, а в доме — общий. И в 12 ночи все квартиры добавляют домовому счетчику свой расход электричества за сутки.

Ну тогда будет физическая проблема. Когда в каждой квартире стоит свой счетчик, а в доме — общий. И в 12 ночи все квартиры добавляют домовому счетчику свой расход электричества за сутки.

Интересный у тебя подход. Ты придумываешь проблему, а потом предлагаешь ее решить. Никто так не делает что б в 12 добавлять счетчик)) Счетчик считает постоянно. Режим передачи куда-то еще это отдельная тема. Смотря какое подключение. Если через мобилку то, данные собираются на карте и раз в 5-10 мин передаются. Ну, разные режимы есть.. Кто в облако, кто как, смотря где и какой учет..

То есть, несколько концептов не могут аггрегировать свою информацию в один концепт? То есть, мы не можем на этом новом железе с шинами сделать общий счетчик для дома, который будет получать по шинам данные из всех квартир?

То есть, мы не можем на этом новом железе с шинами сделать общий счетчик для дома, который будет получать по шинам данные из всех квартир?

Можем. А зачем? Так не правильно строить систему. Можно несколько счетчиков сделать в квартире. На розетки или еще что.. Причем с удаленным управлением. Например отключение по событию превышения тока или ограничения по мощности. Если обратил внимание программа остается без изменений. Только подписки добавить на тока или на мощность. А общий счетчик ставится для контроля. Иерархически. Как по квартире, по подъезду, можно по фазам. А аналитика делается на верхнем уровне. Там можно интересный анализ делать. По расходу и утечек.. Кстати, можно на одной железке несколько счетчиков сделать. Что б один считал, допустим, зеленую энергию. В общем там много возможностей появляется. Таких как дисплей не нужен. Значения можно передавать на мобилу, экран, сайт, часы и куда угодно. Не обязательно счетчик в подъезде ставить. Можно в квартире

Общий счетчик это дисплей с подпиской на события change.Value всех устройств суммируя

У него проц сдохнет, если он будет не каждый тик в каждой из 500 квартир однопоточно менять свои данные.
А если все счетчики из 500 квартир одновременно пушнут в него данные — будут неправильные результаты. Показываю:

В счетчике дома лежит 10000 киловатт-часов.
Счетчик в квартире 1 поюзал 500 квт.
Счетчик в квартире 2 показывает 50.
Счетчик в квартире 3 показывает 5000.
Все три одновременно пытаются добавить к домашнему 10000 свое значение.

Как делается добавление (оператор +=)? Проц вычитывает по шине в свой регистр старое значение (10000) из памяти, добавляет к нему свое значение (500, 50 или 5000) из другого регистра, суммирует два регистра в третий, и потом записывает обратно в память значение третьего регистра. Итого, что будет в вашей системе:

Счетчик 1 тянет по шине 1 значение 10000 из счетчика дома.
Счетчик 2 тянет по шине 2 значение 10000 из счетчика дома.
Счетчик 3 тянет по шине 3 значение 10000 из счетчика дома.

Счетчик 1 прибавляет к вытянутому 10000 свои 500 у себя в проце.
Счетчик 2 прибавляет к вытянутому 10000 свои 50 у себя в проце.
Счетчик 3 прибавляет к вытянутому 10000 свои 5000 у себя в проце.

Счетчик 1 пишет по шине 10500 обратно в значение счетчика дома.
Счетчик 2 пишет по шине 10050 обратно в значение счетчика дома.
Счетчик 3 пишет по шине 15000 обратно в значение счетчика дома.

И вот то, что получится в счетчике дома, будет числом, которое записали последним. Если счетчик 2 тормознул дольше других — будет 10050 израсходовано всеми квартирами. Если счетчик 1 самый медленный — тогда будет 10500 как сумма. Но никогда при одновременном добавлении не будет 15550, то есть реально оно не просуммирует.

У него проц сдохнет, если он будет не каждый тик в каждой из 500 квартир однопоточно менять свои данные.

Логика работы не такая. Я не зря талдычу о семантических смыслах событий. Сумматор S (если в этом возникла необходимость) подписывается не на каждый тик, а на изменение значения V, которое его интересует. Это смысл. Т.е. заявляет в то, место M, где это изменение происходит. Таким образом инициатором передачи значения является M. И это произойдет тогда, и только тогда, когда обнаружится интерес при изменении этого значения. Т.е. подписка, которая содержит адрес куда надо отправлять измененное значение. Стало быть для этого адреса надо предусмотреть место. Ибо бесконечное или даже максимальное значение резервировать для этого не разумно. Что б не растекаться за подробности могу сказать что адресация «умная». И кроме того в дело вступает построение иерархии положения концепта. Адресация бывает нескольких типов по уровню. Концепт непосредственно в памяти, до 16-ти одноуровневых и до 16 выше по иерархии. Адресация к верхним по уровню устройствам осуществляется через «Экран», который собирает все подписки и отражает их (допускает подписки) хоть миллиону «зрителей».

Так большая и светлая же чтобы пользователи сами строили что захотят, и оно работало? Вот мне кажется, что очень логично строить так, чтобы в полночь данные из всех квартир собирались в ЖЭК.

Для тех, кто не в курсе как работает счетчик электроэнергии коротко расскажу. Считываются 1-2-5 тысяч раз в сек значения тока и напряжения, суммируются, усредняются, перемножаются и результат суммируется.

Для тех, кто не в курсе как работает счетчик электроэнергии коротко расскажу. Считываются 1-2-5 тысяч раз в сек значения тока и напряжения, суммируются, усредняются, перемножаются и результат суммируется.

О хоспади! Да кто ж в софте это делает? Железо для измерения стоит не баснословных денег.

О хоспади! Да кто ж в софте это делает? Железо для измерения стоит не баснословных денег.

Хочу тебя удивить. Именно так это дешевое железо и работает))

Правильно, железо работает по осциллятору чтобы разгрузить основное управляющее железо. Поэтому пример непонятен — если ты метишь в нишу копеечной железячки — там чем проще, тем лучше и дешевле и твоя архитектура — это излишество, которое не нужно, если в нишу микроконтроллеров повыше, то не раскрыта тем работы с железками — чтение из порта, это даже не пример использования. Мало того, в твоём примере выше абсолютно непонятны преимущества твоей архитектуры — читать из порта и суммировать можно на любом микроконтроллере с любой архитектурой.

Поэтому пример непонятен — если ты метишь в нишу копеечной железячки — там чем проще, тем лучше и дешевле и твоя архитектура — это излишество,

Излишество до тех пор, пока не стоит задача интегрирования в систему. А за это приходится платить на порядки выше.

Излишество до тех пор, пока не стоит задача интегрирования в систему. А за это приходится платить на порядки выше.

Интеграция — это 1/10 потраченого времени, даже в таких сложных системах как современное авто.

Интеграция — это 1/10 потраченого времени, даже в таких сложных системах как современное авто.

Это не соответствует действительности. Любое изделие стоит дороже чем сумма комплектующих. И эта разница на порядок.

Если что, то ты заявил что проблемы счётчика не решить алгоритмом, и сам написал на неё алгоритм.

Если что, то ты заявил что проблемы счётчика не решить алгоритмом.

Я не говорил что программу для счетчика нельзя решить алгоритмом. Миллионы цифровых счетчиков именно так и работают. Просто у меня больше возможностей и проще. Если понять, конечно.

и сам написал на неё алгоритм.

А вот тут как раз и заявка на принципиальное отличие. Читаем определение алгоритма здесь ru.wikipedia.org/wiki/Алгоритм
Алгори́тм конечная совокупность точно заданных правил решения некоторого класса задач или набор инструкций, описывающих порядок действий исполнителя для решения определённой задачи.
Обычная программа является именно последовательностью определяющей порядок выполнения, за исключением условных переходов. Если обратил внимание у меня нет общего описания строгой последовательности. Т.е. в общем случае нельзя сказать что сначала произойдет и как будет выполняться. Гарантирована последовательность только только пары событие-подписка. Т.е. это не алгоритм!

Если обратил внимание у меня нет общего описания строгой последовательности. Т.е. в общем случае нельзя сказать что сначала произойдет и как будет выполняться.

Ну да. Это всеми любимый ru.wikipedia.org/...​информатика)#Проблематика

Ну да. Это всеми любимый ru.wikipedia.org/...​информатика)#Проблематика

Не совсем так. Здесь речь идет о вычислениях, а я за смыслы. Эта проблема глубже. Я б поговорил, надо бы пообщаться и подискутировать. Я и сам не все осознал. Потому четких формулировок еще нет. Есть только мысли. Речь идет о логике, высказываниях, формулировках и постановке задачи. Есть глубокое подозрение что события это по сути логические высказывания. В программировании выражения. Вполне возможно любую задачу можно сформулировать высказываниями. Высказывания перевести в события запускаемые на моей архитектуре и получить результат. Как пример, классическая задача сортировки легко формулируется как запуск итератора по множеству с подписками на события больше-меньше. Т.е. именно так, как формулирует ее человек. Тогда «программа» сортировки и является ее формулировкой. Трансляцией у меня тоже в перспективе занимается компьютер непосредственно с определением грамматики на моем языке. Т.е. определение грамматики является программой.

Как пример, классическая задача сортировки легко формулируется как запуск итератора по множеству с подписками на события больше-меньше. Т.е. именно так, как формулирует ее человек.

Тут исчезают все разрекламированные возможности архитектуры. Потому что итератор один, ему придется ездить по всему массиву данных и по-одной сравнивать все пары несоклько раз. А одновременно сравнивать все и менять местами одновременно пары во всем массиве — это попортит сами данные. То есть, в плане сортировки мы вернулись от кучи шин и концептов к одной шине, сравнивающей по два концепта за раз. То есть — к обычному одноядерному процессору.

Почему одна шина? Вот приблизительно так
‘Создаем массив Integer A
Integer A Change |‘Две подписки на событие «Change Value»
‘В первой сравниваем текущий элемент со следующим
{A [Index] ~ A [Index+1]) | > A [Index+1]:=: A [Index] ‘Если событие > то меняем.
‘Во второй подписке сравниваем текущий элемент с предыдущим
A [Index] ~ A [Index-1]) | < A [Index]:=: A [Index −1] ‘Если < то меняем
} [] ‘Определение массива Integer
Из незнакомого здесь только знаки операции сравнения «~» и перестановки «:=:». Выполнение начинается с изменения значения какого-то элемента массива. Так как определены подписки на события больше и меньше то, выполняются операция сравнения и реакция на произошедшие события — обмен соседними значениями, что приводит в свою очередь к изменению значения соседнего элемента массива. И так до тех пор, пока элемент не найдет свое место в массиве.
Не очень красиво с синтаксисом. Старая версия. Но, принцип видно.

Это сортировка вставкой — если у нас уже дан отсортированный массив. Сложность квадратичная, чтобы отсортировать с нуля. И у нас ни на одном шагу не используется 2 ядра или две шины — кроме первоначального этапа сравнения. То есть, обычный проц сделает то же самое за то же квадратичное время.

А для первичной сортировки неупорядоченного массива есть алгоритмы, работающие за N*log(N) то есть, обычный проц через quicksort() отсортирует неупорядоченный массив чисел быстрее, чем этот вариант с подписками.

обычный проц через quicksort() отсортирует неупорядоченный массив чисел быстрее, чем этот вариант с подписками.

А с чего ты решил что я спешу? В перспективе у меня куча и шин и процессоров) А это определение массива. Он при создании отсортируется.

Ну ладно, Там подписки на изменение элемента. Тогда следующие вопросы:
1) Можно ли в массиве изменить один элемент пока другой элемент еще не сел на свое место (пока происходит сортировка из-за подписки)?
2) Смена элементов местами :=: происходит через временную переменную, или как?

2) Смена элементов местами :=: происходит через временную переменную, или как?

Это осталось не додуманое. Из старого достал. Пока нет операции обмена. Даже в самой свежей версии что сейчас делаю. Думаю над итераторами. А отсортированные массивы будут.

Ну ладно, Там подписки на изменение элемента.

Сори. На изменение значения элемента.

Это осталось не додуманое.

Вот если через временную переменную — тогда смена значений двух элементов массива местами (например, есть массив 0, 1, 2, ... 100. меняем 0 и 100 местами) приведет к порче данных во время сортировки.
А если не через временную переменную — тогда как? И на каком железе?
Как говорят, дьявол в деталях.

Потому и не реализовал, что мабуть лишнее будет.

Так как в результате должна работать сортировка? Или она не должна вообще работать на этом железе, потому что операция смены данных местами не будет реализована?

Если обратил внимание у меня нет общего описания строгой последовательности. Т.е. в общем случае нельзя сказать что сначала произойдет и как будет выполняться. Гарантирована последовательность только только пары событие-подписка. Т.е. это не алгоритм!

Читайте наступні два речення. Там навіть є пояснення про «последовательность».

В старой трактовке вместо слова «порядок» использовалось слово «последовательность», но по мере развития параллельности в работе компьютеров слово «последовательность» стали заменять более общим словом «порядок». Независимые инструкции могут выполняться в произвольном порядке, параллельно, если это позволяют используемые исполнители.

Сувора послідовність — не потрібна. У наведеному коді — теж є порядок дій, як ви самі вкзали.

Зайдіть на англійську сторінку вікі про алгоритм, там побачите, що алгоритми бувають дуже різні, наприклад паралельні, розподілені, квантові та недетерміністичні. І їх творці не шукали ідотської слави, їм було шо реально запропонувати, то вони цілком логічно просто розширили та доповнили поняття алгоритм.

І їх творці не шукали ідотської слави, їм було шо реально запропонувати, то вони цілком логічно просто розширили та доповнили поняття алгоритм.

А в чем претензия? И я реально предложил еще один класс алгоритмов. Или у меня фамилия не достойна для предложить? Так я и не претендую. Назвал А ритмы. С частичным порядком пары событие-подписка. С чего так возбудились?

А в чем претензия?

Пафосна заява

не все задачи удобны ( я не говорю разрешимы) для решения алгоритмами. И вот я хочу показать нечто новое.

не відповідає дійсності. Воно вигляда як не дуже специфічний різновид паралельних алгоритмів. Тому питання

а нахрена это все?

лишається.

Пафосна заява

Это ваше ощущение. Понты вообще не про меня.

не відповідає дійсності. Воно вигляда як не дуже специфічний різновид паралельних алгоритмів. Тому питання

Не понял. Удобство вообще мутная категория и очень субъективная. Зависит от личного опыта. Как оно может не соответствовать действительности? Как и оценка «не очень специфический». Или очень.. Это ни о чем. Допустим, я согласен. Может раскроете подробней что хотели сказать? Буду благодарен.

Ну вот все эти задачи каким-то образом уже десятилетия как решают. Появляется кто-то новый, говорит, что его способ самый удобный, но при этом он не хочет разобраться, как другие это привыкли делать.

Ну вот все эти задачи каким-то образом уже десятилетия как решают.

А ты один эти десятилетия решал? Я был на другой планете? Сколько можно говорить включи голову и прочитай внимательно.

А ты один эти десятилетия решал? Я был на другой планете? Сколько можно говорить включи голову и прочитай внимательно.

Судя по тому, что ты не приводишь сравнение своего изобретения с общеизвестными системами вроде Erlang — то да, на другой планете.

Это ваше ощущение.

Не тільки моє, боюсь. Ви замахнулись на базові речі.

Удобство вообще мутная категория и очень субъективная.

Так мова не про зручність, а про щось принципово нове, що прям відкидає алгоритми. Такого там нема. Паралелізм, події та підписки на них — не є новими концепціями, як їх не тасуй.

Говорячи про зручність — на МТ ніхто не програмує! Вона не про зручність! Тому якщо Машина Кузьміна зручніше за Тюрінга — це не має ніякого значення. Загугливши Машину Тюрінга — можна прям онлайн нею погратися і зрозуміти як вона працює. Хоч вона не для того абсолютно потрібна. З Машиною Кузьміна — все навпаки, погратись нею для розуміння як вона працює (а може і зацінити зручність) — не можливо, хоч це якби не основне її призначення.

Не тільки моє, боюсь. Ви замахнулись на базові речі.

Замахнулся. И что?

У понятия «алгоритм» нет определения. И быть не может. Алгоритм — это одно из неопределяемых понятий, которое мы понимаем интуитивно через его свойства. Так, например, вот это «определение»

Алгори́тм конечная совокупность точно заданных правил решения некоторого класса задач или набор инструкций, описывающих порядок действий исполнителя для решения определённой задачи.

Допустим, у нас есть некоторая задача. Скажите, будет ли алгоритмом ее решения последовательность действий:

1. Реши задачу
2. PROFIT!!!

Невозможно сказать, что НЕ является алгоритмом, так как нет критерия, чтоб определить, что же такое алгоритм. У машин Тьюринга, к слову, тоже нет никакой конкретной последовательности шагов, но тезис Тьюринга-Черча говорит о том, что все алгоритмы реализуемы на машине Тьюринга. И обратите внимание на слово «тезис» — это не теорема, так как это утверждение недоказуемо как раз из-за отсутствия определения алгоритма.

Ты очень даже прав. Более того, ты продемонстрировал алгоритм не разрешимой задачи))
1. Решение не разрешимой задачи.
2. Profit)

То есть не существует неразрешимых задач? Да и чем же тогда Ваш А-ритм отличается от алгоритма? Только конкретно. Без этих Ваших «да всем!». Вот очень конкретно.

Допустим, я смотрю на какой-то текст решения задачи. Как мне определить, что это не алгоритм, а именно А-ритм?

Допустим, я смотрю на какой-то текст решения задачи. Как мне определить, что это не алгоритм, а именно А-ритм?

Не готов сейчас ответить. Не думал над этим. Вообще-то серьезный вопрос. А как определить алгоритм глядя на текст? Это не из серии тех же примеров что мы приводили выше?)

Я даже название придумал на алгоритм, а А-ритм.

Как картинку добавить со схемой, не знаю. Сделал копию в PDF. Могу отправить. Ну, кто понял как работает эта программа уже понял, что слово алгоритм здесь не очень удачно подходит.

Это было уже 100 раз в прошлых темах этого автора

Ссылок не будет, картинок не будет, работающих примеров не будет, ничего не будет. Зато будет 100 объяснений, почему это сделать нельзя, не сейчас, тяжело, когда-то потом, ругать все могут, давайте лучше конференцию или позвоните мне.

Автор жаждет общения, а ему задают неудобные вопросы. Ну, тоже какое-никакое, но общение, вот он и возвращается снова и снова

Автор жаждет общения, а ему задают неудобные вопросы. Ну, тоже какое-никакое, но общение, вот он и возвращается снова и снова

Да, жду вопросов. И отвечаю. И выразил благодарность тем, кто их формулирует для разобраться. А в остальном из вас плохая Кассандра. Скорее проецируете свои комплексы не имея своего мнения потому как не Ваш уровень. Вам бы в политику.

Может сначала все-таки bubble sort, а потом советы?

Может сначала все-таки bubble sort, а потом советы?

Так уже здесь приводил...Поищи в этой теме.

Приводили не работающий (так как операции обмена нет). А работающий есть?

Приводили не работающий (так как операции обмена нет). А работающий есть?

Разбей на две команды. Сохранить в стек и достать из стека. Кстати, двухоперандных команд тоже нет. Только стековая машина.

Без атомарного swap будет race condition. Как его устранять?

Без атомарного swap будет race condition. Как его устранять?

Та нет здесь проблем. И гонок нет. Анализ на события не изменяет значения. Лишняя проверка не помешает. Пока подумаю. Пока не реализовал. Команда зарезервирована.

Та все уже давно понятно, автор типичный поциэнт с синдромом непризнанного гения. Наработок на самом деле нет, а синдром — есть. Отсюда и вся эта Машина Кузьмина © тм

. Отсюда и вся эта Машина Кузьмина

Зачем меня обсуждать по теме есть что сказать?

Підписатись на коментарі