>Никто не мешает вам купить пульсоксиметр и провести эксперимент на себе, чтобы убедиться, что это бред.
Так и сделал. По 10 минут без маски, и с маской в состоянии покоя, посматривая youtube чтобы не концентрироваться на процессе.
Не нашёл никаких существенных различий ни в оксигинации, ни в пульсе.
Без маски:
96,97 — оксигинация, 73-76 пульс
С маской:
95-97 — оксигинация (97 преобладает), 70-80 пульс
Проходил АСИТ в киевском аллергоцентре.
Аллергия на бытовые аллергены. Никакого эффекта не заметил. А времени это занимает уйму.
Больше всего огорчило то, что приступ можно словить через неделю или через месяц.
Т.е. тогда, когда АСИТ уже должен действовать в полный рост.
Ещё бы практическое руководство по готовым (желательно бесплатным) инструментам.
Типа какчаем такую тулзу, запускаем такой батник, вот так скармливаем картинки — опа, получили автоматический распознаватель сисек
установить на носителях видеокамеры, чтобы изображение транслировалось в реальном времени в интернете.
Интересно, а вообще возможно видео в реальном времени транслировать?
Там же вроде и с обычной связью какие-то проблемы есть. А тут видео передавать.
Или я с посадкой путаю?
Просто если возможно, тогда непонятно почему до сих пор не прикрутили для расследования инциндентов?
Вот интересно, это сервы или моторы?
Там 3 провода. Они все силовые. Или один управляющий, как в серве?
Я к тому что можно ли этот мотор подключить напрямую к приёмнику к выходу под серву?
Мы когда-то пытались брутефорсить блочный шифр на FPGA.
Казалось, что FPGA для этого идеально подходит.
Я довольно быстро накатал прогу на Verilog. Так вот она у меня не смогла скопмилится. Даже один раунд.
Проблема в том, что ячейки в FPGA не соединяются каждая с каждой, а имеют ограниченное количество связей.
А в шифре есть таблица битовых перестановок. Получается такое себе битовое выражение, которое компилер пытался упростить,
чтобы вложится в доступное к-во связей. :)
Самое смешное, что трудоёмко, но вполне реально, сделать раунд блочного шифра на макетке, используя обычные логические микрухи и соединив их обычными проводками.
Так что не всё так просто с FPGA.
Я уж молчу про операции с плавающей точкой.
А с деструкторами тоже не всё так страшно.
Проблемы возникают только тогда, когда деструкторы выполняют код, который сам по себе может сгенерить исключение.
Например, пусть у нас есть транзакция, мы её оборачиваем RAII. Если коммит не проиходит, то происходит автоматический rollback() в деструкторе.
Теперь допустим в процессе обработки данных что-то пошло не так:
void do_something()
{
throw std::runtime_error("processing data failed");
}
Транзакция нормально откатывается:
begin transaction
rollback transaction
processing data failed
Теперь допустим, что в процессе обработки данных исключение не генерируется, но commit() не происходит, скажем по логическим причинам в самой проге. Тогда автоматом вызовется rollback() из деструктора. И вот допустим уже в rollback() происходит исключение:
void Transaction::rollback()
{
if(!active)
return;
throw std::runtime_error("something bad happens when we rollback transaction");
std::cout<<"rollback transaction"<<std::endl;
active=false;
}
bool do_something()
{
return false;
}
int main()
{
...
Transaction tr;
if(!do_something())
return 1;
tr.commit();
...
}
О боже! Мы не словили исключение в деструкторе и ничего не произошло. Мы успешно добрались до catch():
begin transaction
something bad happens when we rollback transaction
И вот только, если исключение в деструкторе генерируется в процессе обработки другого исключение, тогда у нас проблемы:
void Transaction::rollback()
{
if(!active)
return;
throw std::runtime_error("something bad happens when we rollback transaction");
std::cout<<"rollback transaction"<<std::endl;
active=false;
}
void do_something()
{
throw std::runtime_error("processing data failed");
}
int main()
{
...
Transaction tr;
do_something();
tr.commit();
...
}
Это весь вывод:
begin transaction
Что же делать? Если код в деструкторе достаточно простой, то обычно забивают и ничего не делают.
Можно просто глушить исключения в деструкторе, как многие рекомендуют.
Но я не считаю, что это хорошее решение. Т.к. в нашем случае, если транзакция нормально не откатится, то хорошо бы об этом знать.
Это, ваш пример не демонстрирует проблему с деструкторами.
Логично, что если main() не ловит исключение, оно перехватывается в std::terminate()
Важно понимать, что из std::terminate поток уже не возвращается. Поэтому логично, что до деструкторов дело не доходит.
Вместо того, чтобы давить исключение в testShared(), можно обернуть весь main()
Как-то так:
В В любом случае в этом есть смысл, т.к. вероятно вы хотите как-то хотя бы сообщать об ошибках в своей программе, прежде чем она тихо упадёт.
И тогда все деструкторы будут прекрасно отрабатываться.
А какие обязательства компании по IPO?
Просто выглядит так, что компания получает деньги на шару.
Даже, что компания может получать прибыль из воздуха.
Допустим мы захотели сделать ЯндексОчки.
Мы делаем вполне реальные очки, с туманной экономической перспективой.
Делаем побольше пафосных презентаций.
Запускаем закрытое тестирование.
Первые счастливые обладатели пишут свои обзоры на хабре.
Находим своего держателя акций (хотя бы даже и самого андеррайтера), выходим на IPO.
Делаем пафосное заявление, что компания уже настолько зрелая, что выходит на IPO.
Акции начинают расти.
Нанимаем штат программистов для написания приложений под ЯндексОчки.
Делаем пафосное заявление, что ЯндексОчки обладают полноценной средой.
Акции начинают расти.
Покупаем датацентр, ну например для распознавания образов в реалтйам.
Делаем пафосное заявление, что у нас теперь очки дополненной виртуальной реальности.
Акции начинают расти.
Вставляем ЯндексБар.
Делаем пафосное заявление, что теперь есть монетизация проекта.
Акции начинают расти.
И так ещё столько раз, сколько сможем.
При этом пофиг, что очки нормально не работают, софта нет, датацентр ничего не распознаёт, а ЯндексБар только бесит.
Пока инвесторы окончательно не поймут, что потребителю ЯндексОчки нафиг не сдались, наш договорной
инвестор продаёт свои акции, компания объявляется банкротом
или в лучшем случае продаётся с программистами и датацентром.
Договорной инвестор даёт откат основателям — все счастливы.
Риск только на этапе вложений в стартап. После этого с любого пункта можно спрыгнуть.
Эх! Хотел написать статью про ультразвуковой дальномер и «типа 3d сканер» на основе него.
Но т.к. результат оказался так себе, то ограничился сообщением на форуме.
>Загрузка системы идет в консольном режиме и управляется как раз через тот самый mini jaсk (telnet). Сами процессоры мы тестировали — в следующем обзоре выложим результаты тестов.
А можно подбробнее объяснить, как грузятся 10 лезвий после включения питания?
Для начала как они вообще сконфигурированы. Каждое лезвие грузится со своего винта (рейда)?
Сделать не просто сильную программу, а программу которая выигрывает всегда.
Действительно от функции многое зависит. Возможно, даже существует такая функция, которая реализует победную тактику без просмотра уровней вперёд. Для крестиков-ноликов ведь она существует, теоретически может существовать и для гомоку.
Алис в своей работе упоминал, что для успешной игры против профессионалов необходимо просматривать на 15 шагов вперёд. Из-за того, что это проблематично, придумывают разные эвристики, для ограничения перебора.
Игра сейчас заточена больше под анализ и поиск ошибок в алгоритме. В ней нет случайных ходов, и она никак не использует информацию из дерева решений.
Цель дерева решений — доказать, что крестики всегда выигрывают. Как бонус можно получить программу, которая также всегда выигрывает крестиками, начиная со стартовой позиции.
Так и сделал. По 10 минут без маски, и с маской в состоянии покоя, посматривая youtube чтобы не концентрироваться на процессе.
Не нашёл никаких существенных различий ни в оксигинации, ни в пульсе.
Без маски:
96,97 — оксигинация, 73-76 пульс
С маской:
95-97 — оксигинация (97 преобладает), 70-80 пульс
Разве что в маске жарковато в комнате.
pikabu.ru/story/pervobyitnaya_voyna_pochemu_lyudi_voyuyut_4031171
Аллергия на бытовые аллергены. Никакого эффекта не заметил. А времени это занимает уйму.
Больше всего огорчило то, что приступ можно словить через неделю или через месяц.
Т.е. тогда, когда АСИТ уже должен действовать в полный рост.
Типа какчаем такую тулзу, запускаем такой батник, вот так скармливаем картинки — опа, получили автоматический распознаватель сисек
Там 3 провода. Они все силовые. Или один управляющий, как в серве?
Я к тому что можно ли этот мотор подключить напрямую к приёмнику к выходу под серву?
Казалось, что FPGA для этого идеально подходит.
Я довольно быстро накатал прогу на Verilog. Так вот она у меня не смогла скопмилится. Даже один раунд.
Проблема в том, что ячейки в FPGA не соединяются каждая с каждой, а имеют ограниченное количество связей.
А в шифре есть таблица битовых перестановок. Получается такое себе битовое выражение, которое компилер пытался упростить,
чтобы вложится в доступное к-во связей. :)
Самое смешное, что трудоёмко, но вполне реально, сделать раунд блочного шифра на макетке, используя обычные логические микрухи и соединив их обычными проводками.
Так что не всё так просто с FPGA.
Я уж молчу про операции с плавающей точкой.
Проблемы возникают только тогда, когда деструкторы выполняют код, который сам по себе может сгенерить исключение.
Например, пусть у нас есть транзакция, мы её оборачиваем RAII. Если коммит не проиходит, то происходит автоматический rollback() в деструкторе.
#include <iostream> #include <vector> #include <memory> #include <string> #include <exception> class Transaction { bool active; public: Transaction() : active(false) { std::cout<<"begin transaction"<<std::endl; active=true; } ~Transaction() { rollback(); } void commit() { if(!active) return; std::cout<<"commit transaction"<<std::endl; active=false; } void rollback() { if(!active) return; std::cout<<"rollback transaction"<<std::endl; active=false; } }; void do_something() { } int main() { try { Transaction tr; do_something(); tr.commit(); } catch(const std::exception& e) { std::cerr<<e.what()<<std::endl; } catch(...) { std::cerr<<"Unknown exception"<<std::endl; } return 0; }Вывод ожидаемый:
Теперь допустим в процессе обработки данных что-то пошло не так:
void do_something() { throw std::runtime_error("processing data failed"); }Транзакция нормально откатывается:
Теперь допустим, что в процессе обработки данных исключение не генерируется, но commit() не происходит, скажем по логическим причинам в самой проге. Тогда автоматом вызовется rollback() из деструктора. И вот допустим уже в rollback() происходит исключение:
void Transaction::rollback() { if(!active) return; throw std::runtime_error("something bad happens when we rollback transaction"); std::cout<<"rollback transaction"<<std::endl; active=false; } bool do_something() { return false; } int main() { ... Transaction tr; if(!do_something()) return 1; tr.commit(); ... }О боже! Мы не словили исключение в деструкторе и ничего не произошло. Мы успешно добрались до catch():
И вот только, если исключение в деструкторе генерируется в процессе обработки другого исключение, тогда у нас проблемы:
void Transaction::rollback() { if(!active) return; throw std::runtime_error("something bad happens when we rollback transaction"); std::cout<<"rollback transaction"<<std::endl; active=false; } void do_something() { throw std::runtime_error("processing data failed"); } int main() { ... Transaction tr; do_something(); tr.commit(); ... }Это весь вывод:
Что же делать? Если код в деструкторе достаточно простой, то обычно забивают и ничего не делают.
Можно просто глушить исключения в деструкторе, как многие рекомендуют.
Но я не считаю, что это хорошее решение. Т.к. в нашем случае, если транзакция нормально не откатится, то хорошо бы об этом знать.
Можно сделать так:
~Transaction() { try { rollback(); } catch(...) { if(!std::uncaught_exception()) throw; } }Если мы не находимся в процессе обработки исключения, то можем спокойно выпустить исключение из деструктора.
Если находимся, то приходится его давить.
Логично, что если main() не ловит исключение, оно перехватывается в std::terminate()
Важно понимать, что из std::terminate поток уже не возвращается. Поэтому логично, что до деструкторов дело не доходит.
Вместо того, чтобы давить исключение в testShared(), можно обернуть весь main()
Как-то так:
int main() { try { vector<shared_ptr<Slot>> vec {make_shared<Slot>("0"), make_shared<Slot>("1"), make_shared<Slot>("2"), make_shared<Slot>("3"), make_shared<Slot>("4")}; for (auto& x:vec) testShared(x); } catch(const std::exception& e) { std::cerr<<e.what()<<std::endl; } catch(...) { std::cerr<<"Unknown exception"<<std::endl; } return 0; }В В любом случае в этом есть смысл, т.к. вероятно вы хотите как-то хотя бы сообщать об ошибках в своей программе, прежде чем она тихо упадёт.
И тогда все деструкторы будут прекрасно отрабатываться.
Просто выглядит так, что компания получает деньги на шару.
Даже, что компания может получать прибыль из воздуха.
Допустим мы захотели сделать ЯндексОчки.
Мы делаем вполне реальные очки, с туманной экономической перспективой.
Делаем побольше пафосных презентаций.
Запускаем закрытое тестирование.
Первые счастливые обладатели пишут свои обзоры на хабре.
Находим своего держателя акций (хотя бы даже и самого андеррайтера), выходим на IPO.
Делаем пафосное заявление, что компания уже настолько зрелая, что выходит на IPO.
Акции начинают расти.
Нанимаем штат программистов для написания приложений под ЯндексОчки.
Делаем пафосное заявление, что ЯндексОчки обладают полноценной средой.
Акции начинают расти.
Покупаем датацентр, ну например для распознавания образов в реалтйам.
Делаем пафосное заявление, что у нас теперь очки дополненной виртуальной реальности.
Акции начинают расти.
Вставляем ЯндексБар.
Делаем пафосное заявление, что теперь есть монетизация проекта.
Акции начинают расти.
И так ещё столько раз, сколько сможем.
При этом пофиг, что очки нормально не работают, софта нет, датацентр ничего не распознаёт, а ЯндексБар только бесит.
Пока инвесторы окончательно не поймут, что потребителю ЯндексОчки нафиг не сдались, наш договорной
инвестор продаёт свои акции, компания объявляется банкротом
или в лучшем случае продаётся с программистами и датацентром.
Договорной инвестор даёт откат основателям — все счастливы.
Риск только на этапе вложений в стартап. После этого с любого пункта можно спрыгнуть.
Это же один производитель, просто мощность разная.
Может 7W просто неисправная?
Но т.к. результат оказался так себе, то ограничился сообщением на форуме.
На самой медленной скорости приходится напрягаться, чтобы контекст не забыть.
А можно подбробнее объяснить, как грузятся 10 лезвий после включения питания?
Для начала как они вообще сконфигурированы. Каждое лезвие грузится со своего винта (рейда)?
Действительно от функции многое зависит. Возможно, даже существует такая функция, которая реализует победную тактику без просмотра уровней вперёд. Для крестиков-ноликов ведь она существует, теоретически может существовать и для гомоку.
Алис в своей работе упоминал, что для успешной игры против профессионалов необходимо просматривать на 15 шагов вперёд. Из-за того, что это проблематично, придумывают разные эвристики, для ограничения перебора.
Есть отдельно игра и отдельно дерево решений.
Игра сейчас заточена больше под анализ и поиск ошибок в алгоритме. В ней нет случайных ходов, и она никак не использует информацию из дерева решений.
Цель дерева решений — доказать, что крестики всегда выигрывают. Как бонус можно получить программу, которая также всегда выигрывает крестиками, начиная со стартовой позиции.