-
Notifications
You must be signed in to change notification settings - Fork 944
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
New module @turf/sector #653
Conversation
Thank for the fast implementation. Is it already ready in the turf.min.js ? Thanks. |
@Adraesh I just happened to be implementing it at the right moment apparently 😄 |
It is created by the
Perfectly fine what you did, for every new PR generate a new forked branches from Turf's
The minified build happens when a new release is published using CC: @stebogit |
@stebogit Look over your source code! 👍 I'm going to send over a few commits to add dynamic testing from GeoJSON point features in |
@DenisCarriere so this is the way to go for any (new) module now, right?
I started this module by cloning the |
@stebogit ideally every module should have dynamic testing and you shouldn't have to touch the source code of the Just added dynamic tests via 57b0717. Noticed an issue with:
And an error with:
|
This might be handy to have 65c3c36
|
Different OS has minor differences in coordinate decimals, truncate normalizes the results to pass on all different OS
@DenisCarriere I don't understand exactly how to run |
@stebogit Are you running on MacOS or Linux? You can simply just execute it via the terminal/command line.
In windows you might need to add
|
@stebogit You might be interested to know that there's already a https://github.com/Turfjs/turf/blob/master/packages/turf-invariant/index.js#L22-L50 |
This `sector-error.geojson` seems to be having some issues, it should be the inverse. - bearing1 = -15 (345) - bearing2 = -50 (310) CC: @stebogit
Added test case
I'm sure this would be resolved if we have a 100% tested @stebogit 👍 We are almost there!! |
packages/turf-sector/bench.js
Outdated
* sector3 x 38,093 ops/sec ±2.97% (77 runs sampled) | ||
* sector4 x 210,468 ops/sec ±2.58% (78 runs sampled) | ||
* sector5 x 26,438 ops/sec ±9.98% (70 runs sampled) | ||
* sector6 x 29,032 ops/sec ±2.36% (70 runs sampled) | ||
*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@DenisCarriere I thought to run bench.js
and it turned out it worked 😆 (I guess)
I don't understand though if the result is good, I mean how do I evaluate these numbers, what do they mean?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well the results will vary based on each machine, however it's a good performance gauge when you are trying to tweak a specific function.
Let's say you want to know if map()
is faster than featureEach()
, you can run the benchmark and then change the function and run the benchmark again to see which one has better performance.
Also when refactoring existing code, you might want to know if your "new" code is actually improving the performance or decreasing it. My @turf/buffer
attempt is a good example of refactoring gone bad 🤦♂️ #656 (fail me)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so higher ops/sec
means better performance, right?
then you might want to re-run bench.js
here, as I'm sure my old macbook air here at home is slower than your machine...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes higher ops/sec
is better.
The Benchmark results are approximate, it gives you a good idea where the module stands.
@DenisCarriere since we have now more than one module having angles/bearing as input, I think the |
@stebogit 👍 for I'm sure there's a few other TurfJS modules that have this type of function internally built in, you could poke around and see if you could include it in other modules. |
@DenisCarriere may/should I add this task as a new issue and assign it to myself then? |
@stebogit Yep, make a new issue or open up a new PR and briefly explain it. Usually I let a PR sit for a few days and review it again with a fresh mindset, you might find a better name for |
@DenisCarriere what about |
@stebogit 👍 I like it a lot! A lot better than the previous method name. I think you've got a winner there! |
@DenisCarriere I believe this module might be ready for merging, after your blessing 😃 |
@stebogit ✋ High Five! Looks great! |
@DenisCarriere Great, thanks! 🎉 |
Strange, might be an issue on the GitHub Network graph. I simply merged it via this PR, nothing special (maybe check again tomorrow, might be a delay). Regardless, it's always best to delete the branch after it's been merged (if no more work is going to happen on that branch). |
@stebogit Reference the network graph. Maybe it's because when I merge I always select the Squash and merge vs. using Create a merge commit (I personally like having a single commit for each individual PRs vs. having 10 new commits for one fix/new module). |
@DenisCarriere I implemented the
turf-sector
module (related to #155 and #649).However I did not create the
README
file cause I thought it was created automatically from the documentation in theindex.js
, but it didn't. Should I create it manually?Not sure if the
index.d.ts
andbench.js
are correct, as I'm not familiar with them.Is that ok if I created the branch in this repo or should I work on my forked one?