Warning should be raised when log scale is used for negative values about chemiscope

[Luthaf]

Yes, sendWarning is the right function for this! You can call it with a string argument containing the warning message, something like sendWarning("this property contains negative values, taking the log will discard them").

[Luthaf]

This is a good issue for newcomers!

The code to change would be around https://github.com/cosmo-epfl/chemiscope/blob/15bdb4147c3bb022d17a8b67d82fa53fd3145d88/src/map/options.ts#L212, adding a check that all values are positive before applying the operation in the 'log' case.

[3dvkr]

@Luthaf I think a quick array method on the value would do the check. I'm a little stuck on what kind of warning to raise. Should the function return null or would the warning need look like something else?

Edit: I found the sendWarning, just going over how it works now.

[3dvkr]

@Luthaf I think I've got the right idea for what to do, but I'm having a bit of trouble with the linter. I wrote the check as an arrow function, and as per output I added parentheses and semi-colons. It is passing all other tests. Would you know why it's still failing that one with the linter?

[rosecers]

Hi @3dvkr -- looking at #122 right now. I think I intended this issue to apply to the log scaling of the axes, as the sizes are never negative, but rather scaled between the max and min of the property value. This can be seen in the built chemiscope that the log-scaled sizes never make negative values disappear, but rather just get very small. However, when you apply a log scale to the axes, points do disappear. Sorry for the confusion! I should have corrected @Luthaf's original comment.

[Luthaf]

Right, I should have read the surrounding code as well =/. Really sorry about that.

This makes this issue a bit harder to deal with, the code to modify is now the three functions this._options.x.scale.onchange/this._options.y.scale.onchange/this._options.z.scale.onchange; as well as changeRange.

https://github.com/cosmo-epfl/chemiscope/blob/eecc7349b2c31f992930ff7343086a8d98a28e62/src/map/map.ts#L350-L358

https://github.com/cosmo-epfl/chemiscope/blob/eecc7349b2c31f992930ff7343086a8d98a28e62/src/map/map.ts#L362

You can get the values for the coordinates on one axis using this._coordinates(this._option.x, 0)[0] (and similar with this._option.y and this._option.z). The axis style (linear/log) is stored in this._options.x.scale.value/this._options.y.scale.value/this._options.z.scale.value as either 'linear' or 'log'.

[3dvkr]

No problem. Would there be a threshold value that we should check for in the options.ts file? If I understand correctly, we could have the check make sure that the values are above this threshold if the scale mode is log instead of checking that the numbers are positive. I'll need a bit more time to comb through and come up with a plan for the three functions, but the check could acknowledge the issue to users for the time-being?

[Luthaf]

What happen in options.ts is related to the size of the points in the map; but this issue is actually related to using log scale for the x/y/z coordinates of the points in the map.

What @rosecers was saying above is that for the size of the points, scaling happening in options.ts, and we already guarantee that values passed to Math.log are positive by rescaling them between 0 and 1. The code doing this is here: https://github.com/cosmo-epfl/chemiscope/blob/eecc7349b2c31f992930ff7343086a8d98a28e62/src/map/options.ts#L237.

The only thing that needs a check is the corresponding code for x/y/z coordinates of the points. In this case, we use plotly's capabilities to do a logscale plot (setting xaxis.type and friends to 'log'), and do not compute the log ourself.

https://github.com/cosmo-epfl/chemiscope/blob/eecc7349b2c31f992930ff7343086a8d98a28e62/src/map/map.ts#L350-L358

But since taking the log of a negative value results in NaN, the corresponding points are dropped from the map, and that's what the warning would have to be about.

Let me know if I'm unclear 😃

[rosecers]

@3dvkr you're right on with making a threshold -- hypothetically if there's one value at 1E-12 and the rest between 1E-4 and 1E-2, we don't want the map to have the majority of the data squashed to one side and one lone point sitting on its own. Ideally it should be a tunable threshold, what do you think @Luthaf ?

[Luthaf]

There is already a min/max setting for the axis range, which should deal with this. Or are you referring to something different?

[rosecers]

No, I'm talking with respect to this. When going to log scale, the minimum should automatically change to some epsilon > 0. Agreed?

[Luthaf]

I think this is a separate issue from this one 😄. My feeling here is that we should not mess with these value automatically in case the user already set them to something meaningful. If the min is negative, we will get a warning once this improvement is implemented (actually, we don't have to check all values for the warning, only the min). If the min is positive but the data distribution is strange, I'd rather leave it to the user to adapt visualization as they want.

[ceriottm]

Two notes: 1. we may also want to check the max (imagine the case where all values are negative, what's the expected behavior? 2. if there are negative values we should de facto enforce as a minimum the smallest positive value.

…

On Tue, 2 Mar 2021 at 15:10, Guillaume Fraux ***@***.***> wrote: I think this is a separate issue from this one 😄. My feeling here is that we should not mess with these value automatically in case the user already set them to something meaningful. If the min is negative, we will get a warning once this improvement is implemented (actually, we don't have to check all values for the warning, only the min). If the min is positive but the data distribution is strange, I'd rather leave it to the user to adapt visualization as they want. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#109 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIREZ5VYX4Y4JE6NFRDNOTTBTWU7ANCNFSM4XA32N6A> .

[3dvkr]

Hi @Luthaf,

I tried going through the map.ts file, and I can find a min value in line 369, but cannot find where the file checks the scaleMode that the user has selected. I'm also unsure that the min in line 369 is the same min from options.ts.

In map.ts there's also a this._options.size.mode.value, line 550, which is a slightly different path than this.size.mode.value which is what scaleMode is assigned to in options.ts.

They are both properties of a MapOptions-type object/class, but can you please confirm if I've found the correct values/properties in map.ts? By checking if they're log and negative, would that check (this._options.size.mode.value === 'log') be an else if statement around line 553?

[Luthaf]

In map.ts there's also a this._options.size.mode.value, line 550, which is a slightly different path than this.size.mode.value which is what scaleMode is assigned to in options.ts.

this._options in the map is an instance of the MapOptions class defined in options.ts, so these refer to the same value.

But, as mentioned in the message above (#109 (comment)), this issue is not about the size.mode option.

Instead, this is about the axis mode, stored in this._options.x.scale.value/this._options.y.scale.value/this._options.z.scale.value.

I tried going through the map.ts file, and I can find a min value in line 369, but cannot find where the file checks the scaleMode that the user has selected. I'm also unsure that the min in line 369 is the same min from options.ts.

I don't think that the minimal value for coordinates along a given axis is already computed, so you would have to add code to compute it.

---

Overall, the code to modify would be the three callback functions this._options.x.scale.onchange/this._options.y.scale.onchange/this._options.z.scale.onchange. You should compute the min value there directly; and send the warning from there directly as well.

[jakublala]

Fixed in PR #146