How to control the operation process of "Partition" module in JMP "decision tree" according to the specified "date" condition in actual data?See attachment and screenshot for specific data and operation steps.

My purpose is to use the segmentation module of JMP to calculate the prediction formula. Firstly, the prediction formula is processed by "date", and only one average value is obtained for the same date. Then, the prediction formula is used to average the unique average value of different dates to calculate the prediction value of this formula.
Thanks!
Re: How to control the operation process of "Partition" module in JMP "decision tree" according to the specified "date" condition in actual data?I found my description verbose and didn't know if I had made the problem clear.Please give me advice and help from an experienced expert.Thank you very much!
Re: How to control the operation process of "Partition" module in JMP "decision tree" according to the specified "date" condition in actual data?For example, if this Leaf label formula in A certain "date", there are many code's "actual" is very large, but in other "date" in line with this Leaf label formula "code" is not many, and "actual" is not good, but according to JMP now is to carry out all the "code" of average calculation, this predictor value is also good
But if according to this Leaf label formula, different "code" of the same "date" to the "date" of the average calculation, which makes this Leaf label formula makes an "actual" each "date", the last in A different "date" to indicate the formula of the average forecast, one way to check, after JMP get better forecast formula of the check result often is not good.
(I would like to make a note here: In order to verify whether JMP already has this feature, I also tried to use the "date" factor as a "freq" option button parameter, but the effect did not meet my requirements.)

Re: How to control the operation process of "Partition" module in JMP "decision tree" according to the specified "date" condition in actual data?According to each "code" object in the graph file, different index data (X factor) will be generated on different "date", and "actual" a will be generated(Y Response).
Using the "Partition" module of JMP, taking "actual" as the Y Response and "M-BY" as the X factor, and using "training, verification and test" to find out the X factor that is highly correlated with "actual".
And use the "Partition" function to save the predictor value and Leaf label formula.
In this way, JMP can generate better prediction value and Leaf label formula(Setting: The "actual" larger the value, is the better).
But many times the Leaf label formula with a high predictor value will not work best when tested:
I have tested A lot of such data and found that JMP only averages all "actual" that conform to this Leaf label formula without further classification of the "date" factor.
Re: JMP is Not a SpreadsheetOk, I will write another topic, thank markbailey!Re: JMP is Not a SpreadsheetMy purpose for this discussion was to help users, especially new users, approach JMP as it is and not as a spreadsheet It seems to me that a lot of frustration arises from spreadsheet users attempting to solve problems and analyze data with JMP as if it were a spreadsheet, which it is not..
Your points about Partition are valid but perhaps you should have started a new discussion to address them or submit your desires to the Wish List area instead of this discussions where they are off the topic.
Re: JMP is Not a SpreadsheetJMP global Discussions is a good learning platform, where I learn a lot of JMP skills, I prefer to study here.
Thanks!Re: JMP is Not a Spreadsheet
Re: JMP is Not a SpreadsheetIt seems that there are specific data to better explain, I add data to upload.
Re: JMP is Not a SpreadsheetHi @lwx228 Thanks for contributing here: me being a relative novice to the use of classification trees (or regression trees), I found your problem statement and elaboration of your solution very hard to follow. Maybe if you cannot share your own personal dataset, you can make a dummy datastet which shows the defficiency you are aluding to and points specifically again to your questions? this would be great for me and others on the community as a shared learning opportunity!
Secondly, it looks like from your screen shots that you have JMP Pro (but an older version): I know that the newer versions of Pro have more advanced and flexible algorithms based on boostine and neural-network based algorithms (bootstrap forest and boosted tree). These will undoubtedly give you a better fitting model.
Re: JMP is Not a SpreadsheetI found my description verbose and didn't know if I had made the problem clear.
My purpose is to use the segmentation module of JMP to calculate the prediction formula. Firstly, the prediction formula is processed by "date", and only one average value is obtained for the same date. Then, the prediction formula is used to average the unique average value of different dates to calculate the prediction value of this formula.
Thanks!
Re: JMP is Not a SpreadsheetBut if according to this Leaf label formula, different "code" of the same "date" to the "date" of the average calculation, which makes this Leaf label formula makes an "actual" each "date", the last in A different "date" to indicate the formula of the average forecast, one way to check, after JMP get better forecast formula of the check result often is not good.
(I would like to make a note here: In order to verify whether JMP already has this feature, I also tried to use the "date" factor as a "freq" option button parameter, but the effect did not meet my requirements.)

Re: JMP is Not a SpreadsheetBut many times the Leaf label formula with a high predictor value will not work best when tested:
I have tested A lot of such data and found that JMP only averages all "actual" that conform to this Leaf label formula without further classification of the "date" factor.
For example, if this Leaf label formula in A certain "date", there are many code's "actual" is very large, but in other "date" in line with this Leaf label formula "code" is not many, and "actual" is not good, but according to JMP now is to carry out all the "code" of average calculation, this predictor value is also good.
Re: JMP is Not a SpreadsheetThank markbailey for giving me the opportunity to bring this up.
According to each "code" object in the graph file, different index data (X factor) will be generated on different "date", and "actual" a will be generated(Y Response).
Using the "Partition" module of JMP, taking "actual" as the Y Response and "M-BY" as the X factor, and using "training, verification and test" to find out the X factor that is highly correlated with "actual".
And use the "Partition" function to save the predictor value and Leaf label formula.
In this way, JMP can generate better prediction value and Leaf label formula(Setting: The "actual" larger the value, is the better).

Re: JMP is Not a SpreadsheetAnother resource for submitting ideas is to give your JMP sales team's systems engineer a call or email with what you think your improvement should be. Reason I suggest this is I was once a JMP sales systems engineer and quite often I'd get just such a call and lo and behold JMP might just be able to 'do' what you seek. You just don't know it! That's one of the very cool capabilities of being a JMP user vs. a generic spreadsheet application...you have a world class team of support from SAS and the JMP division ready to assist!
Re: JMP is Not a SpreadsheetYou can submit suggestions and requests here.
Re: JMP is Not a SpreadsheetI've been using JMP as a quantification tool.
The one I use the most is its "decision tree"-"Partition" module.
In the process of using JMP, I also found that the "decision tree"-"Partition" function of JMP needs to be improved, but I don't know how to feedback my own ideas to JMP company?Make improvements to related functions.
Thanks!