What would be the use case for the binary formatter and the hex formatter?

I also don't understand what the linearscale formatter does. Can you add an example?

I developed the Binary and Hex formatters specifically for plotting the output of a Digital-to-Analog Converters versus the input. The x-axis needed to indicate the input bits in a way that was easier to understand than decimal numbers.

LinearScaleFormatter is a way of transforming the values shown on the axis without modifying the underlying data. It can probably be generalized to an arbitrary tick value-to-display value mapping function, but I found it useful to just specify a linear transformation with two points on the input range and two points on the output range.

A sample use-case would be if you had data acquired with say imperial units like quarts, but wanted to display the axis in liters. If you did not want to provide a transformed dataset, you could wrap your existing formatter with something like LinearScaleFormatter(1.0, 0.946353, ax.xaxis.get_major_formatter()) (1qt = 0.946353L). I expect this is much more useful than the other two formatters. I will work on a piece of example code to add to the gallery.

Both the binary and hex formatters could be implemented with (or replaced by?) the StrMethodFormatter.

The example of changing units is something we should get more unit support for, though I feel like much of the underlying infrastructure is there already, but I'm not sure how to use it. Maybe one of the unit examples would be useful.

Both the binary and hex formatters could be implemented with (or replaced by?) the StrMethodFormatter.

I thought so too at first, but it turns out you have to explicitly cast to an int to use b and x formats. The input to Formatter.__call__ is pretty much always a float, even with MaxNLocator(integer=True).

Really strange that it's not defined because you can do 123.0.hex() and get '0x1.ec00000000000p+6' back.

Yeah. Python 3.5.2:

>>> '{:b}'.format(123.0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Unknown format code 'b' for object of type 'float'
>>> '{:x}'.format(123.0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Unknown format code 'x' for object of type 'float'

What I can do is redefine BinaryIntFormatter and HexIntFormatter as a single class and add a paramter type, which would be 'hex', 'bin' or 'oct'.

@QuLogic I have converted BinaryIntFormatter and HexIntFormatter into a single extension of StrMethodFormatter that mainly just converts the input to an integer before calling the super implementation. Thanks for inspiring that idea.

@NelleV Hopefully the new form is more acceptable. While I agree that the original implementation was a bit domain specific, a formatter that handles the conversion to integer properly is much more generally useful.

I will get the bugs out shortly.

For the sake of avoiding adding more very thin classes, I'd suggest simply adding a doc entry suggesting the use of FuncFormatter(lambda x, i: format(int(x), fmt)). This is honestly not that much longer to write than IntegerFormatter(fmt), and much clearer for the reader. Likewise the proposed unsigned kwarg can trivially be implemented by using the - flag in the format string. So I'm fairly strongly -1 on adding such a class.

LinearScaleFormatter is more promising, but should probably be implemented as a general Formatter transformer that simply takes an arbitrary input->output transform callable. Also, following @QuLogic's suggestion I'd like first to know whether the unit machinery is already enough (or close to enough, in which case it should be improved accordingly) to handle this case.

In any case, please make all attributes of these new classes private, unless you have a strong reason to keep them public. Also, please check how LinearScaleFormatter interacts with format_cursor_data.

Current coverage is 61.97% (diff: 87.09%)

Merging #7482 into master will increase coverage by 0.08%

@@             master      #7482   diff @@
==========================================
  Files           173        174     +1   
  Lines         56140      56059    -81   
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
  Hits          34743      34743          
+ Misses        21397      21316    -81   
  Partials          0          0          

Powered by Codecov. Last update 45e4a46...c6741ed

@anntzer. While I agree that IntegerFormatter is a pretty thin wrapper and can generally be omitted, I am not sure that the unsigned keyword can be replaced with a - format (which is the default anyway). In fact, it is part of the reason that I created the class in the first place. unsigned = True does not just remove the minus sign from the number: it causes negative numbers to be treated as n-bit unsigned numbers. Either way, I am fine with making this a recipe in the examples if that is the general concensus.

I will rewrite LinearFormatter as MappingFormatter. The linear transformation can then go into a recipe in the examples section.

Finally, when you say "making the attributes private", do you mean prepending an underscore or something else?

Not sure how the unit infrastructure would help since unit is a bad name for it. The infrastructure is really about registering and working with datatypes and it sounds like this data is in floats/ints.

Oh, I completely misunderstood what "unsigned" does, sorry about that. It's arguably a bit more complicated but this can still be implemented as

FuncFormatter(lambda x, i:
    format(int.from_bytes(int(x).to_bytes(int(x).bit_length() // 8 + 1, "big", signed=True),
                          "big"),
           fmt)

which is not necessarily more legible, but now the argument is instead that this feature may be a bit too specialized? (Again I'm all for adding it in the docs.)

And yes I meant that attributes must be prepended with an underscore. Otherwise it basically becomes impossible later to modify the class while maintaining backcompatibility, as users may be relying on whatever public attributes are present...

OK. I will make all the object attributes private. I would like to keep the transform method public in all the cases though.

@tacaswell I believe that my latest push addresses your immediate concerns.

@anntzer , in reference to your request

Also, please check how LinearScaleFormatter interacts with format_cursor_data.

format_cursor_data is defined in Artist, and does not get overriden by Axes or Axis as far as I can tell. There is no direct interaction with a formatter at all.

If you meant the default implementation of _AxesBase.format_coord, it does in fact use the major formatter's format_data_short method. I will therefore go ahead and made proper references to the remaining methods of the underlying Formatter.

I took all of the advice I got on this thread and made a completely new class called TransformFormatter which allows generic mapping of tick values before plugging them into a different Formatter or formatting function. I then added the two Formatters I had before to an example in the documentation since they are now trivial to implement. The new tests verify, among other things, that format_data_short works correctly.

The only major comment that I am no longer following here is that the two attributes of this new class are both public. I think that in this context it makes sense to do it this way, in the same way that FormatStrFormatter exposes the fmt attribute.

Another possible problem is that this class is sensitive to changes in the underlying API. This is probably fine, but I want to add a note to add the appropriate redirects in TransformFormatter if the Formatter or TickHelper methods ever change. Where would I add such a note to future developers?

Finally, I have a purely technical question. At the moment, the axis attribute is a reference shared by the base instance and the underlying formatter. However, this means that the view and data bounds are not transformed for the underlying formatter. Should I make the formatter attribute always have a _DummyAxis assigned to it with the transformed bounds? Or is the way I currently did it going to work OK?

Could someone please explain why the appveyor test is failing while the same configuration in Travis is passing? Is it something I am missing that can be easily fixed or should I change the test to avoid using unicode strings?

@madphysicist Because windows ;)

Rebased temporarily onto #7965. This is just to make my life easier when #7965 gets merged. Please ignore until then.

As far as I can tell, I have addressed all the issues with this PR. Still waiting on approval from @tacaswell and at least one other reviewer though.

Bump.

I don't think the travis error has anything to do with me...

'nother bump.

@QuLogic Based on your comments, I have greatly simplified the configuration of the linear transform in the example. I hope you like it. I found myself trying to figure out where I was going with the original version and just gave up :)

I made all the other changes you recommended as well.

@madphysicist Sorry this has completely fallen through the cracks (for 4 years!). Are you still interested in working on this?

This had a lot of input, but I'll close for now as orphaned...