I often need to convert prices in webshops to my local currency to better understand it.
This small package ExchangeRates.jl does this with a (in my opinion) slick interface:
julia> using ExchangeRates
[ Info: Fetching rates from https://www.ecb.europa.eu/stats/eurofxref/eurofxref-daily.xml
julia> 100€/DKK
746.02
The interface appears to be a bit backwards if you consider the currencies to be units, i.e., you use €/DKK to produce a result in DKK, rather than DKK/€.
Does DKK/€ not translate to the number of Danish crowns per euro?
To me the easiest way to see that this interface makes sense is the following: If you multiply the equation 100 €/DKK = 746.02 by DKK, you obtain 100 € = 746.02 DKK, which makes total sense to me. Thanks for the package!
Seems consistent to me: 1 m / mm = 1 m / (1 mm) = 1000. To me 100€/DKK reads as 100 Euros divided by 1 DKK, not as 100 Euros multiplied by the ratio EUR/DKK (that would be 100 €^2 / DKK).
Does DKK/€ not translate to the number of Danish crowns per euro?
No, just like mm/m is 0.001, i.e. the number of meters in a millimeter, not 1000 (the number of millimeters in a meter).
Overloading the in operator is a bad idea here – it is not the usual semantic meaning of in (set inclusion). That type of overload is frequently called “punning” and is discouraged similarly to how piracy is discouraged.
I’m sure this is pretty quick, but I wonder if you’ve considered using a cached file that automatically refreshes when it’s >age old?
Disclaimer: this comes to mind because it’s one of the things that DataToolkit does (but it won’t be a good dep for other packages until the next minor release).
I have considered that, and Scratch.jl looks like a way to do it. I’ll also look into DataToolkit.jl.
It may come in a later release, but for now I prioritized the simplicity of just fetching at load time.