Вот я честно говоря не понимаю, за что человека минусуют. Одно дело если у тебя зп в валюте и пугают нарастающие сложности с получением оной, и потом сейчас далеко не все зарубежные компании готовы совершать переводы в рф. И совсем другое дело если ты и так в рублях получаешь — зачем эти лишние приседания?
Edit: окей, человек тролль, но это же не значит, что он не может высказать здравую мысль. Или додо пицца платит 5-6k$+ чтобы это имело хоть какой то смысл?)
Круто, действительно интересно, спасибо за перевод. Однако я бы еще пару выводов для себя сделал в этом контексте — macOS не нужен, jvm не нужен
Типа если уж принимать миллионы клиентов — можно и заточиться под конкретное железо и ос, и тут jvm скорее мешает чем помогает, а мак очевидно не лучший выбор по итогам тестов :)
Спасибо, интересный обзор. Пара вопросов - чем отличается XOR от любых других способов пошифровать файл, и чем отличаются malware packers от любых других пакеров? Например, UPX - это malware packer? :)
Понятно, спасибо, всегда интересно поговорить с умным человеком, вы уж меня извините за дотошность, очень хотелось понять что происходит. Написали комментариев уже ещё на парочку таких статей :) Предлагаю добавить в статью ссылки на другие ваши статьи, чтобы была возможность понять, к чему это всё.
Исходные данные представлены на рис.1 и собраны в 3 таблицы: таблица 10, таблица 20, таблица 30. Верхняя строка каждой таблицы отображает одно из возможных текущих состояний, левый столбец таблицы ее возможное действие.
Если собрать все переходы, то получим таблицу Замогилья.
Выходит все же кто-то должен собирать таблицу переходов, этого к сожалению не увидел.
Ну все равно у вас по сути там набор конечных автоматов, которые кто-то должен описать и соединить между собой прежде всего и наполнить данными, анализ всего этого это отдельная тема. Этап формирования таблиц и связей между ними как мне кажется упущен, там сразу постулируется - вот у нас есть такие-то таблицы)
Лучше покажите конкретный пример, как вы делаете то, что описываете, при помощи этого аппарата, как этот аппарат понимает, что считать объектами, и как они влияют друг на друга? Только не приводите конкретные примеры, как в статье (лампа, стол, ...)
Справедливости ради у вас не абстрактное решение - а отрисовка двух объектов, которые двигаются по строго заданным траекториям. Вы хотите сказать, что граф сам себя построит и проанализирует любые потоки данных?) В любом случае придётся создавать абстракцию для таких задач. А как вы говорите, это больше на нейросети похоже
Да я понимаю, учился в университете на технической специальности, и всё это у нас было (правда давненько уже). Непонятно чего мы хотим добиться - ну можем сделать абстракцию над значением, позволяющую добавлять логику любой сложности так, чтобы снаружи это выглядело как просто значение - это классная мысль, но не новость, в ООП называется инкапсуляция такой подход. Можем воспользоваться формальной логикой для описания предметной области - эта идея тоже в целом не нова. Ну можем описать фазовое пространство графами, чего мы можем добиться теперь?
Тут на самом деле неважно, как выполняется реализация. Это можно было сделать по ФП-шному, в процедурном стиле или ещё как-то - по крайней мере, это наглядный и доступный пример, взглянув на который сразу понятно, что происходит. ООП в данной ситуации - абстракция над потоками данных (как ни крути, а если хочется с этими потоками работать - какую-никакую абстракцию делать придётся). Собственно недопонимание у меня потому что:
все есть переменная
Это утверждение никак не связано с графами, как две произвольные прямые в пространстве - иногда они параллельные, иногда пересекаются, а иногда - скрещиваются.
базовые вещи: быть, не-быть
Наверное мне не достаёт контекста, вообще не понимаю о чем речь, и главное - при чем тут графы в первую очередь
фазовое пространство представимо именно графом
У меня к сожалению очень скудные знания на тему фазовых пространств, вы постулируете это утверждение и допустим я согласен. Что нам это дает, и как это связано с первоначальной мыслью о том, что все - переменная?
class First : IValueProvider<FirstState>
{
private FirstState _state = default;
public enum FirstState { A, B, C }
public void MoveNext()
{
_state = _state switch
{
FirstState.A => FirstState.B,
FirstState.B => FirstState.C,
FirstState.C => FirstState.A,
}
}
public FirstState Get()
{
return _state;
}
}
class Second : IValueProvider<SecondState>
{
private readonly IValueProvider<First.FirstState> _sourceStateProvider;
private SecondState _state = default;
public enum SecondState { R, W }
public Second(IValueProvider<First.FirstState> sourceStateProvider)
{
_sourceStateProvider = sourceStateProvider;
}
public void MoveNext()
{
var sourceState = _sourceStateProvider.Get();
if (sourceState != First.FirstState.C)
{
return;
}
_state = _state switch
{
SecondState.R => SecondState.W,
SecondState.W => SecondState.R,
}
}
public SecondState Get()
{
return _state;
}
}
Конечно придётся руками вызывать MoveNext для обоих классов, это легко обойти путем введения интерфейса по типу IValueChangedProvider. Используем наши классы:
var first = new First();
var second = new Second(first);
for (var i = 0; i < 1000; i++)
{
first.MoveNext();
second.MoveNext();
Console.WriteLine("#{0} Step. First value - {1}, second value - {2}", i, first.Get(), second.Get());
}
Вот если бы что-то такое было в статье, а не какой-то код рисующий два объекта, перемещающихся по строго заданной траектории, было бы гораздо проще. И согласитесь, графы тут совершенно ни при чем - можно нарисовать какие-то графы для этого кода, но нет никакой необходимости в графах, чтобы реализовать то, о чем вы говорите.
Вот смотря в код - у вас по факту два бесконечных автомата, состояние первого описывается выражением time1 % 3, второго - time2 % 2, соответственно когда первый автомат находится в третьем состоянии - он дает команду второму перейти в следующее состояние.
Ссылку не дам, так как не совсем до конца понимаю, о чем идет речь (что есть F в вашей терминологии?) :) Однако конечные автоматы описываются конечным набором параметров - таких как функция перехода, множество допустимых состояний и т. д., и при определённом желании можно все их сделать переменными. Или например управлять одним конечным автоматом из другого.
Edit: окей, человек тролль, но это же не значит, что он не может высказать здравую мысль. Или додо пицца платит 5-6k$+ чтобы это имело хоть какой то смысл?)
Типа если уж принимать миллионы клиентов — можно и заточиться под конкретное железо и ос, и тут jvm скорее мешает чем помогает, а мак очевидно не лучший выбор по итогам тестов :)
Спасибо, интересный обзор. Пара вопросов - чем отличается XOR от любых других способов пошифровать файл, и чем отличаются malware packers от любых других пакеров? Например, UPX - это malware packer? :)
ShareX и делов-то для записи экрана, + опенсорс
Но ведь можно же взять стек и складывать вершины туда (очередь для поиска в ширину), что позволяет легко и просто избавиться от рекурсии...
Что самое интересное, этот подход и описан в начале. Конечно, рекурсия тоже использует стек в каком-то роде :)
Понятно, спасибо, всегда интересно поговорить с умным человеком, вы уж меня извините за дотошность, очень хотелось понять что происходит. Написали комментариев уже ещё на парочку таких статей :) Предлагаю добавить в статью ссылки на другие ваши статьи, чтобы была возможность понять, к чему это всё.
Так и я о том же, у вас на рис. 1 уже данные собраны в таблицы, с состояниями, действиями и возможными переходами
Выходит все же кто-то должен собирать таблицу переходов, этого к сожалению не увидел.
Ну все равно у вас по сути там набор конечных автоматов, которые кто-то должен описать и соединить между собой прежде всего и наполнить данными, анализ всего этого это отдельная тема. Этап формирования таблиц и связей между ними как мне кажется упущен, там сразу постулируется - вот у нас есть такие-то таблицы)
Вот по этим ссылкам более конкретно, факт, однако первый комментарий передает то, что я хотел сказать.
Лучше покажите конкретный пример, как вы делаете то, что описываете, при помощи этого аппарата, как этот аппарат понимает, что считать объектами, и как они влияют друг на друга? Только не приводите конкретные примеры, как в статье (лампа, стол, ...)
Справедливости ради у вас не абстрактное решение - а отрисовка двух объектов, которые двигаются по строго заданным траекториям. Вы хотите сказать, что граф сам себя построит и проанализирует любые потоки данных?) В любом случае придётся создавать абстракцию для таких задач. А как вы говорите, это больше на нейросети похоже
Да я понимаю, учился в университете на технической специальности, и всё это у нас было (правда давненько уже). Непонятно чего мы хотим добиться - ну можем сделать абстракцию над значением, позволяющую добавлять логику любой сложности так, чтобы снаружи это выглядело как просто значение - это классная мысль, но не новость, в ООП называется инкапсуляция такой подход. Можем воспользоваться формальной логикой для описания предметной области - эта идея тоже в целом не нова. Ну можем описать фазовое пространство графами, чего мы можем добиться теперь?
Мы как будто тёплое с мягким обсуждаем :)
Тут на самом деле неважно, как выполняется реализация. Это можно было сделать по ФП-шному, в процедурном стиле или ещё как-то - по крайней мере, это наглядный и доступный пример, взглянув на который сразу понятно, что происходит. ООП в данной ситуации - абстракция над потоками данных (как ни крути, а если хочется с этими потоками работать - какую-никакую абстракцию делать придётся). Собственно недопонимание у меня потому что:
Это утверждение никак не связано с графами, как две произвольные прямые в пространстве - иногда они параллельные, иногда пересекаются, а иногда - скрещиваются.
Наверное мне не достаёт контекста, вообще не понимаю о чем речь, и главное - при чем тут графы в первую очередь
У меня к сожалению очень скудные знания на тему фазовых пространств, вы постулируете это утверждение и допустим я согласен. Что нам это дает, и как это связано с первоначальной мыслью о том, что все - переменная?
Вот допустим в своих шарпах я объявлю интерфейс провайдера значений, который возвращает произвольное значение (упрощенно, для наглядности):
Затем определим пару реализаций:
Конечно придётся руками вызывать MoveNext для обоих классов, это легко обойти путем введения интерфейса по типу IValueChangedProvider. Используем наши классы:
Вот если бы что-то такое было в статье, а не какой-то код рисующий два объекта, перемещающихся по строго заданной траектории, было бы гораздо проще. И согласитесь, графы тут совершенно ни при чем - можно нарисовать какие-то графы для этого кода, но нет никакой необходимости в графах, чтобы реализовать то, о чем вы говорите.
Не пользуюсь Discord, однако моё вам уважение за такую фичу, этого не хватает практически везде.
Вот смотря в код - у вас по факту два бесконечных автомата, состояние первого описывается выражением time1 % 3, второго - time2 % 2, соответственно когда первый автомат находится в третьем состоянии - он дает команду второму перейти в следующее состояние.
Ссылку не дам, так как не совсем до конца понимаю, о чем идет речь (что есть F в вашей терминологии?) :) Однако конечные автоматы описываются конечным набором параметров - таких как функция перехода, множество допустимых состояний и т. д., и при определённом желании можно все их сделать переменными. Или например управлять одним конечным автоматом из другого.