obsidian-numerals
obsidian-numerals copied to clipboard
feature request: currency conversion
Wonder if it's possible to add this. For e.g.
$100 to INR
Thanks for the suggestion!
Theoretically yes its possible to add, but two primary issues come to mind:
-
I would need a source for up-to-date currency rates. In order to keep this plugin free that API would need to be free (and easily accessible). It also turns an otherwise offline plugin to an online one which I don't love, but perhaps is OK with user opt-in
-
This would be the first function that has a dynamic result, which means the notes contents would change even if the user didn't change anything. Or it would mean that the data was out of data and technically wrong. This is the biggest issue for me as it leads to unpredictable results either way.
Issue 1 is possibly surmountable. 2 is a shift in the overall plugin philosophy.
I agree this would be a great feature, but due to these challenges, it's definitely further out on the roadmap.
If anyone comes here looking for a workaround to use before this is implemented (or in case it won't be), MathJS' createUnit
function allows overriding default units:
createUnit('EUR', '1.0801906 USD', { override: true, aliases: [ '€' ] })
createUnit('AUD', '0.64623444 USD', { override: true, aliases: [ 'A$' ] })
This was quite sufficient for me, one just has to remember to update conversion rates from time to time.
Nice workaround @Mirsario, thank you.
I just want to add that an example of free and accessible API is one from the European Central Bank: http://www.ecb.europa.eu/stats/eurofxref/eurofxref-daily.xml
I believe that's the one that SoulverCore uses.
@filipstachura / @Mirsario - any thoughts on my comment above?
This would be the first function that has a dynamic result, which means the notes contents would change even if the user didn't change anything. Or it would mean that the data was out of data and technically wrong. This is the biggest issue for me as it leads to unpredictable results either way.
Supporting @Mirsario's solution through a simple version of #47 avoids this issue of the values changing over time. Would it be a sufficient solution to support easy definition of static conversion rates that can be used and updated at user request?
I completely understand your point, and I think it's valid. Reproducibility is important. Your proposal has also clear advantage of straightforward User Experience when offline.
From the user perspective:
- easy definition of static conversion rates would work for me 👍
- it would be great to have a way to update it with current rates easily (from European Central Bank or elsewhere). Some ideas: (a) button next to definition to fetch current rates and/or (b) a shortcut to refresh directly from notes
I am using @Mirsario's solution and it works for me, however I have a question about the scope of the new unit. I have two different notes, related to a travel budget to Japan at different times. Each has a new unit (dollar to yen), with a different exchange rate in it. It seems as though the note related to the trip in 2024 can access the exchange rate unit from the note related to the trip in 2020, which really throws out the estimated costs as the exchange rates are about 30% different. Is there a way to limit the scope of the new unit to just its parent note?
I noticed that too at some point, MathJS calls affect a global state, which can "leak" between different documents, values of the latest calls to run being the ones to show up in renders.
Your assessment is correct. While the scope is different for each math block, it's a single instance of the mathjs interpreter. So commands which affect the environment (like creating new units) will lead to non-determinism and leaking between notes. I recognize that's not great, but spinning up different instances seemed to have significant performance impacts.
I'm planning/working on adding numerals-specific directives to create units which will handle the dance with mathjs for you. Just haven't finished yet and there are some strange corner cases to solve.