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

Fixing Apple Silicon issues, getting rid of dplyr, rlang and sp dependencies, adding collapse and s2 = more lightweight and multiple times faster grid materialization, and some small convenience features. #66

Merged
merged 16 commits into from
May 21, 2024

Conversation

SebKrantz
Copy link
Collaborator

No description provided.

SebKrantz added 6 commits July 7, 2023 03:41
… of a double (factor) to long int here: on M1 Macs this is rounded downwards, thus I needed to add a small number. Took me 6 freaking hours of simultaneous debugging on Mac and Windows to find it...
@SebKrantz SebKrantz changed the title Getting rid of dplyr, rlang and sp dependencies, adding collapse and s2 = more lightweight and multiple times faster grid materialization. Fixing Apple Silicon Issues, getting rid of dplyr, rlang and sp dependencies, adding collapse and s2 = more lightweight and multiple times faster grid materialization. Jul 15, 2023
@SebKrantz SebKrantz changed the title Fixing Apple Silicon Issues, getting rid of dplyr, rlang and sp dependencies, adding collapse and s2 = more lightweight and multiple times faster grid materialization. Fixing Apple Silicon issues, getting rid of dplyr, rlang and sp dependencies, adding collapse and s2 = more lightweight and multiple times faster grid materialization. Jul 15, 2023
@SebKrantz
Copy link
Collaborator Author

@r-barnes, first of all thanks for making such an awesome software available for R. I have implemented some fixes, especially for Mac users (#63), made the package more lightweight and significantly faster, and added some vital convenience features. Please consider merging this PR and pushing out a new version to CRAN. See the NEWS file for a summary of the changes. Thanks!

@SebKrantz SebKrantz changed the title Fixing Apple Silicon issues, getting rid of dplyr, rlang and sp dependencies, adding collapse and s2 = more lightweight and multiple times faster grid materialization. Fixing Apple Silicon issues, getting rid of dplyr, rlang and sp dependencies, adding collapse and s2 = more lightweight and multiple times faster grid materialization, and some small convenience features. . Jul 15, 2023
@SebKrantz SebKrantz changed the title Fixing Apple Silicon issues, getting rid of dplyr, rlang and sp dependencies, adding collapse and s2 = more lightweight and multiple times faster grid materialization, and some small convenience features. . Fixing Apple Silicon issues, getting rid of dplyr, rlang and sp dependencies, adding collapse and s2 = more lightweight and multiple times faster grid materialization, and some small convenience features. Jul 15, 2023
@jsocolar
Copy link

Just floating back here to thank @SebKrantz for the fix and also to ask if there is hope of getting this merged and pushed up to CRAN soon. As things stand, I believe M1 users can still get the wrong behavior silently, which is worth patching with some urgency IMO.

@@ -167,7 +167,7 @@ DgHexIDGG::initialize (void)
if (isClassIII())
factor *= M_SQRT7;

maxD_ = factor - 1.0;
maxD_ = factor+0.000001 - 1.0;
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this being added? Can you rewrite as 1e-6?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add a comment before the line explaining the offset.

src/shputils.c Outdated Show resolved Hide resolved
@@ -117,7 +117,7 @@ DgTriIDGG::initialize (void)
double factor = parentScaleFac * 2.0L; // aperture 4

scaleFac_ = factor;
maxD_ = factor - 1.0L;
maxD_ = factor+0.000001 - 1.0L;
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use 1e-6 add a comment before the line explaining the offset.

@@ -167,7 +167,7 @@ DgHexIDGG::initialize (void)
if (isClassIII())
factor *= M_SQRT7;

maxD_ = factor - 1.0;
maxD_ = factor+0.000001 - 1.0;
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add a comment before the line explaining the offset.

@r-barnes
Copy link
Owner

@SebKrantz - Let's get this merged.

One complicating factor is that any changes made to the C++ code need to be upstreamed to https://github.com/sahrk/DGGRID, so I need to be able to justify and explain them to @sahrk. I'm not sure why you've added factor + 1e-6 - can you add a comment explaining that?

I've just updated this file to explain the C++ workflow. If you'd like, I can handle that for this PR.

@SebKrantz
Copy link
Collaborator Author

SebKrantz commented Oct 18, 2023

@r-barnes I have used scientific notation and added a comment: the apple ARM issue was that conversion to integer rounded the number downwards which caused a lot of problems down the line. Adding a small number changed this. This has probably something to do with ARM systems not supporting long double. I note that @sahrk has also merged my PR in the DGGRID C++ library. .

src/shputils.c Outdated
if (dlow < dhigh) dgprintf(stmp,dlow,dhigh,mean);
else if (dlow == dhigh) {
sprintf(stmp,"= %%.%df",iDecimals);
snprintf(stmp, sizeof(stmp), "= %%.%df",iDecimals);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This needs to be dgprintf

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, is that a wrapper around snprintf that works the same? R does not allow calls to sprintf anymore.

@r-barnes
Copy link
Owner

@SebKrantz - Oh, I see you've already got the fix upstreamed - nice!

@r-barnes
Copy link
Owner

@SebKrantz - The latest upstream pull from DGGRID will take me a little bit to verify. I'm working on it.

@SebKrantz
Copy link
Collaborator Author

@r-barnes any news here? Does there need to be an upstream pull? In my experience the patch is working perfectly.

@SebKrantz
Copy link
Collaborator Author

@r-barnes, I‘ve now set up my fork so that people can easily find and install from there. But needless to say this is not ideal. I would be happy to become the CRAN maintainer of dggridR and push this out to CRAN if you feel like this is something you can no longer do. Let me know.

@r-barnes
Copy link
Owner

r-barnes commented Mar 15, 2024 via email

@SebKrantz
Copy link
Collaborator Author

SebKrantz commented Mar 15, 2024

@r-barnes Thanks, happy to set up a call after 22nd March (on Conference Travel this week). However, as indicated, I don’t see the need for an upstream pull, as the package works perfectly well as it is now. Maybe I‘m missing something, but I see the upstream pull rather as something that will just delay deployment to CRAN and might introduce further issues. But yeah, happy to chat about it. Perhaps just send me a meeting suggestion to [email protected]

@AlbanSagouis
Copy link

Beautiful work @r-barnes, thank you!
@SebKrantz, thank you so much, your fork immediately solved my problem.

@SebKrantz
Copy link
Collaborator Author

SebKrantz commented May 5, 2024

@r-barnes what would speak against merging this PR and sending it off to CRAN? (I'd adjust the README again). #70 also suggests that updating C++ may be complicated. Anyway, I'd be available for chats about maintenance this month.

@edzer
Copy link
Collaborator

edzer commented May 17, 2024

If you consider changing maintainer, one could consider to migrate this package to the r-spatial GH organisation, where it maybe receives more eyes; I'd be happy to invite everyone here as contributer there. I'm planning to spend time this fall on problems around grids crossing the antemeridian, as reported e.g. in r-spatial/sf#280

@r-barnes
Copy link
Owner

@SebKrantz - I think the only part of this PR that's challenging are the changes to DGGRID. If you're able to split those off, I think I can land everything else immediately.

@r-barnes
Copy link
Owner

@SebKrantz @edzer - I'm generally pro adding maintainers and I'd appreciate the help. I'm worried about diverging too far from upstream DGGRID in case there are bug fixes or such available from it.

@SebKrantz
Copy link
Collaborator Author

@r-barnes of course the C++ changes could be split off, but that then means that we publish another version of the software that will not work on Mac and any other system that misses the long double type. The C++ changes are minor and have been upstreamed to DGGRID, but if you want to do a full C++ update instead I would suggest to build my fork and send that to CRAN and then do the C++ update. I can then remove the C++ changes from the master branch of my fork for you to merge it.

@r-barnes
Copy link
Owner

@SebKrantz - if the changes have all landed upstream, then we can do the merge here.


maxD_ = factor - 1.0;
// Adding small number (1e-6) to prevent rounding down in conversion to integer (fixes issue #63 experienced on Apple ARM computers)
maxD_ = factor+1e-6 - 1.0;
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

std::nextafter might have been a mildly safer way to do this.

layer <- file_path_sans_ext(basename(shpfname))
bb <- st_bbox_to_sp(st_bbox(st_read(dsn, layer=layer)))

} else bb <- st_bbox_to_sp(st_bbox(shpfname))
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would do better in brackets.

@r-barnes r-barnes merged commit 4d59137 into r-barnes:master May 21, 2024
1 check passed
@r-barnes
Copy link
Owner

@SebKrantz - I've merged having a left a couple of comments.

@SebKrantz
Copy link
Collaborator Author

@r-barnes excellent! You'll have to adjust the README.md again then.

@r-barnes
Copy link
Owner

@SebKrantz - Shoot, I should have squash-merged that. Just did a local rebase and force-pushed.

@r-barnes
Copy link
Owner

@SebKrantz - Good catch on the readme.

@r-barnes
Copy link
Owner

@SebKrantz and @edzer - I've given you collaborator access to the repo, set master to require a code review, and setup Squash+Merge as the available merge type.

@SebKrantz
Copy link
Collaborator Author

Thanks @r-barnes. I suppose you'll prepare a CRAN release? I'd also support @edzer's suggestion to move this to r-spatial for more visibility, but up to you of course.

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