Thanx for going through this long-Q and your help is plenty appreciated.
So, the situation is that I have a piece of FSharp code contained in a module with modules nested in and there is a CSharp code that calls a method from a public type within one of these nested modules. Please see the code below:
namespace MachineLearning.Predictions
// refrences to other namespaces/modules
module Sample =
// so this is set at compile
let cons1 = MachinLearning.Example.Calc.comp(something)
module MulRegression =
// this too is set at compile
let cons2 = MachinLearning.Example.Calc.comp(something)
// other code
type public OPrediction() =
// this runs ok and gets the resulting value
let valu0 =
MachinLearning.Example.Calc.comp(something)
let valu1 = cons2 // debugger jumps out as if no cons2 exist
member this.OPred(atp) =
// a bunch of values, functions, etc, from other modules
module LogRegression =
// other code
type public CPrediction() =
member this.CPred(atp) =
// a bunch of values, functions, etc, from other modules
First, Required namespaces are opened by using NamespacePath;" modules are opened by “using static ModulePath;” and the whole solution builds without any problems. The FSharp code on its own generates the required results within FSharp environment (FSI, call from another FSharp code). Now, the issue occurs with CSharp code calling methods prediction.CPred(inp) in module MachineLearning.Predictions.LogRegression and method OPrediction.OPred(inp) in module MachineLearning.Predictions.MulRegression. If I assign a known-value (e.g., inp, inp + 7, or 2) as the return-value of the methods, everything is fine. With the body intact, as soon as the body hits the first line with some value from outside the scope of the method (say, let len = pidz.Length), the execution simply jumps out. There are no errors, no nothing, it jumps out with no return value!!!
//------------------------------------------------------------
// FSharp test script runs perfectly and produces the results.
//------------------------------------------------------------
// #load directives
module Test1 =
// open statements
let op = OPrediction()
let res = op.OPred(717)
do printfn "%A" res
module Test2 =
// open statements
let cp = CPrediction()
let res = cp.CPred(800.)
do printfn "%A" res
//------------------------------------------------------------
// CSharp calling method does not return anything.
//------------------------------------------------------------
// GET: ODetails/OPredict/1
public Int32 OPredict(int id) {
var op = new OPrediction(); // so far, A-OK!
// 1) OPred(id) is defined like OPred(id) = 2. then result is produced.
// 2) OPred keeps its def, then when 'stepping-in', the first line
// involving other than 'id' or constant, debugger jumps out to
// get the next item in queue and the story repeats.
var res = (Int32)op.OPred(id);
return res;
}
// GET: CDetails/CPredict/1
public Int32 CPredict(double point) {
var cp = new CPrediction();
var res = (Int32)cp.CPred(point);
return res;
}
UPDATE 1: After a day of … : For me it has gotten just more wierd. Within the scope of type OPrediction, it is as if the debugger does not recognise any of values and identifiers defined using stuff from other namespaces/modules in the top Namespace MachineLearning.Predictions nor any of the nested modules including the module that contains the type itself. On the other hand, the debugger seems to recognise the values set using a direct call to said fuction within the body of the type.
UPDATE 2: After inspecting the whole damn thing piece-by-piece throug FSI:
0) The issue was a runtime-thing. Whether the method was called from Program.fs or from CSharp, the problem persisted. It is wierd that I do not encounter the issue when running the code as a script.
1) The problem was specifically with the bluemountaincapital Deedle dataframe and conversion to float, in an expression involving Array.Parallel.map.
2) I am not certain whether the problem was with accessing a dataframe’s rows in parallel or conversion of dataframe columns to float. Just to be safe, I fixed both by explicitly converting each column of dataframe to float and reconstructing the result into a new frame, and taking a lengthier and less-elegant non-parallel path, and now the code runs without a hitch - so far.