Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@EmbersArc
Copy link
Contributor

Closes #330

@EmbersArc EmbersArc marked this pull request as ready for review April 23, 2021 14:59
@EmbersArc
Copy link
Contributor Author

Since I created some new files it's difficult to see what's changed, so here's a quick overview:

Copy link
Owner

@emilk emilk left a comment

Choose a reason for hiding this comment

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

Very nice improvements and cleanups!

I left some comments, mainly:

  • keep the plot name so we don't need to introduce a breaking change a
  • keep old functions with a deprecation notice
  • remove Parametric type and compute its values right away

Comment on lines 146 to 147
let range_union = |range1: &RangeInclusive<f64>, range2: &RangeInclusive<f64>| {
range1.start().max(*range2.start())..=range1.end().min(*range2.end())
Copy link
Owner

Choose a reason for hiding this comment

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

This is the intersection; not the union

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 also be better as fn instead of a lambda, since it doesn't capture anything.

/// ```
/// # let ui = &mut egui::Ui::__test();
/// use egui::plot::{Curve, Plot, Value};
/// use egui::plotting::{Curve, Plot, Value};
Copy link
Owner

Choose a reason for hiding this comment

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

This rename will be a breaking change for users. I think we should just call the module plot instead to avoid this.

pub fn include_y(mut self, y: impl Into<f64>) -> Self {
self.min_auto_bounds.extend_with_y(y.into());
self
}
Copy link
Owner

Choose a reason for hiding this comment

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

the diff becomes harder to read when moving around code like this. what is the motivation?


/// If true, the x-bounds will be symmetrical, so that the x=0 zero line
/// is always in the center.
pub fn symmetrical_x_bounds(mut self, symmetrical_x_bounds: bool) -> Self {
Copy link
Owner

Choose a reason for hiding this comment

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

I agree that the new name (center_x_axis) is better, but keep the old function with an added #[deprecated = "Renamed center_x_axis"]

self.bounds.min[1]..=self.bounds.max[1],
(self.rect.bottom() as f64)..=(self.rect.top() as f64), // negated y axis!
// Initialize values from functions.
// TODO: Let the user pick a resolution?
Copy link
Owner

Choose a reason for hiding this comment

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

The from_explicit_callback and from_parametric_callback already does, so this TODO is done?

Comment on lines 146 to 147
.center_x_axis(false)
.center_y_axis(false)
Copy link
Owner

Choose a reason for hiding this comment

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

Since this is the default

Suggested change
.center_x_axis(false)
.center_y_axis(false)

let time = self.time;
Curve::from_explicit_callback(
move |x| 0.5 * (2.0 * x).sin() * time.sin(),
Some((-2.)..=2.),
Copy link
Owner

Choose a reason for hiding this comment

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

I think it would be a good demo for sin to span -INF..=INF

Comment on lines 68 to 71
/// Describes a function y = f(x) with an optional range for x and a number of points.
Explicit(Box<dyn Fn(f64) -> f64>, Option<RangeInclusive<f64>>, usize),
/// Describes a function (x,y) = f(t) with a range for t and a number of points.
Parametric(Box<dyn Fn(f64) -> (f64, f64)>, RangeInclusive<f64>, usize),
Copy link
Owner

Choose a reason for hiding this comment

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

Suggested change
/// Describes a function y = f(x) with an optional range for x and a number of points.
Explicit(Box<dyn Fn(f64) -> f64>, Option<RangeInclusive<f64>>, usize),
/// Describes a function (x,y) = f(t) with a range for t and a number of points.
Parametric(Box<dyn Fn(f64) -> (f64, f64)>, RangeInclusive<f64>, usize),
/// Describes a function y = f(x) with a range for x and a number of points.
Explicit{
y_from_x: Box<dyn Fn(f64) -> f64>,
x_range: RangeInclusive<f64>,
resolution: usize,
},
/// Describes a function (x,y) = f(t) with a range for t and a number of points.
Parametric{
xy_from_t: Box<dyn Fn(f64) -> (f64, f64)>,
t_range: RangeInclusive<f64>,
resolution: usize
},

I see no difference between None range and an -INF..=INF range, so better to unify to the simpler type

t_range: RangeInclusive<f64>,
points: usize,
) -> Self {
let generator = Generator::Parametric(Box::new(function), t_range, points);
Copy link
Owner

Choose a reason for hiding this comment

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

The parametric function always computes all the points, so there is not reason to defer that computation to later as far as I can tell.

If you compute values here instead and pass to Self::from_values we get default bounds and also a speedup, because function doesn't need to be boxed (and doesn't need to be 'static either)

@EmbersArc
Copy link
Contributor Author

Thanks for the review! I agree with your suggestions and made all the changes in 2abfb0f. The remaining commits are just the filename changes.

@emilk emilk merged commit a505d01 into emilk:master Apr 24, 2021
@emilk
Copy link
Owner

emilk commented Apr 24, 2021

Thanks!

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.

Plotting library: More features and cleanup

2 participants