Semver 的数字和可排序哈希和答案

【问题标题】：Numeric and orderable hashsum of a SemverSemver 的数字和可排序哈希和
【发布时间】：2016-12-26 04:53:21
【问题描述】：

我正在开发一个依赖伪 semver 版本号（仅使用主要、次要和补丁号）来索引文件的系统。

为了更快的比较和查找以及以这种方式进行操作的乐趣，我正在尝试为这些版本号计算一个数字“哈希”。此数字哈希应具有以下属性（以下极端示例）：

Hash(1.0.500) < Hash(1.1.0) < Hash(1.3000.0) < Hash(2.0.0)

我已经尝试过各种各样的解决方案，例如加权每个位置或像这样

 int hash = 17;
 hash = hash * 42 + Major;
 hash = hash * 42 + Minor;
 hash = hash * 42 + Patch;

但所有这些都可以很快达到限制（跟随乘数或权重）

Hash(1.0.1500) > Hash(1.1.0)

我本可以选择一种肮脏的方式并使用一个大的乘法器来避免这种冲突（并确保最少的组合数量），但我更愿意选择一条更干净的路径

这可能吗？

【问题讨论】：

你对索引的每个部分都有大小限制吗？
我想避免引入尺寸限制，但关于亨利的回应，我想我必须这样做
某些架构（例如 Google App Engine）需要一个（长）数字来标识您的版本。因此，您必须将语义版本转换为数字。我已经使用了major*10000+minor*100+patch。当然，这将您限制为每个未成年人的 99 个乐段。

【解决方案1】：

如果我理解正确，您尝试做的是将具有三个组件（按字典顺序）的版本号转换为单个自然数，以便保留顺序。这不是真正的哈希。

如果组件的大小有上限，这将是微不足道的。只需使用大于最大分量值的乘数即可。

如果没有这样的上限，这是不可能的。假设 0.1.0 映射到数字 N，那么所有版本 0.0.x 都必须映射到小于 N 的数字，如果有无限多个，这是不可能的。

【讨论】：

这就是我的想法，我的另一个想法是使用整个组或版本来找出乘法器，这也是愚蠢的，因为以后添加到组中的任何版本都可能破坏逻辑。我知道这不是纯粹意义上的哈希（这就是为什么它被引号包围）:)。无论如何感谢您的回答