-
Notifications
You must be signed in to change notification settings - Fork 298
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
Feature: new Quartiles
from precalculated values
#176
base: master
Are you sure you want to change the base?
Changes from all commits
5f3d801
5244a9f
4c63766
6731126
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -34,6 +34,14 @@ fn make_point_pair(a: BackendCoord, b: BackendCoord, scale: f64) -> [f64; 4] { | |
] | ||
} | ||
|
||
fn make_circle(center: BackendCoord, radius: u32, scale: f64) -> [f64; 4] { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. To me this isn't related to the PR, right? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think @pelekhay added this commit There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So would you mind rebase to the master branch - since you are actually based on the 0.2 branch There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ah my bad, I will rebase |
||
circle( | ||
center.0 as f64 * scale, | ||
center.1 as f64 * scale, | ||
radius as f64 * scale, | ||
) | ||
} | ||
|
||
impl<'a, 'b> PistonBackend<'a, 'b> { | ||
pub fn new(size: (u32, u32), scale: f64, context: Context, graphics: &'b mut G2d<'a>) -> Self { | ||
Self { | ||
|
@@ -150,7 +158,7 @@ impl<'a, 'b> DrawingBackend for PistonBackend<'a, 'b> { | |
style: &S, | ||
fill: bool, | ||
) -> Result<(), DrawingErrorKind<Self::ErrorType>> { | ||
let rect = circle(center.0 as f64, center.1 as f64, radius as f64); | ||
let rect = make_circle(center, radius, self.scale); | ||
if fill { | ||
ellipse( | ||
make_piston_rgba(&style.as_color()), | ||
|
@@ -204,3 +212,13 @@ pub fn draw_piston_window<F: FnOnce(PistonBackend) -> Result<(), Box<dyn std::er | |
} | ||
None | ||
} | ||
|
||
#[cfg(test)] | ||
mod test { | ||
use super::*; | ||
#[test] | ||
fn test_make_circle() { | ||
assert_eq!(make_circle((1, 1), 0, 1.0), [1.0, 1.0, 0.0, 0.0]); | ||
assert_eq!(make_circle((1, 2), 3, 4.0), [-8.0, -4.0, 24.0, 24.0]); | ||
} | ||
} |
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.
In general, we don't want to panic even if things are going wrong, since we are a library, we want to avoid this kind of panic.
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.
We could either:
Personally I would choose 3 (perhaps with an assertion string to explain what happened). If I calculate or receive quartile values and they are not in order, I want to know very directly that something is wrong.
1 is my next choice, but it could silently smooth over some logic error the user made earlier.
2 has both the previous benefits, but a big fallback since users now have to handle an error variant for what should be a very simple operation.
What do you think?
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.
I don't think we should panic here, since it doesn't deserve that - more importantly, panicking in a library is more like an "unrecoverable error". This is definitely not "an unrecoverable error". In today's Plotters, there are places may panic unexpectedly, but we are constantly working to get rid of them.
In principle, we don't allow any panic unless (1) there's no way handle correctly or (2) we believe panicking is impossible.
I am fine with both 1 and 2, but I am personally prefer 1. Returning result is still an overkill (And panicking in lib is even worse than that). Also if you already copied the data, sorting a 5 elements slice is very lightweight - I believe Rust's sort algorithm has optimizations for small slices.
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.
Ok sounds good, I'll implement option 1 then!