将流数据转换为三进制(base-3)
给定两个设备之间的时钟 3 级 (-1,0,+1) 通道,将比特流与通道表示形式相互转换的最高效的流方式是什么?
当前的方法是取3个二进制位,并转换成两个trit。我相信这浪费了 11% 的通道能力(因为 9 个可能的对中的 1 个从未被使用过)。我怀疑分组可能会减少这种浪费,但该项目使用 8 位设备,因此我的组大小受到限制。
我想使用 divmod-3,但我在任何时候都没有可用的整个二进制流。是否有一种可以从 LSB 开始的“增量”divmod3 方法?
作为未经训练的猜测,我推测应该有一种“分析接下来的 3 位,删除一位,更改一位”形式的方法 - 但我还没有找到可行的方法。
Given a clocked 3-level (-1,0,+1) channel between two devices, what is the most stream-efficient way to convert a stream of bits to and from the channel representation?
The current method is to take 3 binary bits, and convert into two trits. I believe this wastes 11% of the channel capability (since 1 out of 9 possible pairs is never used). I suspect grouping might reduce this waste, but this project is using 8-bit devices, so my group sizes are restricted.
I'd like to use divmod-3, but I don't have the entire binary stream available at any one point. Is there a method for an 'incremental' divmod3 that can start at the LSB?
As an untrained guess, I speculate that there should be an approach of the form 'analyze the next 3 bits, remove one bit, change one bit' -- but I haven't been able to find something workable.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
尝试将 11 位(2048 个代码)打包成 7 个 trit(2187 个代码),您将获得不到 1% 的开销。有几种方法。第一个很简单:查找表。第二个是divmod-3。第三是一些位/三点主运算,如下所示。
第一阶段:使用 3-bit-to-2-trit 方案打包前 9 位:
状态 ZZ 将进一步使用
第二阶段:使用更复杂的逻辑将 6 个 trit 和 2 位打包为 7 个 trit:
未使用的代码将是:
UPD另一种合适的包装关系是19b->19b-> 11t(~0.1% 开销),84b -> 53t(~0,0035% 开销),但似乎超出了。
Try to pack 11 bits (2048 codes) into 7 trits (2187 codes), you'll get less than 1% of overhead. There are several methods. First one is straightforward: the lookup table. Second is divmod-3. Third is some bit/trit mainpulation like below.
First stage: pack first 9 bits using 3-bit-to-2-trit scheme:
state ZZ will be used futher
Second stage: using more complex logic to pack 6 trits and 2 bits into 7 trits:
Unused codes would be:
UPD another suitable packing relations are 19b -> 11t (~0.1% overhead), 84b -> 53t (~0,0035% overhead), but is seems to be overshoot.
你能从http://en.wikipedia.org/wiki/Arithmetic_coding中摘取一些想法吗?
Could you pinch some ideas from http://en.wikipedia.org/wiki/Arithmetic_coding?