Summary of the problem solving of the SiC exercise (2.11): optimization of interval multiplication, sicp2.11

Summary of the problem solving of the SiC exercise (2.11): optimization of interval multiplication, sicp2.11

There is another Ben person in exercise 2.11. As mentioned previously, as long as Ben is talking about it, it is generally correct.

To see what Ben said, he said: "by monitoring the endpoints of the interval, it is possible to break mul-interval into 9, in each case, the multiplication is not more than two times ".

Therefore, Ben suggested Allysa to rewrite the mul-interval process.

In the end, let's take a look at the previous mul-interval process:

(define (mul-interval x y)  (let (( p1 (* (lower-bound x) (lower-bound y)))( p2 (* (lower-bound x) (upper-bound y)))( p3 (* (upper-bound x) (lower-bound y)))( p4 (* (upper-bound x) (upper-bound y))))    (make-interval (min p1 p2 p3 p4)   (max p1 p2 p3 p4))))

We can see that four multiplication times are used here, and then the minimum value of the multiplication 4 is the start point, and the maximum value is the end point.

According to Ben, we can reduce the multiplication of these four times to two times, provided that we can judge the endpoint of the interval.

In fact, we can think about Ben's mysterious words. For example, if the two intervals multiplied are completely greater than zero, the start point of the two intervals must be the minimum value in the four multiplication, the multiplication of two endpoints must be the largest of the four multiplications. In this way, we only need to calculate the multiplication of two endpoints and the multiplication of two endpoints. In this way, we can use two multiplication times to complete the work, instead of four.

However, for our programmers, the work is much more complicated. We need to judge the nine situations and think about the starting and ending points of the nine situations respectively, the code written at the end is as follows:

(define (mul-interval x y)  (if (> (lower-bound x) 0)      (if (> (lower-bound y) 0)  (make-interval (* (lower-bound x) (lower-bound y)) (* (upper-bound x) (upper-bound y)))  (if (> (upper-bound y) 0)      (make-interval (* (upper-bound x) (lower-bound y)) (* (upper-bound x) (upper-bound y)))      (make-interval (* (lower-bound x) (upper-bound y)) (* (lower-bound x) (upper-bound y)))))      (if (> (upper-bound x) 0)  (if (> (lower-bound y) 0)      (make-interval (* (lower-bound x) (upper-bound y)) (* (upper-bound x) (upper-bound y)))      (if (> (upper-bound y) 0)  (make-interval (* (lower-bound x) (lower-bound y))  (* (upper-bound x) (upper-bound y)))  (make-interval (* (lower-bound x) (lower-bound y)) (* (upper-bound x) (upper-bound y)))))  (if (> (lower-bound y) 0)      (make-interval (* (lower-bound x) (lower-bound y)) (* (upper-bound x) (upper-bound y)))      (if (> (upper-bound y) 0)  (make-interval (* (lower-bound x) (lower-bound y))  (* (upper-bound x) (upper-bound y)))  (make-interval (* (lower-bound x) (lower-bound y))  (* (upper-bound x) (upper-bound y))))) )))

Someone may ask, is it interesting to write the original elegant process as it is now? A bunch of ugly judgments!

Here, we need to understand that if multiplication in the system is an operation that consumes a lot, for example, every multiplication consumes 2 seconds, it makes sense to do this optimization, although the code we write is ugly and troublesome, the code running efficiency is high.