We have thought very carefully when introducing type-erasures, including
considering the concerns you raised, and never-the-less have made the
decision
that resulted in the current design, which strikes the balance of
type-erasure and typing.
The original intention of the current design is to
Another data point. While working with a contributor, he/she is asking
to get access to the graph and values of the NDArray (me too) to be
able to reason more effectively about an enhacements to the operators:
https://github.com/apache/incubator-mxnet/pull/15120
I think gathering in the wiki
> Re that particular case.
>
> The shape of vector will be typed after being fetched and won’t affect the
> general effort for programming. Getting the shape vector out contains
> around one line of code.
>
> The str to any map is defined to enable future compatibility of the
> general set of
To put a recent specific example and focus the discussion (there are
many as there are attributes), the shapes in the graph are a vector of
Shape set as an attribute using dmlc::any so this makes it very
difficult to debug the shapes when you have a graph object. I would
have it as a typed
Thanks for the good discussion.
I actually wasn't referring particularly to our conversations in
github with respect of the refactors, but it's nice from you to bring
them up. And it's ok to disagree in small things, hopefully we can
align in the big ones.
I understand that for TVM you might
A good infrastructure design has a long way to go and has a profound impact
on the project itself. That is why we always want to rethink if the
interface can be better done, and think about the next possible
infrastructure to make things better, Refactoring is certainly part of it.
There are
Am 31. Mai 2019 14:13:30 MESZ schrieb Pedro Larroy
:
> I think Martin does a very good job explaining why
>refactoring,
>reducing developer frustration and internal improvement is a crucial
>productivity multiplier which includes lower cost to ship features,
>less
>bugs and time spent
Hi folks
I would like to share this interesting article. I had a few conversations
with members of the community about refactors and internal enhancements
that have no apparent impact in user experience and are sometimes put into
question. I think Martin does a very good job explaining why
