Skip to content

[FEATURE REQUEST] *Optional* support for dtypes uint32 and int32 #719

@sfe-SparkFro

Description

@sfe-SparkFro

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions