matplotlib-devel Mailing List for matplotlib

Cool.

There is a lot of code there to digest so I don't have anything technically
sensible to say yet, but in principle/abstract this seems like a good idea.

This also ties back into the MEP25 (figure serialization) discussion and
the discussion I was having with Eric Firing in the comments of
https://github.com/matplotlib/matplotlib/pull/4172 (yes, a less than ideal
place) about adopting a more structured framework for mpl artists
attributes(ex make them into IPython Configurable/use traitlets) and the
larger discussion started at scipy last year about providing style sheets.

The current style library and rcparams tools provide (several) context
managers so you can mostly avoid damaging the global state.

The ability to apply style once the figure has been drawn is a feature
request I have seen go by several times.

Another major limitation of the rcparam approach is that to add new
parameters can modifying code pretty deep in the core of the library.

Tom

On Sat, Mar 7, 2015 at 9:39 PM Drain, Theodore R (392P) <
the...@jp...> wrote:

> Last year we implemented an object oriented plotting style system for our
> users and I was able to convince our management that we should open source
> it.  You can find it here:  https://github.com/nasa/mplStyle
>
> Many (most?) of the existing MPL style systems seem to be built around RC
> parameters which doesn't work very well for us.  For a large system that
> can create plots in many different scripts/GUI's, we really can't change
> global settings (RC's) to affect how a plot looks as it ends up screwing up
> plots in other areas.  So we designed an OO based style system that allows
> you to create/save/load styles and apply them to individual plot elements
> (text, lines, axes, figures, etc).
>
> This code was extracted from a much larger project so it wasn't really
> written as a standalone library or designed to follow MPL's naming and
> coding conventions.  i.e. don't assume the internals exhibit any great
> design - I was mostly concerned with getting a stand alone package that
> worked in the minimum amount of effort.  It does work fine, every method
> has documentation, and test cases are included (feel free to email me or
> use github if you find any problems) but my real hope is that it either
> serves as an inspiration for building a standard MPL OO style system (or
> perhaps it can be morphed into that over time).
>
> Some of the features include:
> - Object oriented style objects (no changes to global RC parameters)
> - Apply styles to whole figures or to individual plot elements (artists,
> patches, axes, etc)
> - Save and load styles into human editable files
> - Apply styles by name or by style object
> - Styles remember what they were applied to and can be told to re-apply
> after changes.  This is great way to try out style settings without having
> to regenerate a plot.
> - Plot elements can be tagged with a name.  The tag name can later be used
> as a target in the style application.  This is great feature for plotting
> libraries as it allows a script to create plot elements with a set of names
> and the caller can apply various styles to the plot elements by using those
> names.  This separates plot creation from plot styling and makes plotting
> code much easier to reuse as users don't need to edit the plotting script
> just to change the style of a line.
>
> Please take a look and let us know what you think.
> Ted
> ps: FYI for clarity I wasn't the primary author of this code - James Evans
> get's that honor with various contributions from a variety of people who
> work on our development team.
> ------------------------------------------------------------
> ------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Achyut,

As I am sure everyone else on this list is sick of hearing, I have a book
that will be coming out soon that can help explain many of your questions.
It has a chapter explaining some of the differences between the interactive
backends and how backends work, in general. The book is in the prefinal
stage right now and will be going to the printer in the next week (I hope!).

Stay tuned to this page for updates:
https://www.packtpub.com/application-development/interactive-applications-using-matplotlib

Cheers!
Ben Root



On Sat, Mar 7, 2015 at 9:14 PM, Achyut Rastogi <ras...@gm...>
wrote:

> Thank you Tom
> I read the qt backend and the first comment said about rendering from qt
> to agg, thank for the explaination, so if I don't understand some parts of
> the backend is this where I ask.
>
> On 5:47AM, Sun, Mar 8, 2015 Thomas Caswell <tca...@gm...> wrote:
>
>> Achyut,
>>
>> Thank your for your interest, mpl on touch devices sounds super cool!
>>
>> The easiest course is probably to develop a backend modeled after the
>> {qt,wx,gtk}Agg backends which embed an Agg backend into the gui framework
>> of choice.  In those cases we rely on Agg to handle the mpl specific
>> drawing tasks and then embed the resulting bitmap into the GUI.  A majority
>> of the work in the gui backends deals window/widget creation and the
>> plumbing required to convert interaction events from the GUI into the
>> internal events mpl uses.
>>
>> Tom
>>
>> On Sat, Mar 7, 2015 at 4:15 PM Achyut Rastogi <ras...@gm...>
>> wrote:
>>
>>> Hello , I am a novice gsoc aspirant and I want to write a backend for
>>> kivy, I read some of the other conversations on the mailing list and I know
>>> about the template you guys provide but I am having trouble getting
>>> started, can you please help me get up-to speed. I would be great help if
>>> you could tell me what all I need to know of matplotlib  to write a good
>>> backend.
>>> Thank You
>>> Achyut Rastogi
>>>
>> ------------------------------------------------------------
>>> ------------------
>>> Dive into the World of Parallel Programming The Go Parallel Website,
>>> sponsored
>>> by Intel and developed in partnership with Slashdot Media, is your hub
>>> for all
>>> things parallel software development, from weekly thought leadership
>>> blogs to
>>> news, videos, case studies, tutorials and more. Take a look and join the
>>> conversation now. http://goparallel.sourceforge.net/
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Last year we implemented an object oriented plotting style system for our users and I was able to convince our management that we should open source it.  You can find it here:  https://github.com/nasa/mplStyle

Many (most?) of the existing MPL style systems seem to be built around RC parameters which doesn't work very well for us.  For a large system that can create plots in many different scripts/GUI's, we really can't change global settings (RC's) to affect how a plot looks as it ends up screwing up plots in other areas.  So we designed an OO based style system that allows you to create/save/load styles and apply them to individual plot elements (text, lines, axes, figures, etc).

This code was extracted from a much larger project so it wasn't really written as a standalone library or designed to follow MPL's naming and coding conventions.  i.e. don't assume the internals exhibit any great design - I was mostly concerned with getting a stand alone package that worked in the minimum amount of effort.  It does work fine, every method has documentation, and test cases are included (feel free to email me or use github if you find any problems) but my real hope is that it either serves as an inspiration for building a standard MPL OO style system (or perhaps it can be morphed into that over time).

Some of the features include:
- Object oriented style objects (no changes to global RC parameters)
- Apply styles to whole figures or to individual plot elements (artists, patches, axes, etc)
- Save and load styles into human editable files
- Apply styles by name or by style object
- Styles remember what they were applied to and can be told to re-apply after changes.  This is great way to try out style settings without having to regenerate a plot.
- Plot elements can be tagged with a name.  The tag name can later be used as a target in the style application.  This is great feature for plotting libraries as it allows a script to create plot elements with a set of names and the caller can apply various styles to the plot elements by using those names.  This separates plot creation from plot styling and makes plotting code much easier to reuse as users don't need to edit the plotting script just to change the style of a line.

Please take a look and let us know what you think.  
Ted
ps: FYI for clarity I wasn't the primary author of this code - James Evans get's that honor with various contributions from a variety of people who work on our development team.

Thank you Tom
I read the qt backend and the first comment said about rendering from qt to
agg, thank for the explaination, so if I don't understand some parts of the
backend is this where I ask.

On 5:47AM, Sun, Mar 8, 2015 Thomas Caswell <tca...@gm...> wrote:

> Achyut,
>
> Thank your for your interest, mpl on touch devices sounds super cool!
>
> The easiest course is probably to develop a backend modeled after the
> {qt,wx,gtk}Agg backends which embed an Agg backend into the gui framework
> of choice.  In those cases we rely on Agg to handle the mpl specific
> drawing tasks and then embed the resulting bitmap into the GUI.  A majority
> of the work in the gui backends deals window/widget creation and the
> plumbing required to convert interaction events from the GUI into the
> internal events mpl uses.
>
> Tom
>
> On Sat, Mar 7, 2015 at 4:15 PM Achyut Rastogi <ras...@gm...>
> wrote:
>
>> Hello , I am a novice gsoc aspirant and I want to write a backend for
>> kivy, I read some of the other conversations on the mailing list and I know
>> about the template you guys provide but I am having trouble getting
>> started, can you please help me get up-to speed. I would be great help if
>> you could tell me what all I need to know of matplotlib  to write a good
>> backend.
>> Thank You
>> Achyut Rastogi
>>
> ------------------------------------------------------------
>> ------------------
>> Dive into the World of Parallel Programming The Go Parallel Website,
>> sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub
>> for all
>> things parallel software development, from weekly thought leadership
>> blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>

Sorry for the spam, but I just wanted to say that I now understand that I
should be using plt.xlim to zoom in on the x-axis rather than changing the
bins. When I zoom in with that, the bin height is indeed constant as
expected.

On Sat, Mar 7, 2015 at 8:00 PM, Tomo Lazovich <laz...@gm...> wrote:

> Thanks for the suggestion...I will see how numpy handles this.
>
> Sorry for not being clearer earlier. Tom is right that by "zooming" I
> meant changing the bins so that they covered a smaller range. Is there a
> better way of "zooming" in on an axis so that I don't have this issue?
>
> Thanks!
>
> Tomo
>
> On Sat, Mar 7, 2015 at 7:39 PM, Thomas Caswell <tca...@gm...> wrote:
>
>> Paul,
>>
>> Note that by zoom the op means they are changing the bins, not actual
>> zooming(by just changing the x axis).
>>
>> I was going to say we deal with normalization by delegating to numpy, but
>> we actually handle it internally (with a note that when we drop np 1.5 to
>> make numpy do it).
>> I think the best course of action here is to do that conversion and
>> forward this feature request to numpy (if it does not already do this).
>>
>> Tom
>>
>> On Sat, Mar 7, 2015, 18:29 Paul Hobson <pmh...@gm...> wrote:
>>
>>> IMO, this seems like a bug. I would expect bars to change height with
>>> zoom/limit levels.
>>> -p
>>>
>>> —
>>> Sent from Mailbox <https://www.dropbox.com/mailbox>
>>>
>>>
>>> On Sat, Mar 7, 2015 at 4:20 PM, Tomo Lazovich <laz...@gm...>
>>> wrote:
>>>
>>>> Hello matplotlib developers,
>>>>
>>>> I'm not sure if this is the right mailing list for this question, so
>>>> please re-direct me if it is not.
>>>>
>>>> I am wondering whether it is possible to have a histogram in pyplot
>>>> normalized to the total length of the list input, rather than just the bins
>>>> showing on the plot (i.e. include those entries in the "overflow" and
>>>> "underflow", off the right and left edges of the plot). As far as I can
>>>> tell, the normed option of pyplot.hist currently makes it so that the area
>>>> under the bins showing is 1. This can lead to a situation like the one
>>>> pasted below, where when I look at the whole histogram the bins have
>>>> certain values but when I try to zoom in to see one part of the plot better
>>>> those values change.
>>>>
>>>> I can think of two ways to solve this as of now:
>>>>
>>>> 1) Use the weights option to scale each entry by 1/len(input) rather
>>>> than using normed=True.
>>>> 2) Somehow add the contents of the overflow to the last bin of the
>>>> plot, which would keep the normalizations constant for earlier bins even if
>>>> you extend the axes.
>>>>
>>>> Is there a better way of doing this? If the option does not currently
>>>> exist, I am also happy to help implement it if the community would find it
>>>> desirable.
>>>>
>>>> Thanks for your help!
>>>>
>>>> Tomo Lazovich
>>>>
>>>> P.S. Here is a toy example of what I mean:
>>>>
>>>>  >> import numpy as np
>>>> >> import matplotlib.pyplot as plt
>>>> >> h1 = [0, 0, 0, 1, 1, 2, 3]
>>>> >> my_bins = np.linspace(-0.5, 4.5, 6)
>>>> >> plt.hist(h1, bins=my_bins, normed=True)
>>>> >> plt.show()
>>>>
>>>> gives
>>>>
>>>>  <image.png>
>>>>
>>>>
>>>> Now, if I change the range on the x axis that I would like plot:
>>>>
>>>>  >> my_bins2 = np.linspace(-0.5, 1.5, 3)
>>>> >> plt.hist(h1, bins=my_bins2, normed=True)
>>>> >> plt.show()
>>>>
>>>>  <image.png>
>>>>
>>>>
>>>> The y values have changed to 0.6 and 0.4 because the normalization does
>>>> not include the values that are cut off to the right of the plot.
>>>>
>>>
>>> ------------------------------------------------------------
>>> ------------------
>>> Dive into the World of Parallel Programming The Go Parallel Website,
>>> sponsored
>>> by Intel and developed in partnership with Slashdot Media, is your hub
>>> for all
>>> things parallel software development, from weekly thought leadership
>>> blogs to
>>> news, videos, case studies, tutorials and more. Take a look and join the
>>> conversation now. http://goparallel.sourceforge.net/
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>
>

Thanks for the suggestion...I will see how numpy handles this.

Sorry for not being clearer earlier. Tom is right that by "zooming" I meant
changing the bins so that they covered a smaller range. Is there a better
way of "zooming" in on an axis so that I don't have this issue?

Thanks!

Tomo

On Sat, Mar 7, 2015 at 7:39 PM, Thomas Caswell <tca...@gm...> wrote:

> Paul,
>
> Note that by zoom the op means they are changing the bins, not actual
> zooming(by just changing the x axis).
>
> I was going to say we deal with normalization by delegating to numpy, but
> we actually handle it internally (with a note that when we drop np 1.5 to
> make numpy do it).
> I think the best course of action here is to do that conversion and
> forward this feature request to numpy (if it does not already do this).
>
> Tom
>
> On Sat, Mar 7, 2015, 18:29 Paul Hobson <pmh...@gm...> wrote:
>
>> IMO, this seems like a bug. I would expect bars to change height with
>> zoom/limit levels.
>> -p
>>
>> —
>> Sent from Mailbox <https://www.dropbox.com/mailbox>
>>
>>
>> On Sat, Mar 7, 2015 at 4:20 PM, Tomo Lazovich <laz...@gm...> wrote:
>>
>>> Hello matplotlib developers,
>>>
>>> I'm not sure if this is the right mailing list for this question, so
>>> please re-direct me if it is not.
>>>
>>> I am wondering whether it is possible to have a histogram in pyplot
>>> normalized to the total length of the list input, rather than just the bins
>>> showing on the plot (i.e. include those entries in the "overflow" and
>>> "underflow", off the right and left edges of the plot). As far as I can
>>> tell, the normed option of pyplot.hist currently makes it so that the area
>>> under the bins showing is 1. This can lead to a situation like the one
>>> pasted below, where when I look at the whole histogram the bins have
>>> certain values but when I try to zoom in to see one part of the plot better
>>> those values change.
>>>
>>> I can think of two ways to solve this as of now:
>>>
>>> 1) Use the weights option to scale each entry by 1/len(input) rather
>>> than using normed=True.
>>> 2) Somehow add the contents of the overflow to the last bin of the plot,
>>> which would keep the normalizations constant for earlier bins even if you
>>> extend the axes.
>>>
>>> Is there a better way of doing this? If the option does not currently
>>> exist, I am also happy to help implement it if the community would find it
>>> desirable.
>>>
>>> Thanks for your help!
>>>
>>> Tomo Lazovich
>>>
>>> P.S. Here is a toy example of what I mean:
>>>
>>>  >> import numpy as np
>>> >> import matplotlib.pyplot as plt
>>> >> h1 = [0, 0, 0, 1, 1, 2, 3]
>>> >> my_bins = np.linspace(-0.5, 4.5, 6)
>>> >> plt.hist(h1, bins=my_bins, normed=True)
>>> >> plt.show()
>>>
>>> gives
>>>
>>>  <image.png>
>>>
>>>
>>> Now, if I change the range on the x axis that I would like plot:
>>>
>>>  >> my_bins2 = np.linspace(-0.5, 1.5, 3)
>>> >> plt.hist(h1, bins=my_bins2, normed=True)
>>> >> plt.show()
>>>
>>>  <image.png>
>>>
>>>
>>> The y values have changed to 0.6 and 0.4 because the normalization does
>>> not include the values that are cut off to the right of the plot.
>>>
>>
>> ------------------------------------------------------------
>> ------------------
>> Dive into the World of Parallel Programming The Go Parallel Website,
>> sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub
>> for all
>> things parallel software development, from weekly thought leadership
>> blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>

Paul,

Note that by zoom the op means they are changing the bins, not actual
zooming(by just changing the x axis).

I was going to say we deal with normalization by delegating to numpy, but
we actually handle it internally (with a note that when we drop np 1.5 to
make numpy do it).
I think the best course of action here is to do that conversion and forward
this feature request to numpy (if it does not already do this).

Tom

On Sat, Mar 7, 2015, 18:29 Paul Hobson <pmh...@gm...> wrote:

> IMO, this seems like a bug. I would expect bars to change height with
> zoom/limit levels.
> -p
>
> —
> Sent from Mailbox <https://www.dropbox.com/mailbox>
>
>
> On Sat, Mar 7, 2015 at 4:20 PM, Tomo Lazovich <laz...@gm...> wrote:
>
>> Hello matplotlib developers,
>>
>> I'm not sure if this is the right mailing list for this question, so
>> please re-direct me if it is not.
>>
>> I am wondering whether it is possible to have a histogram in pyplot
>> normalized to the total length of the list input, rather than just the bins
>> showing on the plot (i.e. include those entries in the "overflow" and
>> "underflow", off the right and left edges of the plot). As far as I can
>> tell, the normed option of pyplot.hist currently makes it so that the area
>> under the bins showing is 1. This can lead to a situation like the one
>> pasted below, where when I look at the whole histogram the bins have
>> certain values but when I try to zoom in to see one part of the plot better
>> those values change.
>>
>> I can think of two ways to solve this as of now:
>>
>> 1) Use the weights option to scale each entry by 1/len(input) rather than
>> using normed=True.
>> 2) Somehow add the contents of the overflow to the last bin of the plot,
>> which would keep the normalizations constant for earlier bins even if you
>> extend the axes.
>>
>> Is there a better way of doing this? If the option does not currently
>> exist, I am also happy to help implement it if the community would find it
>> desirable.
>>
>> Thanks for your help!
>>
>> Tomo Lazovich
>>
>> P.S. Here is a toy example of what I mean:
>>
>>  >> import numpy as np
>> >> import matplotlib.pyplot as plt
>> >> h1 = [0, 0, 0, 1, 1, 2, 3]
>> >> my_bins = np.linspace(-0.5, 4.5, 6)
>> >> plt.hist(h1, bins=my_bins, normed=True)
>> >> plt.show()
>>
>> gives
>>
>>  <image.png>
>>
>>
>> Now, if I change the range on the x axis that I would like plot:
>>
>>  >> my_bins2 = np.linspace(-0.5, 1.5, 3)
>> >> plt.hist(h1, bins=my_bins2, normed=True)
>> >> plt.show()
>>
>>  <image.png>
>>
>>
>> The y values have changed to 0.6 and 0.4 because the normalization does
>> not include the values that are cut off to the right of the plot.
>>
>
> ------------------------------------------------------------
> ------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

IMO, this seems like a bug. I would expect bars to change height with zoom/limit levels. 

-p



—
Sent from Mailbox

On Sat, Mar 7, 2015 at 4:20 PM, Tomo Lazovich <laz...@gm...> wrote:

> Hello matplotlib developers,
> I'm not sure if this is the right mailing list for this question, so please
> re-direct me if it is not.
> I am wondering whether it is possible to have a histogram in pyplot
> normalized to the total length of the list input, rather than just the bins
> showing on the plot (i.e. include those entries in the "overflow" and
> "underflow", off the right and left edges of the plot). As far as I can
> tell, the normed option of pyplot.hist currently makes it so that the area
> under the bins showing is 1. This can lead to a situation like the one
> pasted below, where when I look at the whole histogram the bins have
> certain values but when I try to zoom in to see one part of the plot better
> those values change.
> I can think of two ways to solve this as of now:
> 1) Use the weights option to scale each entry by 1/len(input) rather than
> using normed=True.
> 2) Somehow add the contents of the overflow to the last bin of the plot,
> which would keep the normalizations constant for earlier bins even if you
> extend the axes.
> Is there a better way of doing this? If the option does not currently
> exist, I am also happy to help implement it if the community would find it
> desirable.
> Thanks for your help!
> Tomo Lazovich
> P.S. Here is a toy example of what I mean:
>>> import numpy as np
>>> import matplotlib.pyplot as plt
>>> h1 = [0, 0, 0, 1, 1, 2, 3]
>>> my_bins = np.linspace(-0.5, 4.5, 6)
>>> plt.hist(h1, bins=my_bins, normed=True)
>>> plt.show()
> gives
> [image: Inline image 1]
> Now, if I change the range on the x axis that I would like plot:
>>> my_bins2 = np.linspace(-0.5, 1.5, 3)
>>> plt.hist(h1, bins=my_bins2, normed=True)
>>> plt.show()
> [image: Inline image 2]
> The y values have changed to 0.6 and 0.4 because the normalization does not
> include the values that are cut off to the right of the plot.

Hello matplotlib developers,

I'm not sure if this is the right mailing list for this question, so please
re-direct me if it is not.

I am wondering whether it is possible to have a histogram in pyplot
normalized to the total length of the list input, rather than just the bins
showing on the plot (i.e. include those entries in the "overflow" and
"underflow", off the right and left edges of the plot). As far as I can
tell, the normed option of pyplot.hist currently makes it so that the area
under the bins showing is 1. This can lead to a situation like the one
pasted below, where when I look at the whole histogram the bins have
certain values but when I try to zoom in to see one part of the plot better
those values change.

I can think of two ways to solve this as of now:

1) Use the weights option to scale each entry by 1/len(input) rather than
using normed=True.
2) Somehow add the contents of the overflow to the last bin of the plot,
which would keep the normalizations constant for earlier bins even if you
extend the axes.

Is there a better way of doing this? If the option does not currently
exist, I am also happy to help implement it if the community would find it
desirable.

Thanks for your help!

Tomo Lazovich

P.S. Here is a toy example of what I mean:

>> import numpy as np
>> import matplotlib.pyplot as plt
>> h1 = [0, 0, 0, 1, 1, 2, 3]
>> my_bins = np.linspace(-0.5, 4.5, 6)
>> plt.hist(h1, bins=my_bins, normed=True)
>> plt.show()

gives

[image: Inline image 1]

Now, if I change the range on the x axis that I would like plot:

>> my_bins2 = np.linspace(-0.5, 1.5, 3)
>> plt.hist(h1, bins=my_bins2, normed=True)
>> plt.show()

[image: Inline image 2]

The y values have changed to 0.6 and 0.4 because the normalization does not
include the values that are cut off to the right of the plot.

Achyut,

Thank your for your interest, mpl on touch devices sounds super cool!

The easiest course is probably to develop a backend modeled after the
{qt,wx,gtk}Agg backends which embed an Agg backend into the gui framework
of choice.  In those cases we rely on Agg to handle the mpl specific
drawing tasks and then embed the resulting bitmap into the GUI.  A majority
of the work in the gui backends deals window/widget creation and the
plumbing required to convert interaction events from the GUI into the
internal events mpl uses.

Tom

On Sat, Mar 7, 2015 at 4:15 PM Achyut Rastogi <ras...@gm...>
wrote:

> Hello , I am a novice gsoc aspirant and I want to write a backend for
> kivy, I read some of the other conversations on the mailing list and I know
> about the template you guys provide but I am having trouble getting
> started, can you please help me get up-to speed. I would be great help if
> you could tell me what all I need to know of matplotlib  to write a good
> backend.
> Thank You
> Achyut Rastogi
> ------------------------------------------------------------
> ------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>