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

Fix log scale calculations #6903

Merged
merged 5 commits into from Jan 14, 2020
Merged

Fix log scale calculations #6903

merged 5 commits into from Jan 14, 2020

Conversation

kurkle
Copy link
Member

@kurkle kurkle commented Jan 4, 2020

My suggestion in addition to #6902

Fixes: #6934

@benmccann
Copy link
Contributor

Can you share the images for data: [0, 0.001, 0.02, 0.3, 4, 50, 600] and data: [0.001, 0.001, 0.02, 0.3, 4, 50, 600] as you did in #6902 so that I can understand what this looks like?

@kurkle
Copy link
Member Author

kurkle commented Jan 4, 2020

test/specs/scale.logarithmic.tests.js Outdated Show resolved Hide resolved
src/scales/scale.logarithmic.js Show resolved Hide resolved
src/scales/scale.logarithmic.js Outdated Show resolved Hide resolved
@@ -69,19 +62,20 @@ const defaultConfig = {
class LogarithmicScale extends Scale {
_parse(raw, index) { // eslint-disable-line no-unused-vars
const value = LinearScaleBase.prototype._parse.apply(this, arguments);
return helpers.isFinite(value) && value >= 0 ? value : undefined;
if (value === 0) {
Copy link
Contributor

Choose a reason for hiding this comment

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

I think I prefer calculating minPositive in _getMinMax rather than handling 0 specially here. (Actually probably what would be nicest is overriding _getMinMax in the log scale, but the _getMinMax logic has gotten so complicated that's a bit harder).

E.g. what if someone has a toggle between linear and log scales and wants to set parsing: false? I think the more we can keep scales out of the parsing business the better.

Copy link
Member Author

Choose a reason for hiding this comment

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

Data with only positive values (and 0) works fine without parsing, if its in the correct format. One needs to set min value to scale manually then, but that would be expected when parsing=false, wouldn't it?
I have a follow-up to make beginAtZero work nicely on log scale, but I'm getting bored with this.

Copy link
Contributor

Choose a reason for hiding this comment

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

In my mind parsing is just that. It doesn't include validation or anything else. But I don't necessarily want to spend more time on this, so if you and @etimberg are both okay with this then so am I

Copy link
Member

@etimberg etimberg left a comment

Choose a reason for hiding this comment

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

The test changes make sense. I didn’t see anything overtly wrong with the code. Am curious as to how beginAtZero would ever be handled since we can’t get to 0.

@kurkle kurkle added this to the Version 3.0 milestone Jan 10, 2020
if (value > me.min && value > 0) {
decimal = (log10(value) - me._startValue) / me._valueRange + me._valueOffset;
if (value === undefined || value === 0) {
value = me.min;
Copy link
Contributor

Choose a reason for hiding this comment

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

can we return null here or something? this seems a little funny and I'm not quite sure why we're doing it

Copy link
Member Author

Choose a reason for hiding this comment

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

Returning min value of scale for 0 (and parsed 0 that will be undefined), so those values are drawn.

Copy link
Contributor

Choose a reason for hiding this comment

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

Why use the scale min instead of undefined though? It seems strange to me to change it to a somewhat arbitrary different value rather than making it undefined

Copy link
Member Author

Choose a reason for hiding this comment

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

Lets make one thing clear, do you think we should continue to draw zero on a log chart or not?

Copy link
Contributor

Choose a reason for hiding this comment

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

I would say we should not

Copy link
Member Author

Choose a reason for hiding this comment

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

There are few fixed issues about that. #4913 fixed some for v2.7.1

If its not clear already, this is not something I want to spend my time with.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ok. I'm not sure how this will work in all cases, but if we need to change it later I suppose we can

@kurkle
Copy link
Member Author

kurkle commented Jan 13, 2020

The test changes make sense. I didn’t see anything overtly wrong with the code. Am curious as to how beginAtZero would ever be handled since we can’t get to 0.

93af7c5

Just lowering the min value so 0 and the lowest non zero are differentiated.

If scale breaks would be implemented, then we could add a break in between.

Copy link
Contributor

@benmccann benmccann left a comment

Choose a reason for hiding this comment

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

Might not be perfect, but seems probably better than the way it currently works

@benmccann
Copy link
Contributor

Just lowering the min value so 0 and the lowest non zero are differentiated.

At first this sounded funny to me, but I after thinking about it for awhile I think this is actually a pretty good default for drawing bar charts on a log scale. I did a google image search for bar chart log scale and lots of them were drawn this way

@etimberg
Copy link
Member

We should find a way to keep that functionality, though I agree that it is out of scope for this PR

@etimberg etimberg merged commit f181797 into chartjs:master Jan 14, 2020
@kurkle kurkle deleted the log branch February 19, 2020 18:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Linechart: NaN values are not skipped when type: 'logarithmic' is used
3 participants