RFE: Fraction decompilation - more weight to common divisors?

I really liked the introduction of fractions instead of numbers with long decimal sequences. It cought me by surprise and put a smile on my face. That feature is the very definition of quality. Really good job!

But, there's always room for improvement. :-)

I think it would make sense to give preference to the following divisors: 2^n for n in (8,10,12-16, 20) 2^n-1 for n in (8,10,12,15,16)

Some rationale: 255 (2^8-1) is very common when converting (u)byte (f.ex. RGB) <-> normalized float. 2^10 and 2^20 is common when converting larger numbers to computer-K and -M. I saw a long color initialization sequence where the decompiler preferred 51 as divisor, where 255 would have been more obvious (example below).

Coming to think of it, should negative numbers become handled, maybe even 2^7 and 2^7-1 should be considered.

I have also seen code normalizing values in f.ex the ranges +/- 4K, 16K, 32K and 64K, so maybe negative numbers should be considered too (at least for a/this small subset of potential divisors)?

I believe that would allow better/nicer decompilation of some code than the following example of current decompiler output (all three should preferrably be divisor 255f): 0.882352948f, 40f / 51f, 0.5882353f.

Again, good job!