Accept generic float type for fitness/mutation rate

[HyperCodec]

This crate should work with any type that implements PartialOrd, not just f32.

However, it would add a bit of complexity to the project, and I don't know if that's really worth it since I don't see any reason why someone wouldn't just use f32.

ig it could be useful to be able to use f64 for more precision, but I still don't know whether it's worth making a big refactor for.

[HyperCodec]

also add mutation rate to this.

[ai-mannamalai]

I'd say maybe the users wanting to have polymorphic types should implement an into() trait for f32 type which should solve it without asking too much of the library

[HyperCodec]

I'd say maybe the users wanting to have polymorphic types should implement an into() trait for f32 type which should solve it without asking too much of the library

Yeah that's kind of what I was thinking and why I've kind of procrastinated this issue for so long. It's probably just not worth the hassle to maintain a polymorphic PartialOrd type when it only benefits a select few people that actually need that level of precision to differentiate their genomes (and even then, it's probably their fault if the fitness function needs to return values that close together).

The mutation rate being arbitrary is a little bit more plausible, since the context API already exists and could already replace mutation rate, though I don't know how I feel about forcing users to interact with a complex API just to use a simple value that most implementations need. It's already probably as good as it's gonna get, since the explicit mutation rate parameter helps the vast majority of use cases, yet the context API can be used to inject a custom value for those that need it.

[ai-mannamalai]

One of the frustrating aspects of many discrete optimization libraries is that despite the methodology supporting the gradient free techniques but rigidly supporting the float types whereas multiple data types are possible in real world problems; BSAT type problems etc. Thanks for the work here I'm planning to use it sometime soon

…

On Sun, Apr 12, 2026 at 8:12 AM Tristan Murphy ***@***.***> wrote: *HyperCodec* left a comment (HyperCodec/genetic-rs#97) <#97 (comment)> I'd say maybe the users wanting to have polymorphic types should implement an into() trait for f32 type which should solve it without asking too much of the library Yeah that's kind of what I was thinking and why I've kind of procrastinated this issue for so long. It's probably just not worth the hassle to maintain a polymorphic PartialOrd type when it only benefits a select few people that actually need that level of precision to differentiate their genomes (and even then, it's probably their fault if the fitness function needs to return values that close together). The mutation rate being arbitrary is a little bit more plausible, since the context API already exists and could already replace mutation rate, though I don't know how I feel about forcing users to interact with a complex API just to use a simple value that most implementations need. It's already probably as good as it's gonna get, since the explicit mutation rate parameter helps the vast majority of use cases, yet the context API can be used to inject a custom value for those that need it. — Reply to this email directly, view it on GitHub <#97 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APGLTDD6KXV5RLUFSQHNJJL4VOW7PAVCNFSM6AAAAAB4WTKKWWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DEMZRG43TOMBVG4> . You are receiving this because you commented.Message ID: ***@***.***>