add functional equivalences about unitfulequivalences.jl HOT 6 CLOSED

I don’t see the point of extending the @eqrelation macro like this. The main advantage of the macro is that it defines the methods for conversion in both directions, i.e., you need to write one macro call and get two edconvert methods. With the proposed @eqrelation Name a = f(b), one has to use the macro twice to get both directions and one has to define the function f and its inverse. This is no easier than just writing these functions as edconvert methods.

Regarding the Plato–sg conversion, I still don’t think that an equivalence is the correct thing. But I agree that using different dimensions is also ugly. I would prefer a different solution:

The thing about Plato is that it’s not proportional to other units of its dimension. Therefore, it is like an AffineUnits, only more complicated. One could define a new type of unit (maybe QuadraticUnits) that is related to another unit by a quadratic relation (instead of just an offset, like for AffineUnits) and define Plato as such a unit. Then one would just use uconvert without Equivalences (since those are for converting between quantities of different dimensions).

from unitfulequivalences.jl.

Fine. I just thought it would be more elegant to have a more consistent way of defining the equivalences, regardless of the form, and it would make it slightly easier for users of the package, which is the aim of any package. Besides, it wouldn't change the current use of the proportional and anti-proportional equivalences. But that's ok, no big deal.

from unitfulequivalences.jl.

Thanks for your input. I’m also in favor of consistency and ease of use, but I don’t think the extended @eqrelation macro would achieve that:

• I don’t think it is consistent that some forms of the macro define the conversion in both directions and some only in one direction.
• I don’t think it is easier because one still has to define the function, so one might as well define it as a edconvert method. Of course, this has to be properly documented (which I plan to do soon).

from unitfulequivalences.jl.

Well, we could write @eqrelation y = e * x and @eqrelation y = e / x and have the code figure out whether rhs.args has length 3 or 2, to distinguish from @eqrelation y = f(x), and proceed accordingly.

But that is ok. I am just thinking out loud. I understand if using macro just as an alias is considered not good coding. I don't know. I am here to learn. And I am! I have never even browsed over this meta-programming stuff, and it is being fun to learn it, at least. I don't know how else I could help, though.

from unitfulequivalences.jl.

I don't know whether you are considering this or not, but for the moment I am okay with using edconvert directly, so I feel I should close the issue since I was the one to raise it.

from unitfulequivalences.jl.

I’m not really considering this, since I think it is not much easier than defining edconvert methods.

from unitfulequivalences.jl.