Что лучшие способы использовать десятичные числа и datetimes с буферами протокола?

Question

Что лучшие способы использовать десятичные числа и datetimes с буферами протокола?

Если требуется иметь меньше встроенного PHP, отличный способ выполнения, это через JavaScript.

Используя jQuery, это просто:

<script type="text/javascript">
$('div:odd').css('background-color', 'red');
</script>

9

datetime decimal protocol-buffers

задан sorin 30 September 2009 в 09:49

3 ответа

Извините, но не полный ответ, но «я тоже».

Я думаю, что это отличный вопрос, и я бы хотел получить ответ самому себе. Невозможность изначально описывать фундаментальные типы, такие как даты и время и (для финансовых приложений) десятичные дроби с фиксированной точкой, или отображать их в типы, определяемые языком или пользователем, - настоящая убийца для меня. Это более или менее мешало мне использовать библиотеку, которая в остальном считаю фантастической.

Объявление вашего собственного сообщения «DateTime» или «FixedPoint» в прото грамматике на самом деле не является решением, потому что вы по-прежнему необходимо вручную преобразовать представление вашей платформы в / из сгенерированных объектов, что чревато ошибками. Кроме того, эти вложенные сообщения сохраняются как указатели на объекты, размещенные в куче в C ++, что крайне неэффективно, когда базовый тип в основном представляет собой 64-битное целое число.

В частности, я хотел бы иметь возможность записать что-то вроде этого в своих прото-файлах:

message Something {
   required fixed64 time = 1 [cpp_type="boost::posix_time::ptime"];
   required int64 price = 2 [cpp_type="fixed_point<int64_t, 4>"];
   ...
 };

И мне потребуется предоставить все клей был необходим для преобразования этих типов в / из fixed64 и int64, чтобы сериализация работала. Может быть, с помощью чего-то вроде adobe :: promotion ?

2

ответ дан 4 December 2019 в 21:50

Вот несколько идей, основанных на моем опыте работы с проводным протоколом, подобным протоколу буферов.

datetime (точность в секундах)

datetime (точность в миллисекундах)

Я думаю, что ответ на эти два вопроса будет таким же, как правило, вы будете иметь дело с меньшим диапазоном чисел в случае точности в секундах.

Используйте sint64 / sfixed64, чтобы сохранить смещение в секундах / миллисекундах от некоторой хорошо известной эпохи, например, полуночи по Гринвичу 1/1/1970. Так объекты Date внутренне представлены в Java . Я уверен, что есть аналоги в Python и C ++.

Если вам нужна информация о часовом поясе, укажите дату и время в формате UTC и смоделируйте соответствующий часовой пояс в виде отдельного строкового поля. Для этого, вы можете использовать идентификаторы из базы данных Olson Zoneinfo , так как это стало в некоторой степени стандартным.

Таким образом, у вас есть каноническое представление для даты / времени, но вы также можете локализовать любой часовой пояс.

десятичные числа с фиксированной точностью

Моя первая мысль - использовать строку, похожую на то, как конструируются объекты Decimal из пакета decimal Python. Я полагаю, что это может быть неэффективно по сравнению с некоторым числовым представлением.

Могут быть лучшие решения в зависимости от того, с какой областью вы работаете. Например, если вы моделируете денежное выражение, возможно, вам удастся обойтись без использования uint32 / 64 для передачи значения в центах, а не дробных долларовых сумм.

В также есть несколько полезных предложений. поток .

десятичные дроби с переменной точностью

Разве буферы протоколов уже не поддерживают это с типами скалярных чисел с плавающей запятой / двойными? Возможно, я неправильно понял этот пункт.

В любом случае, если вам нужно было обойти эти скалярные типы, вы можете кодировать с помощью IEEE-754 в uint32 или uint64 (float vs double соответственно). Например, Java позволяет извлекать представление IEEE-754 и наоборот из объектов Float / Double. Аналогичные механизмы есть в C ++ / Python.

много значений типа bool (если у вас много Java позволяет извлекать представление IEEE-754 и наоборот из объектов Float / Double. Аналогичные механизмы есть в C ++ / Python.

много значений типа bool (если у вас много Java позволяет извлекать представление IEEE-754 и наоборот из объектов Float / Double. Аналогичные механизмы есть в C ++ / Python.

много значений типа bool (если у вас много из них похоже у вас будет 1-2 байтов накладных расходов для каждого из них из-за их теги.

Если вас беспокоит потеря байтов в сети, вы можете использовать методы битовой маскировки , чтобы сжать множество логических значений в один uint32 или uint64.

Поскольку первого нет Поддержка классов в буферах протокола, все эти методы требуют джентльменского контракта между агентами. Возможно, использование соглашения об именах в ваших полях, таких как «_dttm» или «_mask», поможет взаимодействовать, когда данное поле имеет дополнительную семантику кодирования сверх стандартного поведения буферов протокола.

3

ответ дан 4 December 2019 в 21:50

Другие вопросы по тегам:

datetime decimal protocol-buffers

Похожие вопросы:

score 3 · Accepted Answer

Обоснование проектирования протобуфа, скорее всего, сохранит поддержку типов данных как можно более "родной", так что в будущем легко освоить новые языки. Я полагаю, что они могли бы предоставлять встроенные типы сообщений, но где Вы проводите черту?

Моим решением было создание двух типов сообщений:

DateTime
TimeSpan

Это только потому, что я пришел из фона C#, где эти типы воспринимаются как само собой разумеющееся.

Оглядываясь назад, TimeSpan и DateTime, возможно, было бы чрезмерным, но это был "дешевый" способ избежать преобразования из h/m/s в s и наоборот; при этом было бы просто реализовать такую утилитную функцию, как:

int TimeUtility::ToSeconds(int h, int m, int s)

Bklyn, указал на то, что для вложенных сообщений используется куча памяти; в некоторых случаях это явно очень корректно - мы всегда должны знать, как используется память. Но, в других случаях это может быть менее тревожным, где нас больше беспокоит простота реализации (это философия Java/C#, я полагаю).

Есть также небольшой недостаток в использовании неинтринных типов с протобуфом TextFormat::Printer; нельзя указать формат, в котором он отображается, так что он будет выглядеть как:

my_datetime {
    seconds: 10
    minutes: 25
    hours: 12
}

... что для некоторых слишком многословно. Тем не менее, было бы сложнее прочитать, если бы он был представлен в считанные секунды.

В заключение я бы сказал:

Если вас беспокоит эффективность памяти/парсинга, используйте секунды/миллисекунды.
Однако, если целью является простота реализации, используйте вложенные сообщения (DateTime и т.д.).