Why are IntSlider and FloatSlider completely independent?

[jdemeyer]

It seems that the IntSlider and FloatSlider widgets are implemented completely independently, even though they do essentially the same thing for a different type. I would have expected that both classes would be specializations of, say, NumericSlider or even that there would be just one class which could handle both int and float.

I am asking this question because maybe I want sliders for other kind of numbers (e.g. numpy or SageMath numbers or fractions).

CC @SylvainCorlay

[jasongrout]

It looks like at least the views are shared: https://github.com/ipython/ipywidgets/blob/master/jupyter-js-widgets/src/widget_float.ts#L69

I thought there was more code sharing than apparently there actually is. It sounds like a good idea to refactor common functionality to a base class.

[jdemeyer]

Part of the reason is surely because of traitlets. Traitlets doesn't support something like general "numbers", only Int and Float.

[SylvainCorlay]

Do you think that there is a need for a Number trait type?

[jdemeyer]

There should probably be something like a number meta-trait type, say Number() where the current Int() is essentially equivalent to Number(int) and the current float equivalent to Number(float).

But I don't know anything about traitlets to be honest...

[SylvainCorlay]

Wow, we haven't gotten into meta trait types yet (like c++ templates )! 😄

That would be cool though. I was more thinking of a trait like Any that validate anything that is an instance of numbers.Number.

[jdemeyer]

Wow, we haven't gotten into meta trait types yet (like c++ templates )! 😄

Well, you have Union which is a kind of meta-trait type.

[SylvainCorlay]

@minrk what do you think of a Real trait type corresponding to numbers.Real? That would be a good match for javascript's Number.

[SylvainCorlay]

Well, you have Union which is a kind of meta-trait type.

Not quite, I meant parameterized trait types :) - although we have Instance, but it is an identity, not some computation based on types.

[jdemeyer]

@minrk what do you think of a Real trait type corresponding to numbers.Real. That would be a good match for javascript's Number.

That would be useful, but it would just be Number(numbers.Real) in my proposal.

You could consider just changing Float to accept any numbers.Real instance as value, but I don't know how much that would break stuff.

[SylvainCorlay]

You could consider just changing Float to accept any numbers.Real instance as value, but I don't know how much that would break stuff.

Changing Float to Number(float) would probably work...

[minrk]

A Number(SomeABC) trait sounds reasonable to me. This is mostly the same as what you already get with Instance(Type), but presumably Number would also get things like bounds.

[SylvainCorlay]

Yeah, I was thinking of matching the numbers hierarchy (Number encompasses Complex...)

[jdemeyer]

Yeah, I was thinking of matching the numbers hierarchy

I don't see how that would work, since those are abstract types. I don't see the point of making a difference between IntegralSlider() and RationalSlider() for example.

You need concrete types for this because you want to control the type of widget.value. That's why I would propose something like NumericSlider(t) taking a type t as argument. This type should satisfy issubclass(t, Real).

[SylvainCorlay]

You need concrete types for this because you want to control the type of widget.value. That's why I would propose something like NumericSlider(t) taking a type t as argument. This type should satisfy issubclass(t, Real).

That is exactly what I had in mind. Just that complex is not an option :)

[jdemeyer]

That is exactly what I had in mind. Just that complex is not an option :)

But that's not at all "matching the numbers hierarchy", so I'm confused now...

[SylvainCorlay]

But that's not at all "matching the numbers hierarchy", so I'm confused now...

I meant creating traittypes for the different levels of the numbers hierarchy.

[jdemeyer]

I meant creating traittypes for the different levels of the numbers hierarchy.

You mean concrete trait types like RealNumber() or you mean meta-trait types like RealNumber(float)?

Like I said before, I would really prefer to determine the concrete type of widget.value (like you currently do with IntSlider and FloatSlider), not just anything which is an instance of numbers.Real.

[SylvainCorlay]

You mean concrete trait types like RealNumber() or you mean meta-trait types like RealNumber(float)?

The former.

[jdemeyer]

The former.

But that wouldn't solve my problem...

[SylvainCorlay]

My proposal is

• create Number and Real trait types
• potentially collapse FloatWidget and IntWidget base widget types into a Real widget type?

the latter would be a better match with the js frontend which does not have a notion of int.

[jdemeyer]

the latter would be a better match with the js frontend which does not have a notion of int.

I don't know the internal implementation, but why would the js frontend even need to know the value of the widget? I would prefer if the js widget would be as basic as possible: it should only know "this is a slider with 100 marks and the current value is mark 39".

[jasongrout]

I don't know the internal implementation, but why would the js frontend even need to know the value of the widget?

As an example, our jslink/jsdlink widgets let you hook widget values up on the browser side, so you'd need to know the value there.