В ML нет такой папки в корне, не нашел ее вообще на диске.
Бэкапы iTunes в ~/Library/Application Support/MobileSync/
Версии документов в /.DocumentRevisions-V100
Никаких папок занимающих хото сколько много не нашел вообще.
Место не пропадает.
Система стоит с релиза ML без переустановки.
Time Machine включено — делается на сетевую Time Capsule.
Именно. За много лет жизни в Германии «Kugelschreiber» я слышал наверное единожды — на уроках немецкого русской тетки. В дикой природе не встречал употребления слова именно в такой форме.
Нет уже, извините — с русскими я давно зарекся работать уже — после таких пользователи жаловались, что переводы были сделаны гуглом, хотя обещали переводы нативами.
Ну и еще пара стоп-факторов — с теми, кто продвигается спамом я не работаю принципиально и в название у вас созвучно «алгогольной» теме.
Плюс не вижу смысла менять проверенных партнеров, с которыми давно и успешно работаю — тем более делать проверку за собственные деньги.
С точки зрения баз данных русский самый длинный, т.к. там каждый символ требует 2-х байт. Это акктуально для тех же полей описания приложений в App Store. Русский приходится сокращать намного сильнее.
Сами шумы вызваны множеством факторов — вибрации от вентиляторов в мониторе и компе, сердцебиение и пульс пользователя, метро проходящее рядом и так далее.
Вращение земли, как фактор можно не рассматривать — его влияние настолько мало, что не будет заметно датчиками.
Реализовать самим нечто подобное и реально работающее врядли получится. Почему — ясно из презентации SF от Google по ссылке выше, а также рассказывалось на WWDC про Core Motion от Apple. Для вычислений используются данные недоступные разработчикам (как, например, температура), что Apple сказал прямым текстом, а у Google это мельком заметно на слайде.
Если это калибрация поворотом на 180 градусов, то я писал формулу вычисления коррекционного вектора выше в комментах:
VE=(VG0-VG1*MR180)/2 — если не ошибся. Здесь замеры гравитации в двух положениях и матрица поворота на 180 градусов по нужной оси. Векторы нужно нормализовать.
Из вектора коррекции по калибрации потом просто строится поворотная матрица на которую умножаются новые показания — и это не для риалтайм коррекции, а для устранения ошибки в установке датчика, индивидуальной для каждого дивайса.
Автоматическая и идеальная же коррекция здесь нереальна — Sensor Fusion (что точно известно) и Core Motion (предположительно) скорее, наоборот, гироскоп компенсируют данными акселерометра.
В чистом виде ФК не решит проблему дрифта, если пользоваться данными только от одного сенсора, поэтому техники совмещения данных от всех доступных сенсоров подобные SF это выход.
Если кратко, то, например, дрифт гироскопа это как раз и есть результат фильтрации шума.
В iOS аналогичная технология фильтрации данных зашита в CoreMotion. Она работает и развивается уже достаточно давно. Фильтрация на уровне драйвров CM появилась с 2010 года.
2)
Sensor Fusion штука более интересная и отвечает на большее число вопросов, но она также подвержена аналогичным недостаткам — просто так недостатки железа не обойдешь софтом, ошибка все равно будет накапливаться и точность, актуальность ориентации будет теряться со временем.
Панацеи решения вопросов потери данных в дискретных датчиках софтом я пока не вижу.
Знать недостатки сенсоров и пользоваться приложениями их использующими зная эти недостатки все равно будет нужно.
3)
Эти данные тщательно обычно скрываются.
Часть удается установить опытным путем, как, например, FOV камеры — часть искать на сайтах производителей, когда какой Chip Works разберет устройство на части и идентифицирует конкретные компоненты.
Единственное, что я видел, на одном из WWDC рассказали, что акселерометр и гироскоп в новом дивайсе имеют разрешение (частоту) в N раз больше, чем в предыдущих поколениях устройств, не вдаваясь в конкретные числа.
Здесь соответвенно считается, то настоящая гравити это вектор «b», за который берется наибольший базисный вектор от гравитации, если при этом устройство лежит какой-либо гранью на идеально выравненной плоской поверхности.
nginx таки скорее сервер, а не кэш.
Много клевых фич — в планэ кэш-акселлератора nginx до него далеко.
В ML нет такой папки в корне, не нашел ее вообще на диске.
Бэкапы iTunes в ~/Library/Application Support/MobileSync/
Версии документов в /.DocumentRevisions-V100
Никаких папок занимающих хото сколько много не нашел вообще.
Место не пропадает.
Система стоит с релиза ML без переустановки.
Time Machine включено — делается на сетевую Time Capsule.
В Mavericks пока не смотрел.
Ну и еще пара стоп-факторов — с теми, кто продвигается спамом я не работаю принципиально и в название у вас созвучно «алгогольной» теме.
Плюс не вижу смысла менять проверенных партнеров, с которыми давно и успешно работаю — тем более делать проверку за собственные деньги.
Да, подмечено верно — еще просто schreiber.
У нас с офисе народ обычно так говорит именно про ручки.
Собственно Kugelschreiber заставило задуматься над профессионализмом переводчиков.
/занудство OFF
Как их объядиняют с гироскопом описано здесь — схемы, математика, код:
www.thousand-thoughts.com/2012/03/android-sensor-fusion-tutorial/
Схема:
Идеалом это тоже не является, но помогает.
Похожие технологии уже зашиты в Android и iOS на уровне драйверов, но дрифт небольшой все равно остается.
Сами шумы вызваны множеством факторов — вибрации от вентиляторов в мониторе и компе, сердцебиение и пульс пользователя, метро проходящее рядом и так далее.
Вращение земли, как фактор можно не рассматривать — его влияние настолько мало, что не будет заметно датчиками.
Если это калибрация поворотом на 180 градусов, то я писал формулу вычисления коррекционного вектора выше в комментах:
VE=(VG0-VG1*MR180)/2 — если не ошибся. Здесь замеры гравитации в двух положениях и матрица поворота на 180 градусов по нужной оси. Векторы нужно нормализовать.
Из вектора коррекции по калибрации потом просто строится поворотная матрица на которую умножаются новые показания — и это не для риалтайм коррекции, а для устранения ошибки в установке датчика, индивидуальной для каждого дивайса.
Автоматическая и идеальная же коррекция здесь нереальна — Sensor Fusion (что точно известно) и Core Motion (предположительно) скорее, наоборот, гироскоп компенсируют данными акселерометра.
В чистом виде ФК не решит проблему дрифта, если пользоваться данными только от одного сенсора, поэтому техники совмещения данных от всех доступных сенсоров подобные SF это выход.
Здесь неплохое видео, которое объясняет технические детали, включая и про ФК:
www.youtube.com/watch?v=C7JQ7Rpwn2k
Если кратко, то, например, дрифт гироскопа это как раз и есть результат фильтрации шума.
В iOS аналогичная технология фильтрации данных зашита в CoreMotion. Она работает и развивается уже достаточно давно. Фильтрация на уровне драйвров CM появилась с 2010 года.
2)
Sensor Fusion штука более интересная и отвечает на большее число вопросов, но она также подвержена аналогичным недостаткам — просто так недостатки железа не обойдешь софтом, ошибка все равно будет накапливаться и точность, актуальность ориентации будет теряться со временем.
Панацеи решения вопросов потери данных в дискретных датчиках софтом я пока не вижу.
Знать недостатки сенсоров и пользоваться приложениями их использующими зная эти недостатки все равно будет нужно.
3)
Эти данные тщательно обычно скрываются.
Часть удается установить опытным путем, как, например, FOV камеры — часть искать на сайтах производителей, когда какой Chip Works разберет устройство на части и идентифицирует конкретные компоненты.
Единственное, что я видел, на одном из WWDC рассказали, что акселерометр и гироскоп в новом дивайсе имеют разрешение (частоту) в N раз больше, чем в предыдущих поколениях устройств, не вдаваясь в конкретные числа.