А кажется разобрался, во втором случае мы как-бы p зафиксировали, и условия пишем для фиксированного p и эпсилон, а в первом случае только эпслилон фиксированное, а p "плавает" по всем натуральным. Хотя.. если p любое натуральное, не означает ли это что оно и во втором случае "плавает".. что-то я не до конца разобрался..
Не смог постичь чем отличаются две формулировки с переставленным "для любого натурального p", кто-то может прояснить? Мне кажется "любое натуральное p" никак семантически не связано к остальными условиями, это самостоятельное ограничение и его можно поставить как в начало так и в конец, общий смысл как буд-то бы не меняется. Что я упускаю?
У меня была такая история.
Работал я давно в одной фирме, где мы делали некий диагностический прибор для железной дороги. Одна из подсистем должна была начинать и останавливать видеосъемку по сигналам с рельсовых датчиков, то бишь фиксировать на видео движение конкретного вагона. Занимался этим небольшой демон, а «видеосъемка» заключалась в получении потока jpeg файлов с камеры по ethernet с одной стороны и дальнейшее их сохранение базу на хосте. В офисе у нас круглосуточно для отладки гонялся тестовый стенд, где эти самые сигналы с датчиков аппаратно эмулировались, а камера сохраняла в базу просто фотки офиса. Так вот в процессе отладки этого демона долго не могли поймать один баг — демон вылетал с ошибкой именно ночью. Запускаешь демона на тестовой стойке, весь день все отлично работает — ни единого сбоя до вечера, вечером уходишь домой, на утро приходишь — демон лежит, и так каждый день. Просто магия какая-то.
Воспроизвести багу днем никак не удавалось идей не было. И я тогда начал рассуждать, чем таким ночь отличается от дня? Ну, ночью темно, а днём светло… пошел накрыл камеру темной материей — вуаля, баг воспроизвелся! Выяснилось, что когда темно — у камеры чувствительности не хватает и она начинает «снежить», такой снежный кадр сжимается хуже и из-за этого обьем одного jpeg кадра вырастал в среднем до ~50Кб, тогда как днем он занимал примерно 20-30 Кб. Причина была в размере этого кадра, падало в момент записи в базу, запись не успевала прожевать такие большие BLOBы и потому все падало.
P.S.: В дальнейшем от записи в базу бинарей вообще отказались.
Мне показалось, что я продрался через словесные дебри, однако один момент остался не ясен:
«тем не менее, мы определённо можем перевести наше метаматематическое утверждение, „формулу с номером Гёделя sub(y, y, 17) нельзя доказать“, в формулу с уникальным номером Гёделя.»
Если я правильно понял, чтобы формула имела номер Гёделя, одна должна быть записана через 12 элементарных символов из таблицы.
Действительно ли утверждение „формулу с номером Гёделя sub(y, y, 17) нельзя доказать“ может быть выражена в виде формулы через эти 12 табличных символов?
Можно ли это доказать, и как она будет выглядеть, кто-нибудь знает?
В принципе можно и без координат обойтись, можно в столбик записывать и xor-ить номера клеток от 0 до 63, это тоже 6 бит. Тогда получим не координаты а номер клетки, которую перевернуть надо.
Я эту задачу решил немного по своему а потом уже нашел ее на хабре. Мое решение мне кажется проще и понятнее (все комменты не читал, надеюсь, никто его еще не привел), оно отталкивается от координат:
Каждая монета на доске имеет координаты по X и по Y от 0 до 7, то есть для передачи одной координаты достаточно 3 бита информации.
Дальше договариваемся какое состояние монет будет базовым, пусть это будет например реверс. Записываем в столбик координаты всех реверсов, которые нам разложил тюремщик, в двоичном виде и xor-им их друг с другом:
X Y
001 101
100 101
111 000
000 101
ит.д…
-----XOR---------
MMM MMM (результат xor по координатам)
В результате получаем некий набор бит ("маска" доски). А нам надо добиться того, чтобы в результате у нас получились координаты загаданной клетки, чтобы наш друг придя на испытание сделал ту же саму операцию и в результате узнал координаты клетки, загаданной тюремщиком. Для этого мы должны еще добавить в список для xor координаты загаднной тюремщиком клетки. В итоге получаем координаты клетки которую мы должны перевернуть, это все.
Если мы посчитаем новую маску (после переворота клетки), то она будет нулевой, а если мы посчитаем ее без клетки загаданной тюремщиком, то как раз получим ее координаты.
Еще интересная особенность получается — клетку с координатами (0,0) можно не переворачивать )
О, спасибо за статью. Когда я гуглил проблему, ничего аналогичного найти не мог, теперь ситуация будет другой.
Судя по возможным ошибкам, спецификация действительно допускает такое состояние адаптера (а точнее сказать STO протокола), когда текстовый вывод недоступен.
У вас в статье написано что возможное решение (не гарантируемое) это позвать STO->Reset() после GOP->SetMode().
А если после вызова GOP->SetMode() позвать STO->SetMode(), разве это может как-то испортить режим GOP'а или просто текстовый режим не установится? Странно, почему в документации эти важные моменты явно никак не описаны.
Мне просто выводить текст поверх графики желательно, но не очень критично. Это используется для ошибочных логов, которые не только на экран попадают, но и в другие места. Реализовывать ради этого текстовый вывод средствами GOP, слишком развесисто. Проще в этих редких случаях без логов на экране обойтись. Главное просто не испортить графический режим Reset'ом или SetMode'ом)
Хмм, дак у SimpleTextOutput и у GOP одни и те же режимы чтоли? Я так понял из документации, что у них независимые наборы режимов, у текста свои, у графики свои. Описание функции EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.QueryMode() из спеки 2.5:
EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.QueryMode()
Summary
Returns information for an available text mode that the output device(s) supports.
Prototype
typedef EFI_STATUS
(EFIAPI *EFI_TEXT_QUERY_MODE) (
IN EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL *This,
IN UINTN ModeNumber,
OUT UINTN *Columns,
OUT UINTN *Rows
);
Parameters This — A pointer to the EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL instance. Type EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL is defined in the “Related Definitions” of Section 11.4. ModeNumber — The mode number to return information on. Columns, Rows — Returns the geometry of the text output device for the request ModeNumber.
Description
The QueryMode() function returns information for an available text mode that the output device(s) supports.
It is required that all output devices support at least 80x25 text mode. This mode is defined to be
mode 0. If the output devices support 80x50, that is defined to be mode 1. All other text dimensions
supported by the device will follow as modes 2 and above. If an output device supports modes 2 and
above, but does not support 80x50, then querying for mode 1 will return EFI_UNSUPPORTED.
Как я понял из этого описания, данная функция на вход принимает номер текстового режима, и возвращает его геометрию в выходных параметрах, либо то, что режим невалидный (этот случай описан отдельно для режима 1). Я не нашел где было бы сказано, что номера режимов здесь такие же как и у GOP.
Как можно было бы понять из документации что номенклатура текстовых и графических режимов пересекается? Куда посмотреть?
Описано все так как будто текстовый и графический протоколы существуют абстрактно и независимо друг от друга. Или как все-таки следует понимать эту документацию?)
Хотел задать вопрос может быть не совсем по теме, дело в том, что я с этим тоже столкнулся непосредственно.
У вас на сайте я нашел такое утверджение: «работоспособность процедур вывода текста Simple Text Output Protocol не гарантируется после установки произвольного видео режима с использованием Graphics Output Protocol». В официальной спеке UEFI 2.5 я про это ничего не нашел. Описание в спеке выглядит так что SimpleTextOutput и GraphicsOutput независимые протоколы. Однако по факту имеем на некоторых машинах, что после GOP->SetMode() консоль действительно «портится». Вопрос в том, вы эту информацию где-то в официальных доках нашли, и если да, то где, либо это тоже эмпирически обнаружено?
Сложно сказать на самом деле. Проект я начал еще в прошлом году, но приступал к нему время от времени, с перерывами по несколько месяцев и на каждый коммит тратил разное время. Можно грубо оценить снизу: всего 18 коммитов, если на каждый я в среднем тратил 4 часа, то получается 60. Но это оценка снизу, на самом деле времени было потрачено больше + еще были постоянные размышления и диалоги с коллегами…
Тут 2 причины:
1) В идеале хотелось максимально решить все средствами cmake без запуска внешних процессов (жаль время узнать не удалось)
2) Я не так давно являюсь пользователем linux и просто не знал про tput
А кажется разобрался, во втором случае мы как-бы p зафиксировали, и условия пишем для фиксированного p и эпсилон, а в первом случае только эпслилон фиксированное, а p "плавает" по всем натуральным. Хотя.. если p любое натуральное, не означает ли это что оно и во втором случае "плавает".. что-то я не до конца разобрался..
Не смог постичь чем отличаются две формулировки с переставленным "для любого натурального p", кто-то может прояснить? Мне кажется "любое натуральное p" никак семантически не связано к остальными условиями, это самостоятельное ограничение и его можно поставить как в начало так и в конец, общий смысл как буд-то бы не меняется. Что я упускаю?
А есть ли (или планируется) аналогичный проект для распознавания старых медицинских карт?
Работал я давно в одной фирме, где мы делали некий диагностический прибор для железной дороги. Одна из подсистем должна была начинать и останавливать видеосъемку по сигналам с рельсовых датчиков, то бишь фиксировать на видео движение конкретного вагона. Занимался этим небольшой демон, а «видеосъемка» заключалась в получении потока jpeg файлов с камеры по ethernet с одной стороны и дальнейшее их сохранение базу на хосте. В офисе у нас круглосуточно для отладки гонялся тестовый стенд, где эти самые сигналы с датчиков аппаратно эмулировались, а камера сохраняла в базу просто фотки офиса. Так вот в процессе отладки этого демона долго не могли поймать один баг — демон вылетал с ошибкой именно ночью. Запускаешь демона на тестовой стойке, весь день все отлично работает — ни единого сбоя до вечера, вечером уходишь домой, на утро приходишь — демон лежит, и так каждый день. Просто магия какая-то.
Воспроизвести багу днем никак не удавалось идей не было. И я тогда начал рассуждать, чем таким ночь отличается от дня? Ну, ночью темно, а днём светло… пошел накрыл камеру темной материей — вуаля, баг воспроизвелся! Выяснилось, что когда темно — у камеры чувствительности не хватает и она начинает «снежить», такой снежный кадр сжимается хуже и из-за этого обьем одного jpeg кадра вырастал в среднем до ~50Кб, тогда как днем он занимал примерно 20-30 Кб. Причина была в размере этого кадра, падало в момент записи в базу, запись не успевала прожевать такие большие BLOBы и потому все падало.
P.S.: В дальнейшем от записи в базу бинарей вообще отказались.
«тем не менее, мы определённо можем перевести наше метаматематическое утверждение, „формулу с номером Гёделя sub(y, y, 17) нельзя доказать“, в формулу с уникальным номером Гёделя.»
Если я правильно понял, чтобы формула имела номер Гёделя, одна должна быть записана через 12 элементарных символов из таблицы.
Действительно ли утверждение „формулу с номером Гёделя sub(y, y, 17) нельзя доказать“ может быть выражена в виде формулы через эти 12 табличных символов?
Можно ли это доказать, и как она будет выглядеть, кто-нибудь знает?
Каждая монета на доске имеет координаты по X и по Y от 0 до 7, то есть для передачи одной координаты достаточно 3 бита информации.
Дальше договариваемся какое состояние монет будет базовым, пусть это будет например реверс. Записываем в столбик координаты всех реверсов, которые нам разложил тюремщик, в двоичном виде и xor-им их друг с другом:
X Y
001 101
100 101
111 000
000 101
ит.д…
-----XOR---------
MMM MMM (результат xor по координатам)
В результате получаем некий набор бит ("маска" доски). А нам надо добиться того, чтобы в результате у нас получились координаты загаданной клетки, чтобы наш друг придя на испытание сделал ту же саму операцию и в результате узнал координаты клетки, загаданной тюремщиком. Для этого мы должны еще добавить в список для xor координаты загаднной тюремщиком клетки. В итоге получаем координаты клетки которую мы должны перевернуть, это все.
Если мы посчитаем новую маску (после переворота клетки), то она будет нулевой, а если мы посчитаем ее без клетки загаданной тюремщиком, то как раз получим ее координаты.
Еще интересная особенность получается — клетку с координатами (0,0) можно не переворачивать )
Судя по возможным ошибкам, спецификация действительно допускает такое состояние адаптера (а точнее сказать STO протокола), когда текстовый вывод недоступен.
У вас в статье написано что возможное решение (не гарантируемое) это позвать STO->Reset() после GOP->SetMode().
А если после вызова GOP->SetMode() позвать STO->SetMode(), разве это может как-то испортить режим GOP'а или просто текстовый режим не установится? Странно, почему в документации эти важные моменты явно никак не описаны.
Мне просто выводить текст поверх графики желательно, но не очень критично. Это используется для ошибочных логов, которые не только на экран попадают, но и в другие места. Реализовывать ради этого текстовый вывод средствами GOP, слишком развесисто. Проще в этих редких случаях без логов на экране обойтись. Главное просто не испортить графический режим Reset'ом или SetMode'ом)
Как я понял из этого описания, данная функция на вход принимает номер текстового режима, и возвращает его геометрию в выходных параметрах, либо то, что режим невалидный (этот случай описан отдельно для режима 1). Я не нашел где было бы сказано, что номера режимов здесь такие же как и у GOP.
Как можно было бы понять из документации что номенклатура текстовых и графических режимов пересекается? Куда посмотреть?
Описано все так как будто текстовый и графический протоколы существуют абстрактно и независимо друг от друга. Или как все-таки следует понимать эту документацию?)
У вас на сайте я нашел такое утверджение: «работоспособность процедур вывода текста Simple Text Output Protocol не гарантируется после установки произвольного видео режима с использованием Graphics Output Protocol». В официальной спеке UEFI 2.5 я про это ничего не нашел. Описание в спеке выглядит так что SimpleTextOutput и GraphicsOutput независимые протоколы. Однако по факту имеем на некоторых машинах, что после GOP->SetMode() консоль действительно «портится». Вопрос в том, вы эту информацию где-то в официальных доках нашли, и если да, то где, либо это тоже эмпирически обнаружено?
1) В идеале хотелось максимально решить все средствами cmake без запуска внешних процессов (жаль время узнать не удалось)
2) Я не так давно являюсь пользователем linux и просто не знал про tput
А так да, спасибо за замечание :)