首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    约瑟夫环的循环链表解法和数学公式解法

    约瑟夫环(Josephus)问题是由古罗马的史学家约瑟夫(Josephus)提出的,他参加并记录了公元66—70年犹太人反抗罗马的起义。约瑟夫作为一个将军,设法守住了裘达伯特城达47天之久,在城市沦陷之后,他和40名死硬的将士在附近的一个洞穴中避难。在那里,这些叛乱者表决说“要投降毋宁死”。于是,约瑟夫建议每个人轮流杀死他旁边的人,而这个顺序是由抽签决定的。约瑟夫有预谋地抓到了最后一签,并且,作为洞穴中的两个幸存者之一,他说服了他原先的牺牲品一起投降了罗马。 约瑟夫环问题的具体描述是:设有编号为1,2,……,n的n(n>0)个人围成一个圈,从第1个人开始报数,报到m时停止报数,报m的人出圈,再从他的下一个人起重新报数,报到m时停止报数,报m的出圈,……,如此下去,直到所有人全部出圈为止。当任意给定n和m后,设计算法求n个人出圈的次序。

    04

    GreatSQL的多层SP中Cursor的m_max_cursor_index相关BUG分析

    一、问题发现 在一次开发中在sp中使用多层cursor的时候想知道每层的m_max_cursor_index值分别是多少,以用来做后续开发。 于是做了以下的试验,但是发现第一个level=2那层的m_max_cursor_index的值有点问题。 注:本次使用的GreatSQL 8.0.32-25 SQL语句示例: greatsql> CREATE TABLE t1 (a INT, b VARCHAR(10)); 以下注释里面是该层sp_pcontext的参数值。 DELIMITER $$ CREATE PROCEDURE processnames() -- level=0,m_max_cursor_index=1+8+1 BEGIN DECLARE nameCursor0 CURSOR FOR SELECT * FROM t1; -- level=1,m_cursor_offset=0,m_max_cursor_index=1+8+1 begin DECLARE nameCursor1 CURSOR FOR SELECT * FROM t1; -- level=2,m_cursor_offset=1,m_max_cursor_index=1+8 ☆问题点 begin DECLARE nameCursor2 CURSOR FOR SELECT * FROM t1; -- level=3,m_cursor_offset=2,m_max_cursor_index=1 DECLARE nameCursor3 CURSOR FOR SELECT * FROM t1; -- level=3,m_cursor_offset=2,m_max_cursor_index=2 DECLARE nameCursor4 CURSOR FOR SELECT * FROM t1; -- level=3,m_cursor_offset=2,m_max_cursor_index=3 DECLARE nameCursor5 CURSOR FOR SELECT * FROM t1; -- level=3,m_cursor_offset=2,m_max_cursor_index=4 end; end; begin DECLARE nameCursor6 CURSOR FOR SELECT * FROM t1; -- level=2,m_cursor_offset=1,m_max_cursor_index=1 end; END $$ DELIMITER ; 首先查看上面的sp的code,可以发现nameCursor6和nameCursor1属于同一层,因此他们的offset值一样。 greatsql> show procedure code processnames; +-----+---------------------------------------+ | Pos | Instruction | +-----+---------------------------------------+ | 0 | cpush nameCursor0@0: SELECT * FROM t1 | | 1 | cpush nameCursor1@1: SELECT * FROM t1 | | 2 | cpush nameCursor2@2: SELECT * FROM t1 | | 3 | cpush nameCursor3@3: SELECT * FROM t1 | | 4 | cpush nameCursor4@4: SELECT * FROM t1 | | 5 | cpush nameCursor5@5: SELECT * FROM t1 | | 6 | cpop 4 | | 7 | cpop 1 | | 8 | cpush nameCursor6@1: SELECT * FROM t1 | | 9 | cpop 1 | | 10 | cpop 1 | +-----+---------------------------------------+ 11 rows in set (6.02 sec) 然后通过debug查看每层 sp_pcontext 的参数值(相关参数值已经在上面标识出),发现第一个level=2的sp_pcontext的m_max_cursor_index值多了很多,预期值应

    01

    流程控制引擎组件化

    在较大规模的业务系统中经常会有这样的模块,它按照一定的业务流程调用其它模块来实现一定的业务逻辑,我们姑且称之为流程引擎。这里称之为引擎有两层含义,一、突显其在业务系统的核心重要位置。二、它又是复杂不好维护的,通常由资深程序员把持。这样的引擎不仅代码繁多,与各个模块的接口复杂,并且一定程度对外是不透明的,就像一个黑盒模块。当一个新手想对其进行哪怕是一点点修改的时候都将会是一个灾难。本文就来讨论如何将这样一个庞大的引擎进行组件化改造,使其拥有代码级的流程图,使代码的维护难度降低一个量级,让新手也可以很快知道要如何修改代码,给引擎增加新的功能。

    02
    领券