I have a sequence generated by list comprehension as follows:
var a_bigram_list = lc[a[i..i+2] | (i <- 0..<len(a)), string]
Now, I would like to sort it but sort(a_bigram_list) will result in the following compilation error
Error: type mismatch: got (seq[string])
but expected one of:
proc sort[A, B](t: OrderedTableRef[A, B]; cmp: proc (x, y: (A, B)): int)
proc sort[A, B](t: var OrderedTable[A, B]; cmp: proc (x, y: (A, B)): int)
proc sort[A](t: CountTableRef[A])
proc sort[A](t: var CountTable[A])
proc sort[T](a: var openArray[T]; cmp: proc (x, y: T): int; order = SortOrder.Ascending)
Is there any way of sorting a sequence? Or do I need to convert it to array? If so, can is there a way to obtain an array from lc?
sort works with sequences (openArray is a generic parameter type that accepts both arrays and seqs), but it expects a comparison proc as a second parameter.
You can provide it a default cmp from system module:
sort(a_bigram_list, system.cmp)
Related
I've got a library which implements a set (interface with documentation available here: http://pastebin.com/j9QUyN1G). I understand everything apart from this fragment:
val iter : ('a -> unit) -> 'a t -> unit
(** [iter f s] applies [f] to all elements in set [s]. The elements
are passed to [f] in increasing order with respect to the ordering
used to create the set. *)
So iter takes a function as one of the arguements and applies it to all elements of set. So I would expect something like ('a -> 'a) which takes an element of the set and changes it to element of the same type with other value or ('a -> 'b) which takes 'a t and transforms it to 'b t. But instead iter takes a function of type ('a -> unit) and also returns unit, not an 'a t nor 'b t.
So how should an example function passed to iter look like?
iter doesn't change the elements of the set. It's executed purely for its side effects. You might use it to print the elements, for example:
module StringSet = Set.Make(String)
…
StringSet.iter print_endline ss
The set data structure is immutable, so you can't change the elements of the set. You can build a new set whose elements are derived from an existing set. For a list, there's the function map which takes a list [x1; …; xn] and returns a new list [f x1; …; f xn]. There is no similar function in the Set module because elements in a set are not stored in the order chosen by the caller: there's no such thing as a set with its elements in an order derived from another set. If you want to build a set from the images of the elements of a set, insert the new elements one by one.
module Int = struct
type t = int
let compare = Pervasives.compare
end
module IntSet = Set.Make(Int)
module StringSet = Set.Make(String)
let int_to_string_set is =
IntSet.fold (fun i ss -> StringSet.add (string_of_int i) ss) is StringSet.empty
iter takes such function that accepts argument of type 'a do with it whatever it whats and returns a value of type unit. In other words it is evaluated for the side-effects since it can't return anything worthwhile.
What you're looking for is a map function, that usually accepts a function of type 'a -> 'b a container with elements of type 'a and returns an container with elements of type 'b. Unfortunately to you, the interface you've shown, doesn't provide such function. But this is not a problem, since it provides a fold function, that is the most general iterator. Having only fold you can implement any other iteratos, like map, iter, exists, etc... Indeed in Core library you can find Container.Make functor that will automatically derive a common container interface from only one function - fold. But also, you can define map by yourself:
let map f xs =
fold (fun x ys -> add (f x) ys) xs empty
It would be a function with side effects, like this:
Let p x = Printf.printf "%d\n" x
I want the common name of a higher order function that applies a list of functions onto a single argument.
In this sense it is a converse of map. map takes a function and a list of arguments and applies that function to the entire list. In Python it might look like this
map = lambda fn, args: [fn(arg) for arg in args]
I'm thinking of the function that does the same but has the alternate argument as a list type
??? = lambda fns, arg: [fn(arg) for fn in fns]
I suspect that this function exists and has a common name. What is it?
Actually, what you describe is not the converse of map, but just map applied in another way. Consider, e.g.,
map(lambda f: f(2), [lambda x: x + 1, lambda x: x, lambda x: x * x])
which in effect applies three functions (plus 1, identity, and squaring) to the argument 2. So what you wanted is just
alt_map = lambda x, fns: map(lambda f: f(x), fns)
which is still an ordinary map.
I'm trying to write a program that loads 2 text files, converts the numbers in those files into 2 lists, and then calculates the pearson correletion between those lists.
The pearson function can only take floats, so I made a function called floatconvert to try to fix this problem, but it hasn't. I get an error saying "Couldn't match expected type 'IO b0' with actual type 'Float.' In the first argument of 'pearson', namely 'input1.'"
Any help with fixing this problem would be greatly appreciated.
main = do
input1file <- readFile "input1.txt"
input2file <- readFile "input2.txt"
let input1 = floatconvert input1file
let input2 = floatconvert input2file
pearson input1 input2
floatconvert x = [ read a::Float | a <- words x ]
pearson xs ys = (psum-(sumX*sumY/n))/(sqrt((sumXsq-(sumX**2/n)) * (sumYsq-(sumY**2/n))))
where
n = fromIntegral (length xs)
sumX = sum xs
sumY = sum ys
sumXsq = sum([ valX*valX | valX <- xs ])
sumYsq = sum([ valY*valY | valY <- ys ])
psum = sum([ fst val * snd val | val <- zip xs ys ])
The error message is somewhat misleading in this case. The real problem is that pearson does not return IO something. If you meant to print the result, write
main = do
...
print $ pearson input1 input2
The reason for GHC's confusion here is that the inferred type of pearson is
pearson :: Floating a => [a] -> [a] -> a
so when you try to use it as a statement in the do-block, it infers from the return type that a ~ IO b and therefore the arguments must have type [IO b]. However, it already knows that they have type [Float] so you get a confusing error message about it being unable to match Float with IO b in the argument when the source of the problem is the return type.
I second Dave's advice about adding type signatures to your functions. It can make error messages more helpful. For example, if you had given pearson the type signature pearson :: [Float] -> [Float] -> Float, you would have gotten this message:
Pearson.hs:8:5:
Couldn't match expected type `IO b0' with actual type `Float'
In the return type of a call of `pearson'
In a stmt of a 'do' block: pearson input1 input2
while working on a project I accidentally noticed that the same method with only one additional (unused) argument manages to run even ten times faster than the other one, with optimizations enabled.
type Stream () =
static member private write (x, o, a : byte[]) = (for i = 0 to 3 do a.[o + i] <- byte((x >>> 24 - i * 8) % 256)); 4
static member private format f x l = Array.zeroCreate l |> fun a -> (f(x, 0, a) |> ignore; a)
static member private format1 f x l o = Array.zeroCreate l |> fun a -> (f(x, 0, a) |> ignore; a)
static member Format (value : int) = Stream.format (fun (x: int, i, a) -> Stream.write(x, i, a)) value 4
static member Format1 (value : int) = Stream.format1 (fun (x: int, i, a) -> Stream.write(x, i, a)) value 4
When tested, Stream.Format1 runs much faster than Stream.Format, although the only difference between the private members Stream.format and Stream.format1 is just the o argument, which moreover is unused by the method itself.
How does the compiler treat in so different ways two almost identical methods?
EDIT: thanks for the explanation and sorry for the ignorance.
The problem is that when you call Format1 with just a single argument, it only returns a function. It doesn't do the actual formatting yet. This means that if you compare the performance of:
Stream.Format 42
Stream.Format1 42
... then you're actually comparing the performance of actual formatting (that creates the array and writes something in it) in the first case and the performance of code that simply returns a function value without doing anything.
If you're not using the o parameter of format1 for anything, then you can just pass in some dummy value, to actually evaluate the function and get the result. Then you should get similar performance:
Stream.Format 42
Stream.Format1 42 ()
Format actually invokes Array.zeroCreate l |> fun a -> (f(x, 0, a) |> ignore; a).
Format1 returns a function that when passed an object invokes Array.zeroCreate l |> fun a -> (f(x, 0, a) |> ignore; a).
I.e., one does actual work, the other is merely a partial function application; the latter is obviously quicker.
If you're not familiar with partial function application, there is a section in the F# docs titled 'Partial Application of Arguments' that's worth reading over: Functions (F#)
If you define a While method of the builder-object, you can use while-loops in your computation expressions. The signature of the While method is:
member b.While (predicate:unit->bool, body:M<'a>) : M<'a>
For comparison, the signature of the For method is:
member b.For (items:seq<'a>, body:unit->M<'a>) : M<'a>
You should notice that, in the While-method, the body is a simple type, and not a function as in the For method.
You can embed some other statements, like let and function-calls inside your computation-expressions, but those can impossibly execute in a while-loop more than once.
builder {
while foo() do
printfn "step"
yield bar()
}
Why is the while-loop not executed more than once, but merely repeated? Why the significant difference from for-loops? Better yet, is there some intended strategy for using while-loops in computation-expressions?
If you look at how computation expressions are evaluated, you'll see that
while foo() do
printfn "step"
yield bar()
is translated to something like
builder.While(fun () -> foo(),
builder.Delay(fun () ->
printfn "step"
builder.Yield(bar()))))
This translation allows the body of the while loop to be evaluated multiple times. While your type signatures are accurate for some computation expressions (such as seq or async), note that the insertion of the call to Delay may result in a different signature. For instance, you could define a list builder like this:
type ListBuilder() =
member x.Delay f = f
member x.While(f, l) = if f() then l() # (x.While(f, l)) else []
member x.Yield(i) = [i]
member x.Combine(l1,l2) = l1 # l2()
member x.Zero() = []
member x.Run f = f()
let list = ListBuilder()
Now you can evaluate an expression like:
list {
let x = ref 0
while !x < 10 do
yield !x
x := !x + 1
}
to get the equivalent of [0 .. 9].
Here, our While method has the signature (unit -> bool) * (unit -> 'a list) -> 'a list, rather than (unit -> bool) * 'a list -> 'a list. In general, when the Delay operation has type (unit -> M<'a>) -> D<M<'a>>, the While method's signature will be (unit -> bool) * D<M<'a>> -> M<'a>.