滑动窗口 [英] Sliding window
问题描述
让我重新解释一下我的问题没有得到妥善回答。我希望
将文件读入n位数据块_extremely fast_，处理
块，最后将它们写回另一个文件。问题
通常人们建议算法很慢。
我在想可能的算法应该先读取文件
进入一个缓冲区（在计算机内存中），这是一个很大的wrt
的长度是个别的比特块。其次，应该尽量避免像for这样的缓慢的操作。也许像memmove或memcopy这样的操作可以解决这个问题，但是如何？
所以，基本上，人们可以认为算法就像一个窗口
通过一个文件顺序显示一次只有n位
块。没有一个简单的解决方案，因为计算机处理字节
而不是位，算法必须是最先进的。
有什么建议吗？谢谢。
" filia& sofia" < in ********* @ hotmail.comwrote in message
news：2a ********************* ************* @ q10g2000 prf.googlegroups.com ...
让我重新解释一下我的问题回答得当。我希望
将文件读入n位数据块_extremely fast_，处理
块，最后将它们写回另一个文件。问题
通常人们建议算法很慢。
我在想可能的算法应该先读取文件
进入一个缓冲区（在计算机内存中），这是一个很大的wrt
的长度是个别的比特块。其次，应该尽量避免像for这样的缓慢的操作。也许像memmove或memcopy这样的操作可以解决这个问题，但是如何？
所以，基本上，人们可以认为算法就像一个窗口
通过一个文件顺序显示一次只有n位
块。没有一个简单的解决方案，因为计算机处理字节
而不是位，算法必须是最先进的。
有什么建议吗？谢谢。
典型的块有多大？一个典型的文件？
读入内存时，你想要它们是字节对齐的吗？ （如果没有，只需阅读
整个文件到内存中也将所有块读入内存;然后
你可以原位处理它们，也许使用一个特殊的指针格式，
包括位域信息）
memmove和类似的函数都是字节对齐的。如果块很大，你可以在主要部分使用memmove等，但我想你可能想要
块移位（所以它从头开始第一个字节，但可能
在最后一个字节中仍有未使用的位）
输出的对齐是否与输入中的对齐相同？ br />
我没有任何实际答案，但有时提供更多细节，例如这些可以获得更好的帮助。
-
Bart
" filia& sofia" < in ********* @ hotmail.comwrites：
让我重新解释一下我的问题没有得到妥善回答。我希望
将文件读入n位数据块_extremely fast_，处理
块，最后将它们写回另一个文件。问题
通常人们建议算法很慢。
我在想可能的算法应该先读取文件
进入一个缓冲区（在计算机内存中），这是一个很大的wrt
的长度是个别的比特块。其次，应该尽量避免像for这样的缓慢的操作。也许像memmove或memcopy这样的操作可以解决这个问题，但是如何？
所以，基本上，人们可以认为算法就像一个窗口
通过一个文件顺序显示一次只有n位
块。没有一个简单的解决方案，因为计算机处理字节
而不是位，算法必须是最先进的。
有什么建议吗？谢谢。
是的。购买一本关于编程和编程C的好书。
这通常被认为是圣经：
http://www.amazon.com/Programming-La.../dp/0131103628
很高兴有帮助。
典型的块有多大？一个典型的文件？
实际上，没有典型的块或典型文件。
的长度是动态分配的块，典型的文件是任何文件，例如
游戏设置文件或DVD电影。
读入内存时，是否希望它们按字节对齐？ （如果没有，只需阅读
整个文件到内存中也将所有块读入内存;然后
你可以原位处理它们，也许使用一个特殊的指针格式，
包括位域信息）
memmove和类似的函数都是字节对齐的。如果块很大，你可以在主要部分使用memmove等，但我想你可能想要
块移位（所以它从头开始第一个字节，但可能
在最后一个字节中仍有未使用的位）
我只想要文件中存在的位本来。
的长度应该是ceil（n / 8）字节。此外，不保存任何信息的位位于最高位位置。结束。在
short中，读取信息（以位为单位）以字节表示。
例如，如果文件包含：0110 0100 1111 1101 0011 0101 0101 1100
0000"并且n = 9.
然后，第一个块是（没有填充）0110 0100 1。第二个是111 1101
00。第三个是11 0101 010。第4个是1 1100 0000。
现在，我们需要两个字节来表示9位。我们用零填充所有块
，例如1st变为0000000 011001001。
输出的对齐是否与输入中的对齐相同？
输出文件与输入文件相同：算法必须以保留信息的方式删除
填充零和加入块在
重叠字节。此时，该算法应该以极快的速度生成相同的文件。
希望这些附加信息有帮助。
Let me rephrase my question that hasn''t been answered properly. I want
to read a file into n-bit chunks of data _extremely fast_, process the
chunks and finally write them back into a different file. The problem
is that usually people suggest algorithms that are slow.
I''m thinking that the possible algorithm should first read the file
into a buffer (in computer memory), which is large w.r.t. length of
the individiual chunk of bits. Secondly, one should try to avoid slow
operations such as "for". Maybe operations like memmove or memcopy
would do the trick, but how?
So, basically, one could think that the algorithm is like a window
that goes through a file sequentially showing at a time only the n-bit
chunk. There isn''t a trivial solution, because computers process bytes
instead of bits and the algorithm has to be state-of-art.
Any suggestions? Thank you.
"filia&sofia" <in*********@hotmail.comwrote in message
news:2a**********************************@q10g2000 prf.googlegroups.com...Let me rephrase my question that hasn''t been answered properly. I want
to read a file into n-bit chunks of data _extremely fast_, process the
chunks and finally write them back into a different file. The problem
is that usually people suggest algorithms that are slow.
I''m thinking that the possible algorithm should first read the file
into a buffer (in computer memory), which is large w.r.t. length of
the individiual chunk of bits. Secondly, one should try to avoid slow
operations such as "for". Maybe operations like memmove or memcopy
would do the trick, but how?
So, basically, one could think that the algorithm is like a window
that goes through a file sequentially showing at a time only the n-bit
chunk. There isn''t a trivial solution, because computers process bytes
instead of bits and the algorithm has to be state-of-art.
Any suggestions? Thank you.How big are typical chunks? A typical file?
When read into memory, do you want them byte-aligned? (If not, just reading
the entire file into memory will also read all the chunks into memory; then
you could process them in-situ, perhaps using a special pointer format that
includes bitfield info)
memmove and similar functions are all byte-aligned. If the chunks are big,
you can use memmove etc on the main portion, but I guess you may want the
chunk bit-shifted (so it starts on the beginning of the first byte, but may
still have unused bits in the last byte)
Will the alignment on output be the same as in the input?
I don''t have any actual answers, but sometimes providing more details such
as these can elicit better help.
--
Bart
"filia&sofia" <in*********@hotmail.comwrites:
Let me rephrase my question that hasn''t been answered properly. I want
to read a file into n-bit chunks of data _extremely fast_, process the
chunks and finally write them back into a different file. The problem
is that usually people suggest algorithms that are slow.
I''m thinking that the possible algorithm should first read the file
into a buffer (in computer memory), which is large w.r.t. length of
the individiual chunk of bits. Secondly, one should try to avoid slow
operations such as "for". Maybe operations like memmove or memcopy
would do the trick, but how?
So, basically, one could think that the algorithm is like a window
that goes through a file sequentially showing at a time only the n-bit
chunk. There isn''t a trivial solution, because computers process bytes
instead of bits and the algorithm has to be state-of-art.
Any suggestions? Thank you.Yes. Buy a good book on programming and programming C in particular.
This is generally considered the bible:
http://www.amazon.com/Programming-La.../dp/0131103628
Nice to have help.
How big are typical chunks? A typical file?Actually, there are no typical chunks or typical file. The length of
the chunks are dynamically assigned and typical file is any file e.g.
game setup file or DVD movie.
When read into memory, do you want them byte-aligned? (If not, just reading
the entire file into memory will also read all the chunks into memory; then
you could process them in-situ, perhaps using a special pointer format that
includes bitfield info)
memmove and similar functions are all byte-aligned. If the chunks are big,
you can use memmove etc on the main portion, but I guess you may want the
chunk bit-shifted (so it starts on the beginning of the first byte, but may
still have unused bits in the last byte)I want only the bits that exist in the file originally. The length of
the chunks should be ceil(n/8) bytes. Also, the bits that do not hold
any information are located at the "Most Significant Bit" end. In
short, the read information (in bits) is represented in bytes.
For example, if the file has: "0110 0100 1111 1101 0011 0101 0101 1100
0000" and n=9.
Then, 1st chunk is (without padding) "0110 0100 1". 2nd is "111 1101
00". 3rd is "11 0101 010" and 4th is "1 1100 0000".
Now, we need two bytes to represent nine bits. We pad all the chunks
with zeroes, e.g. 1st becomes "0000000 011001001" etc.
Will the alignment on output be the same as in the input?The output file is same as the input file: the algorithm has to remove
padded zeroes and join chunks in the way that preserves information in
overlapping bytes. At this point, the algorithm should produce
identical files in a extremely fast manner.
Hopefully, this additional information helps.
这篇关于滑动窗口的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
