Skip to content

Add vectorized mod2pi #15797

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

Closed
wants to merge 2 commits into from
Closed

Add vectorized mod2pi #15797

wants to merge 2 commits into from

Conversation

eford
Copy link

@eford eford commented Apr 8, 2016

No description provided.

@tkelman tkelman added the needs tests Unit tests are required for this change label Apr 8, 2016
eford referenced this pull request in JuliaAttic/ReverseDiffSource.jl Apr 8, 2016
@eford
Copy link
Author

eford commented Apr 8, 2016

I understand the Julia automated testing system.
If you want a test, you could add

@test_approx_eq maximum(abs(mod2pi(testCases[:,1]).-testCases[:,2])) 0.0

to the end of

julia/test/mod2pi.jl

@tkelman tkelman removed the needs tests Unit tests are required for this change label Apr 8, 2016
@stevengj
Copy link
Member

stevengj commented Apr 8, 2016

Now that map is fast, hoping to move away from vectorizing all the functions, and just have a general syntax like .mod2pi(x) for broadcasting. See #8450

@eford
Copy link
Author

eford commented Apr 8, 2016

I definitely like making map faster, but that proposed syntax for
broadcasting functions strikes me as ugly and prone to creating bugs due
to confusing syntax.
At one point Julia prided itself in allowing syntax like 2func(x).
Which makes 2.func(x) ambiguous or at least confusing to humans.

On Fri, Apr 8, 2016 at 4:49 PM, Steven G. Johnson [email protected]
wrote:

Now that map is fast, hoping to move away from vectorizing all the
functions, and just have a general syntax like .mod2pi(x) for
broadcasting. See #8450 #8450


You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#15797 (comment)

Eric Ford
Professor of Astronomy & Astrophysics
Center for Exoplanets & Habitable Worlds
Center for Astrostatistics
Institute for CyberScience
Penn State Astrobiology Research Center
Pennsylvania State University

@nalimilan
Copy link
Member

The proposed syntax is actually func.(x), not not .func(x).

Anyway, I think the question is: are other similar functions vectorized or not? Arbitrarily vectorizing some functions and not others isn't a very good solution.

@ViralBShah
Copy link
Member

Yes, at this point, we want to have some syntax for vectorization and discourage addition of more vectorized operations.

@eford
Copy link
Author

eford commented Apr 11, 2016

Personally, I'm not convinced that the choice of syntax is wise. I was
happy with having a simple macro to vectorize functions that one wanted
vectorized. If we need a naming convention, I think I'd rather have
something like func_vec, rather than an obscure "." syntax that's easy to
overlook. But if that's the worst thing about julia, then I'll get over
it. I definitely appreciate the work of the julia developers.

On Mon, Apr 11, 2016 at 6:37 AM, Viral B. Shah [email protected]
wrote:

Yes, at this point, we want to have some syntax for vectorization and
discourage addition of more vectorized operations.


You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#15797 (comment)

Eric Ford
Professor of Astronomy & Astrophysics
Center for Exoplanets & Habitable Worlds
Center for Astrostatistics
Institute for CyberScience
Penn State Astrobiology Research Center
Pennsylvania State University

@nalimilan
Copy link
Member

@eford That issue has been discussed a lot already. See the other issue for arguments.

@tkelman
Copy link
Contributor

tkelman commented May 11, 2016

closing, given #15032

@tkelman tkelman closed this May 11, 2016
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.

5 participants