多线程算法特别难以设计/调试/证明.Dekker的算法是设计正确的同步算法有多么困难的一个主要例子.Tanenbaum的现代操作系统在其IPC部分中充满了示例.有没有人有这方面的好参考(书籍,文章)?谢谢!
我正在寻找有关平铺游戏的文章,比如旧的最终版本6和7,甚至是拼图海盗.特别:
我想学习垃圾收集背后的理论.我该怎么做呢?显而易见的答案是 - 编译器教科书......问题是,是否有必要学习词法分析,解析和其他通常在文本中垃圾收集之前的东西?
简而言之,了解垃圾收集理论的先决条件是什么?
PS - 我确实知道解析,词法分析等的目的是什么.只是不知道它们是如何实现的.
B树和2-3-4树有什么区别?
另外,您如何找到每个的最大和最小高度?
我想知道Java是否正交,如果是,那么它的哪些特性使它正交.如何判断语言是否正交?例如,我在某些网站上发现C++不是正交的,但没有解释,为什么不.还有哪些其他语言正交?请帮助我,因为互联网上几乎没有关于这个主题的信息.
谢谢
一个理论问题,也许很明显:
在以N个线程的并行方式实现后,算法的执行速度是否比原始的单线程算法快N倍?换句话说,增益是否可以更好地与线程数线性相关?
我正在学习计算机组织和汇编语言课程.本周我们实验室的书面部分有一个问题让我难过.问题是......
减去以下无符号二进制数(显示借位和溢出位).不要转换成二进制补码.
0101 0111 1101
-1110 1011 0110
--------------
Run Code Online (Sandbox Code Playgroud)
我意识到答案是-1001 0011 1001但是我很难通过取较大的数字并从较小的数字中减去并显示我的工作来弄清楚如何借用来实际执行这个减法.我的整个生命从一个较小的数字中减去一个大数字我已经扭转了问题,而是从较大的数字中减去较小的数字,并在结果前面添加了一个负号.我问教授,他说他希望问题能够解决问题.我不允许通过从较大的数字中减去较小的数字来解决这个问题,并且像我通常那样否定.我无法在网上找到任何从较小的无符号二进制数减去较大的无符号二进制数的例子.
如果有人可以向我描述如何在这种情况下执行减法,我将非常感激.
更新:@Alex是正确的.教授正在寻找
0110 1100 0111 (1735)
Run Code Online (Sandbox Code Playgroud)
感谢大家.
你如何争论lambda演算是图灵完整的事实(以最简单的方式)?
可能重复:
'功能'和'程序'有什么区别?
我在网上搜索了这个问题的答案,我得到的答案是函数可以返回值,修改值等,但子程序不能.但我对这种解释并不满意,在我看来,差异不仅仅是术语问题.
所以我正在寻找一个更概念性的答案.
在研究JPEG文件的这篇文章时,我在上述文件的第7.3节中遇到了" 八法则 ".
尽管使用SmartScale扩展引入了1到16的其他块大小,超出原始JPEG标准中的固定大小8,但事实仍然是8的块大小仍然是默认值,而所有其他大小的DCT根据标准8x8 DCT进行缩放.
" 八法则 "解释了为什么大小8是DCT大小的正确默认值和参考值.
我的问题是
从历史上看,是否进行了一项研究,评估了样本中的大量图像,得出的结论是8x8图像块包含足够的冗余数据以支持使用DCT的压缩技术?像8M(4Kx4K)这样非常大的图像尺寸在大多数数字图像/视频中迅速成为常态,这种假设是否仍然有效?
将宏块限制为8x8的另一个历史原因是较大宏块的计算上禁止的图像数据大小.使用现代超标量体系结构(例如CUDA),限制不再适用.
此前类似的问题存在- 1,2和3.但他们都没有打扰任何关于这个神秘的基本" 八法则 "的细节/链接/参考.
1.原始研究的参考/摘录/细节将受到高度赞赏,因为我想用具有非常大尺寸图像的现代数据集重复它以测试8x8宏块的最佳有效性.
2.如果最近进行了类似的研究,也欢迎提及它.
我确实理解SmartScale是有争议的.没有任何明显的潜在好处1,充其量只能与jpeg标准2的其他向后兼容扩展相媲美.我的目标是了解选择8x8作为DCT块大小(在jpeg图像压缩标准中)的原始原因是否仍然相关,因此我需要知道八个定律是什么.
theory ×10
algorithm ×2
math ×2
b-tree ×1
binary ×1
correctness ×1
dct ×1
definition ×1
function ×1
java ×1
jpeg ×1
orthogonal ×1
performance ×1
proof ×1
subroutine ×1
subtraction ×1
terminology ×1
tree ×1