yes, feature_select and train endpoints are the same in that they require a “response” field that has the categorical output (strings or ints)…in your case strings denoting which sensor on which device.
Mike
yes, feature_select and train endpoints are the same in that they require a “response” field that has the categorical output (strings or ints)…in your case strings denoting which sensor on which device.
Mike
OK, thanks, that makes sense! In that case, I suggest you update the documentation for feature_select so it (a) mentions the required “response” field, and (b) makes it clear that the other features can be named anything. Documentation is crucial, not just for people to be able to use your service but also (since we don’t have anything else to go by), users will use the documentation’s quality as a way to estimate the quality of the company behind it.
It would also be easier to understand if the examples used more realistic values instead of “A,B,C” so it’s easier to see what we should put in there. You could for example have a running example where we use (say) a light sensor to detect whether the fridge door is open. Perhaps we also have a temperature sensor in there. The example would then become:
"temperature": [42, 42, 42, 43],
"response": ["Closed","Closed","Open","Open"] }```
You may also want to include this input again on the bottom of the page in the Request Example section, so it is complete.