Насколько я знаю, стержень из ситуации два не только передаёт усилие на закрылок для изменения его положения, но и для удержания его в одном положении. Набегающий поток стремится перевести закрылок в положение «убрано».
Соответственно, если стержень сломается — набегающий поток воздуха это сделает. Тоже самое и при достаточно большом падении давления в гидравлической системе.
Хотя, возможно, Сессна устроена как-то по другому. Но вряд ли.
Насколько я понял ситуацию — разработчики SkyForge столкнулись с ситуацией, когда надо было определять ближе или дальше 2 поверхности, находящиеся на расстоянии, допустим, 20 см друг от друга, но при этом — 20км от камеры:
20 км = 2*10^4 м
20 см = 2*10^-2 м.
Разница в 6 порядков, при доп. операциях — это наверняка оказывается за пределами точности типа.
То есть в больших числах важно некое довольно малое ɛ, которое тип хранить не способен.
В таких условиях произвести сравнение вообще не возможно. Мы будем получать какой-то шум вместо актуальной картинки.
> Что значит «заспамить девятками»? Девятка — это значащая цифра.
Намного эффективнее будет представить значение в виде 1+ (a — b) / b. Так вы получите всю доступную мощность типа для хранения данных, так как (а-b)/b близок к нулю. Это я и называю хранением бессмысленных девяток.
Причиной ошибки сравнения в статье про SkyForge на больших дистанция являлась как раз потеря точности при хранении больших чисел. Остававшейся точности типа не хватало для корректного сравнения.
Не согласен. При вычитании/сложении мы теряем часть информации (если не всю) из меньшего числа, но в памяти у нас попрежнему находятся значимые цифры. При делении же, всю точность типа может заспамить нулями и девятками. И если у вас получится не «1» — уже повезло.
Вообще, если при работе с числами с плавающей точкой есть возможность приблизить оперируемые числа к нулю — лучше это сделать.
Например, ((2+ 0.0001) + (2 + 0.00000001))/2 приведёт к потере данных с большей вероятностью, чем 2 + (0.0001 + 0.00000001)/2.
В любом случае, если вы ведёте какие-то серьёзные вычисления во float — надо понимать, зачем и что вы делаете. Яркий тому пример — статья про разработку SkyForge — там есть описание работы вывернутым буфером глубины.
Деление близких (17485/17484) чисел даёт, наверное, даже большую ошибку. Так как ведущей оказывается единица (или девятка), а дальше куча нулей (девяток) перед первой осмысленной цифрой, на которые тратится вся точность типа. В принципе, как понимаю, оно тут и имеет место быть
Windows 10 портирован в том числе и на ARM. Raspberry Pi — ARM. Единственное, что там надо целенаправленно сделать — это указать что на какие выводы подключено, а это относительно дешёвая операция. Зато теперь Microsoft имеет модную ныне ачивку «Наша операционка запускается на Raspberry Pi!»
Кстати говоря: В оригинальном конструкторе стороны прямоугольников были разными:
Например, при размере тела блока в 5x5 условных кубиков у одной пары противоположных сторон был набор зубцов в порядке зубец-дырка-зубец-дырка-зубец, а у другой — дырка-зубец-дырка-зубец-дырка. Это позволяло соединять детали без лесенок и лишних щелей.
И самая полезная деталь:
XX_XX
_XXX_
XX_XX
Я бы на вашем месте всё таки озадачился проверкой патентов.
Лет так 15 назад общался с детским конструктором с деталями именно такой формы. Электроники там, естественно, не было, но соединялись они также. Было это обычным полым пластиком.
То есть как минимум часть с формой деталей не оригинальна и реализация существует.
Отсюда возникает вопрос: а не будет ли у вас проблем с патентами (которые наверняка есть и вполне может быть — ещё не истекли), которые принадлежат не вам?
> При этом MyISAM таблицы повреждаются очень просто — с этим проблем нет никаких.
На мой неискушённый взгляд, это веский повод не использовать MyISAM вообще.
Кстати, процессор, на котором исполняется код. В теории, Objective-C должен обладать той же проблемой, если Apple не принял каких-то дополнительных усилий.
Но в любом случае, инструментарий довольно широк:
@synchronized
GCD
pthread_*_lock.
Будет время — оттестирую.
Ну, с наукой в универах у нас не всё так плохо. Например, у нас в Калининграде в БФУ суперкомпьютер стоит уже лет 5 как. Какие-то рассчёты там на нём проводят регулярно, видимо есть что считать :)
Согласен. Но по сравнению с одиночной головкой оно таки тяжелее. Устройство из топика — это модификация системы подачи прута, головка головка принтеру нужна одна. Главный минус — нужно предсказывать расход прута с идеальной точностью, что может быть проблемой, на мой взгляд.
Соответственно, если стержень сломается — набегающий поток воздуха это сделает. Тоже самое и при достаточно большом падении давления в гидравлической системе.
Хотя, возможно, Сессна устроена как-то по другому. Но вряд ли.
20 км = 2*10^4 м
20 см = 2*10^-2 м.
Разница в 6 порядков, при доп. операциях — это наверняка оказывается за пределами точности типа.
То есть в больших числах важно некое довольно малое ɛ, которое тип хранить не способен.
В таких условиях произвести сравнение вообще не возможно. Мы будем получать какой-то шум вместо актуальной картинки.
Намного эффективнее будет представить значение в виде 1+ (a — b) / b. Так вы получите всю доступную мощность типа для хранения данных, так как (а-b)/b близок к нулю. Это я и называю хранением бессмысленных девяток.
Причиной ошибки сравнения в статье про SkyForge на больших дистанция являлась как раз потеря точности при хранении больших чисел. Остававшейся точности типа не хватало для корректного сравнения.
*f(((2+ 0.0001) + (2 + 0.00000001))/2) приведёт к потере данных с большей вероятностью, чем 2 + f'((0.0001 + 0.00000001)/2)
Вообще, если при работе с числами с плавающей точкой есть возможность приблизить оперируемые числа к нулю — лучше это сделать.
Например, ((2+ 0.0001) + (2 + 0.00000001))/2 приведёт к потере данных с большей вероятностью, чем 2 + (0.0001 + 0.00000001)/2.
В любом случае, если вы ведёте какие-то серьёзные вычисления во float — надо понимать, зачем и что вы делаете. Яркий тому пример — статья про разработку SkyForge — там есть описание работы вывернутым буфером глубины.
Не обобщайте :) У кого-то и в XCode такой проблемы нет.
Например, при размере тела блока в 5x5 условных кубиков у одной пары противоположных сторон был набор зубцов в порядке зубец-дырка-зубец-дырка-зубец, а у другой — дырка-зубец-дырка-зубец-дырка. Это позволяло соединять детали без лесенок и лишних щелей.
И самая полезная деталь:
XX_XX
_XXX_
XX_XX
Я бы на вашем месте всё таки озадачился проверкой патентов.
То есть как минимум часть с формой деталей не оригинальна и реализация существует.
Отсюда возникает вопрос: а не будет ли у вас проблем с патентами (которые наверняка есть и вполне может быть — ещё не истекли), которые принадлежат не вам?
На мой неискушённый взгляд, это веский повод не использовать MyISAM вообще.
Но в любом случае, инструментарий довольно широк:
@synchronized
GCD
pthread_*_lock.
Будет время — оттестирую.
Пс. ой, какую археологию я устроил :D