-
Notifications
You must be signed in to change notification settings - Fork 125
Description
Describe the solution you'd like
Optional support for dtypes uint32 and int32, similar to how complex number are optionally enabled by setting ULAB_SUPPORTS_COMPLEX
.
Additional context
I skimmed a bit through #341 and #306 (comment). Sounds like the main concern is that adding more dtypes results in ulab's compiled size increasing dramatically (double?). Totally understand and agree with that concern!
However, I'm working on an application where the entire compiled firmware size is multiple MB in size. It does not matter to me if ulab's compiled size doubles (eg. ~120kB to ~240kB), that's negligible for this application.
And the solution provided by #342 does not work for my application. I unfortunately can't go into detail about my exact application right now (that will change soon!), but in short, I have an array where each element is a counter. The count values can easily exceed the capacity of 16-bit integers. Using a float array is not acceptable, because if the count value exceeds 23-bits (32-bit float mantissa size), then counts can start to be lost. Precision matters here, so lost counts from using floats are not acceptable.
Although this feature request is primarily motivated for my application, it would certainly be helpful for others as well, given the discussions in #341, #364, #306, etc.