New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Generic functions, not aliases, for unicode operators in LinearAlgebra #37109
Comments
This would be great, I imagine that some future database package might want to use \times for the cartesian product of sets which is called |
If you're using the operator with a different meaning you should use a different generic function. The |
I guess our real problem is that we need a unicode symbol for cartesian product. Is there another unicode symbol that would work for cartesian product? On the other hand, we could just call the cartesian product of sets |
You can use the same symbol and just give it a new definition. |
If instead of a unicode collision with It's the same with unicode identifiers. A problem might arise when you import packages: julia> cross(a, b) = "a × b"
cross (generic function with 1 method)
julia> using LinearAlgebra
WARNING: using LinearAlgebra.cross in module Main conflicts with an existing identifier.
julia> cross([1,0,0],[0,1,0])
"a × b"
julia> LinearAlgebra.cross([1,0,0],[0,1,0])
3-element Array{Int64,1}:
0
0
1 You might be up against wanting to export the symbol, and have it cooperate with some of the names in To me it seems that the cartesian product of two sets has nothing to do with the vector cross product (though if ever I were to feel nervous making that claim, I think it's in front of those who know a lot of category theory...) if not for the name / symbols. And so they should get different (fully-qualified) names in Julia. To use the identifier "cross" both uses, you can separate them by namespace. |
I think it's clear that this is the current setup. But ×(a::Set, b::Set) = Set(zip(a, b)) For package developers, the current |
I'm not sure what this means. What alternative do you see? The only one I see is to not export Everything that could be said about |
I assume the alternative Chad that has in mind is the one suggested in the OP: make the Unicode operators into generic functions that can be overloaded.
This statement gets to the heart of the disagreement here. Stefan has clearly stated his philosophy of generic functions: that functions with different meanings should have different names. That may well be a good rule of thumb, but I do not think it should apply to Unicode operators for mathematical notation. It is a basic and ubiquitous feature of mathematical notation that it is overloaded in ways that the same symbol does not have the same meaning in all contexts. Two examples have already been given in this thread; we could come up with countless others. The wonderful thing about Julia is that multiple dispatch makes it easy to accommodate this context-dependence! So let's embrace that and make |
Mixing the semantics of operators that happen to have the same name seems extremely fraught.
This is true -- but it's the notation that's overloaded, not the function. Cross product and Cartesian product may use the same symbol but they're not the same object. Merging operations into one function un-solves the expression problem. Defining a separate function -- a new [1] Incidentally, julia> (××)(a::Set,b::Set) = Set(Iterators.product(a,b))
ERROR: syntax: "×" is not a unary operator but I think they should be, barring some countervailing big problem. |
I don't think that multiple dispatch handles this context dependence. If I write a function in terms of I am reminded of a long thread that discusses C++'s "Argument Dependent Lookup". There might be room for a Julia feature that chooses the correct |
The
LinearAlgebra
module exports two unicode operators, like this:Would it be possible to change these to generic functions?
The reason is that
\cdot
does not always have the interpretation of a dot product. For example, in Catlab we use it as a generic composition operator. Likewise,\times
is not always a cross product; in many contexts it conventionally represents the cartesian product of sets or types. By using generic functions instead of aliases, it would at least be possible to override these operators for specific types when a different interpretation makes sense.It would be better still to have typing, e.g.
The text was updated successfully, but these errors were encountered: