Сколько угодно и математики этим активно занимаются. Статья дает интересную перспективу на числа, но есть и другой взгляд на вещи, который идет из современной алгебры и теории чисел.
Как выразить через такие векторы число пи? Никак. Точное выражение через единицы измерения означает точную десятичную запись.
Можно взять и начать считать пары палочек — получатся рациональные дроби. Пара (1,3) будет означать 1/3. Правда рассматривать нужно будет не сами пары, а классы эквивалентностей на этих парах, так чтобы (1,3) попадало в тот же класс что и (2,6). Далее дедекиндовыми сечениями на рациональных дробях получаем вещественные числа. Далее вводим пары вещественных чисел и получаем комплексные числа, с особым правилом умножения и получаем комплексные. А вот следующее расширение множества чисел уже придумать нельзя.
Ремарка — прежде чем вводить понятие пар и классов эквивалентностей нужно договориться о том, что такое множество. Это оказывается не так просто, можно гуглить про ZFC.
Вопрос на засыпку — чем отличается вектор [1,2] от 1 + 2*i? Ответ — комплексные числа можно умножать и получать комплексные числа. Вектора, в общем случае, умножать нельзя. Для размерности векторов 3 придумали полезную операцию «умножения», но это частный случай и не умножение, потому что некоммутативное.
Логические операции вместе с множеством из двух элементов (например {0, 1}, {да, нет}, {красное, зеленое}) образуют алгебраическое поле, так же как и вещественные и комплексные числа и много чего еще.
Любое множество, которое мы можем оснастить структурой алгебраического поля можно назвать числами (скалярами, наверное, правильнее говорить). Например поле можно сделать из матриц 2x2, и даже найти изоморфизм между такими матрицами и комплексными числами.
Ограниченные вещественные функции на интервале тоже можно рассматривать как числа.
Кольцо вычетов по простому модулю это тоже поле. Например множества — {1,2,3} или {1,2,3,4,5} но не {1,2,3,4}
А есть еще алгебры Ли и еще миллион всяких других алгебр, которые реально используются в расчетах и инженерии. Короче — учить надо современную алгебру и теорию чисел, палочки это хорошо, но идет немного в сторону от основной дороги математики.
Да ладно вам, ничего я не изобретал, вы же не думаете, что я тут полемику развел и не представляю как оно внутри работает :) Я просто показал, что можно в рамках существующих БД добиться обнаружения злонамеренных искажений данных. А еще в нагрузку получить кучу специалистов, знакомых с технологией, кучу готовых инструментов и интеграцию со всеми средами разработки и языками. И кажется все это сильно перевешивает сомнительные перспективы интегрировать сторонний сервис, которому все равно нельзя доверять.
Почему для аудита и защиты от подделки не использовать старую добрую цифровую подпись? Кажется ее довольно тяжело подделать даже самому главному админу.
0. Для начала выдаем пользователям пару публичный и приватный ключ.
1. Берем запись в базе, которую хотим защитить от подлога.
2. Вычисляем ее хеш или просто склеиваем все поля. Для пущей надежности запишем туда же хеш предыдущей версии или же возьмем и сериализуем дерево Меркле. Тут уж в зависимости от требований.
3. Подписываем то, что получилось с помощью приватного ключа пользователя и записываем результат куда-нибудь рядом.
4. Если надо проверить подлинность записи, то достаточно взять публичный ключ пользователя и проверить подпись.
Если кто-то захочет поменять данные, то ему придется «засветиться» и оставить везде свою подпись и переписать кучу хешей. Абсолютно то же самое случится если кто-то перепишет блокчейн, что вполне возможно если он не основан на proof of work. И кажется все это более оправдано в текущей ситуации, потому что в обмен на 3-4 недели работы по реализации цифровой подписи, получаем все богатство инструментария для работы с БД. Инструменты для блокчейна до этого уровня дойдут лет через 5.
Для надежной репликации уже есть миллион решений и блокчейн новых не предлагает. Например CouchDB, она будет отлично реплицироваться и будет также append only (собственно это следствие отсутствия проблем с реализацией).
Кажется, что корень всех зол в том, что мы (разработчики ПО) не умеем произвольно взятую задачу «правильно» декомпозировать на модули. Всякие умные подходы вроде ООП, MVC, DDD, Viper и т.п. не особо в этом помогают. Если представить все варианты реализаций требований как множество, то похоже, в этом множестве лишь немногие точки отвечают «хорошей» системе. В итоге три варианта:
1. Разработчики уже знают как делать правильно, это называется «опыт в предметной области»;
2. Приходят к хорошей системе путем непрерывного рефакторинга, стоит это бешеных денег и времени. Раза 3-4 всю системы нужно будет переписать. На практике такое возможно только в своих собственных проектах. Поэтому свои, домашние, проекты, лучше растят скилл по сравнению с коммерческой разработкой.
3. Делают как показалось вначале правильным, судорожно пытаются найти время на рефакторинг и оказываются в итоге там же, где и большинство — в левой части вашего квадрата.
Исправить такое незавидное положение можно если придумать некую алгебраическую структуру на множестве требований. Тогда «правильную» архитектуру мы сможем вычислять, с некоторой точностью. Но такого даже на горизонте нет. А пока нужно рассчитывать на опытных коллег, сообщество, общение и передачу знаний о том, что работает, а что нет.
Кажется этот сценарий покрывается следующими мерами (кажется вы так и сделали)
— лог изменений в базу (таблица audit log например)
— сертификатами и цифровой подписью к каждой записи
И кажется, это сильно удобнее в эксплуатации, чем использование цепочки блоков и последующее решение как все это индексировать, реплицировать и т.п. Может тут есть какие-то подводные грабли, но мне они не очевидны.
Прошу прощения, но я все еще не вижу что нового ваш подход приносит в мир. Не могли бы вы описать его примерно в таких терминах или указать на релевантные части статьи:
— есть модель данных, характеризуется так-то и такие-то типичные запросы, варианты обновления данных
— есть реляционные или иные БД, которые с этим не справляются потому что неправильные индексы, не тот MVCC, не тот оптимизатор и т.п.
— вот наша модель, она хорошо справляется, потому что — тут ваша инновация.
Все проблемы изучения ООП состоят в том, что оно преподносится как техника проектирования системы. Но ООП это просто идея, к проектированию оно отношения не имеет.
Все просто, вы не будете разрабатывать каждый самолет с нуля, вы в любом случае возьмете успешную модель и просто доработаете ее.
Это ключевой момент — такого уровня адаптации, как вам потребуется вы не получите от абстрактного класса и наследования. И даже композиция вам не поможет — быстро выяснится, что ваши объекты не соединятся так как надо конкретно в вашем случае и нужно менять интерфейсы или искать обходные пути.
Скорее всего вам потребуется что-то посложнее, начнутся всякие паттерны и прочее. А паттерны это, в частности, о том как делить систему на части. То что кто-то части называет объектами и классами, а кто-то функциями и модулями проблемы не меняет.
Все проблемы React Native можно видеть в новом Skype на iOS (на Android наверное тоже). Страдает RN такой же болезнью, что и Appcelerator Titanium когда-то. Весь JS работает в отдельном от UI потоке, что иногда хорошо, а иногда не очень.
RN считает, что DOM (иерархию view) никто кроме него не изменяет, потому что diff иначе сгенерировать невозможно. Но большая часть контролов об этом не знает и сами генерируют свои внутренности по своим алгоритмам. Например, UITableView вставляет/удаляет в иерархию view ячейки по мере скролинга, обрабатывает всякие свайпы изменяя ячейки и т.п. Решить эти проблемы можно только делая нативные контролы, которые заточены под React. По сути рождается слой костылей для адаптации нативных контролов под ожидания React.
Возможно RN когда-нибудь допилят, но пока я за Xamarin, так как он ближе к платформе.
В 2007 на планете было еще много мест куда не добрался быстрый интернет, флешки и прочие радости жизни. В 2014 году в одном из проектов у меня было требование уметь записывать информацию на DVD, потому что где-то в Малазии и Африке это был очень популярный способ потреблять информацию.
… то это должна быть ссылка. Или параметр конструктора.
1. Что с ОС делать предлагаете?
2. Если «список операций» это зависимость, то что останется в калькуляторе?
3. Почему то, что останется должно быть именно в калькуляторе, а не передаваться также в качестве зависимости?
Назначение объекта «калькулятор» — делать расчеты в соответсвии с исходными данными, используя операции из списка.
Если для калькулятора указать список операций, то это будет сильно больше чем «Его можно исчерпывающе описать одним предложением, не используя союзы.»
Для ОС тоже можно указать список, там очень много пунктов. Я думаю никто не обрадуется увидев такой объект в ядре операционной системы. Тогда возникает вопрос — почему для калькулятора список функций это ок, а для ОС видимо не ок.
Вы просите дать полное описание того, что такое «работать». Полные описания редко помещаются в одно простое предложение. Любой программный компонент имеет нефункциональные требования к производительности, портируемости работе в многопоточной среде.
Каждый программный объект имеет одно и только одно назначение.
Его можно исчерпывающе описать одним предложением, не используя союзы.
Тут меня сразу подмывает задать несколько вопросов:
— Назначение объекта типа «калькулятор» складывать или умножать?
— Ограничения на длину предложения существуют?
— Предъявите требования к точности и емкости определения. Например — «Объект реализует функции операционной системы» это ответственность?
— Являются ли ответственностью объекта такие штуки
• Возможность работать на i386, x86_64, ARM
• Умение работать в многопоточной среде
• Переносимость на другие ОС
• Асимптотическая сложность операций
Я не вижу почвы для холиваров. Есть конкретный вопрос, лежащий в технической области.
Этот спор очень просто решить, предложите сценарии использования такого блокчейна и покажите почему он лучше базы данных в таком сценарии.
Сценарий вы предложили (регпалата Грузии), но очевидно, что частный блокчейн в этом сценарии не дает никаких преимуществ перед БД. Более того, DLT Trust в этом сценарии тоже не дает населению доп. защиты.
Какое тут доверие? Частному блокчейну доверять нельзя, им владеет единственный и злонамеренный владелец. На шаге 1 Гера регистрирует юр. лицо, появляется запись в биткоин. На шаге 2 Гела переписывает юр. лицо на себя и появляется ещё одна запись в биткоин. Все честно, вот запись в частном блокчейне, вот хеш в биткоине.
В реальной жизни Гела пойдет в суд с поддельных договором купли продажи. Или Геру посадят и не выпустят пока он не подпишет документы.
И так, между делом, если частному блокчейну нельзя доверять и все работает на делегировании (посылке хешей), то зачем вообще блокчейн? Я могу хеши из базы посылать с тем же успехом.
Итого — ваш пример шикарно работает на основе БД, а еще ни БД ни даже полноценный блокчейн озвученную проблему не решают. Решают ее независимые суды и органы право порядка.
Я все еще жду примера чем частный блокчейн, контролируемый одной организацией, лучше обычной БД.
В частном блокчейне все узлы, в той или иной степени, административно связаны друг с другом в рамках иерархических связей внутри организации, например, банка. Захочет хозяин банка подменить отчетность, записанную в блокчейне его банка (частный блокчейн), и очень легко это сделает.
Откуда вы это берете, где этот кладезь дезинформации? Блокчейн, принадлежащий одному хозяину это бессмысленная, дорогая и неудобная база данных, так никто не делает. Или делают для распила бабла или для того, чтобы впарить инновации кому-нибудь.
Посмотрите хотя бы на Hyperledger Fabric. Частный блокчейн, узлы могут контролироваться разными организациями, для изменения алгоритма работы сети эти узлы должны проголосовать. Такой блокчейн можно использовать в банках (множественное число), например, для работы с KYC (know your customer) данными. И никакой провинциальный банк из Дагестана не сможет изменить кредитный рейтинг без согласия других участников системы. В этом и есть сила блокчейна, в том, что данные децентрализованы и им можно доверять.
А по вашему получается, что частный блокчейн живет в одной организации и контролируется ею же. Поставьте тогда любую БД, настройте репликацию и права доступа и не парьтесь. Это будет многократно дешевле и проще.
Впрочем, так как все узлы банка находятся административно в одних руках, то качество консенсуса может оказаться как в старом анекдоте позапрошлого века:
В этом случае вам хватит БД и она будет работать на порядок лучше чем блокчейн. Блокчейн имеет смысл как хранилище, которому несколько разных институтов (компаний, людей) могут доверять. А если как вы говорите, то блокчейн это просто тормозная, неудобная и дорогая в эксплуатации база данных.
Можно взять и начать считать пары палочек — получатся рациональные дроби. Пара (1,3) будет означать 1/3. Правда рассматривать нужно будет не сами пары, а классы эквивалентностей на этих парах, так чтобы (1,3) попадало в тот же класс что и (2,6). Далее дедекиндовыми сечениями на рациональных дробях получаем вещественные числа. Далее вводим пары вещественных чисел и получаем комплексные числа, с особым правилом умножения и получаем комплексные. А вот следующее расширение множества чисел уже придумать нельзя.
Ремарка — прежде чем вводить понятие пар и классов эквивалентностей нужно договориться о том, что такое множество. Это оказывается не так просто, можно гуглить про ZFC.
Вопрос на засыпку — чем отличается вектор [1,2] от 1 + 2*i? Ответ — комплексные числа можно умножать и получать комплексные числа. Вектора, в общем случае, умножать нельзя. Для размерности векторов 3 придумали полезную операцию «умножения», но это частный случай и не умножение, потому что некоммутативное.
Логические операции вместе с множеством из двух элементов (например {0, 1}, {да, нет}, {красное, зеленое}) образуют алгебраическое поле, так же как и вещественные и комплексные числа и много чего еще.
Любое множество, которое мы можем оснастить структурой алгебраического поля можно назвать числами (скалярами, наверное, правильнее говорить). Например поле можно сделать из матриц 2x2, и даже найти изоморфизм между такими матрицами и комплексными числами.
Ограниченные вещественные функции на интервале тоже можно рассматривать как числа.
Кольцо вычетов по простому модулю это тоже поле. Например множества — {1,2,3} или {1,2,3,4,5} но не {1,2,3,4}
А есть еще алгебры Ли и еще миллион всяких других алгебр, которые реально используются в расчетах и инженерии. Короче — учить надо современную алгебру и теорию чисел, палочки это хорошо, но идет немного в сторону от основной дороги математики.
Да ладно вам, ничего я не изобретал, вы же не думаете, что я тут полемику развел и не представляю как оно внутри работает :) Я просто показал, что можно в рамках существующих БД добиться обнаружения злонамеренных искажений данных. А еще в нагрузку получить кучу специалистов, знакомых с технологией, кучу готовых инструментов и интеграцию со всеми средами разработки и языками. И кажется все это сильно перевешивает сомнительные перспективы интегрировать сторонний сервис, которому все равно нельзя доверять.
0. Для начала выдаем пользователям пару публичный и приватный ключ.
1. Берем запись в базе, которую хотим защитить от подлога.
2. Вычисляем ее хеш или просто склеиваем все поля. Для пущей надежности запишем туда же хеш предыдущей версии или же возьмем и сериализуем дерево Меркле. Тут уж в зависимости от требований.
3. Подписываем то, что получилось с помощью приватного ключа пользователя и записываем результат куда-нибудь рядом.
4. Если надо проверить подлинность записи, то достаточно взять публичный ключ пользователя и проверить подпись.
Если кто-то захочет поменять данные, то ему придется «засветиться» и оставить везде свою подпись и переписать кучу хешей. Абсолютно то же самое случится если кто-то перепишет блокчейн, что вполне возможно если он не основан на proof of work. И кажется все это более оправдано в текущей ситуации, потому что в обмен на 3-4 недели работы по реализации цифровой подписи, получаем все богатство инструментария для работы с БД. Инструменты для блокчейна до этого уровня дойдут лет через 5.
Для надежной репликации уже есть миллион решений и блокчейн новых не предлагает. Например CouchDB, она будет отлично реплицироваться и будет также append only (собственно это следствие отсутствия проблем с реализацией).
1. Разработчики уже знают как делать правильно, это называется «опыт в предметной области»;
2. Приходят к хорошей системе путем непрерывного рефакторинга, стоит это бешеных денег и времени. Раза 3-4 всю системы нужно будет переписать. На практике такое возможно только в своих собственных проектах. Поэтому свои, домашние, проекты, лучше растят скилл по сравнению с коммерческой разработкой.
3. Делают как показалось вначале правильным, судорожно пытаются найти время на рефакторинг и оказываются в итоге там же, где и большинство — в левой части вашего квадрата.
Исправить такое незавидное положение можно если придумать некую алгебраическую структуру на множестве требований. Тогда «правильную» архитектуру мы сможем вычислять, с некоторой точностью. Но такого даже на горизонте нет. А пока нужно рассчитывать на опытных коллег, сообщество, общение и передачу знаний о том, что работает, а что нет.
— лог изменений в базу (таблица audit log например)
— сертификатами и цифровой подписью к каждой записи
И кажется, это сильно удобнее в эксплуатации, чем использование цепочки блоков и последующее решение как все это индексировать, реплицировать и т.п. Может тут есть какие-то подводные грабли, но мне они не очевидны.
— есть модель данных, характеризуется так-то и такие-то типичные запросы, варианты обновления данных
— есть реляционные или иные БД, которые с этим не справляются потому что неправильные индексы, не тот MVCC, не тот оптимизатор и т.п.
— вот наша модель, она хорошо справляется, потому что — тут ваша инновация.
Это ключевой момент — такого уровня адаптации, как вам потребуется вы не получите от абстрактного класса и наследования. И даже композиция вам не поможет — быстро выяснится, что ваши объекты не соединятся так как надо конкретно в вашем случае и нужно менять интерфейсы или искать обходные пути.
Скорее всего вам потребуется что-то посложнее, начнутся всякие паттерны и прочее. А паттерны это, в частности, о том как делить систему на части. То что кто-то части называет объектами и классами, а кто-то функциями и модулями проблемы не меняет.
Чем конкретно предложенная модель лучше бд? Какие особенности бд мешают эффективно реализовать вашу модель?
Кажется вы «изобрели» обычную бд с mvcc. Чем эта штука лучше postgres?
RN считает, что DOM (иерархию view) никто кроме него не изменяет, потому что diff иначе сгенерировать невозможно. Но большая часть контролов об этом не знает и сами генерируют свои внутренности по своим алгоритмам. Например, UITableView вставляет/удаляет в иерархию view ячейки по мере скролинга, обрабатывает всякие свайпы изменяя ячейки и т.п. Решить эти проблемы можно только делая нативные контролы, которые заточены под React. По сути рождается слой костылей для адаптации нативных контролов под ожидания React.
Возможно RN когда-нибудь допилят, но пока я за Xamarin, так как он ближе к платформе.
1. Что с ОС делать предлагаете?
2. Если «список операций» это зависимость, то что останется в калькуляторе?
3. Почему то, что останется должно быть именно в калькуляторе, а не передаваться также в качестве зависимости?
Если для калькулятора указать список операций, то это будет сильно больше чем «Его можно исчерпывающе описать одним предложением, не используя союзы.»
Для ОС тоже можно указать список, там очень много пунктов. Я думаю никто не обрадуется увидев такой объект в ядре операционной системы. Тогда возникает вопрос — почему для калькулятора список функций это ок, а для ОС видимо не ок.
Вы просите дать полное описание того, что такое «работать». Полные описания редко помещаются в одно простое предложение. Любой программный компонент имеет нефункциональные требования к производительности, портируемости работе в многопоточной среде.
Тут меня сразу подмывает задать несколько вопросов:
— Назначение объекта типа «калькулятор» складывать или умножать?
— Ограничения на длину предложения существуют?
— Предъявите требования к точности и емкости определения. Например — «Объект реализует функции операционной системы» это ответственность?
— Являются ли ответственностью объекта такие штуки
• Возможность работать на i386, x86_64, ARM
• Умение работать в многопоточной среде
• Переносимость на другие ОС
• Асимптотическая сложность операций
Сценарий вы предложили (регпалата Грузии), но очевидно, что частный блокчейн в этом сценарии не дает никаких преимуществ перед БД. Более того, DLT Trust в этом сценарии тоже не дает населению доп. защиты.
В реальной жизни Гела пойдет в суд с поддельных договором купли продажи. Или Геру посадят и не выпустят пока он не подпишет документы.
И так, между делом, если частному блокчейну нельзя доверять и все работает на делегировании (посылке хешей), то зачем вообще блокчейн? Я могу хеши из базы посылать с тем же успехом.
Итого — ваш пример шикарно работает на основе БД, а еще ни БД ни даже полноценный блокчейн озвученную проблему не решают. Решают ее независимые суды и органы право порядка.
Я все еще жду примера чем частный блокчейн, контролируемый одной организацией, лучше обычной БД.
Этот спор очень просто решить, предложите сценарии использования такого блокчейна и покажите почему он лучше базы данных в таком сценарии.
Откуда вы это берете, где этот кладезь дезинформации? Блокчейн, принадлежащий одному хозяину это бессмысленная, дорогая и неудобная база данных, так никто не делает. Или делают для распила бабла или для того, чтобы впарить инновации кому-нибудь.
Посмотрите хотя бы на Hyperledger Fabric. Частный блокчейн, узлы могут контролироваться разными организациями, для изменения алгоритма работы сети эти узлы должны проголосовать. Такой блокчейн можно использовать в банках (множественное число), например, для работы с KYC (know your customer) данными. И никакой провинциальный банк из Дагестана не сможет изменить кредитный рейтинг без согласия других участников системы. В этом и есть сила блокчейна, в том, что данные децентрализованы и им можно доверять.
А по вашему получается, что частный блокчейн живет в одной организации и контролируется ею же. Поставьте тогда любую БД, настройте репликацию и права доступа и не парьтесь. Это будет многократно дешевле и проще.
В этом случае вам хватит БД и она будет работать на порядок лучше чем блокчейн. Блокчейн имеет смысл как хранилище, которому несколько разных институтов (компаний, людей) могут доверять. А если как вы говорите, то блокчейн это просто тормозная, неудобная и дорогая в эксплуатации база данных.