This is the data you provided in your previous post. Your output gives you an error because you are expecting some kind of number, but you have a date in the “maturity-date” and a string in the “description” field. I’m not sure if this is intended or not, but it is not a number, so you should not be iterating over it as if it were.
i’m testing for the field type before adding. I have solved it, there was an error is my example. thanks
see this answer:
In most cases it would not make any sense to speak of fractional cents…
like you have correctly listed,
52 currencies that have no decimal places
239 that have 2 decimal places
3 that have 3 decimal places
1 that has four decimal places
Pre-setting the number of decimal digits, then scaling all values to integer units, should be a big win for simplicity as well as performance.
I know its an older post but I wanted to observe that what is described by @CharlesO is basically what the Decimal package does. It’s a lovely piece of code (as you’d expect from @ericmj). It’s hard to consider using anything other than a decimal format for money types (the representation under the covers matters less - but Decimal is very tightly optimised). And as a lib writer, I find it hard to consider a money type that isn’t tagged in some way with a currency type. There’s just too many things to go wrong.
Decimal is good as the underlying type, but it doesn’t enforce handling partial unrepresentable money values, or verifying the same type of money is being compared/added/etc… That’s why the ex_money library is useful.
If you are responsible for a system that will only ever have 2 decimal point numbers and the operations involved are simply addition, subtraction, hardly ever multiplication or division, I still feel there might be some simplifications that may be obtained by not taking on a dependency.
In such a case a simplification can indeed be made, but it’s a project specific simplification and non e.g. a library or even more the core should make. The best case is always that once code is written you can change the currency without touching any of the logic working on the values. Your constraints allow simplifications, but also limit the selection of currencies to be usable. Especially the core (when we’re talking about build in stuff) should not arbitrarily limit the selection of currencies, especially if it’s just because it’s simpler to implement. If you write a library, which does so, it’s fine for as long as you communicate those limitations properly. And on a per project basis you can do what ever you want anyways. On the per project basis I would still suggest wrapping money values in a struct, which is documented to work within the given constraints and add an api to handle the manipulations on the value. If all you do is add and subtract stuff, such a module should be written quite quickly and you can skip external dependencies.
One should not try to build malformed partial implementations in any case, but even if all the currencies were having 2 decimals, the money unlike numbers require an ability to split 0.33 into two shares, than join them back and get 0.33. Otherwise the first audit would dismiss the whole business. That is impossible without very careful implementation, that is IMHO harder than anything else in the field.
Except it is way trivial to accidentally handle, say, a remainder on a division then, that’s the major issue.
You should never use a basic number as a money type, ever ever I would assert.
Whether you use ex_money or make your own, never allow the base monetary value to be altered directly.
+1