Возможность "поменять местами картинки... и прийти к противоположному результату... используя ту же самую логику" задаётся принципом относительности. Но принцип относительности касается только инерциальных систем отсчёта. В парадоксе близнецов же кот-космонавт находится в неинерциальной системе отсчёта. Поэтому утверждать о симметричности движений котов нельзя.
Вообще "постулат" в физике это что-то принимаемое в теории, но всё равно вытекаемое обычно из опыта.
Вы описываете что-то из времён Евклида. В современной физике у термина "постулат" никакого специального смысла нет. Это синоним "аксиомы".
Что касается "изотропности" - то из неё вытекает Закон сохранения энергии. Вряд ли он иметь отношение к СТО.
Во-первых, сохранение энергии следует из гомогенности, а не изотропности.
Во-вторых, оно следует из гомогенности времени. В контексте же вывода СТО без постулата о скорости света речь шла о гомогенности и изотропности пространства.
т.к. отсутствует понятие времени - оно в "системе отсчёта света" схлопнуто в точный ноль.
Насколько помню, это всего лишь артефакт выбранной системы координат. Можно взять такую аффинную систему, в которой скорость нормально определяется как касательная к мировой линии и для фотона.
Потому что так нарисовано на вашей диаграмме. Коты встречаются в точке пространства-времени с координатами в ИСО спящего кота (x=0, t=12). Ни в каком "дальше в будущем" никто не находится. Оба кота здесь и сейчас.
(12 секунд по неподвижным часам спустя).
С точки зрения кота-космонавта эти часы вовсе не неподвижны.
Под возрастом я понимаю прошедшее время по локальным часам объекта с момента начала эксперимента
Уже лучше. Теперь следующий пункт.
Вы понимаете, что временное измерение пространства-времени и часы это разные вещи ? Часы - механизм, который чего-то там считает. Так вот, что он считает-то ? Что такое "прошедшее время" ?
*Пока вы не видите слона. И ключевые слова ни разу не указали.
Прекрасно видно, что коты в итоге встречаются в одной и той же точке пространства-времени.
На данный момент, вы не понимаете самых базовых вещей :facepalm Но в вашем случае, надеюсь, это поправимо.
Поэтому начнём.
Что такое отношение "старше-младше" ? Как оно связано с понятием "возраст" ? И что такое этот самый "возраст" у Галилея и в СТО ?
P.S. Способ обучения основанный на попытке объяснить неясную тему другим, на самом деле, очень неплох. Но делать это путём публикации огромной статьи на ресурсе с гигантской аудиторией, при этом не дав вычитать текст хотя бы трём людям, которые действительно понимают в теме (на Хабре их, кстати, достаточно)... Это уже отдаёт манией величия :)
Схожую позицию разделяет Реймонд Чен, объясняя почему функция ReadFile() из WinAPI никогда не возвращает меньше байт, чем было запрошено, при условии, что конец файла не был достигнут.
ReadFile() запросто возвращает меньше чем запрошено.
Например, когда читается буфер консоли и она в режиме ENABLE_LINE_INPUT. Будет построчное чтение. При этом не помешает ещё и GetLastError() проверять каждый раз, так как за кадром может приехать Ctrl+C.
Далее, а что такое "конец файла" для pipe-ов ? Их чтение "разбивается" на куски операцией записи в pipe. И нормальное поведение в этом случае - продолжать читать, а не отваливаться с сообщением о "конце файла".
Таким образом, и на WinAPI, любой минимально обобщённый код на тему должен учитывать возможность частичного чтения.
ssize_t r = ::read(fd, b, std::min(sz, (size_t)0x7ffff000)); // On Linux, read() will transfer at most 0x7ffff000 bytes
if (r == -1)
throw IOError();
Вот здесь не все возвраты -1 будут ошибкой. Если в errno находится EINTR, то такую ситуацию надо обрабатывать как частичное чтение, которое не успело прочитать совсем ничего (0 байт).
Даже в 7-ой версии не сделано то, что должно было быть реализовано ещё в самом первом релизе: Complex Types\Value Objects, нормальная поддержка стандартных SQL-функций типа MIN\MAX и т.д.
Не понимаю о чём вы, объекты-значения поддерживаются давно. Мы их используем.
Для Microsoft SQL Server функций поддерживается много. А для SQLite, например, из стандартных математических в 7-ой есть только ABS, MAX, MIN, ROUND. И те не работают, так как см. выше...
Он действительно решает свою задачу.
Вы путаете "решает свою задачу" с "альтернативы отсутствуют".
Но! Я заметил, что многие от ORM ожидают поддержки на уровне SQL, а такие ожидания ошибочные.
Почему ? Есть какие-то концептуальные препятствия ?
В целом, по факту реализованных проектов могу сказать со 100% уверенностью. Это EF очень удобный инструмент для комфортной и быстрой разработки.
Давайте я процитирую свой исходный комментарий:
"EF Core до 3.1 был абсолютно ужасен. Одному проекту с моим участием сильно повезло, что дедлайн релиза был через пару месяцев после выхода 3.1 и мы миновали основные капуты типа множественных запросов вместо JOIN"
Но начиная с EF 8, ситуация изменилась.
Как хорошо-то. Через 7+ лет наконец-то сделали базовую фичу, которая должна была быть ещё в самом первом релизе.
Вот и я о чем. А тут…! ПК к середине 90х только достигнут этого уровня!
На PC такой уровень был ровно тогда же когда и на Sun.
Насколько можно судить, на фото SunDiag запущенный на системе с GS CG12.
GS CG12 это видеоадаптер-ускоритель разработки Matrox. Практически такой же (и за такие же деньги) они выпускали и для PC. MG-3D Ultra назывался.
И у него, кстати, разрешение было больше :) В Sun, ещё со времён их первых аппаратов, было стандартизировано 1152x900 (чтобы влезало в 1 MB видеопамяти с 8-битным цветом), а на PC уже успели к 1280x1024 прийти (при 24-битном цвете как раз в 4 MB умещается).
А ещё хотелось бы, наконец, узнать почему у CGA такие странные палитры. Вопрос уже лет 30 мучает. Должны быть какие-то технические причины для этого.
Да вроде всё очевидно: RGBI; контрастность и яркость; экономия, а значит оптимизации и хаки.
Я вижу, что 4 палитры из 6
Формально там две палитры. Ещё две обеспечивает отдельно выставляемый глобальный бит интенсивности.
имеют фиксированные яркость и синий цвет (одинаковые для цветов 1-3), а 2 бита управляют зелёным и красным каналами.
Верно. В палитрах зафиксирован бит синего. Вот и (почти) вся "магия".
Кроме цвета 0, он может быть любым из 16 и обычно черный.
Да, для 00x реализован специальный хак выбора любого из 16 цветов.
И не забываем коричневый цвет. Это специальный хак уже в схеме соответствующих RGBI-мониторов производства IBM. Многие мониторы сторонних производителей его не содержали.
Через композитный выход же коричневого вообще не было.
Оставшие 2 палиты так же имеют фиксированный бит яркости, но 2 бита управляют зелёным+синим и красным каналами. Почему так?
Эта пара палитра + интенсивность возникает в отдельном режиме - Mode 5. И на самом деле она идентична палитре 1 из Mode 4, но в Mode 5 выключена генерация сигнала color burst для композитного выхода, что даёт там чёрно-белую картинку. А так как схема построения композитного и RGBI "выхлопов" была на самом деле общая, опять-таки ради экономии, то из-за её особенностей возникал побочный эффект - на мониторах фиолетовый становился красным.
Один костыль для нулевого цвета запилили, а ещё 3 костыля для остальных цветов пожалели?
Вы просто не представляете себе цену этого "ещё 3" в 1981 году. В оригинальном CGA экономили на всём. Поддержка композитного выхода NTSC была сделана на линиях задержки, например.
*Напомню, родоначальник почти всего IBM Personal Computer (он же IBM Model 5150, он же IBM PC) c 16(!)KB памяти, CGA, клавиатурой, без дисководов и без монитора продавался за 1565 долларов. Тогдашних долларов. В нынешних это ~5500.
В идеальном мире: повернул щуп кватернионами по узлам и свел клешню, чтобы взять что-нибудь, снова повернул кватернионами чтобы переставить в другое место, разжал клешню.
В идеальном мире никакие кватернионы не нужны. Там достаточно просто кнопку нажать.
В реальном мире: механические узлы оказались не настолько точными, как математика, в итоге поворот произошёл с различными скоростями по разным осям и оказался на пол сантиметра в стороне от ожидаемой позиции из-за инерциальности системы, а обратный поворот заставляет гнуться узлы на неадекватные углы, в итоге после десятка попыток перетащить объект один из локтей или выходит из строя или начинает клинить, при этом продолжая регистрировать, что происходит движение.
То что кто-то не в курсе что такое погрешность, не понимает необходимости учитывать инерцию, не знает о наличии такой концепции как "граничные условия", не думает о возможности отказов - никак не связано с математикой.
Как итог начинают появляться "костыли" для компенсации и тюнинга под конкретные железки в системе.
Всё что можно запрограммировать - подмножество математики. Причём очень маленькое подмножество. Просто кто-то не умеет в нормальное матмоделирование.
Например, искать в огромной документации - это боль и отдельное искусство.
Документация это тот же самый код. Просто на другом языке. И если исходный-то код кривой, то какие основания полагать, что документация внезапно будет вся такая и хорошо структурированная, и понятная, и удобная, и вообще прелесть ?
Парадокс в том, что нужно дать ответ, какой из братьев окажется старше и почему.
Суть оригинального парадокса близнецов вовсе не в разнице в возрасте, а в утверждении о симметричности движения братьев исходя из принципа относительности. Противоречие с возрастами всего лишь следствие заявленной симметрии.
Ошибка парадокса в том, что в его условиях принцип относительности неприменим, так как он касается только движения в ИСО.
В случае исходной формулировки парадокса, брат-домосед всё время находится в одной и той же ИСО, тогда как у брата-пилота есть участки движения с ускорением. И, соответственно, полное движение братьев симметричным не является.
Аналогично и в вашей формулировке - наличие участков с ускорением, в то время как другой брат сидит в ИСО, исключает симметрию основывающуюся на принципе относительности.
А как там конкретно стареют братья не имеет никакого значения, на самом деле.
*Но если вы хотите всё-таки о возрастах, то для начала вам нужно сформулировать ваш (якобы) парадокс с учётом вышесказанного.
Даже в 7-ой версии не сделано то, что должно было быть реализовано ещё в самом первом релизе: Complex Types\Value Objects, нормальная поддержка стандартных SQL-функций типа MIN\MAX и т.д.
просто лучший!
Но, возможно, действительно лучший в своём классе. Как это ни печально.
Сейчас же, на EF писать прям кайф.
EF Core до 3.1 был абсолютно ужасен. Одному проекту с моим участием сильно повезло, что дедлайн релиза был через пару месяцев после выхода 3.1 и мы миновали основные капуты типа множественных запросов вместо JOIN.
Вообще не понятно, как после всего опыта разработки оригинального EF для .NET Framework можно было так накосячить.
Я, простите, запутался: как подружить утверждение, что фильтр гарантирует отсутствие ложноотрицательных срабатываний и то, что он гарантирует точность только для добавленных в него элементов?
Утверждения о ложноотрицательности\ложноположительности BloomFilter относятся только к условию "элемент x принадлежит фильтру".
Ложноотрицательность здесь - фильтр ответил "нет", но на самом деле элемент добавлялся. И такого быть не может, так как BloomFilter никогда не сбрасывает битики, а только выставляет.
Соответственно, ложноположительность - фильтр ответил "да", но на самом деле элемент никогда не добавлялся. А вот это вполне возможно, так как BloomFilter игнорирует коллизии хэшей.
На платах на фото видны примерно по сотне дискретных (и не очень) элементов обвязки и прочие разъёмы. Как решается вопрос с отказами среди них ?
Ещё интересен вопрос насчёт радиационной стойкости. Значительное увеличение объёмов памяти, уменьшение технологических норм (тут, правда, может быть как минус так и плюс в зависимости от), многослойные чипы и прочая 3D-упаковка, а также существенный рост просто количества электроники в одной единице техники должны заметно повышать вероятность всяких single event сотоварищи. На эту тему есть какие-то шевеления ?
Возможность "поменять местами картинки... и прийти к противоположному результату... используя ту же самую логику" задаётся принципом относительности. Но принцип относительности касается только инерциальных систем отсчёта. В парадоксе близнецов же кот-космонавт находится в неинерциальной системе отсчёта. Поэтому утверждать о симметричности движений котов нельзя.
Вы описываете что-то из времён Евклида. В современной физике у термина "постулат" никакого специального смысла нет. Это синоним "аксиомы".
Во-первых, сохранение энергии следует из гомогенности, а не изотропности.
Во-вторых, оно следует из гомогенности времени. В контексте же вывода СТО без постулата о скорости света речь шла о гомогенности и изотропности пространства.
*Хороший капкан получился :)
Нет, не отсутствует.
Насколько помню, это всего лишь артефакт выбранной системы координат. Можно взять такую аффинную систему, в которой скорость нормально определяется как касательная к мировой линии и для фотона.
Потому что так нарисовано на вашей диаграмме. Коты встречаются в точке пространства-времени с координатами в ИСО спящего кота (x=0, t=12). Ни в каком "дальше в будущем" никто не находится. Оба кота здесь и сейчас.
С точки зрения кота-космонавта эти часы вовсе не неподвижны.
Уже лучше. Теперь следующий пункт.
Вы понимаете, что временное измерение пространства-времени и часы это разные вещи ? Часы - механизм, который чего-то там считает. Так вот, что он считает-то ? Что такое "прошедшее время" ?
*Пока вы не видите слона. И ключевые слова ни разу не указали.
Нет. Без постулата о скорости света нужно делать предположения о гомогенности и изотропности или что-то ещё эквивалентное им.
Конечно же нет. Смотрим вашу диаграмму Минковского:
https://habrastorage.org/r/w1560/getpro/habr/upload_files/e9a/a6f/e6a/e9aa6fe6a69a21b62aaa81fb839e5857.png
Прекрасно видно, что коты в итоге встречаются в одной и той же точке пространства-времени.
На данный момент, вы не понимаете самых базовых вещей :facepalm Но в вашем случае, надеюсь, это поправимо.
Поэтому начнём.
Что такое отношение "старше-младше" ? Как оно связано с понятием "возраст" ? И что такое этот самый "возраст" у Галилея и в СТО ?
P.S. Способ обучения основанный на попытке объяснить неясную тему другим, на самом деле, очень неплох. Но делать это путём публикации огромной статьи на ресурсе с гигантской аудиторией, при этом не дав вычитать текст хотя бы трём людям, которые действительно понимают в теме (на Хабре их, кстати, достаточно)... Это уже отдаёт манией величия :)
Как он может быть "дальше в будущем", если он возвращается в ту же самую точку пространства-времени, в который находится спящий кот ? Непонятно.
ReadFile() запросто возвращает меньше чем запрошено.
Например, когда читается буфер консоли и она в режиме ENABLE_LINE_INPUT. Будет построчное чтение. При этом не помешает ещё и GetLastError() проверять каждый раз, так как за кадром может приехать Ctrl+C.
Далее, а что такое "конец файла" для pipe-ов ? Их чтение "разбивается" на куски операцией записи в pipe. И нормальное поведение в этом случае - продолжать читать, а не отваливаться с сообщением о "конце файла".
Таким образом, и на WinAPI, любой минимально обобщённый код на тему должен учитывать возможность частичного чтения.
Посмотрел по диагонали вашу библиотеку...
Вот здесь не все возвраты -1 будут ошибкой. Если в errno находится EINTR, то такую ситуацию надо обрабатывать как частичное чтение, которое не успело прочитать совсем ничего (0 байт).
Вот об этом:
https://learn.microsoft.com/en-us/ef/core/what-is-new/ef-core-8.0/whatsnew#value-objects-using-complex-types
Всё это должно было быть реализовано в самой первой версии EF Core, а не в 8-ой.
Вот здесь, 3-е место:
https://habr.com/ru/companies/pvs-studio/articles/766948/
Для Microsoft SQL Server функций поддерживается много. А для SQLite, например, из стандартных математических в 7-ой есть только ABS, MAX, MIN, ROUND. И те не работают, так как см. выше...
Вы путаете "решает свою задачу" с "альтернативы отсутствуют".
Почему ? Есть какие-то концептуальные препятствия ?
Давайте я процитирую свой исходный комментарий:
"EF Core до 3.1 был абсолютно ужасен. Одному проекту с моим участием сильно повезло, что дедлайн релиза был через пару месяцев после выхода 3.1 и мы миновали основные капуты типа множественных запросов вместо JOIN"
Как хорошо-то. Через 7+ лет наконец-то сделали базовую фичу, которая должна была быть ещё в самом первом релизе.
На PC такой уровень был ровно тогда же когда и на Sun.
Насколько можно судить, на фото SunDiag запущенный на системе с GS CG12.
GS CG12 это видеоадаптер-ускоритель разработки Matrox. Практически такой же (и за такие же деньги) они выпускали и для PC. MG-3D Ultra назывался.
И у него, кстати, разрешение было больше :) В Sun, ещё со времён их первых аппаратов, было стандартизировано 1152x900 (чтобы влезало в 1 MB видеопамяти с 8-битным цветом), а на PC уже успели к 1280x1024 прийти (при 24-битном цвете как раз в 4 MB умещается).
Всё там было. Просто в 1990 году цена добавления таких удобств начиналась в районе $5000 (без монитора), поэтому лично вы с ними и не встречались.
Да вроде всё очевидно: RGBI; контрастность и яркость; экономия, а значит оптимизации и хаки.
Формально там две палитры. Ещё две обеспечивает отдельно выставляемый глобальный бит интенсивности.
Верно. В палитрах зафиксирован бит синего. Вот и (почти) вся "магия".
Да, для 00x реализован специальный хак выбора любого из 16 цветов.
И не забываем коричневый цвет. Это специальный хак уже в схеме соответствующих RGBI-мониторов производства IBM. Многие мониторы сторонних производителей его не содержали.
Через композитный выход же коричневого вообще не было.
Эта пара палитра + интенсивность возникает в отдельном режиме - Mode 5. И на самом деле она идентична палитре 1 из Mode 4, но в Mode 5 выключена генерация сигнала color burst для композитного выхода, что даёт там чёрно-белую картинку. А так как схема построения композитного и RGBI "выхлопов" была на самом деле общая, опять-таки ради экономии, то из-за её особенностей возникал побочный эффект - на мониторах фиолетовый становился красным.
Вы просто не представляете себе цену этого "ещё 3" в 1981 году. В оригинальном CGA экономили на всём. Поддержка композитного выхода NTSC была сделана на линиях задержки, например.
*Напомню, родоначальник почти всего IBM Personal Computer (он же IBM Model 5150, он же IBM PC) c 16(!) KB памяти, CGA, клавиатурой, без дисководов и без монитора продавался за 1565 долларов. Тогдашних долларов. В нынешних это ~5500.
Можно подробнее ?
*В большинстве случаев, когда возникают такие идеи и желания это означает, что всё делается неправильно :)
Если реальный код именно такой, и доступа к
badTempTargetнигде больше нет, то там не нужен lock. Достаточно объявить поле volatile.В идеальном мире никакие кватернионы не нужны. Там достаточно просто кнопку нажать.
То что кто-то не в курсе что такое погрешность, не понимает необходимости учитывать инерцию, не знает о наличии такой концепции как "граничные условия", не думает о возможности отказов - никак не связано с математикой.
Всё что можно запрограммировать - подмножество математики. Причём очень маленькое подмножество. Просто кто-то не умеет в нормальное матмоделирование.
Документация это тот же самый код. Просто на другом языке. И если исходный-то код кривой, то какие основания полагать, что документация внезапно будет вся такая и хорошо структурированная, и понятная, и удобная, и вообще прелесть ?
Суть оригинального парадокса близнецов вовсе не в разнице в возрасте, а в утверждении о симметричности движения братьев исходя из принципа относительности. Противоречие с возрастами всего лишь следствие заявленной симметрии.
Ошибка парадокса в том, что в его условиях принцип относительности неприменим, так как он касается только движения в ИСО.
В случае исходной формулировки парадокса, брат-домосед всё время находится в одной и той же ИСО, тогда как у брата-пилота есть участки движения с ускорением. И, соответственно, полное движение братьев симметричным не является.
Аналогично и в вашей формулировке - наличие участков с ускорением, в то время как другой брат сидит в ИСО, исключает симметрию основывающуюся на принципе относительности.
А как там конкретно стареют братья не имеет никакого значения, на самом деле.
*Но если вы хотите всё-таки о возрастах, то для начала вам нужно сформулировать ваш (якобы) парадокс с учётом вышесказанного.
EF Core совсем даже не шикарный.
Даже в 7-ой версии не сделано то, что должно было быть реализовано ещё в самом первом релизе: Complex Types\Value Objects, нормальная поддержка стандартных SQL-функций типа MIN\MAX и т.д.
Но, возможно, действительно лучший в своём классе. Как это ни печально.
EF Core до 3.1 был абсолютно ужасен. Одному проекту с моим участием сильно повезло, что дедлайн релиза был через пару месяцев после выхода 3.1 и мы миновали основные капуты типа множественных запросов вместо JOIN.
Вообще не понятно, как после всего опыта разработки оригинального EF для .NET Framework можно было так накосячить.
Утверждения о ложноотрицательности\ложноположительности BloomFilter относятся только к условию "элемент x принадлежит фильтру".
Ложноотрицательность здесь - фильтр ответил "нет", но на самом деле элемент добавлялся. И такого быть не может, так как BloomFilter никогда не сбрасывает битики, а только выставляет.
Соответственно, ложноположительность - фильтр ответил "да", но на самом деле элемент никогда не добавлялся. А вот это вполне возможно, так как BloomFilter игнорирует коллизии хэшей.
На платах на фото видны примерно по сотне дискретных (и не очень) элементов обвязки и прочие разъёмы. Как решается вопрос с отказами среди них ?
Ещё интересен вопрос насчёт радиационной стойкости. Значительное увеличение объёмов памяти, уменьшение технологических норм (тут, правда, может быть как минус так и плюс в зависимости от), многослойные чипы и прочая 3D-упаковка, а также существенный рост просто количества электроники в одной единице техники должны заметно повышать вероятность всяких single event сотоварищи. На эту тему есть какие-то шевеления ?