I’ve written part of a mathematical calculator program. I’ve finished the parser of the program,
so when a user types in a mathematical expression as a string, I already have a way to obtain
a corresponding data structure of the following type:
type expression =
| Term of int
| Addition of expression * expression
| Multiplication of expression * expression
| Subtraction of expression * expression
All I need now is a way to evaluate these kinds of data structures.
(a) Write the expression corresponding to the mathematical statement “3*((1 + 4)- 5).”
(b) Extend the Ocaml datatype to include a Factorial constructor, so that it can handle
expressions like “3*((1 + 4)! -5).”
(c) Write an Ocaml function eval which takes a mathematical expression and returns its
(integer) value. For example, it should return 0 as the result from the expression in part
(a).
# let rec eval expr = ...
val eval : expression -> int = <fun>
You may want to write a factorial Ocaml function to help out with the new Factorial
constructor.
I'm confused about part a. Does it mean let expression = 3*((1 + 4)- 5);?
For part b, should I follow the pattern |Factorial of expression * expression?
What is meant in a) is that you can now write mathematical expressions as values of the provided datatype expression. For example, the constructor Addition expresses that the addition operator (normally written as (+)) forms an expression by taking two smaller expressions as operands. So, for instance, the mathematical expression 2 + 3 can be represented by the Caml value
Addition (Term 2,Term 3)
Now, observing that the factorial operator takes one argument rather than two arguments, you should be able to extend the datatype expression with a constructor for factorials as is asked in b).
Finally, in c), writing an evaluation function for this kind of expression types is straightforward: constants just map to the integer value they are carrying and evaluating an addition involves recursively evaluating the operands of the addition and then adding them up:
let rec eval = function
| Term n -> n
| Addition (l,r) -> eval e1 + eval e2
| ...
The remaining cases (for the remaining constructors, including the one for the constructor for factorials that you will add for b)) are analogous and you should be able to do that by yourself now.
Good luck!
Part b: the point of the question is that a multiplication takes two numbers as input, but factorial takes only one number as input.
Related
In the tryapl.org Primer when you select the Del glyph (∇) it shows an example of a Double-Del (∇∇) where a dop (as I understand it, a user defined operator) can reference itself in a recursive fashion:
Double-Del Syntax: dop self-reference
pow←{ ⍝ power operator: apply ⍵⍵ times
⍵⍵=0:⍵ ⍝ ⍵⍵ is 0: finished
⍺⍺ ∇∇(⍵⍵-1)⍺⍺ ⍵ ⍝ otherwise: recurse
}
Can someone provide me with some examples of this particular dop in use so I can see how to utilize it? I see that a single ⍺ is not used in the body of this dop, only ⍺⍺; does that make this a monadic dop?
I have tried a number of different ways to use this operator in an expression after it's defined and can't seem to get anything but errors or instances where it appears the body/text of the dop is in an array as text, alongside what I was trying to pass to it.
Example usage
incr←{1+⍵} ⍝ define an increment function
(incr pow 3) 5 ⍝ apply it 3 times to 5
8
Lack of single ⍺
The operator has ⍵⍵ which alone makes it a dyadic operator. The lack of a single ⍺ means that, when given the two required operands, it derives a monadic function.
Troubleshooting
When an operator takes an array (as opposed to a function) operand adjacent to an argument, it is crucial to separate the operand from the argument. This can be done in any of three ways:
Name the derived function and then apply it:add3←incr pow 3
add3 5
Parenthesise the derived function:(incr pow 3) 5
Separate the operand from the argument using a function (often, the identity function ⊢ is used): incr pow 3 ⊢ 5
Failing this, the intended operand and argument will strand to a single array, which then becomes the operand, leaving the derived function with no argument that it can apply to:
incr pow (3 5)
The result is therefore the derived function; the text source you see reported.
my question is concerning Exercise 2.11 in the book Concrete Semantics (http://concrete-semantics.org/):
Define arithmetic expressions in one variable over integers
(type int) as a data type:
datatype exp = Var | Const int | Add exp exp | Mult exp exp
Define a function eval :: exp => int => int such that eval e x evaluates e at
the value x.
A polynomial can be represented as a list of coefficients, starting with the
constant. For example, [4, 2, -1, 3] represents the polynomial 4+2x-x^2+3x^3.
Define a function evalp :: int list => int => int that evaluates a polynomial at
the given value. Define a function coeffs :: exp => int list that transforms an
expression into a polynomial. This may require auxiliary functions. Prove that
coeffs preserves the value of the expression: evalp (coeffs e) x = eval e x.
---end
It's all pretty straightforward until you get to coeffs. We would have to deal with expressions like (X + X)*(2*X + 3*X*X) which have to be recursively expanded bottom-up using a distributive law until its in polynomial form. The resulting expression might still be something like (X*X + X*2*X + 3*X*X + 4*X*X*X) so then its necessary to normalize product terms (so eg X*2*X becomes 2*X*X), collect together like terms, and finally order them in order of increasing degree! This just seems significantly more complicated than any of the exercises so far that I wonder if I'm missing something or overly complicating it.
I think this exercise is considerably easier than you think. You can write a single primitively-recursive function coeffs that does the job: the coefficients of Var are [0,1], the coefficients of Const c are [c]. Similarly, if you have two subexpressions and you know their coefficients, you can combine those two coefficient lists into a single list for addition/multiplication.
For that, you should ideally write two auxiliary functions add_coeffs and mult_coeffs which add and multiply two lists of coefficients. (the latter will probably make use of the former)
You will have to prove that add_coeffs and mult_coeffs do the right thing (w.r.t. eval and evalp). The resulting lemmas also make good [simp] rules.
The proofs are all simple inductions where each case is automatic.
As a general rule: a good definition often makes the difference between a long and tedious proof and a straight-forward or even completely automatic proof. Doing a long-winded expansion and then grouping summands etc. as you suggested in your question is sure to lead to a tedious proof.
Of course, the method that I suggested in this answer is not very efficient, but when you want to do things in a theorem prover, efficiency is usually not a big concern – you want things to be simple and elegant and amenable to nice proofs. If you need efficient code, you can still develop your nice and simple abstract formulation into something more efficient later and show equivalence.
I've been reading lots of articles on currying, but almost all of them are misleading, explaining currying as a partial function application and all of examples usually are about functions with arity of 2, like add function or something.
Also many implementations of curry function in JavaScript makes it to accept more than 1 argument per partial application (see lodash), when Wikipedia article clearly tells that currying is about:
translating the evaluation of a function that takes multiple arguments (or a tuple of arguments) into evaluating a sequence of functions, each with a single argument (partial application)
So basically currying is a series of partial applications each with a single argument. And I really want to know real uses of that, in any language.
Real use case of currying is partial application.
Currying by itself is not terribly interesting. What's interesting is if your programming language supports currying by default, as is the case in F# or Haskell.
You can define higher order functions for currying and partial application in any language that supports first class functions, but it's a far cry from the flexibility you get when every function you get is curried, and thus partially applicable without you having to do anything.
So if you see people conflating currying and partial application, that's because of how closely those concepts are tied there - since currying is ubiquitous, you don't really need other forms of partial application than applying curried functions to consecutive arguments.
It is usefull to pass context.
Consider the 'map' function. It takes a function as argument:
map : (a -> b) -> [a] -> [b]
Given a function which uses some form of context:
f : SomeContext -> a -> b
This means you can elegantly use the map function without having to state the 'a'-argument:
map (f actualContext) [1,2,3]
Without currying, you would have to use a lambda:
map (\a -> f actualContext a) [1,2,3]
Notes:
map is a function which takes a list containing values of a, a function f. It constructs a new list, by taking each a and applying f to it, resulting in a list of b
e.g. map (+1) [1,2,3] = [2,3,4]
The bearing currying has on code can be divided into two sets of issues (I use Haskell to illustrate).
Syntactical, Implementation.
Syntax Issue 1:
Currying allows greater code clarity in certain cases.
What does clarity mean? Reading the function provides clear indication of its functionality.
e.g. The map function.
map : (a -> b) -> ([a] -> [b])
Read in this way, we see that map is a higher order function that lifts a function transforming as to bs to a function that transforms [a] to [b].
This intuition is particularly useful when understanding such expressions.
map (map (+1))
The inner map has the type above [a] -> [b].
In order to figure out the type of the outer map, we recursively apply our intuition from above. The outer map thus lifts [a] -> [b] to [[a]] -> [[b]].
This intuition will carry you forward a LOT.
Once we generalize map over into fmap, a map over arbitrary containers, it becomes really easy to read expressions like so (Note I've monomorphised the type of each fmap to a different type for the sake of the example).
showInt : Int -> String
(fmap . fmap . fmap) showInt : Tree (Set [Int]) -> Tree (Set [String])
Hopefully the above illustrates that fmap provides this generalized notion of lifting vanilla functions into functions over some arbitrary container.
Syntax Issue 2:
Currying also allows us to express functions in point-free form.
nthSmallest : Int -> [Int] -> Maybe Int
nthSmallest n = safeHead . drop n . sort
safeHead (x:_) = Just x
safeHead _ = Nothing
The above is usually considered good style as it illustrates thinking in terms of a pipeline of functions rather than the explicit manipulation of data.
Implementation:
In Haskell, point free style (through currying) can help us optimize functions. Writing a function in point free form will allow us to memoize it.
memoized_fib :: Int -> Integer
memoized_fib = (map fib [0 ..] !!)
where fib 0 = 0
fib 1 = 1
fib n = memoized_fib (n-2) + memoized_fib (n-1)
not_memoized_fib :: Int -> Integer
not_memoized_fib x = map fib [0 ..] !! x
where fib 0 = 0
fib 1 = 1
fib n = not_memoized_fib (n-2) + not_memoized_fib (n-1)
Writing it as a curried function as in the memoized version treats the curried function as an entity and therefore memoizes it.
I'm interested in building a derivative calculator. I've racked my brains over solving the problem, but I haven't found a right solution at all. May you have a hint how to start? Thanks
I'm sorry! I clearly want to make symbolic differentiation.
Let's say you have the function f(x) = x^3 + 2x^2 + x
I want to display the derivative, in this case f'(x) = 3x^2 + 4x + 1
I'd like to implement it in objective-c for the iPhone.
I assume that you're trying to find the exact derivative of a function. (Symbolic differentiation)
You need to parse the mathematical expression and store the individual operations in the function in a tree structure.
For example, x + sin²(x) would be stored as a + operation, applied to the expression x and a ^ (exponentiation) operation of sin(x) and 2.
You can then recursively differentiate the tree by applying the rules of differentiation to each node. For example, a + node would become the u' + v', and a * node would become uv' + vu'.
you need to remember your calculus. basically you need two things: table of derivatives of basic functions and rules of how to derivate compound expressions (like d(f + g)/dx = df/dx + dg/dx). Then take expressions parser and recursively go other the tree. (http://www.sosmath.com/tables/derivative/derivative.html)
Parse your string into an S-expression (even though this is usually taken in Lisp context, you can do an equivalent thing in pretty much any language), easiest with lex/yacc or equivalent, then write a recursive "derive" function. In OCaml-ish dialect, something like this:
let rec derive var = function
| Const(_) -> Const(0)
| Var(x) -> if x = var then Const(1) else Deriv(Var(x), Var(var))
| Add(x, y) -> Add(derive var x, derive var y)
| Mul(a, b) -> Add(Mul(a, derive var b), Mul(derive var a, b))
...
(If you don't know OCaml syntax - derive is two-parameter recursive function, with first parameter the variable name, and the second being mathched in successive lines; for example, if this parameter is a structure of form Add(x, y), return the structure Add built from two fields, with values of derived x and derived y; and similarly for other cases of what derive might receive as a parameter; _ in the first pattern means "match anything")
After this you might have some clean-up function to tidy up the resultant expression (reducing fractions etc.) but this gets complicated, and is not necessary for derivation itself (i.e. what you get without it is still a correct answer).
When your transformation of the s-exp is done, reconvert the resultant s-exp into string form, again with a recursive function
SLaks already described the procedure for symbolic differentiation. I'd just like to add a few things:
Symbolic math is mostly parsing and tree transformations. ANTLR is a great tool for both. I'd suggest starting with this great book Language implementation patterns
There are open-source programs that do what you want (e.g. Maxima). Dissecting such a program might be interesting, too (but it's probably easier to understand what's going on if you tried to write it yourself, first)
Probably, you also want some kind of simplification for the output. For example, just applying the basic derivative rules to the expression 2 * x would yield 2 + 0*x. This can also be done by tree processing (e.g. by transforming 0 * [...] to 0 and [...] + 0 to [...] and so on)
For what kinds of operations are you wanting to compute a derivative? If you allow trigonometric functions like sine, cosine and tangent, these are probably best stored in a table while others like polynomials may be much easier to do. Are you allowing for functions to have multiple inputs,e.g. f(x,y) rather than just f(x)?
Polynomials in a single variable would be my suggestion and then consider adding in trigonometric, logarithmic, exponential and other advanced functions to compute derivatives which may be harder to do.
Symbolic differentiation over common functions (+, -, *, /, ^, sin, cos, etc.) ignoring regions where the function or its derivative is undefined is easy. What's difficult, perhaps counterintuitively, is simplifying the result afterward.
To do the differentiation, store the operations in a tree (or even just in Polish notation) and make a table of the derivative of each of the elementary operations. Then repeatedly apply the chain rule and the elementary derivatives, together with setting the derivative of a constant to 0. This is fast and easy to implement.
I am building some equations in F#, and when working on my polynomial class I found some odd behavior using List.mapi
Basically, each polynomial has an array, so 3*x^2 + 5*x + 6 would be [|6, 5, 3|] in the array, so, when adding polynomials, if one array is longer than the other, then I just need to append the extra elements to the result, and that is where I ran into a problem.
Later I want to generalize it to not always use a float, but that will be after I get more working.
So, the problem is that I expected List.mapi to return a List not individual elements, but, in order to put the lists together I had to put [] around my use of mapi, and I am curious why that is the case.
This is more complicated than I expected, I thought I should be able to just tell it to make a new List starting at a certain index, but I can't find any function for that.
type Polynomial() =
let mutable coefficients:float [] = Array.empty
member self.Coefficients with get() = coefficients
static member (+) (v1:Polynomial, v2:Polynomial) =
let ret = List.map2(fun c p -> c + p) (List.ofArray v1.Coefficients) (List.ofArray v2.Coefficients)
let a = List.mapi(fun i x -> x)
match v1.Coefficients.Length - v2.Coefficients.Length with
| x when x < 0 ->
ret :: [((List.ofArray v1.Coefficients) |> a)]
| x when x > 0 ->
ret :: [((List.ofArray v2.Coefficients) |> a)]
| _ -> [ret]
I think that a straightforward implementation using lists and recursion would be simpler in this case. An alternative implementation of the Polynomial class might look roughly like this:
// The type is immutable and takes initial list as constructor argument
type Polynomial(coeffs:float list) =
// Local recursive function implementing the addition using lists
let rec add l1 l2 =
match l1, l2 with
| x::xs, y::ys -> (x+y) :: (add xs ys)
| rest, [] | [], rest -> rest
member self.Coefficients = coeffs
static member (+) (v1:Polynomial, v2:Polynomial) =
// Add lists using local function
let newList = add v1.Coefficients v2.Coefficients
// Wrap result into new polynomial
Polynomial(newList)
It is worth noting that you don't really need mutable field in the class, since the + operator creates and returns a new instance of the type, so the type is fully immutable (as you'd usually want in F#).
The nice thing in the add function is that after processing all elements that are available in both lists, you can simply return the tail of the non-empty list as the rest.
If you wanted to implement the same functionality using arrays, then it may be better to use a simple for loop (since arrays are, in principle, imperative, the usual imperative patterns are usually the best option for dealing with them). However, I don't think there is any particular reason for preferring arrays (maybe performance, but that would have to be evaluated later during the development).
As Pavel points out, :: operator appends a single element to the front of a list (see the add function above, which demonstrates that). You could write what you wanted using # which concatenates lists, or using Array.concat (which concatenates a sequence of arrays).
An implementation using higher-order functions and arrays is also possible - the best version I can come up with would look like this:
let add (a1:_[]) (a2:_[]) =
// Add parts where both arrays have elements
let l = min a1.Length a2.Length
let both = Array.map2 (+) a1.[0 .. l-1] a2.[0 .. l-1]
// Take the rest of the longer array
let rest =
if a1.Length > a2.Length
then a1.[l .. a1.Length - 1]
else a2.[l .. a2.Length - 1]
// Concatenate them
Array.concat [ both; rest ]
add [| 6; 5; 3 |] [| 7 |]
This uses slices (e.g. a.[0 .. l]) which give you a part of an array - you can use these to take the parts where both arrays have elements and the remaining part of the longer array.
I think you're misunderstanding what operator :: does. It's not used to concatenate two lists. It's used to prepend a single element to the list. Consequently, it's type is:
'a -> 'a list -> 'a list
In your case, you're giving ret as a first argument, and ret is itself a float list. Consequently, it expects the second argument to be of type float list list - hence why you need to add an extra [] to the second argument to make it to compile - and that will also be the result type of your operator +, which is probably not what you want.
You can use List.concat to concatenate two (or more) lists, but that is inefficient. In your example, I don't see the point of using lists at all - all this converting back & forth is going to be costly. For arrays, you can use Array.append, which is better.
By the way, it's not clear what is the purpose of mapi in your code at all. It's exactly the same as map, except for the index argument, but you're not using it, and your mapping is the identity function, so it's effectively a no-op. What's it about?