One thing I don’t quite get is: why couple sparse and dense tensors into a single type?
When we are building a system incrementally, for example, adding a new feature on top of the old system, the better way would be adding a new code path, instead of hacking old ones. This would allow clearer separation of functionalities, clearer error message and easier debugging. In our particular case, let’s say, what if there are some code paths not treating the extra field “format”? For example, we forgot to touch code generation on a weird device to be aware of the extra field”format”. It would probably silently fail (or even not failing but produce wrong results) without proper error messages. So my point is, if possible, it is always preferable to add a new type instead of hacking old ones, because we cannot guarantee that the rest of the system still treats the hacked type correctly. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/dmlc/tvm/issues/3731#issuecomment-521275500
