switch-op design

[jacquesqiao]

fix: #8027

[reyoung]

Excellent

[Superjomn]

do these three case similar to if-else or just if? a little vague.

if it is like

if cond1: pass
elif cond2: pass
else: pass #cond3

the three switch.case seems no logic relation with each other.

if it is just three if like

if cond1: pass
if cond2: pass
if cond3: pass

then they shouldn't share the same Switch instance.

Need some improvement to specify what logic it is in first glimpse.

[jacquesqiao]

yes, this is a problem, we have several conditions and the relation is not clear, I will think about this.

[jacquesqiao]

@Superjomn
After some search, I think this situation can be more accurately described by cond op in Lisp https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node84.html

and the interface can be:

def piecewise_decay():
  global_step = pd.Var(shape=[1], value=...)
  learning_rate = pd.Var(shape=[1], value=...)

  candition1 = pd.less_equal(global_step, 100000)
  candition2 = pd.and(pd.less_then(100000, global_step),
                      pd.less_equal(global_step, 110000))

  cand_op = ScalarCandOp()
  with cand_op.case(candition1):
    pd.assign(learning_rate, 1.0)
  with cand_op.case(candition2):
    pd.assign(learning_rate, 0.5)
  with cand_op.default_case():
    pd.assign(learning_rate, 0.1)

  return learning_rate

there are some features for cond op:

• 1. the order of condition is useful, the op will find a suitable branch to run from up to down in order.
• 2. only one branch will run.

[wangkuiyi]

I see.. The point is switch op, but not scalar conditions. Let's change the title to be

# Design Doc: SwitchOp

[wangkuiyi]

Let us shorten this paragraph to be:

In many programming languages, there is switch, as a generalization form of if-elif-else. This design doc is about the implementation of switch for Fluid.

[wangkuiyi]

This is wrong English grammar. Let's change it into

### Example 1. Learning Rate Decay

[wangkuiyi]

I filed a PR to rewrite this document, to correct English grammar, to make it concise and shorter. Please review it @jacquesqiao . Thanks.

[jacquesqiao]

@wangkuiyi thank you for your review and update!

[Superjomn]

We need to scope conds to underline that these three conds are in the same scope.

Currently, the cases should be adjacent, but the with syntax does not have that constraint semantically, so user tends to feel weird and write some wrong code.

what if user write some code like

cond = fluid.switch()
with cond.case(case1):
    pass
with cond.case(case2):
    pass
b = a + c
with cond.case(cond3):
    pass

the b = a + c in the cases will break the global scope/continuous relations of a switch-cases.

Discussed with @jacquesqiao

In lisp, a cond op is like

;; cond has a scope to wrap all the following cases
(cond ((> a 2) "gt")
      ((= a 2) "eq")
      (t "lt")
) ;; cond

it seems better to write code as follows

cond = fluid.switch()
with fluid.switch() as switch:
    '''
    A limitation inside a `switch`-block that no operators can insert between `case`s.  
    This rule is easier to check.
    '''
    with switch.case(fluid.less_equal(a, 10)):
           pass
    with switch.case(fluid.larger(a, 1)):
           pass
    switch()

@wangkuiyi @jacquesqiao

[jacquesqiao]

maybe need a cond.scope() as follow, one cond must and only has one scope.

cond = fluid.switch()
with cond.scope():
    '''
    A limitation inside a `switch`-block that no operators can insert between `case`s.  
    This rule is easier to check.
    '''
    with switch.case(fluid.less_equal(a, 10)):
           pass
    with switch.case(fluid.larger(a, 1)):
           pass

[Superjomn]

LGTM