Возможность "поменять местами картинки... и прийти к противоположному результату... используя ту же самую логику" задаётся принципом относительности. Но принцип относительности касается только инерциальных систем отсчёта. В парадоксе близнецов же кот-космонавт находится в неинерциальной системе отсчёта. Поэтому утверждать о симметричности движений котов нельзя.
Вообще "постулат" в физике это что-то принимаемое в теории, но всё равно вытекаемое обычно из опыта.
Вы описываете что-то из времён Евклида. В современной физике у термина "постулат" никакого специального смысла нет. Это синоним "аксиомы".
Что касается "изотропности" - то из неё вытекает Закон сохранения энергии. Вряд ли он иметь отношение к СТО.
Во-первых, сохранение энергии следует из гомогенности, а не изотропности.
Во-вторых, оно следует из гомогенности времени. В контексте же вывода СТО без постулата о скорости света речь шла о гомогенности и изотропности пространства.
т.к. отсутствует понятие времени - оно в "системе отсчёта света" схлопнуто в точный ноль.
Насколько помню, это всего лишь артефакт выбранной системы координат. Можно взять такую аффинную систему, в которой скорость нормально определяется как касательная к мировой линии и для фотона.
Потому что так нарисовано на вашей диаграмме. Коты встречаются в точке пространства-времени с координатами в ИСО спящего кота (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+ лет наконец-то сделали базовую фичу, которая должна была быть ещё в самом первом релизе.
те феноменальные результаты, которые показывают процессоры Apple в сравнении с Intel и AMD как раз и демонстрируют,
Феноменальными у семейства M1 были прежде всего размер кэша и пропускная способность памяти. Как только конкурирующие организации тоже завели себе 100+ MB кэша и удвоили толщину канала с памятью, то результаты Apple тут же закончились.
где больше нехорошего легаси гавна накопилось -- в x86 или ARM.
И таким образом, архитектурное legacy вообще не имеет отношения к вопросу.
Не "свободно", а "доступно". Пункт "Кэшировано" показывает, что эти 30 GB вполне себе используются прямо сейчас в качестве прозрачного кэша файловой системы.
ФИЗИЧЕСКОЙ памяти 30гб
В современных ОС, то что вы называете "физической памятью" это на самом деле всего лишь страничный кэш для настоящей памяти, которой являются pagefile.sys и прочие file mappings и section objects.
И на скриншоте видно, что настоящая память (пункт "Выделено") как раз почти полностью выжрана.
*Кстати, тот самый Chrome именно так и "работает". Хапает память (настоящую) как не в себя, но при этом единовременно реально использует меньше половины захапанного.
Так что со сценарием нагрузки со скриншота имеет смысл увеличить размер pagefile.sys раза в полтора-два.
Вот и я о чем. А тут…! ПК к середине 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.
В идеальном мире: повернул щуп кватернионами по узлам и свел клешню, чтобы взять что-нибудь, снова повернул кватернионами чтобы переставить в другое место, разжал клешню.
В идеальном мире никакие кватернионы не нужны. Там достаточно просто кнопку нажать.
В реальном мире: механические узлы оказались не настолько точными, как математика, в итоге поворот произошёл с различными скоростями по разным осям и оказался на пол сантиметра в стороне от ожидаемой позиции из-за инерциальности системы, а обратный поворот заставляет гнуться узлы на неадекватные углы, в итоге после десятка попыток перетащить объект один из локтей или выходит из строя или начинает клинить, при этом продолжая регистрировать, что происходит движение.
То что кто-то не в курсе что такое погрешность, не понимает необходимости учитывать инерцию, не знает о наличии такой концепции как "граничные условия", не думает о возможности отказов - никак не связано с математикой.
Как итог начинают появляться "костыли" для компенсации и тюнинга под конкретные железки в системе.
Всё что можно запрограммировать - подмножество математики. Причём очень маленькое подмножество. Просто кто-то не умеет в нормальное матмоделирование.
Например, искать в огромной документации - это боль и отдельное искусство.
Документация это тот же самый код. Просто на другом языке. И если исходный-то код кривой, то какие основания полагать, что документация внезапно будет вся такая и хорошо структурированная, и понятная, и удобная, и вообще прелесть ?
Возможность "поменять местами картинки... и прийти к противоположному результату... используя ту же самую логику" задаётся принципом относительности. Но принцип относительности касается только инерциальных систем отсчёта. В парадоксе близнецов же кот-космонавт находится в неинерциальной системе отсчёта. Поэтому утверждать о симметричности движений котов нельзя.
Вы описываете что-то из времён Евклида. В современной физике у термина "постулат" никакого специального смысла нет. Это синоним "аксиомы".
Во-первых, сохранение энергии следует из гомогенности, а не изотропности.
Во-вторых, оно следует из гомогенности времени. В контексте же вывода СТО без постулата о скорости света речь шла о гомогенности и изотропности пространства.
*Хороший капкан получился :)
Нет, не отсутствует.
Насколько помню, это всего лишь артефакт выбранной системы координат. Можно взять такую аффинную систему, в которой скорость нормально определяется как касательная к мировой линии и для фотона.
Потому что так нарисовано на вашей диаграмме. Коты встречаются в точке пространства-времени с координатами в ИСО спящего кота (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+ лет наконец-то сделали базовую фичу, которая должна была быть ещё в самом первом релизе.
Я много каких характеристик не сравнивал. Ни техпроцесс, ни TDP, ни возможность сделать восьмисокетный сервер...
Феноменальными у семейства M1 были прежде всего размер кэша и пропускная способность памяти. Как только конкурирующие организации тоже завели себе 100+ MB кэша и удвоили толщину канала с памятью, то результаты Apple тут же закончились.
И таким образом, архитектурное legacy вообще не имеет отношения к вопросу.
Отличное наблюдение. Я уже забыл, что такое вообще бывает и даже не думал на тему.
В собственно отключении pagefile вроде ничего особо ужасного нет. Всё зависит от поведения нагрузки. И вот Chrome как раз очень плох в этом плане.
Не "свободно", а "доступно". Пункт "Кэшировано" показывает, что эти 30 GB вполне себе используются прямо сейчас в качестве прозрачного кэша файловой системы.
В современных ОС, то что вы называете "физической памятью" это на самом деле всего лишь страничный кэш для настоящей памяти, которой являются pagefile.sys и прочие file mappings и section objects.
И на скриншоте видно, что настоящая память (пункт "Выделено") как раз почти полностью выжрана.
*Кстати, тот самый Chrome именно так и "работает". Хапает память (настоящую) как не в себя, но при этом единовременно реально использует меньше половины захапанного.
Так что со сценарием нагрузки со скриншота имеет смысл увеличить размер pagefile.sys раза в полтора-два.
На 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.В идеальном мире никакие кватернионы не нужны. Там достаточно просто кнопку нажать.
То что кто-то не в курсе что такое погрешность, не понимает необходимости учитывать инерцию, не знает о наличии такой концепции как "граничные условия", не думает о возможности отказов - никак не связано с математикой.
Всё что можно запрограммировать - подмножество математики. Причём очень маленькое подмножество. Просто кто-то не умеет в нормальное матмоделирование.
Документация это тот же самый код. Просто на другом языке. И если исходный-то код кривой, то какие основания полагать, что документация внезапно будет вся такая и хорошо структурированная, и понятная, и удобная, и вообще прелесть ?