How can we find the square root of a number in F#? Do we have a Sqrt function in F# just like we have Math.Sqrt() function in Java? I am a beginner in F# and couldn't find any significant help on the internet.
F# already has a sqrt function defined, so you should just be able to use:
sqrt x
where x is the value you wish to find the root of.
Yes, F# comes with a "sqrt" function. Called "sqrt" :)
http://blogs.msdn.com/b/dsyme/archive/2008/09/01/the-f-operators-and-basic-functions.aspx
Many more numerical libraries are available for F#, either open source (e.g. CodePlex) or from 3rd party vendors:
http://msdn.microsoft.com/en-us/library/vstudio/hh304372%28v=vs.100%29.aspx
Related
I just ran across
http://frankniemeyer.blogspot.com/2010/04/minimalistic-native-64-bit-array.html
Which contains the line
(# "sizeof !0" type('T) : nativeint #)
I believe the technical phrase is "what the heck?" I have never in my (~8 months) of F# programming run across something even resembling that...
FSI tells me something about deprecated constructs, used only for F# libs...
And google with (# does uh...well, not much
Any direction in this?
This is the notation for inline IL emission. It used to be a more prominent feature during F#'s earlier years, but has been deprecated. A gentleman named Brian from the F# team has indicated that it is currently used mainly to bootstrap the F# compiler, and that the team had intended to mark this construct as an error, not merely a warning.
See his post here for the full story.
It's inline IL (intermediate language) code. This construct is used internally by the F# team to implement bits of the F# core library you just can't do any other way. This code will admit a warning saying it shouldn't be used any where other than the F# core libraries, so you probably don't have to worry about it too much as it should never appear in production code.
Fascinating. But I think F# already gives us the conversion operations (for this particular operation!) you need without resorting to IL.
[<Unverifiable>]
let inline ArrayOffset (itemSize:int64) (length:int64) (start:int64) (idx:int64) =
if idx < 0L || idx >= length then raise(IndexOutOfRangeException())
NativePtr.ofNativeInt(nativeint(start + (idx * itemSize)))
There is need for tracing. The decorator should print function name, parameters values and return value. Instead of writing each time a decorator for each function, it would be terrific if it could be possible to do this programmatically.
The current function name can be discovered using reflection via MethodBase.GetCurrentMethod. Functions could be easily decorated with an inline function for logging:
let inline log args f =
let mi = System.Reflection.MethodBase.GetCurrentMethod()
let result = f ()
printf "%s %A -> %A" mi.Name args result
let add a b = log (a,b) (fun () -> a + b)
add 1 1
Which prints: add (1, 1) -> 2
EDIT: Another option would be to create a wrap function, i.e.:
let inline wrap f =
fun ps ->
let result = f args
printfn "%A -> %A" args result
result
let add (a,b) = a + b
wrap add (1,1)
However in this case there is not an easy way to programmatically retrieve the function name.
Yet another option might be to develop a Type Provider that takes an assembly path as a parameter and provides wrapped versions of all members.
I had the same desire previously and found that there are no current automated solutions for F#.
See: Converting OCaml to F#: Is there a simple way to simulate OCaml top-level #trace in F#
While OCaml's trace facility with time travel is the most useful debugging feature of comparison to what is desired, it is not an exact fit; but when I use OCaml it is the first inspection tool I use.
See: Using PostSharp with F# - Need documentation with working example
Also the suggestion of using AOP, i.e. PostSharp, was another good suggestion, as the response from Gael Fraiteur, the Principal Engineer of PostSharp points out:
PostSharp does not officially support F#.
Other than using reflection as suggested by Phillip Trelford, which I have not tried, the best solution I have found is to manually modify each function to be traced as I noted in Converting OCaml to F#: Is there a simple way to simulate OCaml top-level #trace in F# and save the results to a separate log file using NLog.
See: Using NLog with F# Interactive in Visual Studio - Need documentation
Another route to pursue would be check out the work of F# on Mono as there is a lot of work being done there to add extra tooling for use with F#.
Basically what I have found is that as my F# skills increase my need
to use a debugger or tracing decrease.
At present when I do run into a problem needing this level of inspection, adding the inspection code as noted in Converting OCaml to F#: Is there a simple way to simulate OCaml top-level #trace in F# helps to resolve my misunderstanding.
Also of note is that people who come from the C# world to the F# world tend to expect a debugger to be just as useful. Remember that imperative languages tend to be about manipulating data held in variables and that the debugger is used to inspect the values in these variables, while with functional programming, at least for me, I try to avoid mutable values and so the only values one needs to inspect are the values being passed to the function and no other values, thus reducing or obviating the need for a debugger or inspection beyond that of the function of question.
Reading sources of Array2D module, I've stumbled upon this interesting construct in implementation of many core functions, for example:
[<CompiledName("Get")>]
let get (array: 'T[,]) (n:int) (m:int) = (# "ldelem.multi 2 !0" type ('T) array n m : 'T #)
I can only assume that this is the syntax to inline CIL and is used here obviously to gain performance benefits. However, when I've tried to use this syntax in my program, I get an error:
warning FS0042: This construct is deprecated: it is only for use in the F# library
What exactly is this? Is there any detailed documentation?
I think that this has 2 purposes:
These functions compile down to exactly 1 CIL instruction which has to be encoded somewhere, so encoding at the source seems best.
It allows for some extra trickery with defining polymorphic Add functions in a high performance way which is hard with the F# type system.
You can actually use this but you have to specify the --compiling-fslib (undocumented) and --standalone flags in your code.
I've found some details in usenet archives: http://osdir.com/ml/lang.fsharp.general/2008-01/msg00009.html
Embedded IL in F# codes. Is this feature officially supported
Not really. The 99.9% purpose of this feature is for operations defined
in FSharp.Core.dll (called fslib.dll in 1.9.2.9 and before).
Historically it has been useful to allow end-users to embed IL in order
to access .NET IL functionality not accessible by F# library or
language constructs using their own embedded IL. The need for this is
becoming much more rare, indeed almost non-existent, now that the F#
library has matured a bit more. We expect this to continue to be the
case. It's even possible that we will make this a library-only feature
in the "product" version of F#, though we have not yet made a final
decision in this regard.
This was a message from Don Syme, dated January of 2008.
I'm following a language called 'elm' which is an attempt to bring a Haskel-esque syntax and FRP to Javascript. There has been some discussion here about implementing the pipeline operator from F# but the language designer has concerns about the increased cost (I assume in increased compilation time or compiler implementation complexity) over the more standard (in other FP langs at least) reverse pipeline operator (which elm already implements). Can anyone speak to this? [Feel free to post directly to that thread as well or I will paste back the best answers if no one else does].
https://groups.google.com/forum/?fromgroups=#!topic/elm-discuss/Kt0MbDyRpO4
Thanks!
In the discussion you reference, I see Evan poses two challenges:
Show me some F# project that uses it
Find some credible F# programmer talking about why it is a good idea and what costs come with it (blog post or something).
I'd answer as follows:
The forward pipe-idiom is very common in F# programming, both for stylistic (we like it) and practical (it helps type inference) reasons. Just about any F# project you'll find will use it frequently. Certainly all of my open source projects use it (Unquote, FsEye, NL found here). No doubt you'll find the same with all of the Github located F# projects including the F# compiler source itself.
Brian, a developer on the F# compiler team at Microsoft, blogged about Pipelining in F# back in 2008, a still very interesting and relevant blog which relates F# pipes to POSIX pipes. In my own estimation, there is very little cost to implementing a pipe operator. In the F# compiler, this is certainly true in every sense (it's a one-line, inline function definition).
The pipeline operator is actually incredibly simple - here is the standard definition
let inline (|>) a b = b a
Also, the . operator discussed in the thread is the reverse pipe operator in F# (<|) which enables you to eliminate some brackets.
I don't think adding pipeline operators would have a significant impact on complexity
In addition to the excellent answers already given here, I'd like to add a couple more points.
Firstly, one of the reasons why the pipeline operator is common in F# is that it helps to circumvent a shortcoming the way type inference is currently done. Specifically, if you apply an aggregate operation with a lambda function that uses OOP to a collection type inference will typically fail. For example:
Seq.map (fun z -> z.Real) zs
This fails because F# does not yet know the type of z when it encounters the property Real so it refuses to compile this code. The idiomatic fix is to use the pipeline operator:
xs |> Seq.map (fun z -> z.Real)
This is strictly uglier (IMO) but it works.
Secondly, the F# pipe operator is nice to a point but you cannot currently get the inferred type of an intermediate result. For example:
x
|> h
|> g
|> f
If there is a type error at f then the programmer will want to know the type of the value being fed into f in case the problem was actually with h or g but this is not currently possible in Visual Studio. Ironically, this was easy in OCaml with the Tuareg mode for Emacs because you could get the inferred type of any subexpression, not just an identifier.
I just ran across
http://frankniemeyer.blogspot.com/2010/04/minimalistic-native-64-bit-array.html
Which contains the line
(# "sizeof !0" type('T) : nativeint #)
I believe the technical phrase is "what the heck?" I have never in my (~8 months) of F# programming run across something even resembling that...
FSI tells me something about deprecated constructs, used only for F# libs...
And google with (# does uh...well, not much
Any direction in this?
This is the notation for inline IL emission. It used to be a more prominent feature during F#'s earlier years, but has been deprecated. A gentleman named Brian from the F# team has indicated that it is currently used mainly to bootstrap the F# compiler, and that the team had intended to mark this construct as an error, not merely a warning.
See his post here for the full story.
It's inline IL (intermediate language) code. This construct is used internally by the F# team to implement bits of the F# core library you just can't do any other way. This code will admit a warning saying it shouldn't be used any where other than the F# core libraries, so you probably don't have to worry about it too much as it should never appear in production code.
Fascinating. But I think F# already gives us the conversion operations (for this particular operation!) you need without resorting to IL.
[<Unverifiable>]
let inline ArrayOffset (itemSize:int64) (length:int64) (start:int64) (idx:int64) =
if idx < 0L || idx >= length then raise(IndexOutOfRangeException())
NativePtr.ofNativeInt(nativeint(start + (idx * itemSize)))