【问题标题】:Programming Logic: Finding the smallest equation to a large number编程逻辑:找到一个大数的最小方程
【发布时间】:2010-08-04 20:03:00
【问题描述】:

我对数学知之甚少,所以我不知道如何开始用谷歌搜索我正在寻找的东西,所以我依靠专家的智慧来帮助我了解我所追求的......

我正在尝试为特定的大数找到最小的方程串。例如给定数字

“39402006196394479212279040100143613805079739270465446667948293404245721771497210611414266254884915640806627990306816”

最小的方程是 64^64(据我所知)。它只包含 5 个字节。

基本上,该程序会反转数学运算,而不是接受一个表达式并找到答案,而是接受一个答案并找到最简单的表达式。简单的是这种情况意味着最小的字符串,而不是真正简单的数学。

这已经创建了吗?如果是这样,我在哪里可以找到它?我正在寻找非常大的数字(10 ^ 10000000)并将它们分解为希望长度为100个字符的表达式。这甚至可能吗?现代 CPU/GPU 无法进行如此大的计算吗?


编辑:

好的。因此,根据答案判断,找到最小的方程需要太多时间。有没有办法暴力破解这个并获得迄今为止发现的最小的?

例如给定一个超级超级大的数字。有时取数字的平方根会导致表达式小于数字本身。

至于它会从什么表达式开始,它自然会尝试最小的表达式。我确信有很多我不知道的数学知识,但是让数字变小很多的方法之一就是幂。

【问题讨论】:

  • 您究竟为什么要这样做?我看不到一点。
  • 你所说的“方程”是什么意思?假设你有(你的号码)+1。你想要“64^64+1”吗?如果你只想要权力,那相对容易。否则,您必须准确定义您允许作为“方程式”的表达式类型。 (“64^64”只是一个表达式,而不是一个方程。一个方程是一个带有等号的东西,你说一件事等于另一件事。)
  • 我希望您的目标不是使用这种技术制作压缩算法。即使假设这样的程序不仅存在而且在合理的时间内运行,“魔函数理论”与任何其他压缩技术(例如鸽子洞原理)具有相同的局限性。
  • 2^384 也可以,长度一样。
  • 更不用说4^1928^12816^96

标签: algorithm math


【解决方案1】:

只是为了在您的 Google 料斗中添加另一个关键字,请参阅 Kolmogorov Complexity。字符串的 Kolmogorov 复杂度是在给定空输入的情况下输出字符串的最小图灵机的大小。这是一种形式化你所追求的东西的方法。但是,已知计算给定字符串的 Kolmogorov 复杂度是一个无法确定的问题:)

希望这会有所帮助,

TJ

【讨论】:

  • +1:这本质上是我认为要解决的问题(链接比我将信息论视为一个整体的答案更好)
  • 比这更简单。我们可以列出哪些字符串评估为值,检查它们的值,然后在列表中查找,直到找到具有所需值的字符串。由于写出的数字是可接受的字符串,我们总是会在有限时间内找到一个有限数字的值。这是完全可以决定的,只是完全不切实际。
  • 不错的想法,但我不同意。 Kolmogorov 复杂性指的是 图灵完备 语言。这里的问题是指一种非常有限的算术表达式语言,它并不完整。顺便说一句,Kolmogorov 不可计算性的证明不适用于这种语言(它需要条件和循环)。
  • 这是 Stack Overflow 上最糟糕的一种现象,有人用令人印象深刻的大词发布了一个无益的答案,每个人都在没有检查的情况下投票。 Kolmogorov 复杂性的不可判定性在这里根本不相关,使用如此有限的语言......这里的问题实际上是微不足道的。
  • 正如@David、@Eyal 和@Shreevastsa 提到的,我们当然可以枚举所有小于一定长度(例如数字的长度)的字符串,所以这完全是100% 可判定的。跨度>
【解决方案2】:

这里有一个很好的程序可以做到这一点: http://mrob.com/pub/ries/index.html

【讨论】:

  • 这很酷,可能会起作用...我猜肯定有一些数字会永远旋转而找不到精确匹配,即使您将其限制为整数。跨度>
  • @rmeador:实际上,在这种情况下,它会耗尽内存而不是永远循环。 :)
【解决方案3】:

我问了“这样做有什么意义”这个问题,因为我不知道您是从数学角度还是从大量因式分解的角度来看这个问题。

由于其他答案已经考虑了因式分解的观点,我将看看数学角度。特别是,您描述的问题是 可压缩性 问题。这是你有一个数字的地方,并且想用最小的算法来描述它。高度随机数的可压缩性很差,因为要描述它们,您要么必须写出所有数字,要么描述仅比数字本身略小的确定性算法。

目前没有通用数学定理可以确定数字的表示是否是该数字的最小可能(尽管可以通过了解香农的信息论来发现下限)。 (我说的是一般定理,因为确实存在特殊情况)。

正如你所说,你不懂很多数学,这对你来说可能不是一个有用的答案......

【讨论】:

    【解决方案4】:

    您正在执行某种形式的无损压缩,而无损压缩不适用于随机数据。相反,假设您有一种将 N 位数字压缩为 N-1 位数字的方法。在这种情况下,您将有 2^N 个值压缩成 2^N-1 个名称,每个名称平均有 2 个值,因此您的平均名称无法解压缩。无损压缩适用于相对结构化的数据,其中我们可能获得的数据被压缩得很小,而我们不会获得的数据实际上会增长一些。

    它比这更复杂一些,因为您通过允许每个字符提供更多信息来部分地进行压缩。 (涉及数字和运算符的 N 字符序列的数量比单独的数字要多。)不过,您不会获得无损压缩,平均而言,它比仅将整数写入二进制更好。

    【讨论】:

    • 请注意,原始字母表有 10 个符号 (0-10),“目标”字母表允许乘法、求幂等符号。不过,即使您添加(比如说)5 个符号,压缩所有长度为 n 的 10^n 个字符串,在最坏的情况下,您至少需要 n log(10/15) 个符号,因此您不能压缩超出常数因子的任意数字。
    【解决方案5】:

    看起来您基本上想要对任意大的数字进行因式分解。这是一个非常困难的问题,它实际上是现代密码学的基石。

    【讨论】:

    • 不,这没有保理那么困难。您可以找到附近的数字并将它们分解。
    • @ShreevatsaR:所以现在你已经用首先确定保理不是要采取的路线(不确定你是如何决定的)然后将所有的保理周围的数字?这怎么容易?
    • @Mark Peters:找到附近的合数要容易得多 - 每个 n^th 数都可以被 n 整除。 (此外,除非数字中有小数的大幂,否则分解是从不的路线:可以检查。)
    • @ShreevatsaR:所以?正如我的挑战清楚地表明的那样,这并不能保证更小的方程式。回答我的挑战,然后我会考虑相信你。在那之前,你没有为你的观点提供任何证据或引用,所以我只能驳回它们。
    • @Mark Peters:正如我所说,当数字中有很大的幂时,因式分解可能是最佳的——就像你的例子(或者实际上是问题中的 64^64)。但是有人断言这个问题与因式分解一样困难,并且在某些情况下因式分解是最优的这一事实不足以证明这一断言的合理性。当然,举证责任在于做出断言的一方。
    【解决方案6】:

    这似乎是一个数学问题,而不是编程或计算机科学问题。你应该在https://math.stackexchange.com/

    上问这个

    【讨论】:

      【解决方案7】:

      虽然您的问题还不清楚,但也许integer relation finding 是您所追求的。

      编辑:

      有人猜测,找到“短”形式与因式分解问题有某种关系。我不相信这是真的,除非你的定义需要一个产品作为答案。考虑下面的伪算法,它只是草图,没有尝试优化。

      如果“最短”是一个定义明确的概念,那么通常您可以通过使用小整数到大幂来获得“短”表达式。如果 N 是我的整数,那么我可以在附近找到一个 0 mod 4 的整数。有多接近?在 +/- 2 内。我可以在 +/- 4 内找到一个整数,即 0 mod 8。依此类推。现在这只是 2 的幂。我可以用 3、5、7 等执行相同的练习。例如,我们可以轻松找到同时是 2、3、5、7 幂的乘积的最接近整数, 11、13 和 17,称之为 N_1。现在计算 N-N_1,称之为 d_1。也许 d_1 是“短”的。如果是这样,那么 N_1(表示为素数的幂)+ d_1 就是答案。如果不是,则递归查找 d_1 的“短”表达式。

      我们也可以选择可能比我们的首选更远的整数;即使差异 d_1 较大,它也可能具有较短的形式。

      【讨论】:

        【解决方案8】:

        无限数量的素数的存在意味着总会有无法通过因式分解来简化的数字。抱歉,您的要求是不可能的。

        【讨论】:

        • "2^6972593-1" 是超过 200 万位的素数,但我用 11 个字符表示
        • 是的,一些素数可以用“整数”的小偏移量来表示,但 OP 给出了涉及因式分解而不是混合和匹配的示例。
        • 但是,OP 并未将其排除为一个选项。
        猜你喜欢
        • 2023-04-09
        • 1970-01-01
        • 2011-08-13
        • 1970-01-01
        • 1970-01-01
        • 2014-06-09
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多