Skip to content
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

Types troubles #32

Open
GurovNik opened this issue Aug 25, 2019 · 0 comments
Open

Types troubles #32

GurovNik opened this issue Aug 25, 2019 · 0 comments

Comments

@GurovNik
Copy link
Contributor

GurovNik commented Aug 25, 2019

Here is a place for real troubles.
Screenshot 2019-08-25 at 19 12 38
At 1 we set the type first time. At 2 - the second time. At 3 there is the craziest thing. For different types, we should define variables of different names.
Example:
float_val = val
int_val = val

The function should have one variable name for all cases. That is the fundamental thing for comfortable usage of the framework.
More exciting is that:
int_val = val
int64_val = val

are different things.
More specifically:
tensor = hs.TensorProto(dtype=hs.DT_FLOAT, tensor_shape=tensor_shape, int_val=val.flatten())
tensor = hs.TensorProto(dtype=hs.DT_FLOAT, tensor_shape=tensor_shape, int64_val=val.flatten())

One of the lines is valid and second is not depending on the situation. End there is no hints that the problem is here.
The main issue - having all these things in the mind during DS developing is very painful. Especially when logs have no hints on the cause of the problem. Of course, there is documentation. But from my point of view service should be intuitive. Looking through documentation each time user deploy a model is a bad user exp.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant