Отличный вопрос!
Я знаю, что этому вопросу уже 9 лет, и я знаю только часть ответа, который вы искали, но я только что пришел сюда с похожим вопросом, и многие вещи изменились после того, как этот вопрос был задан, например, аппаратное обеспечение. и GPS доступны. Я часто работаю с этой темой в прошивках, связанных с различными типами GPS в различных приложениях, и потерял счет часов (и дней), которые я потратил на разработку «наилучшего дизайна» для различных приложений, с которыми я работал или развиты.
Как всегда, различные решения будут обеспечивать выгоды и затраты, и, в конечном счете, «лучший дизайн» всегда будет «наилучшим образом соответствовать» преимуществам и затратам в соответствии с требованиями системы. Вот некоторые вещи, которые я должен учитывать, когда задаю тот же вопрос:
Стоимость процессора
Если в CPU нет встроенного сопроцессора с плавающей запятой (как в случае многих микроконтроллеров), то работа с «float», «double» и «long double» может быть чрезвычайно дорогостоящей. Например, с одним 16-разрядным микроконтроллером, с которым я работаю регулярно, умножение с использованием «двойных» значений стоит 326 тактовых циклов ЦП, а деление - 1193 тактовых цикла. Очень дорого!
Точность компромисса
На экваторе - значение с плавающей запятой (32-разрядное значение IEEE-754 с плавающей запятой), необходимое для представления значения степени со знаком, предполагая, что 7 «чистых» значащих десятичных разрядов могут быть представлены, изменение одной наименьшей значащая десятичная цифра (например, от 179,9999 до 180,0000) будет представлять расстояние около 11,12 метра. Это может или не может соответствовать жестким требованиям к точности системы. Принимая во внимание, что «двойной» (с 15 представленными «чистыми» значащими десятичными цифрами, таким образом, изменение с 179,9999999999999 до 180,000000000000) составляет около 0,00011 мм.
Ограничения точности ввода
Если вы имеете дело с вводом с GPS, сколько цифр реальной точности вы получаете и сколько вам нужно сохранить?
Стоимость разработки
64-битное значение двойной точности IEEE-754 ('double') и 32-битное значение одинарной точности ('float') ОЧЕНЬ удобно использовать в языке C, так как математические библиотеки для обеих программ практически каждый компилятор C, и, как правило, очень надежны. Если ваш процессор оснащен аппаратным процессором с плавающей запятой, это простой выбор.
Оперативная память и хранение
Если вам необходимо хранить большое количество этих значений в ОЗУ (или в хранилище, например, MYSQL), доступное ОЗУ (и пространство для хранения) может повлиять на работоспособность решения.
Доступные данные против необходимых данных
Один из примеров, с которыми я имею дело при написании этой статьи (причина, по которой я пришел сюда на этот вопрос), - это то, что я имею дело с u-blox M8 GPS, который способен выдавать мне двоичную информацию GPS (сохраняя нагрузку на процессор перевод предложений ASCII NMEA). В этом двоичном формате (называемом «протоколом UBX») широта и долгота представлены в виде 32-разрядных целых чисел со знаком, представление которых может представлять точность (на экваторе) с точностью до 1,11 см. Например, долгота -105,0269805 градусов представлена как -1050269805 (используется все 32 бита), а одно изменение LSb представляет собой изменение ширины на 1,11 см в любом месте и долготу на 1,11 см на экваторе (и меньше на более высоких широтах пропорционально косинусу). широты). Приложение, в котором используется GPS, выполняет навигационные задачи, для которых (уже существующий и хорошо протестированный код) требуются «двойные» типы данных. К сожалению, преобразование этого целого числа в 64-разрядный «двойной» IEEE-754 не может быть легко выполнено простым перемещением целых двоичных битов целого числа во внутренние биты представления «двойного», поскольку выполняемый десятичный сдвиг является десятичное смещение базы-10. Если бы вместо этого был десятичный сдвиг в base-2, тогда биты base-2 целого числа могли бы быть перемещены в битовые поля 'double' с очень небольшим требуемым переводом. Но, увы, это не относится к целому числу со знаком, которое у меня есть. Так что это будет стоить мне умножение на процессор, который не имеет аппаратного процессора с плавающей запятой: 326 тактов процессора.
double ldLatitude;
int32_t li32LatFromGps;
ldLatitude = (double)li32LatFromGps * 0.0000001;
Обратите внимание, что это умножение было выбрано для этого:
ldLatitude = (double)li32LatFromGps / 10000000.0;
потому что «двойное» умножение примерно в 3,6 раза быстрее, чем «двойное» деление на CPU, с которым я имею дело. Такова жизнь в мире микроконтроллеров. : -)
Что было бы BRILLIANT (и может быть в будущем, если я смогу сэкономить время на выходных), так это если бы задачи навигации можно было выполнять непосредственно с 32-разрядным целым числом со знаком! Тогда никакое преобразование не понадобится ... Но будет ли дороже выполнять задачи навигации с таким целым числом? Процессор стоит, наверное, гораздо эффективнее. Время разработки стоит? Это еще один вопрос, особенно с хорошо протестированной системой, которая использует 64-разрядные двойные значения IEEE-754! Кроме того, уже существует программное обеспечение, которое предоставляет картографические данные (с использованием «двойных» значений градусов), и это программное обеспечение также необходимо преобразовать для использования целого числа со знаком, а не задачи на одну ночь!
Один ОЧЕНЬ интересный вариант состоит в том, чтобы напрямую (без перевода) представлять пересечения между аппроксимациями «прямоугольников» (фактически трапеций, которые становятся треугольниками на полюсах), используя необработанные целые значения широты / долготы. На экваторе эти прямоугольники будут иметь размеры примерно 1,11 см восток-запад на 1,11 см север-юг, тогда как на широте, скажем, Лондон, Англия, размеры будут примерно 0,69 см восток-запад на 1,11 см север-юг. Это может или не может быть легко иметь дело, в зависимости от того, что нужно приложению.
В любом случае, я надеюсь, что эти мысли и обсуждения помогут другим, кто ищет в этой теме «лучший дизайн» для своей системы.
С уважением,
Vic