text:
### No.3052 Squaring

レベル : / 実行時間制限 : 1ケース 2.000秒 / メモリ制限 : 512 MB / スペシャルジャッジ問題 （複数の解が存在する可能性があります）
タグ : / 解いたユーザー数 3

ProblemId : 2865 / 出題時の順位表 / 自分の提出

#### 入力

$N$
$A_1$ $\cdots$ $A_N$

・$1 \leq N \leq 26$
・$1 \leq A_1 < \cdots < A_N$
・$A_1 ^ 2 + \cdots + A_N ^ 2 \leq 500 ^ 2$

#### 出力

###### 可能な場合：
$L$
$c_{1, 1} \cdots c_{1, L}$
$\vdots$
$c_{L, 1} \cdots c_{L, L}$

・できあがった正方形の一辺の長さを $L$ とする
・並べ方は、縦 $L$ マス、横 $L$ マスの文字配列 $c$ として表現する
・各マスの文字は、全体の正方形のそのマスに相当する部分が $1$ 番目に小さい正方形である場合は 'A' 、$2$ 番目に小さい正方形である場合は 'B' 、……、$26$ 番目に小さい正方形である場合は 'Z' とする

###### 不可能な場合：
-1

#### サンプル

##### サンプル1
###### 入力
1
3

###### 出力
3
AAA
AAA
AAA

##### サンプル2
###### 入力
2
1 3

###### 出力
-1

$2$ 個の正方形の面積の和は $10$ なので、もし正方形にできるとしたらその一辺の長さは $\sqrt{10}$ にならなければいけませんが、そんなことは不可能です。

##### サンプル3
###### 入力
24
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

###### 出力
-1

##### サンプル4
###### 入力
23
1 2 3 4 5 7 8 10 12 13 14 15 16 19 21 28 29 31 32 37 38 41 44

###### 出力例
110
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWQQQQQQQQQQQQQQQQQQQQQQQQQQQQQTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWQQQQQQQQQQQQQQQQQQQQQQQQQQQQQTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWQQQQQQQQQQQQQQQQQQQQQQQQQQQQQTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWQQQQQQQQQQQQQQQQQQQQQQQQQQQQQTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWQQQQQQQQQQQQQQQQQQQQQQQQQQQQQTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWQQQQQQQQQQQQQQQQQQQQQQQQQQQQQTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWQQQQQQQQQQQQQQQQQQQQQQQQQQQQQTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWQQQQQQQQQQQQQQQQQQQQQQQQQQQQQTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWQQQQQQQQQQQQQQQQQQQQQQQQQQQQQTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWQQQQQQQQQQQQQQQQQQQQQQQQQQQQQTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWQQQQQQQQQQQQQQQQQQQQQQQQQQQQQTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWQQQQQQQQQQQQQQQQQQQQQQQQQQQQQTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWQQQQQQQQQQQQQQQQQQQQQQQQQQQQQTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWQQQQQQQQQQQQQQQQQQQQQQQQQQQQQTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWQQQQQQQQQQQQQQQQQQQQQQQQQQQQQTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWQQQQQQQQQQQQQQQQQQQQQQQQQQQQQTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWQQQQQQQQQQQQQQQQQQQQQQQQQQQQQTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWQQQQQQQQQQQQQQQQQQQQQQQQQQQQQTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWQQQQQQQQQQQQQQQQQQQQQQQQQQQQQTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWQQQQQQQQQQQQQQQQQQQQQQQQQQQQQTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWQQQQQQQQQQQQQQQQQQQQQQQQQQQQQTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWQQQQQQQQQQQQQQQQQQQQQQQQQQQQQTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWQQQQQQQQQQQQQQQQQQQQQQQQQQQQQTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWQQQQQQQQQQQQQQQQQQQQQQQQQQQQQTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWQQQQQQQQQQQQQQQQQQQQQQQQQQQQQTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWQQQQQQQQQQQQQQQQQQQQQQQQQQQQQTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWQQQQQQQQQQQQQQQQQQQQQQQQQQQQQTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWQQQQQQQQQQQQQQQQQQQQQQQQQQQQQTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWQQQQQQQQQQQQQQQQQQQQQQQQQQQQQTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWOOOOOOOOOOOOOOOOOOOOOGGGGGGGGTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWOOOOOOOOOOOOOOOOOOOOOGGGGGGGGTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWOOOOOOOOOOOOOOOOOOOOOGGGGGGGGTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWOOOOOOOOOOOOOOOOOOOOOGGGGGGGGTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWOOOOOOOOOOOOOOOOOOOOOGGGGGGGGTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWOOOOOOOOOOOOOOOOOOOOOGGGGGGGGTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWOOOOOOOOOOOOOOOOOOOOOGGGGGGGGTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWOOOOOOOOOOOOOOOOOOOOOGGGGGGGGTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWOOOOOOOOOOOOOOOOOOOOOJJJJJJJJJJJJJSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWOOOOOOOOOOOOOOOOOOOOOJJJJJJJJJJJJJSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWOOOOOOOOOOOOOOOOOOOOOJJJJJJJJJJJJJSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWOOOOOOOOOOOOOOOOOOOOOJJJJJJJJJJJJJSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWOOOOOOOOOOOOOOOOOOOOOJJJJJJJJJJJJJSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWOOOOOOOOOOOOOOOOOOOOOJJJJJJJJJJJJJSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWOOOOOOOOOOOOOOOOOOOOOJJJJJJJJJJJJJSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
PPPPPPPPPPPPPPPPPPPPPPPPPPPPMMMMMMMMMMMMMMMMOOOOOOOOOOOOOOOOOOOOOJJJJJJJJJJJJJSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
PPPPPPPPPPPPPPPPPPPPPPPPPPPPMMMMMMMMMMMMMMMMOOOOOOOOOOOOOOOOOOOOOJJJJJJJJJJJJJSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
PPPPPPPPPPPPPPPPPPPPPPPPPPPPMMMMMMMMMMMMMMMMOOOOOOOOOOOOOOOOOOOOOJJJJJJJJJJJJJSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
PPPPPPPPPPPPPPPPPPPPPPPPPPPPMMMMMMMMMMMMMMMMOOOOOOOOOOOOOOOOOOOOOJJJJJJJJJJJJJSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
PPPPPPPPPPPPPPPPPPPPPPPPPPPPMMMMMMMMMMMMMMMMOOOOOOOOOOOOOOOOOOOOOJJJJJJJJJJJJJSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
PPPPPPPPPPPPPPPPPPPPPPPPPPPPMMMMMMMMMMMMMMMMOOOOOOOOOOOOOOOOOOOOOJJJJJJJJJJJJJSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
PPPPPPPPPPPPPPPPPPPPPPPPPPPPMMMMMMMMMMMMMMMMLLLLLLLLLLLLLLLNNNNNNNNNNNNNNNNNNNSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
PPPPPPPPPPPPPPPPPPPPPPPPPPPPMMMMMMMMMMMMMMMMLLLLLLLLLLLLLLLNNNNNNNNNNNNNNNNNNNSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
PPPPPPPPPPPPPPPPPPPPPPPPPPPPMMMMMMMMMMMMMMMMLLLLLLLLLLLLLLLNNNNNNNNNNNNNNNNNNNSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
PPPPPPPPPPPPPPPPPPPPPPPPPPPPMMMMMMMMMMMMMMMMLLLLLLLLLLLLLLLNNNNNNNNNNNNNNNNNNNSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
PPPPPPPPPPPPPPPPPPPPPPPPPPPPMMMMMMMMMMMMMMMMLLLLLLLLLLLLLLLNNNNNNNNNNNNNNNNNNNSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
PPPPPPPPPPPPPPPPPPPPPPPPPPPPMMMMMMMMMMMMMMMMLLLLLLLLLLLLLLLNNNNNNNNNNNNNNNNNNNSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
PPPPPPPPPPPPPPPPPPPPPPPPPPPPMMMMMMMMMMMMMMMMLLLLLLLLLLLLLLLNNNNNNNNNNNNNNNNNNNSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
PPPPPPPPPPPPPPPPPPPPPPPPPPPPMMMMMMMMMMMMMMMMLLLLLLLLLLLLLLLNNNNNNNNNNNNNNNNNNNSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
PPPPPPPPPPPPPPPPPPPPPPPPPPPPMMMMMMMMMMMMMMMMLLLLLLLLLLLLLLLNNNNNNNNNNNNNNNNNNNSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
PPPPPPPPPPPPPPPPPPPPPPPPPPPPMMMMMMMMMMMMMMMMLLLLLLLLLLLLLLLNNNNNNNNNNNNNNNNNNNSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
PPPPPPPPPPPPPPPPPPPPPPPPPPPPIIIIIIIIIIIIDDDDLLLLLLLLLLLLLLLNNNNNNNNNNNNNNNNNNNSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
PPPPPPPPPPPPPPPPPPPPPPPPPPPPIIIIIIIIIIIIDDDDLLLLLLLLLLLLLLLNNNNNNNNNNNNNNNNNNNSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
PPPPPPPPPPPPPPPPPPPPPPPPPPPPIIIIIIIIIIIIDDDDLLLLLLLLLLLLLLLNNNNNNNNNNNNNNNNNNNSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
PPPPPPPPPPPPPPPPPPPPPPPPPPPPIIIIIIIIIIIIDDDDLLLLLLLLLLLLLLLNNNNNNNNNNNNNNNNNNNSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
PPPPPPPPPPPPPPPPPPPPPPPPPPPPIIIIIIIIIIIICCCALLLLLLLLLLLLLLLNNNNNNNNNNNNNNNNNNNSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
PPPPPPPPPPPPPPPPPPPPPPPPPPPPIIIIIIIIIIIICCCBBKKKKKKKKKKKKKKNNNNNNNNNNNNNNNNNNNSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
PPPPPPPPPPPPPPPPPPPPPPPPPPPPIIIIIIIIIIIICCCBBKKKKKKKKKKKKKKNNNNNNNNNNNNNNNNNNNSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
PPPPPPPPPPPPPPPPPPPPPPPPPPPPIIIIIIIIIIIIEEEEEKKKKKKKKKKKKKKNNNNNNNNNNNNNNNNNNNSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
PPPPPPPPPPPPPPPPPPPPPPPPPPPPIIIIIIIIIIIIEEEEEKKKKKKKKKKKKKKNNNNNNNNNNNNNNNNNNNSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
PPPPPPPPPPPPPPPPPPPPPPPPPPPPIIIIIIIIIIIIEEEEEKKKKKKKKKKKKKKHHHHHHHHHHVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
PPPPPPPPPPPPPPPPPPPPPPPPPPPPIIIIIIIIIIIIEEEEEKKKKKKKKKKKKKKHHHHHHHHHHVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
PPPPPPPPPPPPPPPPPPPPPPPPPPPPIIIIIIIIIIIIEEEEEKKKKKKKKKKKKKKHHHHHHHHHHVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUFFFFFFFKKKKKKKKKKKKKKHHHHHHHHHHVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUFFFFFFFKKKKKKKKKKKKKKHHHHHHHHHHVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUFFFFFFFKKKKKKKKKKKKKKHHHHHHHHHHVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUFFFFFFFKKKKKKKKKKKKKKHHHHHHHHHHVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUFFFFFFFKKKKKKKKKKKKKKHHHHHHHHHHVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUFFFFFFFKKKKKKKKKKKKKKHHHHHHHHHHVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUFFFFFFFKKKKKKKKKKKKKKHHHHHHHHHHVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUURRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUURRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUURRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUURRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUURRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUURRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUURRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUURRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUURRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUURRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUURRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUURRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUURRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUURRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUURRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUURRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUURRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUURRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUURRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUURRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUURRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUURRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUURRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUURRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUURRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUURRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUURRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUURRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUURRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUURRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUURRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV


text:
# Write the values of the square root of i.

Question:

Write the values of the square root of i.\

Solution:

Let the square root of $i$ be $x+i y$.

$\Rightarrow \sqrt{i}=x+i y$

$\Rightarrow i=x^{2}+y^{2} i^{2}+2 i x y$

$\Rightarrow i=x^{2}-y^{2}+2 i x y$ (Squaring both the sides)

Comparing both the sides:

$x^{2}-y^{2}=0$     ...(i)

and $2 x y=1$   ...(ii)

By equation (ii), we find that $x$ and $y$ are of the same sign.From equation (i),

$x=\pm y$

$\therefore x y=\frac{1}{2}, x^{2}=\frac{1}{2}$

$x=\pm \frac{1}{\sqrt{2}}, y=\pm \frac{1}{\sqrt{2}}$

$\therefore \sqrt{i}=\pm \frac{1}{\sqrt{2}}(1+i)$

format: plain


text:
## help!!!!!HW

Write the chemical equation for the dissociation of the salt into its ions.? If the salt is acidic, write the chemical equation for the reaction of the acidic ion in water to produce hydronium ion. If the salt is basic, write the chemical equation for the reaction of the basic ion with water to produce hydroxide ion. 1. NaC2H3O2 2. NaHCO3 3. Na2CO3 4. NH4Cl


text:
# Pattern matching

OpenCog has a pattern matcher or query engine or variable unifier that can be used to search the atomspace for specific patterns or arrangements or 'templates' of atoms. After specifying some (arbitrarily complex) arrangement of atoms, that is, a hypergraph, the pattern matcher can find all instances of that hypergraph in the atomspace. The pattern or template can have "holes" in it -- locations that are variable -- and so the pattern matcher can act to "fill in the blanks" when presented with a pattern that has blanks in it. For example, a pattern such as "John threw a _____." can be solved or grounded if the atomspace contains the sentence "John threw a ball." In this example, the solution or grounding is "ball". Patterns may have arbitrary numbers of blanks (variables) arranged in arbitrary ways, and may have multiple solutions. Examples of patterns can be found on the BindLink page. The BindLink provides an easy-to-use, convenient API to the pattern matcher. Below follows a more technical description.

It is a unifier, in the theoretical computer-science sense of Unification, because that is what it does. It is a query engine, because the act of performing unification over a database of relations is the same thing as querying that relational database, such as with SQL. See relational algebra in wikipedia, for example. The difference here is that OpenCog relations are expressed as hypergraphs, so that the pattern matcher actually implements a hypergraph query language (HQL) with the BindLink. Its a pattern matcher because it does pattern matching. These are three different names for the same thing.

The book Term Rewriting and All That, Franz Baader, Tobias Nipkow, 1998, Cambridge University Press(GoogleAmazon) provides a good intro (see page 80 of paperback edition). What is implemented here is more sophisticated: it unifies multiple terms at once, and automatically handles unordered terms (terms that can be in any order), provides support for quotation, execution and evaluation. A "term" is any "link", in the sense of "term algebra". It is useful to think of "terms" because, in a term algebra, the notion of variables and arity & etc are -well-developed. In the pattern matcher, a "clause" is a top-level term, that is, a pattern is a single AndLink that wraps N clauses.

The pattern matcher provides support for the concept of negation as failure from autoepistemic logic. That is, a match can be accepted only if it does not contain a specific sub-pattern or set of clauses.

In many ways, the pattern matcher resembles a hygenic macro language; one might even say that it *is* a macro language. See:

The difference, however, is this: a macro expansion can be applied only once. By contrast, patterns are more like production rules, and can be applied repeatedly, whenever the data fits.

The pattern matcher can be thought of as a building block for a:

The pattern matcher is meant to be used as a building block for more sophisticated functions. It is meant to be the foundation on which to build forward and backward chainers, as well as the (user-defined) indexes needed to operate these (e.g. to implement the Rete algorithm or variants).

Pattern matching has a dual, which can be loosely termed as pattern recognition. Thus, if pattern matching is a search for all data that fit a pattern, then pattern recognition is the search for all patterns that might fit some data. In atomese, this dual function is implemented by the DualLink, and is thus an implementation of a kind-of "dynamic" Rete algorithm. The pattern recognizer is built on the same infrastructure as the pattern matcher; it simply reverses the direction of the "arrows", allowing a search for production rules, rather than their application.

The pattern matcher has NOT been influenced by miniKanren, but probably should be.

The pattern matcher has both C++ and scheme interfaces. Most users will want to employ the scheme interfaces; the C++ API is really meant for core developers who are extending the system.

# Overview

The pattern matcher consists of several components that can be used separately or together to perform any of several related tasks:

• Perform graph re-writing. That is, if a (dynamic) match is found, then a new and different graph is created as a result. This can be thought of as a single-step forward-chainer or graph re-write rule applier.

At the core is a component that is able to compare one hypergraph to another, and find a match, if one exists. If one (or more) matches are found, then the corresponding variables in the match are grounded. This is proper, core pattern matcher. The determination of what constitutes a "match" is performed by user-defined callbacks, thus making the pattern matcher highly customizable. A default callback provided; it will accept "syntactical" matches: it implements the simplest form of matching as one might expect to have ("free theory" or "empty theory" unification).

One of the callbacks is the 'initializer' or 'traverser', which specifies the set of graphs that will be examined for a match. The default callback traverses the entire AtomSpace, looking for suitable places where the pattern match can be started. Thus, the default callback, when used with the pattern matcher, can locate all matching patterns in the AtomSpace.

Another component, the 'instantiator', will create an instance of a graph, given a pattern containing variables, and a map giving the substitution of values for variables.

If desired, a capable C++ programmer can use the core matcher without having to use the default initializer/traverser. For example, one could limit the sub-hypergraph search to some subset of the AtomSpace, instead of all of it. A capable C++ programmer could also avoid using the instantiator, and instead create some completely different callback, to do something completely different. All three of these components are implemented in the libquery module, with source code in /opencog/query. However, in essentially all situations, this kind of modification is not needed. The triumverate of these three components combined is sufficient to handle many or most interesting cases. No C++ code is required. If you think that this is not enough for your purposes, please contact User:Linas to discuss.

The SatisfactionLink can be used to perform atomspace queries, and dynamic evaluations. Graph re-writing can be done with the BindLink. BindLinks specify "rules" (in the sense of a graph rewrite rule), and apply those rules to the AtomSpace. Each "rule" is an ImplicationLink, given the interpretation "if P then Q", where P and Q are hypergraphs. If the hypergraph P is matched, then the graph Q is instantiated. The graph Q may be any hypergraph; but if Q is an ExecutionLink, then a match results in some program/function being executed. This is a very powerful feature, because generic computation can be performed by the ExecutionLink. This is documented, together with practical examples, in the BindLink page.

## Performance and flexibility

The pattern matcher was designed to be a flexible, fast, easy-to-use, configurable unifier with a bunch of unit tests that assure correctness.  Because it's written in C++, it should have excellent performance while traversing hypergraphs. However, it has a significant setup cost, so, for small, simple unification problems, hand-written snippets of code, even in scheme or python, can outperform it.  But once a problem starts getting complex, right around the time you get to 2, 3, 4 variables, with complicated match criteria, and start hitting the various backtracking issues that arise during such searches, this is where the pattern matcher comes to its own.

## Custom behaviors

The pattern matcher was designed to be a flexible. Below are some remarks about how certain tasks can be achieved.

### Modifying Truth Values

The pattern matcher will not in any way alter the truth values or attention values associated with the various atoms in the query pattern, or in the groundings. The clever user can write custom procedures to compute and modify these as desired.

This may be done in one of two ways. One way is to work directly with the values returned by cog-bind. Another, and usually a more convenient way, is to specify an ExecutionOutputLink as the 'return value'.

### Triggering arbitrary actions

When an ExecutionOutputLink appears as the consequent of a match, it will cause a named (python or scheme) script to run. This script can perform arbitrary actions of any sort.

### Pattern rejection, negation

The PM provides a mechanism for accepting matches only if they don't contain some specific pattern. This negation can be handled in several different ways: either the indicated pattern must not occur in the Atomspace, or it can occur with (for example) a low truth or attention value.

This feature can be understood as support for the concept of negation as failure in autoepistemic logic.

It is implemented by making use of "optional" clauses. If none of the optional clauses appear in the final solution, then the solution is accepted. If some of the optional clauses do appear, then a callback is invoked to determine if the pattern should be accepted or rejected. The callback can make arbitrary decision criteria to implement the concept of "negation".

There is a default callback, called the "crisp logic" callback, which accepts a pattern only if the optional clauses are either missing, or have a truth value whose strength is zero (i.e. are false).

### Limiting search

The default callbacks behave in such a way that the entire AtomSpace is "searched" for a match. It is straight-forward to write callbacks that will limit the search in some way. The easiest and most useful way of limiting search might be to check the attention value of an atom, and reject a match if it is not high enough. This way, the only part of the AtomSpace that is searched is that with a high AV.

Because the callbacks can perform arbitrary actions, there are other ways in which the search could be limited.

# The Simplified API

The pattern matching engine provides the most general and powerful programming interface, but it can be complicated to use, and is (currently) available only from C++. The "easy-to-use" pattern matcher, described above, has both a C++ and a scheme API. The C++ API can be found in /opencog/query/BindLinkAPI.h . The scheme API is described below.

The scheme API is implemented with three different, related functions: cog-satisfy, cog-satsisfying-set and cog-bind.

The cog-satisfy function takes a single handle, and evaluates, executes and/or performs a grounding, depending on whether the atom contains GroundedPredicateNodes, GroundedSchemaNodes and/or VariableNodes. It returns a truth value of true, if satisfaction was attained, else it returns false. The cog-satisfying-set function does the same, except that it returns a SetLink of the instantiated patterns.

Although the argument can be any atom, there is a slight boost in performance if the argument is wrapped in a SatisfactionLink. This is because certain intermediate results are cached when the SatisfactionLink is used; this caching is particularly important if the pattern search is to be done repeatedly. If the types of the variables in the expression need to be constrained with a VariableTypeNode, then the SatisfactionLink must be used.

A SatisfactionLink consists of two parts: optional variable declarations, and a body. The body specifies the pattern to be grounded (match-pattern). Thus, the general structure is:

 SatisfactionLink
<var-decls>       (optional)
<match-pattern>

The BindLink is similar, except that it can also perform graph re-writing; in this case, the body should be composed of a predicate, interpreted as the pattern to search for, and an implicand specifies how the search results are to be instantiated.

 BindLink
<var-decls>       (optional)
<match-pattern>
<instantiated-pattern>

The cog-satisfy function treats the SatisfactionLink as a database query; the atomspace is searched for all graphs that match the specified query. Considered as a scheme function, cog-satisfy also has a scheme-valued return value: it returns a truth value. The cog-satisfying-set function does the same, except that it returns a list of all of the graphs that were found.

The cog-bind function treats the BindLink as a graph re-write rule: it performs a search; if a match is found, then the re-write is applied and placed into the atomspace. The result of applying the re-write rule may be zero, one or more instantiated patterns that were created in the atomspace. Considered as a scheme function, cog-bind also has a scheme-valued return value: it returns a list of all of the patterns that were instantiated.

The instantiated pattern can be simple, or very complex. To be effective as a graph-re-write rule, the BindLink should typically specify some "complex" pattern, as otherwise, no re-writing occurs. However, the re-writing aspect can also be completely ignored, and cog-bind can simply be used to obtain matches, while skipping the notions of 'instantiation' and 'execution' described above. In this case, the instantiated pattern can simply be a single variable, which would result in no change at all to the atomspace. So, for example, to find and return a list of all of the animals in the atomspace, one may perform the following:

(define find-animals
;; The variable to be bound
(VariableNode "$var") ;; The pattern to be searched for (InheritanceLink (VariableNode "$var")
(ConceptNode "animal")
)
;; The value to be returned.
(VariableNode "$var") ) ) ;; Run the above pattern (cog-bind find-animals) The result of running the pattern matcher will be a list of all possible groundings for the variable$var. So, for example, if the atomspace contains:

(InheritanceLink (ConceptNode "fox") (ConceptNode "animal"))
(InheritanceLink (ConceptNode "skunk") (ConceptNode "animal"))

then cog-bind will return a SetLink with the two animals:

(ListLink (ConceptNode "fox") (ConceptNode "skunk"))

Because the implicand was simply a single, naked VariableNode, the instantiator had no work to do; the atomspace was not altered, and the list of results was returned to the scheme caller. The variable declaration was optional: the following would provide the same results:

(define find-animals
;; The pattern to be searched for
(VariableNode "$var") (ConceptNode "animal") ) ;; The value to be returned. (VariableNode "$var")
)
)

;; Run the above pattern
(cog-bind find-animals)

To get a list of the satisfied clauses, the BindLink and ImplicationLink can be dispensed with, entirely:

(define find-animal-inheritance
;; The pattern to be searched for
(VariableNode "$var") (ConceptNode "animal") ) ) ;; Run the above pattern (cog-satisfying-set find-animal-inheritance) # Design The pattern matcher is written in C++, and has multiple different components, which can be used in a variety of different ways, for many different tasks. It can be customized or adapted to different uses by implementing new and different handlers for callbacks. Thus, it is difficult to understand what the pattern matcher "is", or what it "does", without understanding the components it is built out of, and without understanding the current default settings for the callbacks. This section provides an overview of the design and how to work with it. ## The Engine The core, underlying matching is implemented in class PatternMatchEngine. The main entry point is class PatternMatchEngine::match(). It takes four inputs: a list of variables, a list of clauses, a list of optional clauses (negations), and a user-defined callback class. The callbacks govern the "semantics" of matching, and are completely user-definable. By providing an appropriate callback, the user can impose any semantics whatsoever on the concept of "what constitutes a match". The engine merely presents candidates to the callbacks, but it is up to the callbacks to accept or reject candidates. Thus, for example, the default callback implements "negation semantics" for the optional clauses: it rejects a match if any of the optional clauses are present. These are discussed in greater detail, below. The list of variables is the set of bound variables that will appear in the clauses and the negations. Variables can "match anything"; more specifically, if some atom is discovered where the variable would be, then the user-defined callback is called to report the potential match. The callback can accept or reject the match; if it accepted, then that match is a "grounding" of that variable. The list of clauses determine the hypergraph to be matched. Each clause should be thought of as a directed tree, the edges of the tree corresponding to the outgoing sets of the atoms; the terminal leaves of the tree are Nodes, and the internal vertexes of the tree are Links. The list of clauses should be "connected" to one-another: that is, each clause should have at least one node that also appears in another clause. The engine walks these trees, attempting to match them up to the contents of the atomspace; a match is declared only if each of the clause trees match some tree in the atomspace, connected the same way at the nodes, and having had a successful, consistent grounding of each of the variables. If a match has been found, then a user-defined callback is called, reporting this match. The callback can "accept" or "reject" the match. If the callback "accepts" the match, then all further searching is halted; if it is rejected, then a search for other matches continues. The user-defined callback is free to do as it wishes: for example, if it wants to find all matches, it could simply record the match that was found, "reject" it, and then wait for more matches. The optional clauses are lists of clauses that may or may not be present to satisfy a match. The default callback implements negation semantics for the optional clauses: that is, it explicitly rejects a match if any of the optional clauses are present. Other, user-defined callbacks are free to implement a different semantics for the optional clauses. ### Callbacks The callbacks are defined by a virtual base class class PatternMatchCallback. It has a concrete implementation in class DefaultPatternMatchCB, which does "something reasonable" for most users. Anyone can write a custom callback class to do something different. The callback class has many different callbacks: • node_match() -- this is called whenever two nodes are compared. The callback can accept or reject the match. The default is to accept a match if the two atom handles are identical. A non-default behavior might be more general, for example, allowing matches based on type, or based on truth values, or any other criteria. • variable_match() -- this is called when a variable appearing in a clause is to be matched to a candidate grounding. The default callback accepts a match if the candidate node is one of a given set of types (as described in the BindLink page -- that is, the default callback implements the BindLink semantics). • link_match() -- this is called to compare links. The default callback accepts a match if the link types and the link arities agree. The default callback does not compare the actual outgoing sets: this is the engine's job. A user-defined callback can take any action here, if desired, including modifying or computing truth values, etc. • clause_match() -- called when a single clause has been matched. This callback can accept or reject the match, or take the opportunity to compute truth values. The default callback always accepts matches. • optional_clause_match() -- called when an optional clause is matched. The default callback implements "negation semantics": it always rejects optional clauses. The central idea of negation is that a match is possible only if the negated clause is absent. Other callbacks can be used to define different kinds of optional-clause semantics. In particular, the very idea of "negation" depends on the interpretation of the strength and confidence of a truth value: "negation" might not make sense if the confidence is zero. Similarly, perhaps an optional clause should be rejected only if it is mostly "true", and accepted if it is sufficiently "false". The default callback implements crisp-logic semantics for the negation. • solution() -- called when all clauses have been matched (and all optional clauses have been appropriately handled). This provides an opportunity for the callback to record the solution, and to either terminate or continue the search. In addition to the above, there are three informational callbacks: • push() -- called after a clauses has been fully grounded. This allows the callback class to save partial state onto a stack, if desired. The pattern matcher is a stack machine; as it advances, it maintains a state stack; when it retreats (back-tracks), it pops its own internal stack. This callback provides an opportunity for the user to deal with back-tracking as well; for example, it may want to maintain a cumulative truth value, or attention value; clause by clause. When forced to backtrack, it would then need to be able to discard partial results. This would be done with the pop() callback, below. • pop() -- called when back-tracking. • set_type_restrictions() -- called very early, before any pattern matching has commenced. It conveys the variable typemap that was specified by the BindLink. In addition to the above, there is one very important callback that allows the user to limit or guide the search; that is, to determine the domain of the search. • perform_search() -- called when the engine is invoked. This callback must then turn around and invoke the main entry point to the engine: the PatternMatchEngine::do_candidate() method, as many times as it needs to, to perform the search over the desired domain. That is, the engine itself does not know where to start the search, and even when told where to start, it will not necessarily perform an exhaustive search. This callback allows the user to specify the initial start point, as well as to take the needed actions to make sure that the desired domain has been searched. The default callback attempts to search the entire atomspace, assuming "reasonable" semantics. Under certain unusual semantics, the default may fail to find all matches. In particular, it may fail if the link_match() and node_match() callbacks implement a broader matching semantics than the default. ## The Pattern Matcher The pattern matcher wraps up the engine, described above, together with the default callback class, to provide a reasonably generic, easy-to use system. To make it "easy-to-use", it implements a "variable-typer", an "implicator", an "instantiator" and an "executor". These four additional functions implement the semantics described in the BindLink page. Specifically: • The variable-typer is able to decode and process the type restrictions made in the BindLink, and enforce those type restrictions via the default callback. (Again: the engine itself does not set any policy: all policy, such as type-matching, is enforced via user-defined callbacks.) • The "implicator" extracts the pattern from an ImplicationLink, and configures it in a format suitable for the engine. It also extracts the implicand, and provides it to the instantiator. • The "instantiator" creates a new hypergraph in the atomspace, given a template pattern (containing variables), and a set of variable groundings. By default, the template pattern is the second half of what was found in the ImplicationLink, but this could be over-ridden. • The "executor" handles any ExecutionLinks discovered by the instantiator. It is able to call functions in scheme, and pass them arguments; work has been started for it to handle python scripts as well. See github issue #160 Other programming languages can be (easily!) added. The pattern matcher has several main entry points, which are more-or-less equivalent, except for the format of their arguments: • bindlink() -- accepts a BindLink as its sole argument. • crisp_logic_bindlink() -- as above, but uses crisp-logic semantics to reject negated clauses. • match() --- accepts the same arguments as the engine, except in the format of ListLinks, instead of std::vector<Handle>. Note that a callback must be explicitly specified with this method; it does not use the default callback described above. # Example Walk-through Perhaps the easiest way to explain how the PM works is with a walk-through of what actually happens. We start with the set of terms to be unified: (AndLink (EvaluationLink (PredicateNode "whichmarker") (ListLink (VariableNode "$C")
(VariableNode "$D"))) (EvaluationLink (VariableNode "$D")
(VariableNode "$C") (VariableNode "$E")))
(VariableNode "$A") (ListLink (VariableNode "$B")
(VariableNode "$C"))) The first thing that happens is that the perform_search() callback is called. This callback can be used to limit the domain of the search. The default callback does things so that it seems like the whole atomspace is "searched". Note that they are all variables, except for one constant: PredicateNode "whichmarker". This is an excellent place to start the "search": we've already narrowed the "search" down to just ONE atom! Bravo! Next, the default callback loops over the entire incoming set of PredicateNode "whichmarker", passing control back to the pattern matcher. The incoming set is not sorted or truncated in any way, all of it is explored. But you could change this if desired. For every atom in the incoming set, the PM compares it to "EvaluationLink". It calls a callback called link_match() which is given two links: the EvaluationLink, and the atom in the incoming set. The default callback declares a match if and only if the atom has type EvaluationLink. But you could change this if desired; for example, to reject the match if the AV of the atom is too low. Or you could reject the match if the atom is not in some set. If you reject the match, the PM backtracks to the next atom in the incoming set. If you accept the match, then the PM tries to compare the outgoing sets of the two EvaluationLinks. Since we already did the PredicateNode, it doesn't have to be re-done. Next is the ListLink. Again the link_match() callback is called ... with two arguments: the ListLink from the pattern, and the atom in position 2 of the outgoing set of the EvaluationLink, whatever it may be. Again, you must accept or reject the comparison. The default is to accept if and only if the types match. If you reject the match, the PM backtracks upwards, twice. If you accept the match, then the PM tries to compare the outgoing sets of the ListLink's. This time, the variable_match() callback is called, with two arguments. The first one is VariableNode "$C"  and the second one is (for example) ConceptNode "tree".   You can choose to accept or reject this candidate grounding.

The default callback simply makes sure that ConceptNode is one of the allowed types that VariableNode "$C" is allowed to have. You can write a callback that will reject the match if the tv or av of ConceptNode "tree" is too high or low, or if ConceptNode "tree" is not a recently generated relex2atom atom. Perhaps you want to check some HebbianLink's to see if ConceptNode "tree" is hot stuff. Perhaps one of the best solutions would be to write a generic callback that, whenever its given a VariableNode "$whatever" and a ConceptNode "tree", it rejects the match unless the STI is over 1000.   That way, as long as relex2logic always sets the STI above 1000, and then decays it lower values over time, the search will always be limited to the newest relex2logic atoms.   Simple, easy, straightforward.  This would require only a small amount of new code.  You just have to decide what the selection criterion is.

Anyway, that's how the PM proceeds: it matches incoming and outgoing sets, atom by atom, calling a callback for each possible match.   This sounds real easy, but actually, its not, because of backtracking.  Backtracking requires a stack.   But this is an advanced topic that you don't need to worry about, unless you accept/reject criteria is accumulating data.

## Backtracking

For example, if the first three matches had a mediocre TV, maybe you accept them, but, for the 4th one you decide that too much crappy TV has happened, and you reject. Backtracking might backtrack over the first three matches, and so, now you want to start with a clean slate.  There are push() and pop() callbacks that allow you to "clean the slate".

# Implementation

The implementation may be found in the /opencog/query directory; see opencog/query/README.md for details.

The core of the pattern matcher is implemented as a stack machine, pushing and popping a stack as it finds partial matches to candidate hypergraphs. It uses a set of callbacks that can be used to define what constitutes a "match", to maintain a user-defined stack, and to modify truth values, attention values, and/or even create new atoms as the traversal progresses. One set of default callbacks provide simple crisp logic (boolean logic) evaluation; another set provide variable-type scoping.

The pattern matcher has programming API's at both low and high levels. Currently, the best examples demonstrating how to use these API's are the functional-test cases in the tests/query directory. These are best studied in the order in which they are run.

This pattern matcher is fully functional. User:Linas has several plans for it, including cleaning up the code base to remove the old-style for-each calls, and to improve performance by embedding atom pointers directly. Other plans include adding user-defined indexes to the atom space. These can be understood as being more-or-less equivalent to the structures of the RETE algorithm, and thus should help with the construction of chainers.

# Some Q&A on Callbacks

These questions and answers are pasted here from an email exchange, with some reformatting; the goal being to avoid the same questions being posted and needing to be answered again....

Question:

We want to start with a certain set S of Atoms, and have the PatternMatcher look only at Atoms in the set S, during its whole search process.

The PM never actually searches "the atomspace", it has absolutely no idea of the space its exploring. The space is entirely controlled by the user-defined callbacks. The callbacks determine the space S that is searched.

Let me take a step back and quickly review what the structure of an atom is, and what the PM does with it. Atoms(Links) have an outgoing set: this is explicitly hard-coded into a Link, and is immutable. Atoms also have an incoming set, which is only implicitly defined, as the set of all Links that point to it.

Given a single Link, the transitive closure of it's outgoing set can be pictured as a tree. Likewise, given a single Atom, the transitive closure of the incoming set can be pictured as an upside-down tree (viz, the relationship is going in the opposite direction).

The PM itself never actually touches, uses, or accesses the atomspace! (with some strange misc exceptions) Understanding this is key to answering your question. Since PM doesn't know about the atomspace, it doesn't know that its searching it... or any subset of it. It is up to the user-defined callbacks to control the search.

To start the search, the PM needs to be given at least one atom that is in common between the pattern, and the space S. (If its given none, then game over, and no match). To obtain this single atom, it calls the perform_search() callback. The user must define this callback; there's a reasonable default. in place.

The default arbitrarily picks some node in the pattern, any node that is not a variable, and then tells the PM to start searching there.

PM then proceeds by comparing the incoming trees, starting at that common node, looking for a match. To obtain the incoming set of an atom, the PM performs a callback. It is the job of the callback to provide the incoming set. There is a default callback for this: it does a reasonable thing. It returns the ENTIRE incoming set for that atom!

This is the key step to answer your question. What is the "entire incoming set"? How is it defined? Well, it is the set J of all Links X that have the current atom A appearing somewhere in the outgoing set.

To limit the search to your set S, you need to write a callback, called get_incoming_set(), that returns only those Links X that are in your set S (and are also actually in J) -- return the intersection of S and J. That's all.

Note however that to use the subset S, it has to be "computable": you have to run some algorithm to determine what S actually is. In particular, you need to have a set membership function that answers yes/no to indicate membership. If that's "very inefficient", don't blame the PM. You have to define S so that working with S is fast.

If computing set membership in S is excruciatingly slow, you can use a cache. Here's an example cache that is O(1) in the pattern matcher:

class myMiniSubspaceS : PatternMatchCB
{

return my_incoming_set_map(a);
}

if (not a->is_a_link()) return;  // ignore nodes
foreach(Atom ox in a->outgoing_set()) {
iset = my_incoming_set_map(ox);
iset.insert(a);  // because a is in the incoming set of ox
}
}; // the end.

That's all there's to it, nothing more. The class just holds a cache of incoming sets for the atoms in S. The PM will then only search over stuff in S. It can be very efficient: so if you use hash_map instead of map, the lookup is in O(1) time, even if S is large.

The only "gotcha" is that you have to somehow define what belongs in the set S, and spend the cpu cycles to actually put atoms into S. I don't know how efficient that might be.

Again: the class above is just a cache, which is attempting to cover up the fact that S is very inefficient to compute ...

However, if you can compute the set S efficiently and quickly, then you don't need the above cache. Just compute S on the fly, every time the get_incoming_set() callback is called.

Question:

We want to have the Pattern Matcher prefer matches that have a higher STI (ShortTermImportance)

The get_incoming_set() callback returns a VECTOR of atoms. It searches the first atom first, the second atom second, etc. If you place the vector in sorted STI order, then it will "prefer" higher STI matches first.

Also note that, of the callbacks, one of the last ones to get called is named solution(). It presents the user with one single grounding that the PM thinks it has found, and asks for approval.

If the user-callback replies "I like it", then the search terminates. Otherwise the PM tries again.

The default CB always replies "I hate it", and thus the PM explores *all* possible matches, until it can find no more, Then it dies exhausted, a heart-broken death, having searched the entire kingdom far and wide, and having utterly failed in its quest to find a match.

Now hears the clever bit: the default CB secretly recorded ever match that was returned, and put it in its treasure chest, and then sent out the PM to find yet more. Thus, as the PM scoured the kingdom, the CB built up an exhaustive collection of groundings, because the PM was so through.

However, if the CB was not so greedy, it could save a lot of effort by the PM by simply terminating the search early.

Follow-up question:

Yes, but is there a way to randomize where the PM starts its search, via specifying a random seed for the starting point? Would this also be done in a custom callback?

Yes, as already detailed above. However, perhaps a better randomization could be done with get_incoming_set(). Maybe this would work:

When asked for the incoming set of some atom A, perform a random draw to obtain some subset of the true set. Maybe even order this subset by STI. The return that. Since PM always searches the incoming set in order, this random draw will randomize the search. I can't say how efficient it would be ...

# Formal definition

Below is a formal definition of the pattern matcher, of the kind you might see in math books. Let ${\displaystyle \Sigma }$ be a signature, or rather, a collection of both function symbols and predicate symbols. In OpenCog, these correspond to Atoms; that is a given atom type should be thought of as a signature. Let ${\displaystyle X}$ denote a set of variables. In OpenCog, these correspond to a collection of VariableNodes with different names.

Given this definition, ${\displaystyle T_{\Sigma }(X)}$ is the term algebra of all possible arrangements of Atoms. Likewise, ${\displaystyle T_{\Sigma }}$ is the subset of terms that have no variables in them: these are the "grounded terms" or "closed forms".

At any fixed point in time, the AtomSpace stores some subset of ${\displaystyle T_{\Sigma }(X)}$. Let ${\displaystyle A\subset T_{\Sigma }(X)}$ denote the current contents of the atomspace. Let ${\displaystyle A_{g}\cap T_{\Sigma }\subset A}$ denote the subset of the atomspace consisting only of grounded terms. The pattern matcher is then comes in three forms. The first form is the function ${\displaystyle sat}$, implemented by SatisfactionLink

${\displaystyle sat:T_{\Sigma }(X)\times A_{g}\to \{0,1\}}$

that, given some term ${\displaystyle t(x_{1},x_{2},\cdots ,x_{n})\in T_{\Sigma }(X)}$, it locates some (any) grounded term ${\displaystyle t(g_{1},g_{2},\cdots ,g_{n})\in A_{g}}$ in the AtomSpace, and returns 1 if such a grounded term can be found; else it returns 0.

The above is slightly oversimplified: by employing the correct term definitions, one can search all of ${\displaystyle A}$ and not just ${\displaystyle A_{g}}$, if desired; the same is true for the link types below. However, the current simplification makes things slightly easier to discuss.

The GetLink form is the function

${\displaystyle get:T_{\Sigma }(X)\times A_{g}\to A_{g}}$

that, given some term ${\displaystyle t(x_{1},x_{2},\cdots ,x_{n})\in T_{\Sigma }(X)}$, locates all grounded terms ${\displaystyle t(g_{1},g_{2},\cdots ,g_{n})\in A_{g}}$ in the AtomSpace, and returns a set containing all such lists ${\displaystyle (g_{1},g_{2},\cdots ,g_{n})}$ Note that the operation of the GetLink causes the size of the AtomSpace to expand: it is almost certainly the case that the ListLink ${\displaystyle (g_{1},g_{2},\cdots ,g_{n})}$ was not previously in the AtomSpace, and even if it was, it probably was not in a SetLink with other similar lists.

The BindLink form is the function

${\displaystyle bind:T_{\Sigma }(X)\times T_{\Sigma }(X)\times A_{g}\to A_{g}}$

that, given a pair of terms ${\displaystyle p(x_{1},x_{2},\cdots ,x_{n})\in T_{\Sigma }(X)}$ and ${\displaystyle q(x_{1},x_{2},\cdots ,x_{n})\in T_{\Sigma }(X)}$, locates all grounded terms ${\displaystyle p(g_{1},g_{2},\cdots ,g_{n})\in A_{g}}$ in the AtomSpace, creates a corresponding ${\displaystyle q(g_{1},g_{2},\cdots ,g_{n})}$, and returns a set of all such terms.

${\displaystyle dual:T_{\Sigma }\times A\to T_{\Sigma }(X)}$

that, given a specific ${\displaystyle t(g_{1},g_{2},\cdots ,g_{n})}$, finds all terms ${\displaystyle t(x_{1},x_{2},\cdots ,x_{n})\in A}$ that have one or more variables in place of the grounded atoms. The DualLink becomes interesting and non-trivial, when the variables are globby: are GlobNodes that can match multiple sequential ground terms.

Hmmm. Please realize that the above actually over-simplifies what is really happening: it glosses over a number of very interesting details of the system: most importantly, that the logical connectives AndLink, OrLink are atoms themselves, so that the AtomSpace is not just a term algebra, but a language. Next, the types of the Atoms are atoms themselves... and so terms can have type specifications inside of them. There are even type constructors. The AbsentLink can be used to specify a form of negation... the ChoiceLink can be used to specify choices... and so on.

# Possibly similar projects

These projects might be similar:

• Burlap on github. Quote from IW: Burlap lets you define the problem as a network of nodes with vectors of features or attributes attached to it. The algorithms can search through the network using a combination of brute-force searching and statistically guided exploration. The higher level of the algorithm plans the search and deploys the best algorithms. The toolkit includes dozens of the most useful algorithms for agent-based search.
The tool is useful for data-driven worlds where the data can be mapped into a large collection of nodes or objects. The code is written in Java and includes a large assortment of debugging and profiling tools that are useful for keeping the code moving toward the optimal goal.
• Guile-Log -- the DataLog subset of ProLog for Guile.


text:
# Math Help - Proofs of the Theorems on Circumscribable Quadrilaterals

1. Observe the following illustration. We have the quadrilateral ABCD. The quadrilateral's incircle's center is pt. O. Then there are the two incircles of the triangles formed by the diagonal. P,Q,R and S are the points where the incircles touch the quadrilateral's sides. Now we need to prove that the sides PO, QO, RO and SO are of equal length. Once we do this, the theorem is proved.

The red lines in the above image are the lines connecting the vertices to the center of the incircle. Since we have an incircle these lines bisect their respective angles of the quadrilateral (from the previous theorems). Since we want to show that the sides PO, QO, RO and SO are of equal length then the triangles should be the same two by two. It suffices to show that APO and ASO are congruent triangles and then by the same logic it will follow that PBO and QBO are congruent and also RCO and QCO are congruent! Well, we already have a side (AO) and one angle (angles PAO and SAO from bisector). It'll be simple to just prove that AP = AS.

This is where the right hand side of the drawing comes in. XY and ZY are tangents to the circle with center E and they intersect at point Y. We have that angles EXY and EZY are 90 degrees each (why?). Since XE = ZE and by theorem 5, EY must be a bisector. Hence XYE = ZYE and thus XEY = ZEY. From SAS (sides XE, ZE and YE and angles XEY and ZEY) triangles XYE and ZYE are congruent. Hence XY = ZY.

With this in hand, we immediately have that AS = AP since AD and AB are tangent to the incircle of triangle ABD. Similarly PBO = QBO and RCO = QCO. Hence the sides PO, QO, RO and SO are all the same. Which means they lie on the same circle with center O. Thus the theorem is proved.

2. thanks a lot Sir.

Page 2 of 2 First 12


text:
# How much work is done on the car by the rope

## Homework Statement

A truck with a horizontal tow rope pulls a car. The car skis off to the side, so the rope makes an angle of 15.0degrees with the car's direction of motion, and then continues in a straight line. The tension in the rope is 180 N.

How much work is done on the car by the rope during a displacement of 300 m?

## Homework Equations

W = F*s
W = Fscos $$\phi$$

## The Attempt at a Solution

W = 180(300)cos15
W = 52159.99

seems to large


text:
# Horizontal and Vertical asymptotes of a curve

• October 2nd 2012, 09:00 PM
Oldspice1212
Horizontal and Vertical asymptotes of a curve
Find the horizontal and vertical asymptotes of the curve.

y
= 4e^x/e^x-6

x=
y= (smaller y - value)
y = (larger y - value)

How do you do this?
• October 2nd 2012, 11:07 PM
MarkFL
Re: Horizontal and Vertical asymptotes of a curve
I assume you mean:

$y=\frac{4e^x}{e^x-6}$

To find the vertical asymptote(s) solve:

$e^x-6=0$

To find the horizontal asymptote(s) evaluate:

$\lim_{x\to\pm\infty}\frac{4e^x}{e^x-6}$
• October 2nd 2012, 11:15 PM
FernandoRevilla
Re: Horizontal and Vertical asymptotes of a curve
Quote:

Originally Posted by Oldspice1212
Find the horizontal and vertical asymptotes of the curve. y = 4e^x/e^x-6 How do you do this?

Vertical asymptotes: $e^x-6=0\Leftrightarrow x=\ln 6$ .

Horizontal asymptotes: $f(x)=\frac{4e^x}{e^x-6}=\dfrac{4}{1-\frac{6}{e^x}}\Rightarrow \begin{Bmatrix} \displaystyle\lim_{x \to{+}\infty}f(x)=4\\\displaystyle\lim_{x \to{-}\infty}f(x)=0\end{matrix}$

Edited: Sorry, I didn't see MarkFL2's post.
• October 2nd 2012, 11:20 PM
MarkFL
Re: Horizontal and Vertical asymptotes of a curve
Hey, no worries! I make posts not seeing someone else has posted in the meantime quite frequently! :)


text:
# American Institute of Mathematical Sciences

ISSN:
1078-0947

eISSN:
1553-5231

All Issues

## Discrete & Continuous Dynamical Systems - A

July 2009 , Volume 25 , Issue 2

Select all articles

Export/Reference:

2009, 25(2): 399-429 doi: 10.3934/dcds.2009.25.399 +[Abstract](1822) +[PDF](2229.7KB)
Abstract:
The classical phase-field model has been introduced as a model for non-isothermal phase separation processes in materials. In order to overcome some of the model's shortcomings, a variety of extensions have recently been proposed which include nonlocal interactions as well as stochastic noise terms. In this paper, we study these extensions from a functional-analytic and numerical point of view. More precisely, we present a functional-analytic framework for establishing existence, uniqueness, and qualitative dynamical results, and then propose a spectral method for solving stochastic nonlocal phase-field models. In particular, we establish convergence properties of our method and study the effects of noise regularity and of the nonlocal interaction term on these convergence properties. Finally, numerical studies relating to the associated phase separation process are presented.
2009, 25(2): 431-456 doi: 10.3934/dcds.2009.25.431 +[Abstract](1868) +[PDF](298.5KB)
Abstract:
In this paper we first conduct a study of the spectrum of the negative $p$-Laplacian with Neumann boundary conditions. More precisely we investigate the first nonzero eigenvalue. We produce alternative variational characterizations, we examine its dependence on $p\in( 1,\infty)$ and on the weight function $m\in L^{\infty}(Z) _{+}$ and we prove that the isolation of the principal eigenvalue $\lambda_{0}=0,$ is uniform for all $p$ in a bounded closed interval. All these results are then used to prove an index formula (jumping theorem) for the $d_{( S)_{+}}-$degree map at the first nonzero eigenvalue. Finally the index formula is used to prove a multiplicity result for problems with a multivalued crossing nonlinearity.
2009, 25(2): 457-466 doi: 10.3934/dcds.2009.25.457 +[Abstract](2021) +[PDF](164.8KB)
Abstract:
At the first time, Razumikhin technique is applied for differential equations with piecewise constant argument of generalized type [1, 2]. Sufficient conditions are established for stability, uniform stability and uniform asymptotic stability of the trivial solution of such equations. We also provide appropriate examples to illustrate our results.
2009, 25(2): 467-479 doi: 10.3934/dcds.2009.25.467 +[Abstract](1954) +[PDF](205.7KB)
Abstract:
Let l be a compact convex subset of a Hausdorff topological vector space $(\mathcal{E},\tau)$ and $\sigma$ another Hausdorff vector topology in $\mathcal{E}$. We establish an approximate fixed point result for sequentially continuous maps f: (l,$\sigma$)$\to$ (l,$\tau$). As application, we obtain the weak-approximate fixed point property for demicontinuous self-mapping weakly compact convex sets in general Banach spaces and use this to prove new results in asymptotic fixed point theory. These results are also applied to study the existence of limiting-weak solutions for differential equations in reflexive Banach spaces.
2009, 25(2): 481-493 doi: 10.3934/dcds.2009.25.481 +[Abstract](2037) +[PDF](225.4KB)
Abstract:
We determine topological and algebraic conditions for a germ of holomorphic foliation $\mathcal{F}_X$ induced by a generic vector field $X$ on $(\mathbb{C}^{3},0)$ to have a holomorphic first integral, i.e., a germ of holomorphic map $F$ : $(\mathbb{C}^{3},0)\rightarrow(\mathbb{C}^{2},0)$ such that the leaves of $\mathcal{F}_X$ are contained in the level curves of $F$.
2009, 25(2): 495-509 doi: 10.3934/dcds.2009.25.495 +[Abstract](2143) +[PDF](330.6KB)
Abstract:
We present a version of the Poincaré-Bendixson Theorem on the Klein bottle $K^2$ for continuous vector fields. As a consequence, we obtain the fact that $K^2$ does not admit continuous vector fields having a $\omega$-recurrent injective trajectory.
2009, 25(2): 511-535 doi: 10.3934/dcds.2009.25.511 +[Abstract](1869) +[PDF](283.4KB)
Abstract:
We propose a program for finding the cyclicity of period annuli of quadratic systems with centers of genus one. As a first step, we classify all such systems and determine the essential one-parameter quadratic perturbations which produce the maximal number of limit cycles. We compute the associated Poincaré-Pontryagin-Melnikov functions whose zeros control the number of limit cycles. To illustrate our approach, we determine the cyclicity of the annuli of two particular reversible systems.
2009, 25(2): 537-544 doi: 10.3934/dcds.2009.25.537 +[Abstract](1773) +[PDF](161.4KB)
Abstract:
We study the geometrical and dynamical properties of a holomorphic vector field on a complex surface, assumed to be transverse to the boundary of a domain which is a non-smooth manifold with boundary and corners. We obtain hyperbolicity and prove a compact leaf result. For a pseudoconvex domain with boundary diffeomorphic to the boundary of a bidisc in $\mathbb C^2$ the foliation is pull-back of a liner hyperbolic foliation. If moreover the diffeomorphism is transversely holomorphic then we have linearization.
2009, 25(2): 545-565 doi: 10.3934/dcds.2009.25.545 +[Abstract](2045) +[PDF](289.4KB)
Abstract:
The paper deals with Bean's critical state model for the description of the electromagnetic field in superconductors. A variational inequality for the quasi-stationary approximation on a part of the spatial domain is given. The main goals are the existence, uniqueness and asymptotic behavior as $t\rightarrow\infty$ of the solutions to that system.
2009, 25(2): 567-574 doi: 10.3934/dcds.2009.25.567 +[Abstract](1754) +[PDF](543.2KB)
Abstract:
We investigate iterative systems consisting of Möbius transformations on the extended real line. We characterize systems with unique attractor and give some sufficient conditions for minimality.
Zhen Lei and
2009, 25(2): 575-583 doi: 10.3934/dcds.2009.25.575 +[Abstract](3365) +[PDF](159.5KB)
Abstract:
In this paper we derive a criterion for the breakdown of classical solutions to the incompressible magnetohydrodynamic equations with zero viscosity and positive resistivity in $\mathbb{R}^3$. This result is analogous to the celebrated Beale-Kato-Majda's breakdown criterion for the inviscid Eluer equations of incompressible fluids. In $\mathbb{R}^2$ we establish global weak solutions to the magnetohydrodynamic equations with zero viscosity and positive resistivity for initial data in Sobolev space $H^1(\mathbb{R}^2)$.
2009, 25(2): 585-615 doi: 10.3934/dcds.2009.25.585 +[Abstract](2504) +[PDF](416.6KB)
Abstract:
Rate-independent systems allow for solutions with jumps that need additional modeling. Here we suggest a formulation that arises as limit of viscous regularization of the solutions in the extended state space. Hence, our parametrized metric solutions of a rate-independent system are absolutely continuous mappings from a parameter interval into the extended state space. Jumps appear as generalized gradient flows during which the time is constant. The closely related notion of BV solutions is developed afterwards. Our approach is based on the abstract theory of gradient flows in metric spaces, and comparison with other notions of solutions is given.
2009, 25(2): 617-626 doi: 10.3934/dcds.2009.25.617 +[Abstract](2290) +[PDF](186.0KB)
Abstract:
We present a new and simpler proof that the nonlinear scattering operator $\S$ is analytic on energy space. We apply it in particular to a fourth-order nonlinear wave equation in Rn. In addition, we prove that $\S$ determines the scatterer uniquely and that for small powers there is no scattering.
2009, 25(2): 627-650 doi: 10.3934/dcds.2009.25.627 +[Abstract](2296) +[PDF](262.1KB)
Abstract:
We derive the multifractal analysis of the conformal measure (or, equivalently, of the invariant measure) associated to a family of weights imposed upon a graph directed Markov system (GDMS) using balls as the filtration. Our analysis is done over a subset of the limit set, a subset which is often large. In particular, this subset is the entire limit set when the GDMS under scrutiny satisfies a boundary separation condition. Our analysis also applies to more general situations such as real and complex continued fractions.
2009, 25(2): 651-667 doi: 10.3934/dcds.2009.25.651 +[Abstract](1967) +[PDF](632.7KB)
Abstract:
The Riemann problem for the simplest scalar nonconvex CJ combustion model is considered. A set of entropy conditions are summarized, including pointwise entropy conditions and global entropy conditions. The later is according to the requirement of the structural stability. The unique self-similar entropy solution of the Riemann problem is constructed case by case. Transition from deflagration to detonation is shown, which dose not occur for the convex model.
2009, 25(2): 669-685 doi: 10.3934/dcds.2009.25.669 +[Abstract](1676) +[PDF](218.2KB)
Abstract:
We prove an inequality for Hölder continuous differential forms on compact manifolds in which the integral of the form over the boundary of a sufficiently small, smoothly immersed disk is bounded by a certain multiplicative convex combination of the volume of the disk and the area of its boundary. This inequality has natural applications in dynamical systems, where Hölder continuity is ubiquitous. We give two such applications. In the first one, we prove a criterion for the existence of global cross sections to Anosov flows in terms of their expansion-contraction rates. The second application provides an analogous criterion for non-accessibility of partially hyperbolic diffeomorphisms.
2009, 25(2): 687-699 doi: 10.3934/dcds.2009.25.687 +[Abstract](1676) +[PDF](184.9KB)
Abstract:
A variational problem

Minimize $\quad \int_a^bL(x,u(x),u'(x),u''(x))dx,\quad u\in\Omega$

with a second-order Lagrangian is considered. In absence of any smoothness or convexity condition on $L$, we present an existence theorem by means of the integro-extremal technique. We also discuss the monotonicity property of the minimizers. An application to the extended Fisher-Kolmogorov model is included.

2009, 25(2): 701-718 doi: 10.3934/dcds.2009.25.701 +[Abstract](1861) +[PDF](247.1KB)
Abstract:
In this paper we prove Gevrey smoothness of the persisting invariant tori for small perturbations of analytic linear reversible systems with Rüssmann's non-degeneracy condition by an improved KAM iteration method with parameters.

2019  Impact Factor: 1.338


text:
# Dune

OCTOBER 16, 2004

8.5/10. One of the all-time greats of scifi. I’ve now read 2-3 times over the years a fact that is itself testament to its quality (very little scifi justifies a reread let alone a rereread). I include here the wonderful Litany Against Fear (p. 19 of Dune)

The Bene Gesserit Littainy Against Fear

I must not fear.
Fear is the mind-killer.
Fear is the little-death that brings total obliteration.
I will face my fear.
I will permit it to pass over me and through me.
And when it has gone past I will turn the inner eye to see its path.
Where the fear has gone there will be nothing.
Only I will remain.


text:
## August 30, 2011

### CapJaxMathFax and UberSmart Math Facts programs

I had the chance to look into two math facts practice programs, titled CapJaxMathFax and UberSmart Math Facts. Both programs drill math facts and keep track of your progress.

My testing "girl" liked them both just fine. Her focus definitely was on getting the percentages on the progress chart to go up (in both programs)!

## CapJaxMathFax

Here's a screen of CapJaxMathFax showing a math problem to solve. It alternates the dot and cross symbols for multiplication. It also alternates showing the problems vertically or horizontally. The vertical line is my cursor blinking in the empty space.

If you answer correctly and in less than 3 seconds, it shows you the word "SUPER". Then you get the next fact by pressing "ENTER."

Personally I would have liked a little clearer workspace, but all these colors, buttons, text, etc. on the screen seemingly didn't bother my daughter.

Here is where you select what operation you want to practice, how long, etc. The "word problems" aren't really word problems, but just math facts with words instead of with symbols.

In CapJaxMathFax, you can either practice, or build your ratings. Ratings can be built when you can get "SUPER" answers—those where you answer in 3 seconds or less.

You start off with ratings of 0 in each math type. Your ratings climb as you work through each building level in the math skill types (+, -, x, ÷).

Here are my ratings after playing for a little while:

And this is the general progress chart:

The software has a free evaluation version that you can download here. Website: www.CapJax.com. The price for the software is $19.95. ## UberSmart Math Facts UberSmart Math Facts had a cleaner interface that I liked better, but it has less options. The math facts were shown as flash cards. You get a progress chart, but there aren't any "ratings" as in CapJaxMathFax. There are three ways to practice. The first one is to View Flash Cards. The second one is to View Flash Cards and check the Beat the Clock checkbox. The third one is to take a Test. The first, "View Flash Cards" option, simply shows you the flash card and you just think the answer in your mind, and you can have the program show you the answer. "Beat the Clock" is the main way to practice (this won't affect your progress chart). When you check this box, the flash cards become interactive and you must enter an answer before the computer answers it for you. If you enter the wrong answer, or the computer answers before you do, the correct answer is shown and that fact is moved to the end of the set, so you need to answer it again. The facts you didn't get are repeated in the set until you get them correct. Once you think you're ready, you can take a "test". The results from tests will be shown in your progress chart. This is how you set up the practicing using the "test" option: Here, I would like to see an option to select several tables for a test, such as 4s, 8s, and 9s. Currently it has an option for choosing one table at a time, or all of them. This is how the flashcards look like in the test. If you miss some facts in a test, the program will tell you what you missed after the test, and show you the correct answers. After missing or answering slowly some facts in a particular test, such as in the 4s for multiplication, if you go to the "View Flash Cards" for that same kind of practice, you have the option of doing a "focused" viewing of flash cards. This makes the program only show you flash cards of the problems you missed or were slow in answering in the "test". And lastly, here's the progress chart. Your goal is to get to 100%, and if you are not only 100% correct but also fast enough, it shows a neat star in the chart! My "guinea pig" daughter was plenty motivated by trying to get the progress chart go up to 100%! (And that's how it should be, by the way... that the student would be internally motivated to learn something for the learning's sake.) You can download a free 30-day trial of UberSmart Math Facts here. The main website is Mathfacts.ubersmartsoftware.com/mathfacts.php. The software costs$24.95.

The main feature I'd like to see in these two programs is being more adaptive so that the program would drill those facts much more (not just one extra time) that the child has trouble with. I've seen how Math Rider does that (which I have also reviewed).

I would definitely recommend using something computerized to help children master their math facts. My children have enjoyed trying out many different programs and systems, and I feel it has been quite helpful. BUT not at first--only AFTER they have understood the concepts and the patterns in them!

I also recommend you use the free trials to check and see what program  your child likes best.


text:
# EIP-3386: ERC-721 and ERC-1155 to ERC-20 Wrapper Source

Author Calvin Koder https://github.com/ethereum/EIPs/issues/3384 Draft Standards Track ERC 2021-03-12 165

## Simple Summary

A standard interface for contracts that create generic ERC-20 tokens which derive from a pool of unique ERC-721/ERC-1155 tokens.

## Abstract

This standard outlines a smart contract interface to wrap identifiable tokens with fungible tokens. This allows for derivative ERC-20 tokens to be minted by locking the base ERC-721 non-fungible tokens and ERC-1155 multi tokens into a pool. The derivative tokens can be burned to redeem base tokens out of the pool. These derivatives have no reference to the unique id of these base tokens, and should have a proportional rate of exchange with the base tokens. As representatives of the base tokens, these generic derivative tokens can be traded and otherwise utilized according to ERC-20, such that the unique identifier of each base token is irrelevant.

ERC-721 and ERC-1155 tokens are considered valid base, tokens because they have unique identifiers and are transferred according to similar rules. This allows for both ERC-721 NFTs and ERC-1155 Multi-Tokens to be wrapped under a single common interface.

## Motivation

The ERC-20 token standard is the most widespread and liquid token standard on Ethereum. ERC-721 and ERC-1155 tokens on the other hand can only be transferred by their individual ids, in whole amounts. Derivative tokens allow for exposure to the base asset while benefiting from contracts which utilize ERC-20 tokens. This allows for the base tokens to be fractionalized, traded and pooled generically on AMMs, collateralized, and be used for any other ERC-20 type contract. Several implementations of this proposal already exist without a common standard.

Given a fixed exchange rate between base and derivative tokens, the value of the derivative token is proportional to the floor price of the pooled tokens. With the derivative tokens being used in AMMs, there is opportunity for arbitrage between derived token markets and the base NFT markets. By specifying a subset of base tokens which may be pooled, the difference between the lowest and highest value token in the pool may be minimized. This allows for higher value tokens within a larger set to be poolable. Additionally, price calculations using methods such as Dutch auctions, as implemented by NFT20, allow for price discovery of subclasses of base tokens. This allows the provider of a higher value base token to receive a proportionally larger number of derivative tokens than a token worth the floor price would receive.

## Specification

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

Every IWrapper compliant contract must implement the IWrapper and ERC165 interfaces :

pragma solidity ^0.8.0;

/**
@title IWrapper Identifiable Token Wrapper Standard
@dev {Wrapper} refers to any contract implementing this interface.
@dev {Base} refers to any ERC-721 or ERC-1155 contract. It MAY be the {Wrapper}.
@dev {Pool} refers to the contract which holds the {Base} tokens. It MAY be the {Wrapper}.
@dev {Derivative} refers to the ERC-20 contract which is minted/burned by the {Wrapper}. It MAY be the {Wrapper}.
@dev All uses of "single", "batch" refer to the number of token ids. This includes individual ERC-721 tokens by id, and multiple ERC-1155 by id. An ERC-1155 TransferSingle event may emit with a value greater than 1, but it is still considered a single token.
@dev All parameters named _amount, _amounts refer to the value parameters in ERC-1155. When using this interface with ERC-721, _amount MUST be 1, and _amounts MUST be either an empty list or a list of 1 with the same length as _ids.
*/
interface IWrapper /* is ERC165 */ {
/**
* @dev MUST emit when a mint occurs where a single {Base} token is received by the {Pool}.
* The _from argument MUST be the address of the account that sent the {Base} token.
* The _to argument MUST be the address of the account that received the {Derivative} token(s).
* The _id argument MUST be the id of the {Base} token transferred.
* The _amount argument MUST be the number of {Base} tokens transferred.
* The _value argument MUST be the number of {Derivative} tokens minted.
*/
event MintSingle (address indexed _from, address indexed _to, uint256 _id, uint256 _amount, uint256 _value);

/**
* @dev MUST emit when a mint occurs where multiple {Base} tokens are received by the {Wrapper}.
* The _from argument MUST be the address of the account that sent the {Base} tokens.
* The _to argument MUST be the address of the account that received the {Derivative} token(s).
* The _ids argument MUST be the list ids of the {Base} tokens transferred.
* The _amounts argument MUST be the list of the numbers of {Base} tokens transferred.
* The _value argument MUST be the number of {Derivative} tokens minted.
*/
event MintBatch (address indexed _from, address indexed _to, uint256[] _ids, uint256[] _amounts, uint256 _value);

/**
* @dev MUST emit when a burn occurs where a single {Base} token is sent by the {Wrapper}.
* The _from argument MUST be the address of the account that sent the {Derivative} token(s).
* The _to argument MUST be the address of the account that received the {Base} token.
* The _id argument MUST be the id of the {Base} token transferred.
* The _amount argument MUST be the number of {Base} tokens transferred.
* The _value argument MUST be the number of {Derivative} tokens burned.
*/
event BurnSingle (address indexed _from, address indexed _to, uint256 _id, uint256 _amount, uint256 _value);

/**
* @dev MUST emit when a mint occurs where multiple {Base} tokens are sent by the {Wrapper}.
* The _from argument MUST be the address of the account that sent the {Derivative} token(s).
* The _to argument MUST be the address of the account that received the {Base} tokens.
* The _ids argument MUST be the list of ids of the {Base} tokens transferred.
* The _amounts argument MUST be the list of the numbers of {Base} tokens transferred.
* The _value argument MUST be the number of {Derivative} tokens burned.
*/
event BurnBatch (address indexed _from, address indexed _to, uint256[] _ids, uint256[] _amounts, uint256 _value);

/**
* @notice Transfers the {Base} token with _id from msg.sender to the {Pool} and mints {Derivative} token(s) to _to.
* @param _id       Id of the {Base} token.
* @param _amount   Amount of the {Base} token.
*
* Emits a {MintSingle} event.
*/
function mint(
uint256 _id,
uint256 _amount
) external;

/**
* @notice Transfers _amounts[i] of the {Base} tokens with _ids[i] from msg.sender to the {Pool} and mints {Derivative} token(s) to _to.
* @param _ids      Ids of the {Base} tokens.
* @param _amounts  Amounts of the {Base} tokens.
*
* Emits a {MintBatch} event.
*/
function batchMint(
uint256[] calldata _ids,
uint256[] calldata _amounts
) external;

/**
* @notice Burns {Derivative} token(s) from _from and transfers _amounts of some {Base} token from the {Pool} to _to. No guarantees are made as to what token is withdrawn.
* @param _amount   Amount of the {Base} tokens.
*
* Emits either a {BurnSingle} or {BurnBatch} event.
*/
function burn(
uint256 _amount
) external;

/**
* @notice Burns {Derivative} token(s) from _from and transfers _amounts of some {Base} tokens from the {Pool} to _to. No guarantees are made as to what tokens are withdrawn.
* @param _amounts  Amounts of the {Base} tokens.
*
* Emits either a {BurnSingle} or {BurnBatch} event.
*/
function batchBurn(
uint256[] calldata _amounts
) external;

/**
* @notice Burns {Derivative} token(s) from _from and transfers _amounts[i] of the {Base} tokens with _ids[i] from the {Pool} to _to.
* @param _id       Id of the {Base} token.
* @param _amount   Amount of the {Base} token.
*
* Emits either a {BurnSingle} or {BurnBatch} event.
*/
function idBurn(
uint256 _id,
uint256 _amount
) external;

/**
* @notice Burns {Derivative} tokens from _from and transfers _amounts[i] of the {Base} tokens with _ids[i] from the {Pool} to _to.
* @param _ids      Ids of the {Base} tokens.
* @param _amounts   Amounts of the {Base} tokens.
*
* Emits either a {BurnSingle} or {BurnBatch} event.
*/
function batchIdBurn(
uint256[] calldata _ids,
uint256[] calldata _amounts
) external;
}

## Rationale

### Naming

The ERC-721/ERC-1155 tokens which are pooled are called {Base} tokens. Alternative names include:

• Underlying.
• NFT. However, ERC-1155 tokens may be considered “semi-fungible”.

The ERC-20 tokens which are minted/burned are called {Derivative} tokens. Alternative names include:

• Wrapped.
• Generic.

The function names mint and burn are borrowed from the minting and burning extensions to ERC-20. Alternative names include:

• mint/redeem (NFTX)
• deposit/withdraw (WrappedKitties)
• wrap/unwrap (MoonCatsWrapped)

The function names *idBurn are chosen to reduce confusion on what is being burned. That is, the {Derivative} tokens are burned in order to redeem the id(s).

The wrapper/pool itself can be called an “Index fund” according to NFTX, or a “DEX” according to NFT20. However, the {NFT20Pair} contract allows for direct NFT-NFT swaps which are out of the scope of this standard.

### Minting

Minting requires the transfer of the {Base} tokens into the {Pool} in exchange for {Derivative} tokens. The {Base} tokens deposited in this way MUST NOT be transferred again except through the burning functions. This ensures the value of the {Derivative} tokens is representative of the value of the {Base} tokens.

Alternatively to transferring the {Base} tokens into the {Pool}, the tokens may be locked as collateral in exchange for {Derivative} loans, as proposed in NFTX litepaper, similarly to Maker vaults. This still follows the general minting pattern of removing transferability of the {Base} tokens in exchange for {Derivative} tokens.

### Burning

Burning requires the transfer of {Base} tokens out of the {Pool} in exchange for burning {Derivative} tokens. The burn functions are distinguished by the quantity and quality of {Base} tokens redeemed.

• For burning without specifying the id: burn, batchBurn.
• For burning with specifying the id(s): idBurn, batchIdBurn.

By allowing for specific ids to be targeted, higher value {Base} tokens may be selected out of the pool. NFTX proposes an additional fee to be applied for such targeted withdrawals, to offset the desire to drain the {Pool} of {Base} tokens worth more than the floor price.

### Pricing

Prices should not be necessarily fixed. therefore, Mint/Burn events MUST include the ERC-20 _value minted/burned.

Existing pricing implementations are as follows (measured in base:derivative):

• Equal: Every {Base} costs 1 {Derivative}
• NFTX
• Wrapped Kitties
• Proportional
• NFT20 sets a fixed rate of 100 {Base} tokens per {Derivative} token.
• Variable
• NFT20 also allows for Dutch auctions when minting.
• NFTX proposes an additional fee to be paid when targeting the id of the {Base} token.

Due to the variety of pricing implementations, the Mint* and Burn* events MUST include the number {Derivative} tokens minted/burned.

### Inheritance

#### ERC-20

The {Wrapper} MAY inherit from {ERC20}, in order to directly call super.mint and super.burn. If the {Wrapper} does not inherit from {ERC20}, the {Derivative} contract MUST be limited such that the {Wrapper} has the sole power to mint, burn, and otherwise change the supply of tokens.

If not inheriting from {ERC721Receiver} and/or {ERC1155Receiver}, the pool MUST be limited such that the base tokens can only be transferred via the Wrapper’s mint, burn.

There exists only one of each ERC-721 token of with a given (address, id) pair. However, ERC-1155 tokens of a given (address, id) may have quantities greater than 1. Accordingly, the meaning of “Single” and “Batch” in each standard varies. In both standards, “single” refers to a single id, and “batch” refers to multiple ids. In ERC-1155, a single id event/function may involve multiple tokens, according to the value field.

In building a common set of events and functions, we must be aware of these differences in implementation. The current implementation treats ERC-721 tokens as a special case where, in reference to the quantity of each {Base} token:

• All parameters named _amount, MUST be 1.
• All parameters named _amounts MUST be either an empty list or a list of 1 with the same length as _ids.

This keeps a consistent enumeration of tokens along with ERC-1155. Alternative implementations include:

• A common interface with specialized functions. EX: mintFromERC721.
• Separate interfaces for each type. EX: ERC721Wrapper, ERC1155Wrapper.

#### ERC721, ERC1155

The {Wrapper} MAY inherit from {ERC721} and/or {ERC1155} in order to call super.mint, directly. This is optional as minting {Base} tokens is not required in this standard. An “Initial NFT Offering” could use this to create a set of {Base} tokens within the contract, and directly distribute {Derivative} tokens.

If the {Wrapper} does not inherit from {ERC721} or {ERC1155}, it MUST include calls to {IERC721} and {IERC1155} in order to transfer {Base} tokens.

### Approval

All of the underlying transfer methods are not tied to the {Wrapper}, but rather call the ERC-20/721/1155 transfer methods. Implementations of this standard MUST:

• Either implement {Derivative} transfer approval for burning, and {Base} transfer approval for minting.
• Or check for Approval outside of the {Wrapper} through {IERC721} / {IERC1155} before attempting to execute.

## Backwards Compatibility

Most existing implementations inherit from ERC-20, using functions mint and burn. Events:

• Mint
• WK: DepositKittyAndMintToken
• NFTX: Mint
• Burn
• WK: BurnTokenAndWithdrawKity
• NFTX: Redeem

## Reference Implementation

ERC-3386 Reference Implementation

## Security Considerations

Wrapper contracts are RECOMMENDED to inherit from burnable ERC-20 tokens. If they are not, the supply of the {Derivative} tokens MUST be controlled by the Wrapper. Similarly, price implementations MUST ensure that the supply of {Base} tokens is reflected by the {Derivative} tokens.

With the functions idBurn, idBurns, users may target the most valuable NFT within the generic lot. If there is a significant difference between tokens values of different ids, the contract SHOULD consider creating specialized pools (NFTX) or pricing (NFT20) to account for this.

Copyright and related rights waived via CC0.


text:
## Elementary Geometry for College Students (7th Edition)

sin(a) = $\frac{\sqrt 5}{3}$ sin(b) = $\frac{2}{3}$
The opposite side of angle a is $\sqrt 5$ and hypotenuse is 3. Therefore sin(a) = $\frac{\sqrt 5}{3}$ The opposite side of angle b is unknown and hypotenuse is 3. To find the unknown opposite side, use Pythagorus theorem. $3^{2}$ - $\sqrt 5^{2}$ = $x^{2}$ 9 - 5 = $x^{2}$ $x^{2}$ = 4 x = 2 So sin(b) = $\frac{2}{3}$


text:
# zbMATH — the first resource for mathematics

Boundary value problems for lower semicontinuous differential inclusions. (English) Zbl 0788.34007
The results of the paper deal with the existence of solutions to a boundary value problem $$x'(t) \in F(t,x(t))$$, $$t \in[0,T]$$, $$x(0) \in D$$, $$x(T) \in D'$$, where $$D$$ and $$D'$$ are closed subsets of an $$n$$- dimensional Euclidean space. The existence theorem is obtained for a lower semicontinuous multifunction $$F$$ with compact values.
##### MSC:
 34A60 Ordinary differential inclusions 34B15 Nonlinear boundary value problems for ordinary differential equations