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

Add \approxeq () as an alias to isapprox as well #23478

Closed
wants to merge 2 commits into from

Conversation

staticfloat
Copy link
Sponsor Member

It seems to me that this would be another reasonable shortcut

@yuyichao
Copy link
Contributor

Why do we need two aliases for it?

@staticfloat
Copy link
Sponsor Member Author

Because some people write \appox and others write \approxeq. Considering the semantics behind the symbols, this seems reasonable to me.

@yuyichao
Copy link
Contributor

others write \approxeq

You mean on paper? That seems like a pretty weak reason. I don't think we should add all these as alias though since it'll be confusing for the reader. We can certainly have ascii and unicode operator aliases for functions since operators give the function special syntax and unicode usually makes it shorter. However, having both and seems to me like adding const isapproxeq = isapprox and I think we should just pick one standard operator and stick to it for both the function name and unicode or operator.

Also, FWIW, seems to be a more direct synonym according to https://en.wiktionary.org/wiki/%E2%89%88 .

Also need export, doc, etc.

Also ref #5903. I think we can do that for ones with identical looking (which is IIRC defined in unicode in some way?) but adding other aliases seems like a pretty deep rabit hole.

@yuyichao
Copy link
Contributor

I think we can do that for ones with identical looking (which is IIRC defined in unicode in some way?) but adding other aliases seems like a pretty deep rabit hole.

Or put in another way, if we have some clear rule what should be added, we can add all of them.

@StefanKarpinski
Copy link
Sponsor Member

Yeah, I'm 👎 on this too – I've considered using for other relations and it seems inconsiderate to take yet another name for the same operation in Base.

@KristofferC KristofferC deleted the sf/approxeq branch September 12, 2017 16:00
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

Successfully merging this pull request may close these issues.

None yet

3 participants