Closed ChristophWWagner closed 5 years ago
I gladly welcome the phrase "shit's about to hit the fan" in our discussions!
I like it, since this resolves our old problem of overflows happening while giving more control to the user. Maybe some users now start to think about such issues.
would you consider making it a construct-time option be a smart idea? Technically the best thing one could dream of is a BLAS that allows (int8, int8 -> int8) operations using a large accumulator. That would easen up things at my end tremendously as it would still be memory-efficient and the heavy lifting only happens inside the accumulator (where there is an ALU that doesn't give a shit about the overhead). Anyhow, thinking straight about implementation hassle an output cast option would be a nice thing, too. Assuming -- of course -- the users knows the spirits being called.
Extends the scope of #40.
If we already are at it, let's add another option that promotes the input arrays type to fulfill some minimal requirement. In conjunction with a consistent roll-out of
**options
kwargs to all__init__()
functions this offers the user to widen data types where needed in a meta instance whenever an overflow needs to be avoided, accuracy maintained or for lean matrix representation just to be preserved.As an example think of an int8 matrix class you really don't want to cast to a larger data type (for that it is huge or just out of principle as int8 is enough). Now if you apply its forward transform to another int8 ndarray shit's about to hit the fan if the matrix is large enough to cause accumulation overflows. If something like this could occur it would be nice if the user could just specify an
minType=int32
option and be safe.Any suggestions?