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

Vectorize Macaulay2 functions #177

Open
dkahle opened this issue Jun 7, 2017 · 1 comment
Open

Vectorize Macaulay2 functions #177

dkahle opened this issue Jun 7, 2017 · 1 comment
Assignees

Comments

@dkahle
Copy link
Collaborator

dkahle commented Jun 7, 2017

Last night I ran into this problem with dimension(): I wanted to use primary_decomposition() to compute a primary decomposition of an ideal. In Macaulay2, the result of a call to primaryDecomposition is a list of ideals. Fine. (I actually created a class for this, BTW: m2_ideal_list and m2_ideal_list_pointer; it just seems these things will be pretty common.)

The problem became the dimension() is not vectorized in R or Macaulay2. In other words, if you have an ideal I in Macaulay2, you compute its dimension with dim(I). But if it's a List whose elements are ideals, that won't work, and instead you have to use apply(i, dim), so I baked that into dimension(): it now works on ideals and lists of ideals.

I think the same behavior should apply more broadly. Off the top of my head, we have functions like factor_poly() which wraps the M2 code factor(poly), but if you give it a mpolyList or a character vector of poly's, I expect it to error. I think it would be more sensible to have Macaulay2 vectorize it. So: check if the thing is a vector, and if it is use Macaulay2's apply(x, f) construct to get the job done.

Thoughts?

@coneill-math
Copy link
Owner

coneill-math commented Jun 7, 2017

This sounds reasonable. Quite a few of our functions expect a list of parameters as their main argument. How difficult is it to implement vectorization, and would it break any current usage of these functions?

In particular, would it require adding a third calling option? We already have all combinations of "_" and "." versions, adding a third to make 8 different functions would be chaos.

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

2 participants