答案 0 :(得分:1)
虽然您的解决方案可能更直接,但我认为它实际上并不是更有效率。
我假设“正确”的算法是这样的:
我在比较你的算法时看到的主要内容是:
BigInteger
来存储中间值(我假设您正在使用BigInteger
或某些等效Object
来避免约束最终链表本身之上的int
或long
)。原始算法不会使用多个int
来进行中间计算,因此从长远来看,原始算法实际上使用的内存较少。BigInteger
s进行所有算术运算,而不是int
s。虽然BigInteger
可能真的被优化到不比原始操作慢得多的程度,但我非常怀疑调用BigInteger#add
比在{{+
上执行int
操作更快。 1}}秒。此外,还有一些值得思考的问题。假设你没有像BigInteger
那样方便存储任意大整数的东西。然后你将不得不有一些方法来存储任意大整数,以使你的算法正常工作。在那之后,你基本上需要一种方法来添加任意大整数以添加任意大整数,并且你最终遇到一个问题,你要么必须做一些像原始算法无论如何,或者你最终在子程序中使用完全不同的表示(yikes)。
答案 1 :(得分:0)
(假设“整数”是指int
。)
您的解决方案不会扩展到可以容纳int
的数字,而原始解决方案仅受可用内存量的限制。
就效率而言,您的解决方案没有任何内容可以使其比原始解决方案更有效。
答案 2 :(得分:0)
当然,您的解决方案更容易描述 - 并且在某些情况下可能会提出一个论点,即在与大型团队合作时,您的解决方案所产生的代码的可读性会更好。
然而,大部分时间 - 他们建议的答案是内存效率更高,并且可能更有效率。
您建议浏览第一个链接列表,将其存储为数字(+1商店)。通过第二个,将其存储为数字(+1商店)。添加2个数字,保存结果(+1存储)。将此号码转换为链接列表并保存(+1商店)
他们的解决方案包括浏览第一个和第二个链表,同时写入第三个,并将其存储为新的(+1商店)
这是+1商店,而不是你的+4商店。这似乎并不多,但如果我们尝试同时添加n对数字(在分布式系统或其他东西上),你会看到4n个商店,而不仅仅是n个商店。这可能是一件大事。