Skip to content
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

Exterior algebra: is not a unary operator #17480

Closed
rleegates opened this issue Jul 18, 2016 · 9 comments
Closed

Exterior algebra: is not a unary operator #17480

rleegates opened this issue Jul 18, 2016 · 9 comments

Comments

@rleegates
Copy link

rleegates commented Jul 18, 2016

I'm currently writing a library for exterior algebra on manifolds and need to define the Hodge star operator. In particular, the Hodge star maps a k-form on an n-dimensional manifold to an n-k-form. Is there any use-case which disagrees with being a unary operator? If not and it's a quick fix, could fulfilling this request be part of the 0.5 release?

@simonbyrne
Copy link
Contributor

You can call the function form of *, which accepts a single argument, by enclosing it in parentheses

julia> (*)(1)
1

@oxinabox
Copy link
Contributor

We are talking about \star right?

What does work for \star is, like what @simonbyrne said for *, using it as a function.

julia> ⋆(x)=2*x
⋆ (generic function with 1 method)


julia> ⋆(4)
8

I believe the current unary operators are defined here.

@Keno
Copy link
Member

Keno commented Jul 18, 2016

I'm fine with letting \star be both unary and binary, but from a syntax perspective people may prefer to have it behave like *

@TotalVerb
Copy link
Contributor

What about making unary * syntax for unsafe_load? (Joking. That would be terrible.)

On a more relevant note, how about making \bigcup, \bigcap, \prod, \sum, \bigvee, and \bigwedge unary? These symbols (⋃ ⋂ ∏ ∑ ⋁ ⋀) are fairly commonly used unary in mathematics.

@stevengj
Copy link
Member

@TotalVerb, I think @JeffBezanson's perspective from way back was that \cup would be a binary operator and \bigcup (etc.) would just be an identifier name, so you can basically use it as a unary operator but you have to add parens.

@simonbyrne
Copy link
Contributor

now we can pass comprehensions in functions, these should be reduction operators, i.e. \bigcup (foo(i) for i in X)

@TotalVerb
Copy link
Contributor

TotalVerb commented Jul 20, 2016

I can get behind aliases like

const= sum
const= prod
(x) = reduce(, x)  # all?
(x) = reduce(, x)  # any?
(x) = reduce(union, x)
(x) = reduce(intersect, x)

though the empty case is troublesome, as usual.

@JeffreySarnoff
Copy link
Contributor

wrt sets, Union( ∅, ∅ ) is Union( ∅ ) is (∅) which I am free to write this way () # math, not as a tuple
similarly Intersection, so how about

(x) = reduce(union, x)
(x) = reduce(intersect, x)

() = Void()
() = Void()

# and if it is useful to cover reducing over an empty collection, here are two
const emptyTuple = ()
const zeroElements = []

(emptyTuple) = emptyTuple
(emptyTuple) = emptyTuple
(zeroElements) = zeroElements
(zeroElements) = zeroElements

@c42f
Copy link
Member

c42f commented Jun 7, 2019

Fixed in #31604

@c42f c42f closed this as completed Jun 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants