Skip to content
This repository has been archived by the owner on Jun 3, 2024. It is now read-only.

Slider labels not showing when keys are float #159

Open
cgranier opened this issue Feb 10, 2018 · 12 comments
Open

Slider labels not showing when keys are float #159

cgranier opened this issue Feb 10, 2018 · 12 comments

Comments

@cgranier
Copy link

When I create my slider marks like this:

marks={ 10.0: '10.00%', 25.0: '25.00%', 50.0: '50.00%', 75.0: '75.00%', 100.0: '100.00%' }

the slider labels will not show up. I just get a slider with marks but no labels. The marks still work as expected and will filter the chart according to the keys.

image

Using this:

marks={ 10: '10.00%', 25: '25.00%', 50: '50.00%', 75: '75.00%', 100: '100.00%' }

results in a slider with the proper labels underneath. This slider also works as expected (because my values all have .0 as the decimal value, I suppose).

image

@peterscherpelz
Copy link

I'm also having this issue. When the keys are not divisible by 1, it works for the keys to be floats, but when the keys are divisible by 1, marks only appear if the keys used are ints. Because I'm dynamically generating the marks, I'm having to use:
marks={int(i) if i % 1 == 0 else i: '{}'.format(i) for i in points_to_mark}

@dimiboi
Copy link

dimiboi commented Mar 23, 2019

When I use this slider the labels for the min and max values are missing:

dcc.Slider(
    id='opacity-slider',
    min=0.0,
    max=1.0,
    value=0.5,
    step=None,
    marks={opacity: f'{opacity:.1f}' for opacity in [0.0, 0.4, 0.5, 0.6, 1.0]}
)

Seems to be a related issue.

@Arpafaucon
Copy link

Arpafaucon commented Jan 15, 2021

I am observing the same thing as @cgranier. Here are two sliders, built with the same python code

image

At first I was suspecting something wrong happening if marks are placed that are unreachable (not in the form min + x * step) but looking into the numbers that does not seem to be the reason.

Here is the code building the range slider

    slider_element = dcc.RangeSlider(
        id=dict(type="slider", role="input", data=id),
        min=data_range.min,
        max=data_range.max,
        value=[data_range.min, data_range.max],
        step=step,
        marks=mark_labels,
        allowCross=False,
        tooltip=dict(always_visible=True,placement="left") # tested without this line, same problem
    )
  • the first one (Height), that works, was given the following params:
min=1.63,
max=1.89,
step=0.01,
marks={1.63: {'label': '1.63'},
 1.69: {'label': '1.69'},
 1.7599999999999998: {'label': '1.76'},
 1.8199999999999998: {'label': '1.82'},
 1.89: {'label': '1.89'}}
  • the second one (Weight) does not work, and got:
min=61.0,
max=79.0,
step=0.1,
marks={61.0: {'label': '61.0'},
 67.0: {'label': '67.0'},
 73.0: {'label': '73.0'},
 79.0: {'label': '79.0'},
 85.0: {'label': '85.0'}}

Exploring the html code with Firefox dev tools, I noticed that in (1), the 5 marks are contained in a <div class="rc-slider-marks">.
The same div exists for the weight slider, but is empty.

I hope those information can help anyone looking into this to pinpoint the root cause. In the meantime, thanks for dash, it is bringing a real value in our company :)


Proposed work-around
I wrote the following work-around, that works in my case:

    mark_values = np.linspace(min_value, max_value, 5) # whatever computes the position of the marks
    mark_labels = {}
    for mark_val in mark_values:
        # work-around bug reported in https://github.com/plotly/dash-core-components/issues/159
        # if mark keys happen to fall on integers, cast them to int
        if abs(mark_val-round(mark_val)) < 1e-3: # close enough to an int for my use case
            mark_val = int(mark_val)
        mark_labels[mark_val] = {"label": str(round(mark_val, round_decimal))})

    slider = dcc.RangeSlider(
        marks=mark_labels,
        ...)

@hughjward
Copy link

I have run into the same issue three years later, is there a fix or workaround?

@datalowe
Copy link

I have run into the same issue three years later, is there a fix or workaround?

I'm also seeing the same buggy behavior, using Python 3.8.5 and plotly 5.1.0.

@Arpafaucon described a workaround above, and you can see another one in a related plotly forum thread (unlike Arpafaucon's suggestion, this one only works if you don't have any 'actual decimal values' like say 57.2 in your data).

@the-rccg
Copy link

@Arpafaucon answer seems to be the best one.
When I came across this issue a few years ago, I went with rescaling my values to become integers, which works but introduces a new factor that can cause issues with processing.

@crabbixOCE
Copy link

@Arpafaucon workaround is good but seriously how is this still a bug? Just had problems with it today, this thread is 4 and a half years old

@mcstarioni
Copy link

My solution is to add a small Epsilon value to floats, like marks = {0.0 + eps: {'label': 'first'}}

@hamdav
Copy link

hamdav commented Sep 5, 2023

Same problem... Also added an epsilon to the floats but needed to take care to make it negative for the mark on the high end so that it doesn't disappear. e.g. slider goes from 0 to 1 and I have marks every 0.1. then adding 0.00001 will make the last mark at 1.00001 which means it wont show, so I subtract 0.00001 from that one. Anyway, the developers should really fix this one

@carschandler
Copy link

Popping in to confirm that I'm also still getting this bug :)

@danieleongari
Copy link

The "small epsi" solution by @mcstarioni worked for me.

I just note that small-epsi values do overwrite themselves: my use case is that I have a b c where b can be equal to a or c, so:

marks = { a+epsi: ..., b+epsi: ..., b-epsi: ..., c-epsi: ...}

(where ... is like {'label', str(a), 'style': {'color': '#f50'}}") did now work when b==c because c's style overwrites b's.

However this worked:

marks = { a+epsi: ..., b+epsi: ..., c-epsi: ..., b-epsi: ... }

@luggie
Copy link

luggie commented May 20, 2024

Still a bug in 2024 bump

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests