Monetary Abbreviations (Proposal) about go-humanize HOT 5 OPEN

Hey! I like this idea a lot but I'd question how you would get around the precision of abbreviation, i.e. some people might want $151k for $150,899 instead of $150.9k. Does your implementation cover this at all?

I'm just trying to think of some similar examples that make decisions on precision but I don't think there are any in this package. I think it's probably fine to be opinionated on what it should be, i.e. if it doesn't round to a whole number, then it displays to one decimal place but would want to be clear in documentation.

from go-humanize.

you mean something like this?

#94

from go-humanize.

@jamesallured - https://github.com/dustin/go-humanize/blob/master/si.go#LC101

The monetary code could follow SI

@lfaoro - one could add non-shorthand notation as well
thousand, million, trillion...

I would leave out the currencies in the beginning, focus on something easy

from go-humanize.

This isn't quite universal, though. In finance, US dollars are abbreviated to million with MM (thousand thousand). In environments that use Lakh, it's super confusing. This quickly becomes a localization issue. I'm not sure how to generalize this to the different use cases since we do have different precision and localization requirements.

from go-humanize.

@dustin - wouldn't it be a lot simpler to have the user supply a map[float64]string

map[float64]string{
        ...
	3: "thousand", 
	6: "million", 
	9: "billion", 
        ...
}

that way you can separate the algorithm from the data.
(Decades of multiples of 1 should be handled, also, you may want to have only integer decades (in stead of float64 (how would you handle non-integer floats?))

It may require some work for building the object, that has a parser etc. but it is doable.

from go-humanize.