LeetCode - 319 灯泡开关

本文记录了一位程序员解决LeetCode上的灯泡开关问题的过程,从初始的暴力循环算法到观察到的规律,再到最终利用平方根公式得出高效解决方案。通过测试不同规模的数据,发现了数字与亮灯数量的有趣关系,并探讨了算法优化的重要性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

废话少说,开刷(一定要看到最后,文末有惊喜)

今天随机一题随到一个比较好玩的题,以前经常听说这种题目,但都不是编程序解决的,所以看到这个题还是非常感兴趣的。

题目:

初始时有 n 个灯泡处于关闭状态。第一轮,你将会打开所有灯泡。接下来的第二轮,你将会每两个灯泡关闭第二个。

第三轮,你每三个灯泡就切换第三个灯泡的开关(即,打开变关闭,关闭变打开)。第 i 轮,你每 i 个灯泡就切换第 i 个灯泡的开关。直到第 n 轮,你只需要切换最后一个灯泡的开关。

找出并返回 n 轮后有多少个亮着的灯泡。

来源:力扣(LeetCode)
链接:https://leetcode-cn.com/problems/bulb-switcher
著作权归领扣网络所有。商业转载请联系官方授权,非商业转载请注明出处。

几个testcases:

0 --> 0
1 --> 1
2 --> 1
3 --> 1
100 --> 31

动手刷吧,这个不简单吗,弄个数组,第一轮,1个一个走一遍;第二轮2个2个走一遍;第三轮,3个3个走一遍。。。。。

5分钟,代码就出来了

    public int BulbSwitch(int n)
    {
        bool[] num = new bool[n];
        for (var i = 0; i < n; i++)
        {
            num[i] = true;
        }

        // 先来一个最基本的算法,挨个循环
        for (var i=2; i<=n; i++)
        {
            for(var j=i-1; j<n; j+=i)
            {
                num[j] = !num[j];
            }
        }

        var cnt = 0;
        for (var i = 0; i < n; i++)
        {
            if(num[i] == true)
            {
                cnt++;
            }
        }

        return cnt;
    }

 做了几个UT,上面几个case跑出来了,完美。

最后看到题目上一行小字,0<=n<=10e9,最大是10亿,测一下,发现跑不出来了 [哭]

于是回头看一下,跑了一个1万,10万,100万,到1000万,发现到1亿,UT要16秒才能出来。完犊子了。

 别想了,作为一个中等难度的题,不是这么简单的,换算法吧。

于是想到了另一个算法:

第一个灯,只有1的倍数,操作1次,亮;
第二个灯,有1和2的倍数,操作2次,灭;
第三个灯,有1和3的倍数,操作2次,灭;
第四个灯,有1、2、4的倍数,操作3次,亮;

总结:每个数字获取除了1和他自己的因数,奇亮偶灭。

想到以上想法后,再仔细一项,貌似还是行不通啊。这个针对单个数的测试会快很多,但针对所有数字的计算,还是很大的计算量。 

于是就想到了传说中的最不要脸的查表法,给部分关键数字的数据保存下来,然后按照这个关键数字往上查,关键数字以下的就直接加一个数字就完事了。

太晚了,另外除了这个以外,还想再想想有没有其他的思路。

另外发现一个奇怪的现象:

1 - 1
10 - 3
100 - 10
1,000 - 31
10,000 - 100
100,000 - 316
1,000,000 - 1000
10,000,000 - 3162
100,000,000 - 10000
1,000,000,000 - 31622

睡觉,梦里跟周公讨论讨论去。 

-----

今天继续,昨天想到,要用查表法,然后略微思考了一下,第一反应是常规的指数方式,比如10^n,或者2^n,但仔细一想,发现并不合适,因为不能递归指数级查找,所以从1亿到10亿之间,9亿的数量要查询,1-10就9个数字要查询,差1亿倍的数量级,显然不合适。那就需要平均分了。

那平均分的话,就看良心了。我可以每1亿一个区间分10个区间,也可以每10000分10万个区间。反正这个数字都可以写个程序跑出来然后写到固定的数组里。程序又没有限制我程序文本的大小。显然这样不要脸的行为属于最后的方法,哈哈。

另外就上面那个奇怪的现象,我想先在这个现象上走深入一点看看。

我算了1000万到1亿的数字,画了一个图,寄希望于根据提醒反推出公式,有公式,那就超级简单了。

更细节一点的,10000以内的,锯齿感严重

初步一看,有点像log(n)的公式,这个。,。自己数学不好,网搜去。

搜了一半,说有一个高阶逼近法,然后就兴趣盎然了,为了一个算法去学一个高阶数学公式。。。

回头尝试了2件事:

  • 第一,从1到10000,给数字打印了下来,就是上面那个图的数据源;
  • 第二,从1到10000,打印了有数字变化的数字,就下面这个图

结果发现有大惊喜,这每一个数,不正好是n^2!!!

程序员一句我屮艸芔茻,马上换个算法:

return (int)Math.Sqrt(n);

跑路,验证,通过!

总结:

有啥好总结的,一贯的说法,算法的终极目标,是把算法推算成公式,公式永远比循环啥的快!

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值