小编DrV*_*DrV的帖子

我需要将一些额外的信息打包到浮点NaN值中.我在Python中使用单精度IEEE 754浮点数(32位浮点数).Python和NumPy如何处理这些值？

理论

如果指数位(23..30)被设置,并且至少有一个有效位被设置,则IEEE 754-2008标准似乎认为数字实际上不是数字.因此,如果我们将float转换为32位整数表示,则满足以下条件的任何内容都会变为:

• i & 0x7f800000 == 0x7f800000
• i & 0x007fffff != 0

这会让我有很多选择.但是,标准似乎说有效数字的最高位是is_quiet,应该设置为避免计算中的异常.

实际测试

Python 2.7

为了确定,我运行了一些有趣结果的测试:

import math
import struct

std_nan = struct.unpack("f4", struct.pack("I", 0x7fc00000))[0]
spec_nan = struct.unpack("f4", struct.pack("I", 0x7f800001))[0]
spec2_nan = struct.unpack("f4", struct.pack("I", 0x7fc00001))[0]

print "{:08x}".format(struct.unpack("I", struct.pack("f4", std_nan))[0])
print "{:08x}".format(struct.unpack("I", struct.pack("f4", spec_nan))[0])
print "{:08x}".format(struct.unpack("I", struct.pack("f4", spec2_nan))[0])

这给出了:

7fc00000
7fc00001 <<< should be 7f800001
7fc00001

这个和一些进一步的测试似乎暗示某些东西(struct.unpack？)总是设置is_quiet位.

NumPy的

我尝试使用NumPy,因为我总是可以依赖转换而不是改变一个位:

import numpy as np

intarr = np.array([0x7f800001], dtype='uint32')
f = np.fromstring(intarr.tostring(), dtype='f4') …

背景

我在NumPy数组中有很多数字消息代码,我需要快速将它们转换为字符串.我在性能方面遇到了一些问题,并希望了解为什么以及如何快速完成.

一些基准

我 - 琐碎的方法

import numpy as np

# dictionary to use as the lookup dictionary
lookupdict = {
     1: "val1",
     2: "val2",
    27: "val3",
    35: "val4",
    59: "val5" }

# some test data
arr = np.random.choice(lookupdict.keys(), 1000000)

# create a list of words looked up
res = [ lookupdict[k] for k in arr ]

字典查找占用了我咖啡休息时间的758毫秒.(我也试过,res = map(lookupdict.get, arr)但情况更糟.)

II - 没有NumPy

import random

# dictionary to use as the lookup dictionary
lookupdict = {
     1: …

我正在运行带有ARM Cortex-M3(STM32F205)的裸机嵌入式系统.当我尝试使用snprintf()浮点数时,例如:

float f;

f = 1.23;
snprintf(s, 20, "%5.2f", f);

我得到了垃圾s.格式似乎很荣幸,即垃圾是一个格式良好的字符串,包含数字,小数点和两个尾随数字.但是,如果我重复snprintf,则字符串可能会在两次调用之间发生变化.

浮点数学似乎在其他方面起作用,并且snprintf与整数一起工作,例如:

snprintf(s, 20, "%10d", 1234567);

我使用链接器开关的newlib-nano实现-u _printf_float.编译器是arm-none-eabi-gcc.

我确实怀疑内存分配问题,因为整数打印没有任何打嗝,但浮动表现就好像它们在过程中被破坏一样.该printf系列函数调用malloc用浮漂,不是整数.

唯一不属于newlib我在此上下文中使用的代码是my _sbrk(),这是必需的malloc.

caddr_t _sbrk(int incr)
{
  extern char _Heap_Begin; // Defined by the linker.
  extern char _Heap_Limit; // Defined by the linker.

  static char* current_heap_end;
  char* current_block_address;

  // first allocation
  if (current_heap_end == 0)
      current_heap_end = &_Heap_Begin; …

我有一个带有图形用户界面的低资源嵌入式系统。该接口需要字体数据。为了节省只读内存（闪存），需要压缩字体数据。我正在为此目的寻找算法。

要压缩的数据的属性

• 每个像素为 8 位的矩形像素图的透明度数据
• 字体中通常有大约 200..300 个字形（以特定大小采样的字体）
• 每个字形的大小通常为 6x9 到 15x20 像素
• 有很多零（“无墨水”）和略少的 255（“完全墨水”），否则八位字节的分布非常均匀，因为抗锯齿的性质

对压缩算法的要求

• 解压缩算法的重要指标是数据的大小加上算法的大小（因为它们将驻留在相同的有限内存中）。
• 可用于解压的 RAM 非常少；可以将单个字形的数据解压缩到 RAM 中，但不能更多。
• 为了让事情变得更困难，算法在 32 位微控制器（ARM Cortex-M 内核）上必须非常快，因为在将字形绘制到显示器上时需要对其进行解压缩。每个八位字节十或二十个机器周期是可以的，一百个肯定太多了。
• 为方便起见，完整的数据语料库是先验已知的，并且在压缩阶段有大量的处理能力和内存可用。

结论和想法

• 由于相对较高的熵，仅通过一些可变长度编码打包每个八位字节的幼稚方法并没有给出好的结果。
• 任何利用较早解压缩数据的算法似乎都没有问题，因为不可能存储其他字形的解压缩数据。这使得 LZ 算法效率较低，因为它们只能引用少量数据。
• 处理能力的限制似乎排除了大多数按位运算，即解压缩应该逐个八位字节处理数据。这使得 Huffman 编码变得困难并且无法进行算术编码。
• 这个问题似乎是静态字典编码的一个很好的候选者，因为所有数据都是事先知道的，并且数据本质上有些重复（不同的字形共享相同的形状）。

问题

• 一个好的字典是如何构建的？我知道为某些数据找到最佳字典是一个 np 完全问题，但是否有任何合理的近似值？我尝试过 zstandard 的字典生成器，但结果不是很好。
• 我的结论中是否有错误的地方？（我是否在错误的轨道上并忽略了一些明显的东西？）

迄今为止最好的算法

只是为了提供一些背景信息，我能够找出的最有用的算法如下：

• 单个字形的字体数据中的所有样本都连接（展平）为一维数组（向量、表）。
• 每个样本都有三种可能的状态：0、255 和“其他”。
• 此信息一次将五个连续样本打包成一个 5 位以三为基数的数字 (0..3^5)。
• 由于八位字节中有一些额外的值 (2^8 = 256, 3^5 = 243)，它们用于表示 0 和 255 的较长字符串。
• 对于每个“其他”值，实际值 (1..254) 存储在单独的向量中。

该数据解压速度很快，因为可以通过较小的（243 x 3 = 729 个八位字节）查找表将 base-3 值解码为 base-4 值。压缩率高度依赖于字体大小，但使用我的典型数据，我可以得到大约 1:2。由于这比 LZ 变体（大约为 …