- changed status to open
numpy arrays shouldn't be expandable inside model browser
Given a numpy array inside the model (*.pkl file) browser:
Do not allow to expand that node, because it gives no further information but only clutters the screen with redundant data (e.g. the transpose T) that isn’t of any use for the user:
Comments (23)
-
-
the screen-space issue is resolved with
#646
I don't thinks it’s a good idea making assumptions on what is of use for other users or not. Node fetching is generic, so users should decide self what they like to see here. -
reporter Yes, node fetching is generic, but for one of our most important data type (i.e. numpy.ndarray) we should go the extra mile and make it actually useful for the user. Almost everything from the screenshot above is useless information.
If you really want to make an ndarray node expandable, which is not needed in my opinion, you should do it more like PyCharm, which does it really nice!
If that is to complicated, just do not allow to expand ndarray nodes.
-
The screenshot is pretty outdated, please merge my latest commits (e.g. on
#646) and close this issue, if appropriate. Array value are no printed in one-line only and transposed arrays look like:
-
reporter Having everything in one line looks much better, cool!
But please do not allow to expand the ndarray node. This makes no sense. This browser is for normal users that want to find usefull information, like the feature_importance array of an RF. After the user reaches the actual array values, we should not allow him to go deeper:
This is what a user wants:Advanced user maybe also want this:
-
reporter Let’s discuss this with SL and FT.
-
reporter @Benjamin Jakimow as discussed today, the current ndarray-view needs to be improved.
As a minimal improvement: just present the array data as nested list (nesting level equals the array’s number of dimensions) of values.
Optimal improvement: just steal from PyCharm:
-
In a nested list we lose such information like min and max etc.
-
- changed status to resolved
resolves
#648→ <<cset edca60943775>>
-
reporter Not working for me
-
reporter - changed status to open
-
That’s obviously an unpickling error. Can you run
pickle.load('your file')
? -
isHubflow throws descriptive error message in case of corrupted *.pkl files (addresses
#648)Signed-off-by: Benjamin Jakimow benjamin.jakimow@geo.hu-berlin.de benjamin.jakimow@geo.hu-berlin.de
→ <<cset 095f0e5d107c>>
-
Now arrays look like:
In case you don’t have a valid *.pkl file, you might use
enmapboxtesting\test_datasources.pytest_hubflowtypes
-
- changed status to resolved
-
addresses
#648Signed-off-by: Benjamin Jakimow benjamin.jakimow@geo.hu-berlin.de benjamin.jakimow@geo.hu-berlin.de
→ <<cset cd8ab0b619ec>>
-
reporter No, still not working. In my pickle file, I only have a dictionary with some arrays, list, and a scikit-learn classifier object. No special classes. So unpickling shouldn’t be a problem.
I guess the isHubFlowObj function causes the problem? Maybe it is restricting the pickle content to old hubFlow objects?Remember that in the next release a pickle file can contain anything!
Some days ago, the DataSources panal was able to explore the exact same pkl file. So I guess you cahnged something!?
-
reporter - attached classifier.pkl
-
reporter Please check that pkl file. This is the new format.
-
reporter - changed status to open
-
reporter BTW - from your screenshot, array display looks good now!
-
reporter Oh, wait, maybe the PKL is corrupted
-
reporter - changed status to closed
pkl creation code was buggy after a rebase of the feature branch, I guess this was the problem
- Log in to comment
relates to
#646