You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We need foreign predictors to be "elevated" to the status of GPMs to eliminate the asymmetry between the probabilistic objects in the MML and BQL universe. To be standalone GPMs, we need a better notion of typed-inputs and typed-outputs for a GPM, and communicate this information between MML and BQL.
In particular, a Kepler GPM should have apogee, perigee as inputs and period as output. On its own (ie no composition with crosscat), Kepler GPM cannot answer the BQL query SIMULATE period GIVEN apogee since it has missing condition. It seems to be that reasonable behavior is to thrown an error, since the BQL query is invalid (just like invoking a function with the wrong number of arguments).
As of now, we have three foreign predictors
Kepler
Multiple regression
Random forest
I believe the best solution is to create a generic "foreign predictor to gpm" wrapper, which will save users from the big overhead of implementing the feared metamodel.py and just implement the much simpler IForeignPredictor in python. The composer will then be written to invoke the GPM interface on the output of the FP->GPM wrapper, thus eliminating the asymmetry in the abstraction.
The text was updated successfully, but these errors were encountered:
We need
foreign predictors
to be "elevated" to the status ofGPMs
to eliminate the asymmetry between the probabilistic objects in the MML and BQL universe. To be standalone GPMs, we need a better notion oftyped-inputs
andtyped-outputs
for a GPM, and communicate this information between MML and BQL.In particular, a Kepler GPM should have
apogee, perigee
as inputs andperiod
as output. On its own (ie no composition with crosscat), Kepler GPM cannot answer the BQL querySIMULATE period GIVEN apogee
since it has missing condition. It seems to be that reasonable behavior is to thrown an error, since the BQL query is invalid (just like invoking a function with the wrong number of arguments).As of now, we have three foreign predictors
I believe the best solution is to create a generic "foreign predictor to gpm" wrapper, which will save users from the big overhead of implementing the feared
metamodel.py
and just implement the much simplerIForeignPredictor
in python. The composer will then be written to invoke the GPM interface on the output of the FP->GPM wrapper, thus eliminating the asymmetry in the abstraction.The text was updated successfully, but these errors were encountered: