OO_JAVA_表达式求导

时间 2019-11-08

标签 java 表达式栏目 Java 繁體版

原文原文链接

OO_JAVA_表达式求导_第一弹

---------------------------------------------------表达式提取部分

词法分析

首先，每个表达式内部都存在不可分割的字符组，好比一个不止一位的数字，或是一个sin三角函数，这样不能分离的字符组我称之为词法单元，依照其定义，能够将第三次做业的表达式分割成以下词法单元：java

SPACE：即空格和TAB字符的组合
纯数字：即纯粹由0-9字符集组成
运算符：-、+、*、^，这些都是运算符
三角函数：sin或cos内部不可存在空格
左括号：(
右括号：)

将一串字符解析成词法单元列表的形式，就已是一层处理了，这一步就能够排查出一些错误，直接抛出异常，而后咱们获得了一个由词法单元组成的列表，如今就是采用递归递降的方法线性解析这个列表并生成表达树了。设计模式

语法分析

仔细阅读指导书，能够概括出以下定义：api

Num = [-|+]纯数字
Factor = Num | x [^ Num] | sin ( Factor) [^ Num] | cos ( Factor) [^ Num] | (Expr)
Item = [-|+]Factor (*Factor)*
Expr = [-|+]Item ([-|+]Item)*

** 其中[]表示其中的字符存在或不存在皆可；()*表示可选重复0至任意次；| 表示或 **架构

除Num单元内部，其它语法单元内部能够任意插入SPACEide

写做分析函数的原则有两条：函数

采用分层次的设计思路，从概括的语法定义就能够看出，须要写一个处理Expr的函数，一个处理Item的函数……须要子结构时调用相应函数便可。
只处理本层次须要处理的字符，遇到非法字符，返回上层调用或者抛出异常；

固然，有人会说，这样只是写一堆递归函数（o(╯□╰)o，我就是这么写的），没有实行面对对象，其实，递归递降也是能够面对对象的。this

模式匹配

首先须要一个Parser接口，实现以下（不必定）函数（为清晰起见，写的很简单）atom

public interface Parser {
    public Atom toAtom();

    public Integer getIndex();
    
    public void addParser(Parser parser);
}

分别是一个转换函数，一个获取新遍历下标的函数，一个添加子Parser的函数。架构设计

根据不一样层级Parser的须要，完成相应函数的重写(Override)便可，举个栗子：设计

public class ExprParser implements Parser {
    ArrayList<Parser> itemList;
    // Integer endIndex; //

    private ExprParser() {
        itemList = new ArrayList<>();
    }

    @Override
    public Atom toAtom() {
        Atom root = new Atom(Atom.Type.PLUS, BigInteger.ZERO);
        for (Parser parser:itemList) {
            root.addChild(parser.toAtom());
        }
        return root;
    }
    
    @Override
    public Integer getIndex() {
        return endIndex;
    }

    public static Parser newParser(String string) {
        Parser parser = new ExprParser();
        for (int i = 0; i < string.length();) {
            if (string.charAt(i) == '-' || string.charAt(i) == '+' ||
                    string.charAt(i) != ' ' && string.charAt(i) != '\t') {
                Parser itemParser = ItemParser.newParser(string.substring(i));
                parser.addParser(itemParser);
                i = itemParser.getIndex();
            } else {
                i += 1;
            }
        }
        return parser;
    }

    @Override
    public void addParser(Parser parser) {
        itemList.add(parser);
    }
}

依旧格式简易，可是只是为了说明怎么重写这样的函数，Atom即最后生成的表达树的节点类或者接口，随我的意。

另外没有显式抛出异常，真正写时须要在返回parser时检查item List是否为空，若为空，则显式抛出异常，进行异常处理。

如今说明一下，这个newParser工厂函数为何这么写，为了清楚起见，我把Expr的定义从新拉过来：

Expr = [-|+]Item ([-|+]Item)*

这个语法定义告诉咱们Expr线性扫描，检查是否有减号或是加号，而后须要获取一个Item，这时调用ItemParser的工厂函数便可，格式异常由不一样层级的Parser实现类的工厂函数负责抛出，只要语法分析合理，这样写做是简单无误的。

以此类推，相信读懂了上述抽象的思惟方式，写出Item和Factor的Parser对你易如反掌！

OO_JAVA_表达式求导_第二弹

------------------------------------------------表达树的构建

整体来讲，按照设计模式上能够分为两类：本次实验仍是建议第二种方式（虽然我用了第一种，，::>_<::）

extends 继承，采起一个父类实现所需方法子类重写方法，可是为了统一填充到ArrayList或者HashMap中，必须采起子类cast回父类的方式，这样子类不能有本身的属性，不然没法cast；
implements 实现，采起定义共通的接口，全部节点类重写接口中的方法，如求导方法、化简方法、toString方法。

在第三次做业中，我采用了继承的方案实现树形结构节点的构造，Atom父类实现了很是多的函数，如今的视角来看，是很不合理的，由于Atom负担了全部子类的函数，臃肿累赘，层次是分明了，只有父类Atom和子类各类Atom，可是在工程管理和逻辑架构设计上，仍是有所问题的。

下面是个人Atom类图关系，其它类都继承自Atom很复杂把。

OO_JAVA_表达式求导_第三弹

-----------------------------如何将函数式思惟带入化简函数

要实现化简合并，最好先完成两个准备工做（一个可选）

expand：展开（可选），有时会碰见123*(x+123)这样的状况，*与+没有按照优先级组合，而是须要根据乘法分配率展开这样的项；
flat Map：平铺，在处理字符串生成表达树以及求导表达树返回新表达树的过程当中，会产生不少如1*(1*(1*x))连乘项或连加项嵌套的结果，平铺能够将之展开成为1*1*1*x的形式，利于下一步的分类和合并。

首先从宏观的角度抽象地理解化简，是怎么一回事，一共两步

classification：分类，将能化简的规整在一块儿，不能化简的单独存放，最终结果是一个List<List<Atom>>，每个List<Atom>存放的是能够合并的同类项；
merge：合并，对不一样的可合并List<Atom>进行合并处理，再新建一个父对象，将合并结果依次填回父对象的子节点中，返回父对象。

如今简单说明一下Java8引入的Stream API和lambda表达式(其实是Functional Interface)

举个栗子，如今咱们有一串数字在列表origin中，咱们要对他们都平个方，生成一个新列表，正常作法以下：

List<Integer> after = new ArrayList<>();
for (Integer integer: origin) {
    after.add(integer * integer);
}

可是有了Stream API和lambda表达式，就能够这么写：

List<Integer> after = origin.stream().map(e -> e * e).collect(toList());

Stream流的主要功能有filter(筛选)，map(映射)，flatMap(平铺映射)，collect(收集返回列表或Map或其它)。

须要填充函数接口的参数的来源有两种：

方法引用，好比Integer::add，就是对Integer的加法方法的一个引用，内秉实际上是函数接口
lambda表达式，基本形式为(参数列表)->返回值或 (参数列表)->{语句; return 返回值;}组成。

如今问题来了，为何要这么写呢？何时要写成哪种形式呢？

这两种写法的主要区别在于逻辑的分离性与可控性：前者循环方式，循环流程彻底由你掌控，可操做性极大，同时脑力负担也大一些；后者将循环体隐藏在Stream API的内部，你不须要在控制循环的方方面面，能够一层层地分离逻辑，减轻脑力负担，高效清晰地编写代码。
在循环体内部流程很是简单时，好比上述栗子，你选择哪种都没有什么问题，无非是代码行数和内部执行效率的区别，可是，在具化到我要讲的classification过程时，也就是能够尽可能分离循环体内部操做时，选择Stream API能够清晰地简单地生成新列表，下面就对此说明一下吧。

Classification能够分为四步：

实现一个函数（知足Predicate接口定义），也就是一个泛化意义上的相等函数，用来判断两项可否合并；
根据先前实现的接口，采用Stream的filter过滤器API，对每一个元素，过滤出与之相等（可合并）的元素组成列表；
依照先前产生的列表，通通插入到Map中，为保证key的惟一，采用每个列表的toString方法结果做为key；
将上述生成的Map的values取出，返回一个列表的列表，实现classification的功能。

上述过程就是一个逻辑不断分离的过程，对应到相加项和相乘项，惟一不一样的就是Predicate接口，也是这么思惟的意义所在。

这里把后三步的合并加法与合并乘法共通的代码贴出来：

public List<Atom> filter(Atom atom, Predicate<Atom> predicate) {
    return this.children.stream()
        .filter(predicate)
        .collect(Collectors.toList());
}

public ArrayList<List<Atom>> classify(Predicate<Atom> predicate) {
    Map<String, List<Atom>> map = new HashMap<>();
    for (Atom atom : children) {
        ArrayList<Atom> list = (ArrayList<Atom>) this.filter(atom, predicate);
        map.put(list.toString(), list);
    }
    return new ArrayList<>(map.values());
}

与上述思惟相似，Merge也可分步进行：

先merge全部子节点从新填充到新root节点中；
使用classification，获取新root节点分类后的子节点列表的列表；
建立新root节点，迭代前一步获取的列表，使用合并同类项函数（同类项列表=>合并后的项），将节点依次插入新的root节点中，返回。

继续拆分，上述第三步采用Stream的思路还能够拆分：

产生Stream<List<Atom>>流；
map映射List<Atom>到Atom，这里交由另外一个函数接口负责；
filter筛选须要添加至最终列表的项，这里依然能够分离出去交由另外一个函数接口负责；
最后collect函数收集流中的元素，返回List<Atom>，若为空，返回特定值。

这里举个例子就把合并相加项的filter调用的函数接口写一下吧：

Predicate<Atom> addPredicate = e -> !(
        e.getType().equals(Atom.Type.CONSTANT) && e.getValue().equals(BigInteger.ZERO)
);

上述函数接口代表，若是元素e是一个常数0了话，返回false不然返回true。

综上所述，若是你理解了分离逻辑的操做后，写出清晰简洁的代码应该是易如反掌把！