Должен поправиться, однокашник указал на ошибку и дал источник.
Ученые из ОИВТ (Объединенный институт высоких температур) РАН год назад опубликовали работу в Physical Review Letters, из которой следует что графит не только не кипит при 4200С, но и остается твердым до ~6000K (желающие могут поправить Википедию, море недостоверности станет на каплю меньше).
Таким образом всё сильно проще — получается что можно сделать тигель из графита.
Плохо другое — люди начинают путать реальность с комиксами и PR для "раскрутки акций" и т.п. вплоть до веры что персонаж из фильма (или игравший его актер) может вывести страну из кризиса.
Чтобы хорошо разбираться в подобных темах люди учатся и специализируется по 10-15 лет. В таких масштабах я никак не могу причислить себя к специалистам. Тем не менее, за >25 лет все базовые принципы остались в силе. Поэтому не думаю что по "старой памяти" я сильно навру.
При таких температурах это крайне трудная задача из ~четырех слагаемых:
определять/детектировать совокупность процессов плавления на некотором отрезке температур (в реальности нет "точки" плавления). Очень желательно/хочется при этом оценивать/измерять/отслеживать изменение свойств образца (твердость, прочность, теплопроводность и т.д.)
нагревать образец приемлемо-равномерно и контролируемо.
образец, "горелку" и "термометр" нужно удерживать, а при целевой температуре (например) графит уже не просто жидкий, он кипит!
изменять температуру (определять температурный ландшафт), в том числе иметь понимание (модель) о температуре внутри образца, в том числе помех/засветов от нагревателя и камеры, от испарений "всего вокруг", и поглощения излучения этими парами...
В "лоб" это сделать не возможно. Приходиться придумывать массу самых различных трюков (доказывая что измерения будут корректными) и стоить стенд, который выдержит несколько измерений. В целом, это отдельная уникальная инженерно-научная задача...
С другой стороны, для практических применений важна не температура плавления "шарообразного образца" в вакууме, а поведение в конкретных условиях. В том числе, насколько лучше/хуже новый материал относительно других при применении в составе конкретных изделий...
Поэтому хотелось-бы попросить у mperemitina отдельной статьи по этой достойной теме.
Если сложить границы всех интервалов в упорядоченный контейнер (массив или дерево), то в четных позициях будут начала интервалов, а в нечетных концы.
Затем достаточно искать begin/end вычитаемых или включаемых интервалов и реализовать логику включения/исключения с удалением из контейнера "закрашиваемых" границ.
Либо просто задействовать boost::icl::interval_set ;)
Сильно зависит от локации. В деревне перешел на subj ради LTE (стоит wifi-роутер с симкой и на 4K-телеке прекрасно работает IVI, YT и что-то еще).
входящие SMS именно на билайне у меня часто «застревали»,
В msk наблюдаю регулярно, включая отваливание 3G/LTE при наличии сигнала и т.п.
Уже привык лечить переводом телефон в режим полета (на 1/2 минуты или больше) и обратно
Но неудобно, особенно когда случаются "залеты" — несколько часов не видишь рабочую почту или сообщения.
Даже думал прогу написать, чтобы раз в 5-10 минут проверяла связь и временно "полётила" телефон.
Т.е. компилятор сможет выкинуть больше кода не из-за того что какие-то функции не вызываются (ибо они будут вызываться, это достижимый код), а потому-что эти функции не заканчиваются системными вызовами и не оказывают влияния на результат работы (являются мертвым кодом, включая все операции подготовки их аргументов).
Ок, предположим что так бывает.
В чем тогда провинилось RT?
Т.е. "де-факто" вам сказали (и возможно показали на кошечках) что дела обстоят неким подобным образом.
Но де-факто RT не имеет возможность вещать несмотря на готовность (местных подписчиков!) оплачивать доставку контента?
Очень-очень похоже на глушение вражеских СМИ в эпоху Брежневского застоя.
Только теперь они нас запрещают, но сами "свистят" вовсю.
Вангую что после Трампа в США придут "Андропов-Черненко-Горбачев" и начнётся "perestoyka" ;)
В том-то и дело, что у нас с вами нет WAL by design.) К тому же репликация на уровне WAL как в Postgre — не самая эффективная штука.
В частности поэтому (и еще массе других причин) я не хочу делать репликацию в MDBX.
Тут, кстати, можно посмотреть в сторону чего-нибудь типа delta-crdt, позволяющего мёржить несколько баз в одну. То есть при репликации писать не просто в очередь, а во временную базу имеющую ту же структуру, которую можно подклеить к реплике минимальными телодвижениями.
Это все частные случаи из моря возможных потребностей и их реализаций. В 80% случаев пользовательские данные не натягиваются на CRDT, либо превращаются в снежный ком. Аналогично с отдельной очередью в виде базы (или наоборот).
Файловая система мне выдаёт несколько битых файлов.
Это если нет контроля и повреждены файлы, а не структуры ФС.
Но в принципе может не выдать ничего или просто мусор.
А еще можно (мысленно) разбить диск молотком или вообще не устанавливать, а на запросы отвечать случайными данными.
Я склоняюсь к тому, как это сделано в OrientDB: есть N кластеров (файлов), куда по определённым правилам раскидываются узлы…
Вот, кстати, партицирования у LMDB я так понимаю тоже нет.
А причем тут OrientDB и партиционирование?
MDBX/LMDB — это встраиваемые движки key-value для совместной работы с БД несколькими локальными процессами. В этих целевых сценариях MDBX обеспечивает до 1M пишущих транзакций в секунду и примерно линейно масштабирутся в производительности чтения по ядрам CPU (десятки миллионов запросов в секунду, пока не упирается в memory bandwidth).
Никакому OrientDB в таких сценариях подобное и не снилось.
А для других (не целевых для MDBX) сценариев использования есть другие движки или СУБД, в том числе со всяческим партиционированием и SQL с блекджеком.
А, ну если так и собираетесь оставаться в детском саду, то вы мне не конкурент.)
Хм, а после "детского сада" сколько СУБД (в широком смысле) вы написали (или приняли участие) и довели до production?
Спасибо, конечно, но табличками я сыт по горло.
Каждый "сыт" тем что ему не нужно, и наоборот.
Т.е. "таблички" не в чем не виноваты, это решение предназначенное для некоторого подмножества сценариев использования.
Вы работали когда-нибудь с графовыми СУБД?
Ну делал я их, и видимо скоро снова продолжу (варианты для RDF).
Должен поправиться, однокашник указал на ошибку и дал источник.
Ученые из ОИВТ (Объединенный институт высоких температур) РАН год назад опубликовали работу в Physical Review Letters, из которой следует что графит не только не кипит при 4200С, но и остается твердым до ~6000K (желающие могут поправить Википедию, море недостоверности станет на каплю меньше).
Таким образом всё сильно проще — получается что можно сделать тигель из графита.
Плохо другое — люди начинают путать реальность с комиксами и PR для "раскрутки акций" и т.п. вплоть до веры что персонаж из фильма (или игравший его актер) может вывести страну из кризиса.
Собственно такое было всегда, но все-же неожиданно что "за 2000 лет люди не изменились".
Всё.
Чтобы хорошо разбираться в подобных темах люди учатся и специализируется по 10-15 лет. В таких масштабах я никак не могу причислить себя к специалистам. Тем не менее, за >25 лет все базовые принципы остались в силе. Поэтому не думаю что по "старой памяти" я сильно навру.
При таких температурах это крайне трудная задача из ~четырех слагаемых:
В "лоб" это сделать не возможно. Приходиться придумывать массу самых различных трюков (доказывая что измерения будут корректными) и стоить стенд, который выдержит несколько измерений. В целом, это отдельная уникальная инженерно-научная задача...
С другой стороны, для практических применений важна не температура плавления "шарообразного образца" в вакууме, а поведение в конкретных условиях. В том числе, насколько лучше/хуже новый материал относительно других при применении в составе конкретных изделий...
Поэтому хотелось-бы попросить у mperemitina отдельной статьи по этой достойной теме.
О, еще один иксперт по википедии )
TL;DR
Что-то вы наворотили.
Если сложить границы всех интервалов в упорядоченный контейнер (массив или дерево), то в четных позициях будут начала интервалов, а в нечетных концы.
Затем достаточно искать begin/end вычитаемых или включаемых интервалов и реализовать логику включения/исключения с удалением из контейнера "закрашиваемых" границ.
Либо просто задействовать
boost::icl::interval_set;)Осталось выяснить кто и как из авторов википедии измерил оную температуру плавления ;)
Там все просто — охлаждение за счет испарения.
Ну так воздерживайтесь от ерунды, если вы не специалист.
Причем все поклоняющиеся этой иконе думают что subj умеет что-то рукам делать, очень много знает и т.д. и т.п
off-topic: Хотелось-бы увидеть статью по текущему состоянию и будущему Compreno, что было сделано за 5 лет (после Андреева) и т.п.
Сильно зависит от локации. В деревне перешел на subj ради LTE (стоит wifi-роутер с симкой и на 4K-телеке прекрасно работает IVI, YT и что-то еще).
В msk наблюдаю регулярно, включая отваливание 3G/LTE при наличии сигнала и т.п.
Уже привык лечить переводом телефон в режим полета (на 1/2 минуты или больше) и обратно
Но неудобно, особенно когда случаются "залеты" — несколько часов не видишь рабочую почту или сообщения.
Даже думал прогу написать, чтобы раз в 5-10 минут проверяла связь и временно "полётила" телефон.
Не переживайте, просто вы Нео и теперь в матрице.
Если страница полностью именно с "неизменяемыми данными", то да — бесплатной компактификации не получится, только явная.
Речь об эффекте от удаления мертвого кода, что на стоит путать (например) с удалением недостижимого кода.
Т.е. компилятор сможет выкинуть больше кода не из-за того что какие-то функции не вызываются (ибо они будут вызываться, это достижимый код), а потому-что эти функции не заканчиваются системными вызовами и не оказывают влияния на результат работы (являются мертвым кодом, включая все операции подготовки их аргументов).
Ок, предположим что так бывает.
В чем тогда провинилось RT?
Т.е. "де-факто" вам сказали (и возможно показали на кошечках) что дела обстоят неким подобным образом.
Но де-факто RT не имеет возможность вещать несмотря на готовность (местных подписчиков!) оплачивать доставку контента?
Жмакнул в "за".
Ха-ха, никогда не было и вот опять.
Очень-очень похоже на глушение вражеских СМИ в эпоху Брежневского застоя.
Только теперь они нас запрещают, но сами "свистят" вовсю.
Вангую что после Трампа в США придут "Андропов-Черненко-Горбачев" и начнётся "perestoyka" ;)
В частности поэтому (и еще массе других причин) я не хочу делать репликацию в MDBX.
Это все частные случаи из моря возможных потребностей и их реализаций. В 80% случаев пользовательские данные не натягиваются на CRDT, либо превращаются в снежный ком. Аналогично с отдельной очередью в виде базы (или наоборот).
https://pro-ldap.ru/tr/rfc/rfc4533.html
Это если нет контроля и повреждены файлы, а не структуры ФС.
Но в принципе может не выдать ничего или просто мусор.
А еще можно (мысленно) разбить диск молотком или вообще не устанавливать, а на запросы отвечать случайными данными.
Какой вариант вам кажется наиболее правильным?
А причем тут OrientDB и партиционирование?
MDBX/LMDB — это встраиваемые движки key-value для совместной работы с БД несколькими локальными процессами. В этих целевых сценариях MDBX обеспечивает до 1M пишущих транзакций в секунду и примерно линейно масштабирутся в производительности чтения по ядрам CPU (десятки миллионов запросов в секунду, пока не упирается в memory bandwidth).
Никакому OrientDB в таких сценариях подобное и не снилось.
А для других (не целевых для MDBX) сценариев использования есть другие движки или СУБД, в том числе со всяческим партиционированием и SQL с блекджеком.
Хм, а после "детского сада" сколько СУБД (в широком смысле) вы написали (или приняли участие) и довели до production?
Каждый "сыт" тем что ему не нужно, и наоборот.
Т.е. "таблички" не в чем не виноваты, это решение предназначенное для некоторого подмножества сценариев использования.
Ну делал я их, и видимо скоро снова продолжу (варианты для RDF).