Лучший алгоритм сжатия? (см. ниже для определения лучших),
Я определенно не советую вам делать это, но может быть способ сделать это. Это set_error_handler Вы можете найти больше информации о Обработчике ошибок в документации php.net
Также вы можете посмотреть здесь. Но вам нужно проверить php.net для большего количества примеров. В случае E_USER_ERROR: Вы можете сделать html-стили для изменения стиля ошибок.
My ERROR [$errno] $errstr
\n";
echo " Fatal error on line $errline in file $errfile";
echo ", PHP " . PHP_VERSION . " (" . PHP_OS . ")
\n";
echo "Aborting...
\n";
exit(1);
break;
case E_USER_WARNING:
echo "My WARNING [$errno] $errstr
\n";
break;
case E_USER_NOTICE:
echo "My NOTICE [$errno] $errstr
\n";
break;
default:
echo "Unknown error type: [$errno] $errstr
\n";
break;
}
/* Don't execute PHP internal error handler */
return true;
}
// function to test the error handling
function scale_by_log($vect, $scale)
{
if (!is_numeric($scale) || $scale <= 0) {
trigger_error("log(x) for x <= 0 is undefined, you used: scale = $scale", E_USER_ERROR);
}
if (!is_array($vect)) {
trigger_error("Incorrect input vector, array of values expected", E_USER_WARNING);
return null;
}
$temp = array();
foreach($vect as $pos => $value) {
if (!is_numeric($value)) {
trigger_error("Value at position $pos is not a number, using 0 (zero)", E_USER_NOTICE);
$value = 0;
}
$temp[$pos] = log($scale) * $value;
}
return $temp;
}
// set to the user defined error handler
$old_error_handler = set_error_handler("myErrorHandler");
6 ответов
Со "времени" ints может быть друг близко к другу, попытаться только сохранить первое и после того сохранения различие к интервалу перед (кодированием дельты). Можно попробовать то же за второй интервал, также.
Другая вещь, которую можно попробовать, состоит в том, чтобы реорганизовать данные из [int1, int2, дважды], [int1, int2, дважды]... к [int1, int1...], [int2, int2...], [дважды, дважды...].
Для обнаружения диапазона сжатия результат будет в, можно записать данные в файл и загрузить компрессор CCM от Christian Martelock здесь. Я узнал, что это работает очень хорошо для таких сборов данных. Это использует довольно быстрый алгоритм смешивания контекста. Можно также сравнить его с другими компрессорами как WinZIP или пользоваться библиотекой сжатия как zLib, чтобы видеть, стоит ли это усилия.
Вот общая схема, используемая в большинстве поисковых систем: дельты хранилища значений и кодируют дельту с помощью переменной схемы кодирования байта, т.е. если дельта - меньше чем 128, она может быть закодирована только 1 байтом. См. vint в буферах Lucene и Protocol для деталей.
Это не будет давать Вам лучшую степень сжатия, но обычно самое быстрое для кодирования/декодирования пропускной способности.
Вид, как уже предложено, затем сохраните
(первый ints) (второй ints) (удваивается)
транспонированная матрица. Затем сжатый
Большинство алгоритмов сжатия будет работать одинаково плохо над такими данными. Однако существует несколько вещей ("предварительно обрабатывающих") это, можно сделать, чтобы увеличить сжимаемость данных прежде, чем подать его к gzip или выкачать как алгоритм. Попробуйте следующее:
Во-первых, если это возможно, отсортируйте кортежи в порядке возрастания. Используйте абстрактный идентификатор сначала, затем метка времени. Принятие Вас имеет много чтений от того же датчика, подобные идентификаторы будут помещены близко друг к другу.
Затем, если меры приняты равномерно, заменяют метку времени различием от предыдущей метки времени (за исключением самого первого кортежа для датчика, конечно.), Например, если все меры приняты в интервалах 5 минут, дельта между двумя метками времени обычно будет близко к 300 секундам. Поле метки времени поэтому будет намного более сжимаемым, поскольку большинство значений равно.
Затем при предположении, что измеренные значения стабильны вовремя, замените все чтения дельтой от предыдущего чтения для того же датчика. Снова, большинство значений будет близко к нулю, и таким образом более сжимаемо.
Кроме того, значения с плавающей точкой являются очень плохими кандидатами на сжатие, из-за их внутреннего представления. Попытайтесь преобразовать их в целое число. Например, температурные чтения, скорее всего, не требуют больше чем двух десятичных цифр. Умножьте значения на 100 и вокруг к ближайшему целому числу.
Большие ответы, для записи, я собираюсь объединить их я upvoted в подход, который я наконец использую:
Вид и реорганизовывает данные так, чтобы подобные числа были друг рядом с другом, т.е. видом идентификатором сначала, затем меткой времени и перестроением от
(<int1>, <int2>, <double>), ...кому:([<int1>, <int1> ...], [<int2>, <int2> ... ], [<double>, <double> ...])(как предложено schnaader и Stephan LeclercqИспользуйте кодирование дельты на метках времени (и возможно на других значениях), как предложено schnaader и ididak
Используйте буферы протокола для сериализации (я собираюсь использовать их так или иначе в приложении, таким образом, это не собирается добавлять зависимости или что-либо). Благодаря Marc Gravell для указания на меня к нему.
Если я читаю вопрос правильно, Вы просто хотите хранить данные эффективно. Очевидно простым опциям нравится сжатый xml, просты, но существуют более прямые двоичные методы сериализации. Один прыжки для возражения буферы протокола Google.
Например, в C# с protobuf-сетью, можно просто создать класс для содержания данных:
[ProtoContract]
public class Foo {
[ProtoMember(1)]
public int Value1 {get;set;}
[ProtoMember(2)]
public int Value2 {get;set;}
[ProtoMember(3)]
public double Value3 {get;set;}
}
Затем просто [de] сериализируют Список или Foo [] и т.д. через ProtoBuf. Класс сериализатора.
Я не утверждаю, что это будет вполне столь же эффективно пространством как прокрутка Вашего собственного, но это будут довольно чинить близко. Буферная спецификация протокола делает довольно хорошее использование пространства (например, с помощью основы 128 для целых чисел, таких, что небольшие числа занимают меньше места). Но было бы просто испытать его, не имея необходимость писать весь код сериализации самостоятельно.
Этот подход, а также быть простым реализовать, также имеет преимущество того, чтобы быть простого в использовании от другой архитектуры, так как существуют буферные реализации протокола для различных языков. Это также использует намного меньше ЦП, чем регулярное [de] сжатие (GZip/DEFLATE/etc) и/или находящаяся в xml сериализация.