假设我们有一个包含k个元素的有限域D = {d1,... dk}.
我们认为S是D ^ n的一个子集,即一组形式为<a1,..,an>的元组,其中ai为D.
我们希望使用S'(2 ^ D ^ n的子集)来表示它(紧凑地),即一组形式为<A1,...的元组>,其中Ai是D的子集.这意味着对于任何元组s在'S'中,Ai的叉积中的所有元素都存在于S.
例如,考虑D = {a,b,c}所以k = 3,n = 2并且元组S = <a,b> + <a,c> + <b,b> + <b,c>.
我们可以使用S'= <{a,b},{b,c}>来表示S.
这个单例解决方案也是最小的,S'= <{a},{b,c}> + <{b},{b,c}>也是一个解决方案,但它更大,因此不太理想.
在具体实例中,我们需要处理的一些大小:域D中的k~1000个元素,n <= 10相对较小(复杂性的主要来源),| S | 范围大于> 10 ^ 6.
一种天真的方法在于首先将S插入到S'2 ^ D ^ n的域中,然后使用以下测试,2',S'中的两个元组s1,s2可以融合以在S'iff中形成单个元组. .它们只有一个组成部分不同.
例如
<a,b> + <a,c> - > <{a},{b,c}>(第二部分不同)
<b,b> + <b,c> - > <{b},{b,c}>(第二个组成部分不同)
<{a},{b,c}> + <{b},{b,c}> - > <{a,b},{b,c}>(第一个组件不同)
现在可能有几个最小的S',我们有兴趣找到任何一个,并且某种最小化的近似值也可以,只要它们没有给出错误的结果(即使S'没有它可能的那么小) ,但我们得到非常快的结果).
朴素算法必须处理这样一个事实,即任何新引入的"融合"元组都可以与其他元组匹配,因此即使n保持低,它在大输入集上也会非常严重.你需要| S'| ^ 2比较以确保收敛,并且每当你融合两个元素时,我正在重新测试每一对(我怎么能改进它？).
很多效率都依赖于迭代顺序,因此以某种方式对集合进行排序可能是一个选项,或者可能是使用哈希进行索引,但我不知道该怎么做.
命令式伪代码是理想的,或指向重新设计问题的指针,我可以运行求解器的东西真的会有所帮助.
我试图确定一类可以从使用 Java 8 中引入的 parallelStream API 中受益的 Java 应用程序。
我知道其他 SO 帖子中描述的 API 的许多警告：
尽管如此，如果 Stream API 已经被使用，API 仍然可以使用现代多核机器，代码不是很具有侵入性，因此在低开发成本下没有麻烦的多线程。因此，我仍然认为它在某些情况下很有用。
我认为应用程序上下文因此必须是这样的：
我在github上搜索过，但很难找到不是练习或教科书示例的parallelStream用法的相关示例（我欢迎链接到API的中型+项目中的一些用法）。
那么，Java 语言开发人员使用此 API 的目标是哪种应用程序？
您是否同意上述对 API 有用的应用程序上下文的要求？
我正在 Mac 上编译一些二进制文件，但是使用更新的编译器编译后的大小变得很大（从之前的 ~5MB 增加到 ~20MB）。我认为这与之前未激活的 LTO（链接时间优化）有关。我没有在 linux 上观察到这个文件膨胀。
在玩弄之后strip（实际上没有减少大小，尽管尝试基于 Xcode 的标志-S -x并且也没有标志，以及 GNU libtools strip 由 homebrew binutils 配方提供的标志-s，所有这些似乎都具有相同的效果）我找到了这个工具：https ://github.com/google/bloaty Bloaty McBloated，在我的二进制文件上运行时，它会产生以下输出：
FILE SIZE VM SIZE
-------------- --------------
53.9% 9.72Mi 53.8% 9.72Mi __GNU_LTO,__wrapper_sects
32.5% 5.86Mi 32.4% 5.86Mi __GNU_DWARF_LTO,__debug_info
6.2% 1.11Mi 6.2% 1.11Mi __TEXT,__text
2.2% 403Ki 2.2% 403Ki __TEXT,__eh_frame
1.6% 298Ki 1.6% 298Ki __GNU_LTO,__wrapper_names
1.0% 177Ki 1.0% 177Ki Export Info
0.7% 131Ki 0.7% 131Ki Weak Binding Info
0.4% 77.0Ki 0.4% 77.0Ki __GNU_DWARF_LTO,__debug_str
0.4% …