Exchange rates are prices, and thus are (1) dynamic (and can be very volatile even in the short run) and (2) dispersed: you observe multiple exchange rates depending on quantity, location, assets exchanged (banknotes or other claims).
It is very difficult to make a "general" library for exchange rates, not because of the coding, but because of conceptual issues. Specific applications (eg accounting with a given source of "official" exchange rates, or a trader in a specific market) allow you to make further assumptions and simplify. In particular, I don't see how exchange rates fit with SI units at all. Best, Tamas On Thu, Feb 18 2016, Jeffrey Sarnoff wrote: > I am thinking about how Currencies would fit with software for handling SI > and other physical dimensions and the usual units of measure. > The following approach seems workable and (mostly) not disruptive to the > working and evolving code Andrew Keller offers the community. > > A currency behaves as a representation of, or a stand-in or proxy for all > the banknotes, sovereign wealth and other property interests of a nation. > Two or more currencies for which there is a market that allows one to be > converted into another at an agreed upon, current rate of exchange are not > that different from two or more units of length or units of time that are > allowed to be converted into one another using a predefined multiplicative > ratio. > > (now, 1.0 US Dollar = 8.45536 Swedish Krona, refreshing the page, now > 1.0 US Dollar = 8.45518 Swedish Krona) > > The most impactful distinction is that rates of exchange are dynamic while > the physical conversion factors (BIPM standards, CODATA values) persist. > However currencies may be accommodated, it must protect our ability work > with units with ease and with invisibly amortized processing overhead. > So, the request that gets the appropriate exchange rate to use when > converting from one currency to another must come from the Units code in a > way that does not require other physical unit conversions to operate any > differently. > > One of the things on Andrew's future to do list is allow measures and their > uncertainties to be used and to interact respecting the uncertainty math. > In any currency exchange trade, there is a buyer and a seller. Usually, > when they (or their requests) meet, they disagree. The buyer wants to pay > as little as possible and the seller wants to receive as much as possible. > That separation is called the bid-ask spread (the buyer bids, the seller > asks); almost always it is very, very small relative to the total value > being exchanged. The uncertainties associated with physical measures and > conversions usually are very, very small relative to the total quantity > being determined or the value being mapped into different units. When > uncertainty management is introduced, it is conceivable that currency > support could take advantage of that analogous role.
