-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incorrect d$FN vector in JM_BR.R #29
Comments
Fixed the issue. But not sure if correct. Changed the floor function to round here : RunModels.R. Can someone explain to me or add comments as to what the if else statement does? The else block is entered only for the JM model and incorrectly calculates the lower_pred_bound to be 136 rather than 137 when the floor function is used. I'll close the bug once this is explained. |
I didn't quite get the part from the first comment
|
Sure, I'll try to explain. d$FN exists in both JM and GO models, an expectation would be that vector is be the same for both models. What I gathered from examining the vector is that it contains the point numbers to be predicted. SYS1 has 136 points, and suppose I want to predict failure times of 8 points after that.
This means d$FN should be [137, 138, 139, ..., 144] for both models. But I found that in the JM model d$FN = [136, 137,..., 143]. This error was cascading into other functions which lead to JM predicting the wrong number of points. Hope that makes sense.
…----- Original Message -----
From: "Karthik Katipally" <notifications@github.com>
To: "LanceFiondella/srt.core" <srt.core@noreply.github.com>
Cc: "vshekar" <vshekar@umassd.edu>, "Author" <author@noreply.github.com>
Sent: Thursday, January 12, 2017 8:36:59 PM
Subject: Re: [LanceFiondella/srt.core] Incorrect d$FN vector in JM_BR.R (#29)
I didn't quite get the part from the first comment
n the JM model specifically this function the d$FN vector seems to be incorrect. For example, dataset SYS1 has 136 points which means d$FN should start from 137 but starts from 136 which is not right.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub , or mute the thread .
|
MVF_Inv function is just the inverse of the data points it receives. So any extra data point or missing data point is purely mistake else where data comes from(And I suspect its run models mishandling the data points). The functions are fine. And I want it to be purely mathematical from 'Model contribution' point of view. So any changes to it will confuse contributors. Also data returned from this function should be handled elsewhere as needed because this is a mathematical modeling file. I hope I am making sense.
The missing data point is clearly the data handling issue prior to calling the |
Let me try with just the rounding part in runModels. I will let you know if any thing is abnormal. |
You are right, RunModels is mishandling the data which was what my 2nd comment in this thread talks about. The extra logic to replace Nan values was to keep everything else from breaking, which I had added before raising this issue: #28. In the issue I mentioned that we can remove the logic once I figure out what RunModels does. |
Regarding #28: Sorry I was busy then. |
Shekar can you point me to the bug or commit you fixed by using |
There was no specific issue raised for it as far as I know. But if you asked the model to predict more points than it can and tried to plot it, it would show an error on the browser. You can probably recreate it by removing the max logic and set the finite model param to False. The commit is this one: f1226d9 |
In the JM model specifically this function the d$FN vector seems to be incorrect. For example, dataset SYS1 has 136 points which means d$FN should start from 137 but starts from 136 which is not right.
A corresponding function in GO model also uses the same variable and correctly starts from 137 for SYS1.
This has lead to the incorrect calculation of the number of predictions the model can make. JM makes 1 more prediction than it's supposed to.
The text was updated successfully, but these errors were encountered: