matplotlib-devel Mailing List for matplotlib (Page 7)

PYTHON CODE: 

import serial # import Serial Library
import numpy  # Import numpy
import matplotlib.pyplot as plt #import matplotlib library
from drawnow import *
 
tempF= []
pressure= []
 
arduinoData = serial.Serial('com6', 115200) #Creating our serial object
named arduinoData
plt.ion() #Tell matplotlib you want interactive mode to plot live data
cnt=0
 
def makeFig(): #Create a function that makes our desired plot
    plt.ylim(0,500)                                 #Set y min and max
values
    plt.title('Frequency vs Time')      #Plot the title
    plt.grid(True)                                  #Turn the grid on
    plt.ylabel('Frequency (pulses/sec)')                            #Set
ylabels
    plt.plot(tempF, 'ro-', label='pulses/sec')       #plot the temperature
    plt.legend(loc='upper left')                    #plot the legend
  
 
    plt2=plt.twinx()                                #Create a second y axis
    plt.ylim(0,500)                           #Set limits of second y axis-
adjust to readings you are getting
    plt2.plot(pressure, 'b^-', label='Pressure (Pa)') #plot pressure data
    plt2.set_ylabel('Pressrue (Pa)')                    #label second y axis
    plt2.ticklabel_format(useOffset=False)           #Force matplotlib to
NOT autoscale y axis
    plt2.legend(loc='upper right')                  #plot the legend
   
 
while True: # While loop that loops forever
    while (arduinoData.inWaiting()==0): #Wait here until there is data
        pass #do nothing
    arduinoString = arduinoData.readline() #read the line of text from the
serial port
    dataArray = arduinoString.split(',')   #Split it into an array called
dataArray
    temp = float(dataArray[0])           #Convert first element to floating
number and put in temp
    pres = float(dataArray[1])            #Convert second element to
floating number and put in P
    tempF.append(temp)                     #Build our tempF array by
appending temp readings
    pressure.append(pres)                        #Building our pressure
array by appending P readings
    drawnow(makeFig)                       #Call drawnow to update our live
graph
    plt.pause(.000001)                     #Pause Briefly. Important to keep
drawnow from crashing
    cnt=cnt+1
    if(cnt>10):                            #If you have 50 or more points,
delete the first one from the array
        tempF.pop(0)                       #This allows us to just see the
last 50 data points
        pressure.pop(0)
 
 
 
 
 
 
 
 ARDUINO CODE:
 
 
#include "Wire.h"    // imports the wire library for talking over I2C
#include "Adafruit_BMP085.h"  // import the Pressure Sensor Library
Adafruit_BMP085 mySensor;  // create sensor object called mySensor
 
float tempC;  // Variable for holding temp in C
float tempF;  // Variable for holding temp in F
float pressure; //Variable for holding pressure reading
 
void setup(){
Serial.begin(115200); //turn on serial monitor
mySensor.begin();   //initialize mySensor
}
 
void loop() {
tempC = mySensor.readTemperature(); //  Be sure to declare your variables
tempF = tempC*1.8 + 32.; // Convert degrees C to F
pressure=mySensor.readPressure(); //Read Pressure
 
 
Serial.print(tempF);
Serial.print(" , ");
Serial.println(pressure);
delay(250); //Pause between readings.
}
 
 
 
 
 
 
 



--
View this message in context: http://matplotlib.1069221.n5.nabble.com/Problems-with-scrolling-graph-tp45675.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

PYTHON CODE: 

import serial # import Serial Library
import numpy  # Import numpy
import matplotlib.pyplot as plt #import matplotlib library
from drawnow import *
 
tempF= []
pressure= []
 
arduinoData = serial.Serial('com6', 115200) #Creating our serial object
named arduinoData
plt.ion() #Tell matplotlib you want interactive mode to plot live data
cnt=0
 
def makeFig(): #Create a function that makes our desired plot
    plt.ylim(0,500)                                 #Set y min and max
values
    plt.title('Frequency vs Time')      #Plot the title
    plt.grid(True)                                  #Turn the grid on
    plt.ylabel('Frequency (pulses/sec)')                            #Set
ylabels
    plt.plot(tempF, 'ro-', label='pulses/sec')       #plot the temperature
    plt.legend(loc='upper left')                    #plot the legend
  
 
    plt2=plt.twinx()                                #Create a second y axis
    plt.ylim(0,500)                           #Set limits of second y axis-
adjust to readings you are getting
    plt2.plot(pressure, 'b^-', label='Pressure (Pa)') #plot pressure data
    plt2.set_ylabel('Pressrue (Pa)')                    #label second y axis
    plt2.ticklabel_format(useOffset=False)           #Force matplotlib to
NOT autoscale y axis
    plt2.legend(loc='upper right')                  #plot the legend
   
 
while True: # While loop that loops forever
    while (arduinoData.inWaiting()==0): #Wait here until there is data
        pass #do nothing
    arduinoString = arduinoData.readline() #read the line of text from the
serial port
    dataArray = arduinoString.split(',')   #Split it into an array called
dataArray
    temp = float(dataArray[0])           #Convert first element to floating
number and put in temp
    pres = float(dataArray[1])            #Convert second element to
floating number and put in P
    tempF.append(temp)                     #Build our tempF array by
appending temp readings
    pressure.append(pres)                        #Building our pressure
array by appending P readings
    drawnow(makeFig)                       #Call drawnow to update our live
graph
    plt.pause(.000001)                     #Pause Briefly. Important to keep
drawnow from crashing
    cnt=cnt+1
    if(cnt>10):                            #If you have 50 or more points,
delete the first one from the array
        tempF.pop(0)                       #This allows us to just see the
last 50 data points
        pressure.pop(0)
 
 
 
 
 
 
 
 ARDUINO CODE:
 
 
#include "Wire.h"    // imports the wire library for talking over I2C
#include "Adafruit_BMP085.h"  // import the Pressure Sensor Library
Adafruit_BMP085 mySensor;  // create sensor object called mySensor
 
float tempC;  // Variable for holding temp in C
float tempF;  // Variable for holding temp in F
float pressure; //Variable for holding pressure reading
 
void setup(){
Serial.begin(115200); //turn on serial monitor
mySensor.begin();   //initialize mySensor
}
 
void loop() {
tempC = mySensor.readTemperature(); //  Be sure to declare your variables
tempF = tempC*1.8 + 32.; // Convert degrees C to F
pressure=mySensor.readPressure(); //Read Pressure
 
 
Serial.print(tempF);
Serial.print(" , ");
Serial.println(pressure);
delay(250); //Pause between readings.
}
 
 
 
 
 
 
 



--
View this message in context: http://matplotlib.1069221.n5.nabble.com/Problems-with-scrolling-graph-tp45673.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

One of the big advantage of jet as evidenced by these graphs is that for
most of its range, the perceptual delta is above 200 (although it loses
that advantage in black&white). Parula sacrafices a fair amount of
perceptual delta, but stays mostly above 100. All of the options beat or
matches Parula in this respect overall, even in B&W mode.

However, I wonder just how much should we hold fast to a constant
perceptual delta? As we see with grayscale, perceptual delta is not
constant with respect to luminosity. Keep in mind that our "perceptual
delta" measure is just a model, and I don't think it properly takes into
account luminosity. So, perhaps it might make sense to be a little bit
flexible with perceptual delta (maybe something like an exponental decay).
Nothing jerky like Parula or Jet, but something to help us out on the ends
of the map?

By the way, I have seen Parula in action for the display of water vapor
over Africa, and it looks very nice. Perhaps a real-world example image
might be some sort of geographical map of something familiar across all
disciplines like a terrain map of a continent?

Ben Root

On Wed, Jun 3, 2015 at 9:55 AM, Paul Ganssle <pga...@gm...> wrote:

>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I'm also in the B > A > C camp, FWIW. I agree with OceanWolf in that B
> looks most professional. It looks much crisper than the others as well.
>
> On 6/3/2015 08:50, Tony Yu wrote:
> > It doesn't sound like this is going to be decided by email votes, but
> just so the arguments for C don't dominate, my vote would be:
> >
> > B > A >> C
> >
> > C has the least perceptual range (that's quantifiable, right?). Also, I
> find A and B much more aesthetically pleasing (that's obviously debatable).
> In particular, the yellows and blues in C have a slight visual vibration.
> Actually, if you google "visual vibration", one of the first hits is a
> yellow and violet image
> <https://web.njit.edu/~mmp57/visual%20vibration.jpg>
> <https://web.njit.edu/~mmp57/visual%20vibration.jpg>. B would have this
> to a certain extent, but it's much more problematic if those colors are at
> the limits of the colormap range. It looks like A wouldn't have this
> problem at all since it's white point has a very muted yellow tone, so
> maybe I'll switch my vote to A. (Personally, it's a toss up between the
> two; anything but C, if I haven't made myself clear ;)
> >
> > Thanks to Nathaniel and Stéfan for putting this together! Hopefully
> "jet" can be banished soon :)
> >
> > -Tony
> >
> > On Wed, Jun 3, 2015 at 5:20 AM, OceanWolf <jui...@ya...
> <mailto:jui...@ya...> <jui...@ya...>>
> wrote:
> >
> >     Personally, just looking at the images I think B looks more
> >     professional, the others look faded.  With A and B I see more of
> >     "contrast" in the core of the radial image (though that might arise
> from
> >     a combination of my monitor/eyes, though I usually do quite well in
> >     colour perception tests).
> >
> >     I think we really need to see a variety of real examples before we
> make
> >     a decision though, both in application a.k.a different type of
> datasets,
> >     including ones with NaNs; and different graph types, the 3d example
> will
> >     make for a good test as we get the same information twice, from
> height
> >     and colour, which gives us a reference for comparison.
> >
> >     With the NaNs Andreas, why did you pick B over C?  My eyes see B
> going
> >     to white as well, only C as far as I can tell does not go to white.
> >
> >     Looking forward to having a play later :).  I wonder what
> Parula-based
> >     colormap would look like if we were to make it linear... one other
> >     thing, mpl currently doesn't select good bounds with pure
> >     horizontal/vertical lines, making it very difficult (at least for
> me) to
> >     see the perceptual deltas, zoomed in to option_c the line gets
> >     completely hidden by the axes...
> >
> >     On 03/06/15 09:04, Andreas Hilboll wrote:
> >     > On 03.06.2015 08:54, Juan Nunez-Iglesias wrote:
> >     >> You can always use green for NaN with any of these maps...
> >     > In grayscale that then wouldn't be distinguishable at all ...
> >     >
> >     >> On Wed, Jun 3, 2015 at 4:30 PM, Andreas Hilboll <li...@hi...
> <mailto:li...@hi...> <li...@hi...>
> >     >> <mailto:li...@hi... <li...@hi...>
> <mailto:li...@hi...> <li...@hi...>>> wrote:
> >     >>
> >     >>      > I particularly like that A ends on the white end of the
> spectrum
> >     >>
> >     >>      That's exactly why I don't like A that much.
> >     >>
> >     >>      In many plots, I need a color for NaN results. This color
> should not
> >     >>      fall within the normal range of the colormap. In case of B
> and C, it
> >     >>      would be possible to use white as NaN color. When using
> white for NaN
> >     >>      in A, it would just look like large values. So I guess I'm
> voting
> >     >>
> >     >>      B > C > A
> >     >>
> >     >>      -- Andreas.
> >     >>
> >     >>
> ------------------------------------------------------------------------------
> >     >>
> >     >>      _______________________________________________
> >     >>      Matplotlib-devel mailing list
> >     >>      Mat...@li...
> <mailto:Mat...@li...>
> <Mat...@li...>
> >     >>
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >     >>
> >     >>
> >     >
> >
> >
> >
> ------------------------------------------------------------------------------
> >     _______________________________________________
> >     Matplotlib-devel mailing list
> >     Mat...@li...
> <mailto:Mat...@li...>
> <Mat...@li...>
> >     https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> >
> >
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (MingW32)
>
> iQIcBAEBAgAGBQJVbwc8AAoJEM1U/OPZZL77c5oP/1KSJloy7ZBVyCOb2Dv2w7fM
> +cQAHlSBgzff+/hYf4/vDjvo0MOomP3xq7PwjA5Jeg3eln+Y9wDwarCDWZK5+Kh7
> uDil3Rdtx+yC3vUqrICHQkh6Y6b5xiv6eTAV06UA2sUM4TRnXIuLSCCnR/2ntbiY
> NGyl7/NPFeYmFJHtGnMmNLhVIZV5a01oc7J6xb/CqQhuYzzi3NwN2tuS27+ouG2G
> dOXWXn/f2DdHYONXyjFHQG5NeVxm50r27wZkdk9xhfmo7FaI2939xZQfbeFqUdAO
> qspHwddr0PGIQCU8nr/CCzQ93fMPkd3cM3e4Sn1Ulq2yDuQXLIISBkA7ufi45yPt
> q1pmFiv9La6vbZZzLLJ47c90fQ1NAe3Jdj4z1x6H4ZhZe8I2zgBhOO4m8meh+gU6
> XRfBWFvPCMyGOndSaV18L3YJ7NTl0cdUr6iaqoFK+AyZtcGmQbAhYfs+GTGIGaN8
> qyz2Y+HXavYrLO4kQlLoemLeuWo8EDym3zDGe3CgL/7CCDUvEhF5qoyIW67MYWR0
> 8R1byACucRH8bs6sp5cWiwAzWBst+5a1WHQFtva64WclQe2NrD0gyveX+a27XLxQ
> wc2f+nm4MKMfd1Eu8j+i4ln2WeGiAawTagRTakizcU5xfUq8LSzYptOco83HdvH7
> npX4K4yVTam7AtGhFr5y
> =V4np
> -----END PGP SIGNATURE-----
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
I'm also in the B > A > C camp, FWIW. I agree with OceanWolf in that B
looks most professional. It looks much crisper than the others as well.

On 6/3/2015 08:50, Tony Yu wrote:
> It doesn't sound like this is going to be decided by email votes, but just so the arguments for C
don't dominate, my vote would be:
>
> B > A >> C
>
> C has the least perceptual range (that's quantifiable, right?). Also,
I find A and B much more aesthetically pleasing (that's obviously
debatable). In particular, the yellows and blues in C have a slight
visual vibration. Actually, if you google "visual vibration", one of the
first hits is a yellow and violet image
<https://web.njit.edu/~mmp57/visual%20vibration.jpg>. B would have this
to a certain extent, but it's much more problematic if those colors are
at the limits of the colormap range. It looks like A wouldn't have this
problem at all since it's white point has a very muted yellow tone, so
maybe I'll switch my vote to A. (Personally, it's a toss up between the
two; anything but C, if I haven't made myself clear ;)
>
> Thanks to Nathaniel and Stéfan for putting this together! Hopefully
"jet" can be banished soon :)
>
> -Tony
>
> On Wed, Jun 3, 2015 at 5:20 AM, OceanWolf
<jui...@ya... <mailto:jui...@ya...>>
wrote:
>
>     Personally, just looking at the images I think B looks more
>     professional, the others look faded.  With A and B I see more of
>     "contrast" in the core of the radial image (though that might
arise from
>     a combination of my monitor/eyes, though I usually do quite well in
>     colour perception tests).
>
>     I think we really need to see a variety of real examples before we
make
>     a decision though, both in application a.k.a different type of
datasets,
>     including ones with NaNs; and different graph types, the 3d
example will
>     make for a good test as we get the same information twice, from height
>     and colour, which gives us a reference for comparison.
>
>     With the NaNs Andreas, why did you pick B over C?  My eyes see B going
>     to white as well, only C as far as I can tell does not go to white.
>
>     Looking forward to having a play later :).  I wonder what Parula-based
>     colormap would look like if we were to make it linear... one other
>     thing, mpl currently doesn't select good bounds with pure
>     horizontal/vertical lines, making it very difficult (at least for
me) to
>     see the perceptual deltas, zoomed in to option_c the line gets
>     completely hidden by the axes...
>
>     On 03/06/15 09:04, Andreas Hilboll wrote:
>     > On 03.06.2015 08:54, Juan Nunez-Iglesias wrote:
>     >> You can always use green for NaN with any of these maps...
>     > In grayscale that then wouldn't be distinguishable at all ...
>     >
>     >> On Wed, Jun 3, 2015 at 4:30 PM, Andreas Hilboll
<li...@hi... <mailto:li...@hi...>
>     >> <mailto:li...@hi... <mailto:li...@hi...>>> wrote:
>     >>
>     >>      > I particularly like that A ends on the white end of the
spectrum
>     >>
>     >>      That's exactly why I don't like A that much.
>     >>
>     >>      In many plots, I need a color for NaN results. This color
should not
>     >>      fall within the normal range of the colormap. In case of B
and C, it
>     >>      would be possible to use white as NaN color. When using
white for NaN
>     >>      in A, it would just look like large values. So I guess I'm
voting
>     >>
>     >>      B > C > A
>     >>
>     >>      -- Andreas.
>     >>
>     >>     
------------------------------------------------------------------------------
>     >>
>     >>      _______________________________________________
>     >>      Matplotlib-devel mailing list
>     >>      Mat...@li...
<mailto:Mat...@li...>
>     >>      https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>     >>
>     >>
>     >
>
>
>    
------------------------------------------------------------------------------
>     _______________________________________________
>     Matplotlib-devel mailing list
>     Mat...@li...
<mailto:Mat...@li...>
>     https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
>
>
------------------------------------------------------------------------------
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
 
iQIcBAEBAgAGBQJVbwc8AAoJEM1U/OPZZL77c5oP/1KSJloy7ZBVyCOb2Dv2w7fM
+cQAHlSBgzff+/hYf4/vDjvo0MOomP3xq7PwjA5Jeg3eln+Y9wDwarCDWZK5+Kh7
uDil3Rdtx+yC3vUqrICHQkh6Y6b5xiv6eTAV06UA2sUM4TRnXIuLSCCnR/2ntbiY
NGyl7/NPFeYmFJHtGnMmNLhVIZV5a01oc7J6xb/CqQhuYzzi3NwN2tuS27+ouG2G
dOXWXn/f2DdHYONXyjFHQG5NeVxm50r27wZkdk9xhfmo7FaI2939xZQfbeFqUdAO
qspHwddr0PGIQCU8nr/CCzQ93fMPkd3cM3e4Sn1Ulq2yDuQXLIISBkA7ufi45yPt
q1pmFiv9La6vbZZzLLJ47c90fQ1NAe3Jdj4z1x6H4ZhZe8I2zgBhOO4m8meh+gU6
XRfBWFvPCMyGOndSaV18L3YJ7NTl0cdUr6iaqoFK+AyZtcGmQbAhYfs+GTGIGaN8
qyz2Y+HXavYrLO4kQlLoemLeuWo8EDym3zDGe3CgL/7CCDUvEhF5qoyIW67MYWR0
8R1byACucRH8bs6sp5cWiwAzWBst+5a1WHQFtva64WclQe2NrD0gyveX+a27XLxQ
wc2f+nm4MKMfd1Eu8j+i4ln2WeGiAawTagRTakizcU5xfUq8LSzYptOco83HdvH7
npX4K4yVTam7AtGhFr5y
=V4np
-----END PGP SIGNATURE-----

It doesn't sound like this is going to be decided by email votes, but just
so the arguments for C don't dominate, my vote would be:

B > A >> C

C has the least perceptual range (that's quantifiable, right?). Also, I
find A and B much more aesthetically pleasing (that's obviously debatable).
In particular, the yellows and blues in C have a slight visual vibration.
Actually, if you google "visual vibration", one of the first hits is a yellow
and violet image <https://web.njit.edu/~mmp57/visual%20vibration.jpg>. B
would have this to a certain extent, but it's much more problematic if
those colors are at the limits of the colormap range. It looks like A
wouldn't have this problem at all since it's white point has a very muted
yellow tone, so maybe I'll switch my vote to A. (Personally, it's a toss up
between the two; anything but C, if I haven't made myself clear ;)

Thanks to Nathaniel and Stéfan for putting this together! Hopefully "jet"
can be banished soon :)

-Tony

On Wed, Jun 3, 2015 at 5:20 AM, OceanWolf <jui...@ya...>
wrote:

> Personally, just looking at the images I think B looks more
> professional, the others look faded.  With A and B I see more of
> "contrast" in the core of the radial image (though that might arise from
> a combination of my monitor/eyes, though I usually do quite well in
> colour perception tests).
>
> I think we really need to see a variety of real examples before we make
> a decision though, both in application a.k.a different type of datasets,
> including ones with NaNs; and different graph types, the 3d example will
> make for a good test as we get the same information twice, from height
> and colour, which gives us a reference for comparison.
>
> With the NaNs Andreas, why did you pick B over C?  My eyes see B going
> to white as well, only C as far as I can tell does not go to white.
>
> Looking forward to having a play later :).  I wonder what Parula-based
> colormap would look like if we were to make it linear... one other
> thing, mpl currently doesn't select good bounds with pure
> horizontal/vertical lines, making it very difficult (at least for me) to
> see the perceptual deltas, zoomed in to option_c the line gets
> completely hidden by the axes...
>
> On 03/06/15 09:04, Andreas Hilboll wrote:
> > On 03.06.2015 08:54, Juan Nunez-Iglesias wrote:
> >> You can always use green for NaN with any of these maps...
> > In grayscale that then wouldn't be distinguishable at all ...
> >
> >> On Wed, Jun 3, 2015 at 4:30 PM, Andreas Hilboll <li...@hi...
> >> <mailto:li...@hi...>> wrote:
> >>
> >>      > I particularly like that A ends on the white end of the spectrum
> >>
> >>      That's exactly why I don't like A that much.
> >>
> >>      In many plots, I need a color for NaN results. This color should
> not
> >>      fall within the normal range of the colormap. In case of B and C,
> it
> >>      would be possible to use white as NaN color. When using white for
> NaN
> >>      in A, it would just look like large values. So I guess I'm voting
> >>
> >>      B > C > A
> >>
> >>      -- Andreas.
> >>
> >>
> ------------------------------------------------------------------------------
> >>
> >>      _______________________________________________
> >>      Matplotlib-devel mailing list
> >>      Mat...@li...
> >>      https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >>
> >>
> >
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Personally, just looking at the images I think B looks more 
professional, the others look faded.  With A and B I see more of 
"contrast" in the core of the radial image (though that might arise from 
a combination of my monitor/eyes, though I usually do quite well in 
colour perception tests).

I think we really need to see a variety of real examples before we make 
a decision though, both in application a.k.a different type of datasets, 
including ones with NaNs; and different graph types, the 3d example will 
make for a good test as we get the same information twice, from height 
and colour, which gives us a reference for comparison.

With the NaNs Andreas, why did you pick B over C?  My eyes see B going 
to white as well, only C as far as I can tell does not go to white.

Looking forward to having a play later :).  I wonder what Parula-based 
colormap would look like if we were to make it linear... one other 
thing, mpl currently doesn't select good bounds with pure 
horizontal/vertical lines, making it very difficult (at least for me) to 
see the perceptual deltas, zoomed in to option_c the line gets 
completely hidden by the axes...

On 03/06/15 09:04, Andreas Hilboll wrote:
> On 03.06.2015 08:54, Juan Nunez-Iglesias wrote:
>> You can always use green for NaN with any of these maps...
> In grayscale that then wouldn't be distinguishable at all ...
>
>> On Wed, Jun 3, 2015 at 4:30 PM, Andreas Hilboll <li...@hi...
>> <mailto:li...@hi...>> wrote:
>>
>>      > I particularly like that A ends on the white end of the spectrum
>>
>>      That's exactly why I don't like A that much.
>>
>>      In many plots, I need a color for NaN results. This color should not
>>      fall within the normal range of the colormap. In case of B and C, it
>>      would be possible to use white as NaN color. When using white for NaN
>>      in A, it would just look like large values. So I guess I'm voting
>>
>>      B > C > A
>>
>>      -- Andreas.
>>
>>      ------------------------------------------------------------------------------
>>
>>      _______________________________________________
>>      Matplotlib-devel mailing list
>>      Mat...@li...
>>      https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>

Andreas, sure, it would only be available in colour. But there's other ways
to mark NaNs, which, after all, should be exceptional, not a major chunk of
your data. I don't know enough about your use-case to comment on an exact
solution but I do think that NaN display should not drive design.

I second Todd though — I would really love to have all of these available
so people can choose.

But the issue of branding with the default is also important, so that
doesn't diminish the discussion ahead... Which looks like it will be
intense! =)

Juan.

On Wed, Jun 3, 2015 at 5:04 PM, Andreas Hilboll <li...@hi...> wrote:

> On 03.06.2015 08:54, Juan Nunez-Iglesias wrote:
> > You can always use green for NaN with any of these maps...
>
> In grayscale that then wouldn't be distinguishable at all ...
>
> > On Wed, Jun 3, 2015 at 4:30 PM, Andreas Hilboll <li...@hi...
> > <mailto:li...@hi...>> wrote:
> >
> >     > I particularly like that A ends on the white end of the spectrum
> >
> >     That's exactly why I don't like A that much.
> >
> >     In many plots, I need a color for NaN results. This color should not
> >     fall within the normal range of the colormap. In case of B and C, it
> >     would be possible to use white as NaN color. When using white for NaN
> >     in A, it would just look like large values. So I guess I'm voting
> >
> >     B > C > A
> >
> >     -- Andreas.
> >
> >
>  ------------------------------------------------------------------------------
> >
> >     _______________________________________________
> >     Matplotlib-devel mailing list
> >     Mat...@li...
> >     https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
> >
>
>
> --
> -- Andreas.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Wed, Jun 3, 2015 at 3:46 AM, Nathaniel Smith <nj...@po...> wrote:

> Hi all,
>
> As was hinted at in a previous thread, Stéfan van der Walt and I have
> been using some Fancy Color Technology to attempt to design a new
> colormap intended to become matplotlib's new default. (Down with jet!)
>
> Unfortunately, while our Fancy Color Technology includes a
> computational model of perceptual distance, it does not include a
> computational model of aesthetics. So this is where you come in.
>
> We've put up three reasonable candidates at:
>     https://bids.github.io/colormap/
> (along with some well-known colormaps for comparison), and we'd like
> your feedback.
>
> They are all optimal on all of the objective criteria we know how to
> measure. What we need judgements on is which one you like best, both
> aesthetically and as a way of visualizing data. (There are some sample
> plots to look at there, plus you can download them and play with them
> on your own data if you want.)
>
> We especially value input from anyone with anomalous color vision.
> There are some simulations there, but computational models are
> inherently limited here. (It's difficult to ask someone with
> colorblindness "does this look to you, the same way this other picture
> looks to me?")
>
> -n
>

I assume these are all going to be available as colormaps?

I prefer C, the others seem to dark.  Having too much black doesn't strike
me as very aesthetically pleasing.

So I would say C > B > A

On 03.06.2015 08:54, Juan Nunez-Iglesias wrote:
> You can always use green for NaN with any of these maps...

In grayscale that then wouldn't be distinguishable at all ...

> On Wed, Jun 3, 2015 at 4:30 PM, Andreas Hilboll <li...@hi...
> <mailto:li...@hi...>> wrote:
> 
>     > I particularly like that A ends on the white end of the spectrum
> 
>     That's exactly why I don't like A that much.
> 
>     In many plots, I need a color for NaN results. This color should not
>     fall within the normal range of the colormap. In case of B and C, it
>     would be possible to use white as NaN color. When using white for NaN
>     in A, it would just look like large values. So I guess I'm voting
> 
>     B > C > A
> 
>     -- Andreas.
> 
>     ------------------------------------------------------------------------------
> 
>     _______________________________________________
>     Matplotlib-devel mailing list
>     Mat...@li...
>     https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> 


-- 
-- Andreas.

You can always use green for NaN with any of these maps...

—
Sent from Mailbox

On Wed, Jun 3, 2015 at 4:30 PM, Andreas Hilboll <li...@hi...> wrote:

>> I particularly like that A ends on the white end of the spectrum
> That's exactly why I don't like A that much.
> In many plots, I need a color for NaN results.  This color should not
> fall within the normal range of the colormap.  In case of B and C, it
> would be possible to use white as NaN color.  When using white for NaN
> in A, it would just look like large values.  So I guess I'm voting
>    B > C > A
> -- Andreas.
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

> I particularly like that A ends on the white end of the spectrum

That's exactly why I don't like A that much.

In many plots, I need a color for NaN results.  This color should not
fall within the normal range of the colormap.  In case of B and C, it
would be possible to use white as NaN color.  When using white for NaN
in A, it would just look like large values.  So I guess I'm voting

   B > C > A

-- Andreas.

On Tue, Jun 2, 2015 at 10:03 PM, Paul Ivanov <pi...@be...> wrote:
> 1. C
> 2. B
> 3. A
>
> But I wouldn't call them aesthetic - the purple in there just looks off -
> I'd prefer something like hot, afmhot, or gist_heat - or variations on
> those.

It turns out that it's very difficult to go ~blue to anything like a
red to ~white/yellow, while keeping to our other constraints
(perceptual uniformity in both color and black-and-white). The problem
is that red is way off in a corner of the sRGB color space --
basically anything near red but brighter takes you outside of sRGB.
But you *must* get brighter at a constant rate, while you can only
move away from the corner at a fixed speed, so you tend to
overshoot...

That said, if you want to play around with the editor tool, it's
linked on the webpage :-). Drag to move spline control points,
shift-click to add a control point, control-click to delete a control
point, bottom bars let you set the min/max lightness, and click the
colormap on the side to select which hue/saturation slice of color
space you want the left pane to show. (The game is to keep the yellow
dot inside the slice.) If it starts acting weird try tapping your
modifier keys, sometimes that fixes things.

> Since this thread is bound to get plenty of attention (I suggest getting
> feedback from -users, too), we would be remiss if we didn't point those who
> didn't already see the writeup of colormaps that  Kristen Thyng and
> colleagues did in the docs [1]. Also, I added a pointer to this thread over
> on #875 [2].
>
> 1. http://matplotlib.org/users/colormaps.html
> 2. https://github.com/matplotlib/matplotlib/issues/875

I'm not on -users, but please do distribute the link far and wide to
whoever you think might be interested! With, again, major bonus points
for feedback on colorblindness-friendliness and readability under
adverse display conditions like lousy projectors, since IMO at this
point they're all pretty decent when viewed under optimal conditions.

-n

-- 
Nathaniel J. Smith -- http://vorpus.org

It's astonishing how many different opinions we have!

Anyway, first of all, a big thank you to Nathaniel and Stéfan for some
kick-ass work. I'm amazed at the perceptual delta results for Parula... 8-O
Good to know that MPL will not make the same mistake.

Second, my preferences:

A > B > C.

I particularly like that A ends on the white end of the spectrum, giving it
a "softer" look and a better gradation in grayscale. I'd discard C out of
hand because it doesn't span the full luminance range, which is measured by
the much lower total perceptual delta in grayscale mode.

I'd also discard Paul's vote out of hand since he voted for C. =P

Finally, here's a nice wikipedia article to tally the votes:
https://en.wikipedia.org/wiki/Condorcet_criterion

;)

Juan.

On Wed, Jun 3, 2015 at 3:03 PM, Paul Ivanov <pi...@be...> wrote:

> 1. C
> 2. B
> 3. A
>
> But I wouldn't call them aesthetic - the purple in there just looks off -
> I'd prefer something like hot, afmhot, or gist_heat - or variations on
> those.
>
> Since this thread is bound to get plenty of attention (I suggest getting
> feedback from -users, too), we would be remiss if we didn't point those who
> didn't already see the writeup of colormaps that  Kristen Thyng and
> colleagues did in the docs [1]. Also, I added a pointer to this thread over
> on #875 [2].
>
> 1. http://matplotlib.org/users/colormaps.html
> 2. https://github.com/matplotlib/matplotlib/issues/875
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

1. C
2. B
3. A

But I wouldn't call them aesthetic - the purple in there just looks off -
I'd prefer something like hot, afmhot, or gist_heat - or variations on
those.

Since this thread is bound to get plenty of attention (I suggest getting
feedback from -users, too), we would be remiss if we didn't point those who
didn't already see the writeup of colormaps that  Kristen Thyng and
colleagues did in the docs [1]. Also, I added a pointer to this thread over
on #875 [2].

1. http://matplotlib.org/users/colormaps.html
2. https://github.com/matplotlib/matplotlib/issues/875

On Tue, Jun 2, 2015 at 9:01 PM, Olga Botvinnik <obo...@uc...> wrote:
> Great work! Very nice post describing the methodology. I especially like the
> choice of images you used to expose differences between colormaps.

Thanks!

> My ranking is:
> 1. C
> 2. A
> 3. B
>
> To my eyes, C has the highest dynamic range (somehow the opposite of Eric!)
> and I like the purple/blue undertone in the dark colors.

Unfortunately it's going to depend a bit on individual variations in
monitors (and eyes!).

Bonus points for anyone who sends in feedback based on viewing the
test images on your department's most terrible projector :-).

-n

-- 
Nathaniel J. Smith -- http://vorpus.org

Great work! Very nice post describing the methodology. I especially like
the choice of images you used to expose differences between colormaps.

My ranking is:
1. C
2. A
3. B

To my eyes, C has the highest dynamic range (somehow the opposite of Eric!)
and I like the purple/blue undertone in the dark colors.

On Tue, Jun 2, 2015 at 8:00 PM Eric Firing <ef...@ha...> wrote:

> On 2015/06/02 3:46 PM, Nathaniel Smith wrote:
> > Hi all,
> >
> > As was hinted at in a previous thread, Stéfan van der Walt and I have
> > been using some Fancy Color Technology to attempt to design a new
> > colormap intended to become matplotlib's new default. (Down with jet!)
> >
> > Unfortunately, while our Fancy Color Technology includes a
> > computational model of perceptual distance, it does not include a
> > computational model of aesthetics. So this is where you come in.
> >
> > We've put up three reasonable candidates at:
> >      https://bids.github.io/colormap/
> > (along with some well-known colormaps for comparison), and we'd like
> > your feedback.
>
> Thank you!
>
> I am leaning toward B; to me, it seems to have a little more dynamic
> range than the other two, and a better range and balance of colors.  I
> can imagine situations in which A or C might be better; we can have all
> three available as named options, but I think B will server best as the
> default.
>
> Eric
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On 2015/06/02 3:46 PM, Nathaniel Smith wrote:
> Hi all,
>
> As was hinted at in a previous thread, Stéfan van der Walt and I have
> been using some Fancy Color Technology to attempt to design a new
> colormap intended to become matplotlib's new default. (Down with jet!)
>
> Unfortunately, while our Fancy Color Technology includes a
> computational model of perceptual distance, it does not include a
> computational model of aesthetics. So this is where you come in.
>
> We've put up three reasonable candidates at:
>      https://bids.github.io/colormap/
> (along with some well-known colormaps for comparison), and we'd like
> your feedback.

Thank you!

I am leaning toward B; to me, it seems to have a little more dynamic 
range than the other two, and a better range and balance of colors.  I 
can imagine situations in which A or C might be better; we can have all 
three available as named options, but I think B will server best as the 
default.

Eric

Sorry for send you two emails, Nathaniel.

I'm going to vote for A with C as a close second.

Of the three, B looks the most "bandy" to me (but not overly so).
-p

On Tue, Jun 2, 2015 at 6:46 PM, Nathaniel Smith <nj...@po...> wrote:

> Hi all,
>
> As was hinted at in a previous thread, Stéfan van der Walt and I have
> been using some Fancy Color Technology to attempt to design a new
> colormap intended to become matplotlib's new default. (Down with jet!)
>
> Unfortunately, while our Fancy Color Technology includes a
> computational model of perceptual distance, it does not include a
> computational model of aesthetics. So this is where you come in.
>
> We've put up three reasonable candidates at:
>     https://bids.github.io/colormap/
> (along with some well-known colormaps for comparison), and we'd like
> your feedback.
>
> They are all optimal on all of the objective criteria we know how to
> measure. What we need judgements on is which one you like best, both
> aesthetically and as a way of visualizing data. (There are some sample
> plots to look at there, plus you can download them and play with them
> on your own data if you want.)
>
> We especially value input from anyone with anomalous color vision.
> There are some simulations there, but computational models are
> inherently limited here. (It's difficult to ask someone with
> colorblindness "does this look to you, the same way this other picture
> looks to me?")
>
> -n
>
> --
> Nathaniel J. Smith -- http://vorpus.org
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Hi all,

As was hinted at in a previous thread, Stéfan van der Walt and I have
been using some Fancy Color Technology to attempt to design a new
colormap intended to become matplotlib's new default. (Down with jet!)

Unfortunately, while our Fancy Color Technology includes a
computational model of perceptual distance, it does not include a
computational model of aesthetics. So this is where you come in.

We've put up three reasonable candidates at:
    https://bids.github.io/colormap/
(along with some well-known colormaps for comparison), and we'd like
your feedback.

They are all optimal on all of the objective criteria we know how to
measure. What we need judgements on is which one you like best, both
aesthetically and as a way of visualizing data. (There are some sample
plots to look at there, plus you can download them and play with them
on your own data if you want.)

We especially value input from anyone with anomalous color vision.
There are some simulations there, but computational models are
inherently limited here. (It's difficult to ask someone with
colorblindness "does this look to you, the same way this other picture
looks to me?")

-n

-- 
Nathaniel J. Smith -- http://vorpus.org

There is a proof-of-concept implementation of this by Matthias

http://carreau.github.io/posts/09-Matplotlib-And-IPython-Config.html

Tom

On Fri, May 15, 2015 at 4:40 PM Brian Granger <ell...@gm...> wrote:

> OK i have the MEP for this on my todo list...
>
> On Thu, May 14, 2015 at 5:47 AM, Benjamin Root <ben...@ou...> wrote:
>
>> You could start up a Pull Request describing a MEP that would outline how
>> traitlets would be used. The discussion can go on there to flesh out the
>> concepts and the guidance documentation. Once that is agreed upon, that PR
>> would get merged, and we can then start up a new PR actually implementing
>> the MEP.
>>
>> On Thu, May 14, 2015 at 3:03 AM, Brian Granger <ell...@gm...>
>> wrote:
>>
>>> Great, that is exciting. What do you think is the best way forward?
>>> Should I open an issue on the matplotlib repo about this? Would there be
>>> interest in doing a Google+ hangout about this at some point?
>>>
>>> On Wed, May 13, 2015 at 11:57 PM, Eric Firing <ef...@ha...>
>>> wrote:
>>>
>>>> On 2015/05/13 7:45 PM, Brian Granger wrote:
>>>>
>>>>> We (ipython/jupyter) have been talking some more about integrating
>>>>> matplotlilb in deeper ways with the interactive widgets framework. That
>>>>> only thing that would be required to make this *trivial* is having a
>>>>> traitlet's based API for matplotlib. I have even started to look at
>>>>> wrapping the existing mpl OO API using traitlets to start to explore
>>>>> this. Once this was done, it would be quite easy to autogenerate UIs
>>>>> for
>>>>> any aspect of Matplotlib.
>>>>>
>>>>> Now that traitlets is a standalone pure python package:
>>>>>
>>>>> https://github.com/ipython/traitlets
>>>>>
>>>>> this would be much easier to pull off.
>>>>>
>>>>> If there is interest in this, we might even be able to help do some of
>>>>> the work. Let us know if there is enough interest to discuss this
>>>>> further.
>>>>>
>>>>
>>>> No question about it: there is more than enough interest.
>>>>
>>>> Eric
>>>>
>>>>
>>>>> Cheers,
>>>>>
>>>>> Brian
>>>>>
>>>>> On Wed, May 13, 2015 at 9:36 PM, Eric Firing <ef...@ha...
>>>>> <mailto:ef...@ha...>> wrote:
>>>>>
>>>>>     On 2015/05/13 5:47 PM, Neil Girdhar wrote:
>>>>>     > You're right.  My angle is I just want the setters and getters.
>>>>> Writing
>>>>>     > set_ and get_ feels like the C++ prison I thought I had escaped
>>>>> :)
>>>>>     >
>>>>>     John Hunter once commented that if he were doing it over again he
>>>>> would
>>>>>     not have put in all the set_ and get_; they were a legacy of his
>>>>> origins
>>>>>     as a C++ programmer.  I think he would have started with simple
>>>>>     attributes, which would have been adequate in the early stages.
>>>>>     Properties were very new--only introduced in Python 2.2, at the end
>>>>>     of 2001.
>>>>>
>>>>>     Eric
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>>     One dashboard for servers and applications across
>>>>> Physical-Virtual-Cloud
>>>>>     Widest out-of-the-box monitoring support with 50+ applications
>>>>>     Performance metrics, stats and reports that give you Actionable
>>>>> Insights
>>>>>     Deep dive visibility with transaction tracing using APM Insight.
>>>>>     http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>>>>>     _______________________________________________
>>>>>     Matplotlib-devel mailing list
>>>>>     Mat...@li...
>>>>>     <mailto:Mat...@li...>
>>>>>     https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Brian E. Granger
>>>>> Cal Poly State University, San Luis Obispo
>>>>> @ellisonbg on Twitter and GitHub
>>>>> bgr...@ca... <mailto:bgr...@ca...> and
>>>>> ell...@gm... <mailto:ell...@gm...>
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Brian E. Granger
>>> Cal Poly State University, San Luis Obispo
>>> @ellisonbg on Twitter and GitHub
>>> bgr...@ca... and ell...@gm...
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> One dashboard for servers and applications across Physical-Virtual-Cloud
>>> Widest out-of-the-box monitoring support with 50+ applications
>>> Performance metrics, stats and reports that give you Actionable Insights
>>> Deep dive visibility with transaction tracing using APM Insight.
>>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>>
>>
>
>
> --
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
> @ellisonbg on Twitter and GitHub
> bgr...@ca... and ell...@gm...
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

There is an on-going discussion over on the pandas issue tracker about how
to 'pipe' a dataframe into an arbitrary function.  This is relevant to mpl
as one of the primary use-case for this is plotting.

https://github.com/pydata/pandas/issues/10129

It would be good if more mpl developers than just me had eyes on this.

Tom

After you've setup your development environment with all of the MPL
dependencies, navigate to the MPL source directory and install it with:

$ python setup.py develop

or

$ pip install -e .

That'll create a link in site-packages (or whatever that directory is) to
the source directory. After you make changes to the source code, you'll
either need to use the "imp" module to reload MPL and the submodule you
changed. I typically find it easier to just restart my python interpreter.
-Paul

On Sat, May 16, 2015 at 1:45 PM, Neil Girdhar <mis...@gm...> wrote:

> How do I set it up so that I can import my local matplotlib dev copy?
>
> I tried making a sym-link to matplotlib/lib/matplotlib, but it's giving me
> errors:
>
>     import matplotlib.transforms as mtransforms
> AttributeError: 'module' object has no attribute 'transforms'
>
> Thanks,
>
> Neil
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

How do I set it up so that I can import my local matplotlib dev copy?

I tried making a sym-link to matplotlib/lib/matplotlib, but it's giving me
errors:

    import matplotlib.transforms as mtransforms
AttributeError: 'module' object has no attribute 'transforms'

Thanks,

Neil

OK i have the MEP for this on my todo list...

On Thu, May 14, 2015 at 5:47 AM, Benjamin Root <ben...@ou...> wrote:

> You could start up a Pull Request describing a MEP that would outline how
> traitlets would be used. The discussion can go on there to flesh out the
> concepts and the guidance documentation. Once that is agreed upon, that PR
> would get merged, and we can then start up a new PR actually implementing
> the MEP.
>
> On Thu, May 14, 2015 at 3:03 AM, Brian Granger <ell...@gm...>
> wrote:
>
>> Great, that is exciting. What do you think is the best way forward?
>> Should I open an issue on the matplotlib repo about this? Would there be
>> interest in doing a Google+ hangout about this at some point?
>>
>> On Wed, May 13, 2015 at 11:57 PM, Eric Firing <ef...@ha...> wrote:
>>
>>> On 2015/05/13 7:45 PM, Brian Granger wrote:
>>>
>>>> We (ipython/jupyter) have been talking some more about integrating
>>>> matplotlilb in deeper ways with the interactive widgets framework. That
>>>> only thing that would be required to make this *trivial* is having a
>>>> traitlet's based API for matplotlib. I have even started to look at
>>>> wrapping the existing mpl OO API using traitlets to start to explore
>>>> this. Once this was done, it would be quite easy to autogenerate UIs for
>>>> any aspect of Matplotlib.
>>>>
>>>> Now that traitlets is a standalone pure python package:
>>>>
>>>> https://github.com/ipython/traitlets
>>>>
>>>> this would be much easier to pull off.
>>>>
>>>> If there is interest in this, we might even be able to help do some of
>>>> the work. Let us know if there is enough interest to discuss this
>>>> further.
>>>>
>>>
>>> No question about it: there is more than enough interest.
>>>
>>> Eric
>>>
>>>
>>>> Cheers,
>>>>
>>>> Brian
>>>>
>>>> On Wed, May 13, 2015 at 9:36 PM, Eric Firing <ef...@ha...
>>>> <mailto:ef...@ha...>> wrote:
>>>>
>>>>     On 2015/05/13 5:47 PM, Neil Girdhar wrote:
>>>>     > You're right.  My angle is I just want the setters and getters.
>>>> Writing
>>>>     > set_ and get_ feels like the C++ prison I thought I had escaped :)
>>>>     >
>>>>     John Hunter once commented that if he were doing it over again he
>>>> would
>>>>     not have put in all the set_ and get_; they were a legacy of his
>>>> origins
>>>>     as a C++ programmer.  I think he would have started with simple
>>>>     attributes, which would have been adequate in the early stages.
>>>>     Properties were very new--only introduced in Python 2.2, at the end
>>>>     of 2001.
>>>>
>>>>     Eric
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>>     One dashboard for servers and applications across
>>>> Physical-Virtual-Cloud
>>>>     Widest out-of-the-box monitoring support with 50+ applications
>>>>     Performance metrics, stats and reports that give you Actionable
>>>> Insights
>>>>     Deep dive visibility with transaction tracing using APM Insight.
>>>>     http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>>>>     _______________________________________________
>>>>     Matplotlib-devel mailing list
>>>>     Mat...@li...
>>>>     <mailto:Mat...@li...>
>>>>     https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Brian E. Granger
>>>> Cal Poly State University, San Luis Obispo
>>>> @ellisonbg on Twitter and GitHub
>>>> bgr...@ca... <mailto:bgr...@ca...> and
>>>> ell...@gm... <mailto:ell...@gm...>
>>>>
>>>
>>>
>>
>>
>> --
>> Brian E. Granger
>> Cal Poly State University, San Luis Obispo
>> @ellisonbg on Twitter and GitHub
>> bgr...@ca... and ell...@gm...
>>
>>
>> ------------------------------------------------------------------------------
>> One dashboard for servers and applications across Physical-Virtual-Cloud
>> Widest out-of-the-box monitoring support with 50+ applications
>> Performance metrics, stats and reports that give you Actionable Insights
>> Deep dive visibility with transaction tracing using APM Insight.
>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>


-- 
Brian E. Granger
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgr...@ca... and ell...@gm...

Come to think of it, I think the inheritance of draw and fill attributes
that happen along the path would take advantage of traitlets if you guys
decide to go that route.

On Fri, May 15, 2015 at 11:40 AM, Neil Girdhar <mis...@gm...>
wrote:

> Okay, I'm going to wait for more feedback.  An hour of design can be worth
> ten hours of implementation :)
>
> On Fri, May 15, 2015 at 11:11 AM, Thomas Caswell <tca...@gm...>
> wrote:
>
>> I would advocate for calling yours something different.  path.Path is
>> really a container for a Bezier curve and is probably best left as simple
>> as possible.  There is probably an interesting discussion about right is-a
>> and has-a relations between Path,  FancyPath (don't use that name!), and
>> FancyArrow (which I do not have a clear view of yet).
>>
>> Tom
>>
>> On Fri, May 15, 2015 at 11:04 AM Neil Girdhar <mis...@gm...>
>> wrote:
>>
>>> On Fri, May 15, 2015 at 10:53 AM, Thomas Caswell <tca...@gm...>
>>> wrote:
>>>
>>>> A few very quick comments (just skimmed the docstrings)
>>>>
>>>> We already have a mpl.path.Path class, please don't shadow that.
>>>>
>>>
>>> I read the Path class and based mine on that.  The problem is that I
>>> want to be able to place nodes along the path (like labels) and so I need
>>> to ask it questions.  Maybe we should just extend the existing Path class?
>>> Or else we should call my Path something different?
>>>
>>>
>>>> Is your `Path` going to be an `Artist` that is responsible for drawing
>>>> it's self or does in serve a role like the existing `Path` in that it is
>>>> used by other artists as part of their `draw`?
>>>>
>>>> This feels very similar to the `FancyArrow` (with classes being passed
>>>> in to control how the arrow is styled), would this make sense as an
>>>> extension to that code?  This does seem more general, maybe it makes sense
>>>> to start from scratch and implement `FancyArrow` in terms of this code.
>>>>
>>>
>>> Yes!  Didn't know about that.  I think modifying and extending that code
>>> might be a good way forward.
>>>
>>>
>>>
>>>>
>>>> Tom
>>>>
>>>> On Fri, May 15, 2015 at 10:40 AM Neil Girdhar <mis...@gm...>
>>>> wrote:
>>>>
>>>>> I have a draft proposal of the long term goal for what an interface
>>>>> could look like for drawing arrows between coordinates or nodes.  I based
>>>>> the design on the tikz manual (http://pgf.sourceforge.net/pgf_CVS.pdf),
>>>>> so it might help to flip through that to get an idea for the basis of this
>>>>> design.  I tried to separate the creating of Path objects with the drawing
>>>>> of paths since it's often really useful when compositing layouts to be able
>>>>> to do math with with the positions of things before drawing anything.  For
>>>>> example, when automatically positioning nodes.
>>>>>
>>>>> I'm not committed to this design; it's just an outline to get feedback.
>>>>>
>>>>> Best,
>>>>>
>>>>> Neil
>>>>>
>>>>> class Axes_(_AxesBase):
>>>>>     def path(self, path, draw=True, fill=False):
>>>>>         """
>>>>>         If draw is not falsy, draws along the path using the draw
>>>>>         specification.
>>>>>         If fill is not falsy, fills the closed path using the fill
>>>>>         specification.
>>>>>
>>>>>         Parameters
>>>>>         ----------
>>>>>         path is a Path object or path commands with which to create
>>>>> one.
>>>>>
>>>>>         draw is a draw specification:
>>>>>             either the value True, which indicates some defaults, or
>>>>> else
>>>>>             False, or else a dictionary with the following keys:
>>>>>                 color
>>>>>                 opacity
>>>>>                 line_width
>>>>>                 line_join
>>>>>                 begin_tip is a Tip object
>>>>>                 tip or end_tip is a Tip object
>>>>>                 dashed is a dash specification
>>>>>
>>>>>         a dash specification
>>>>>             either dictionary containing:
>>>>>                 dash_pattern
>>>>>                     an iterable of numbers specifying the length of
>>>>> the dashes
>>>>>                     and gaps in points.  E.g., [2, 3, 4, 3] means on
>>>>> for 2
>>>>>                     points, off for 3, on for 4, off for 3, i.e.,
>>>>> dash-dotted.
>>>>>                 dash_phase
>>>>>                     Shifts the start of the dash pattern by dash_phase
>>>>> points.
>>>>>             or a string, one of:
>>>>>                 'solid'
>>>>>                 'dotted', 'densely dotted', 'loosely dotted'
>>>>>                 'dashed', 'densely dashed', 'loosely dashed'
>>>>>                 'dash dot', 'densely dash dot', 'loosely dash dot'
>>>>>                 'dash dot dot', 'densely dash dot dot', 'loosely dash
>>>>> dot dot'
>>>>>
>>>>>         fill is a fill specification:
>>>>>             TODO
>>>>>         """
>>>>>
>>>>> class Path:
>>>>>     def __init__(self, path_commands):
>>>>>         """
>>>>>         path_commands is either
>>>>>             a coordinate (representing a move to in the first
>>>>> position, or a
>>>>>             line to in any other position)
>>>>>             MoveTo(coordinate)
>>>>>             LineTo(coordinate_or_node, draw=None)
>>>>>             CurveTo(coordinate_or_node, control_points, draw=None)
>>>>>             ClosePolygon()
>>>>>
>>>>>             optional draw commands override the draw specification of
>>>>> the whole
>>>>>             path within that edge.
>>>>>
>>>>>             a coordinate is either an (x, y) pair, or a Coordinate
>>>>> object.
>>>>>             a node is a Node object.
>>>>>         """
>>>>>
>>>>>     def at_position(self, fraction=0.5):
>>>>>         """
>>>>>         Returns a coordinate fraction of the way along the line.
>>>>>         fraction can be one of 'at end', 'very near end', 'near end',
>>>>>         'midway', 'near start', 'very near start', 'at start'
>>>>>         """
>>>>>
>>>>>     def node_at(node, fraction=0.5, location, ...)
>>>>>         """
>>>>>         Sets the node's position so that it sits flush to the path.
>>>>>
>>>>>         Parameters
>>>>>         ----------
>>>>>         location :
>>>>>             Could be 'above', 'below', 'on', or a number, which is the
>>>>> number
>>>>>             of points away from the path to place the node.
>>>>>         """
>>>>>
>>>>>     def pin_node(node, pin_distance, draw=draw_specification):
>>>>>         pass
>>>>>
>>>>>
>>>>> class Coordinate:
>>>>>     @property
>>>>>     def coordinate(self):
>>>>>         return (self.x, self.y)
>>>>>
>>>>>     def node_at(self, node, angle):
>>>>>         """
>>>>>         Places the node so that it is in the direction angle from the
>>>>>         coordinate.  E.g.,
>>>>>         angle=pi/2, or angle='above' places the node so that the
>>>>> coordinate is
>>>>>         touching the center-bottom of the node.
>>>>>         angle could be 'above', 'below', 'left', 'right', 'above
>>>>> left', etc.
>>>>>         """
>>>>>
>>>>> class Node:
>>>>>     """
>>>>>     Available Node objects:
>>>>>         Rectangle, Circle
>>>>>     """
>>>>>     @property
>>>>>     def center(self):
>>>>>         return (self.x, self.y)
>>>>>
>>>>>     def node_at(self, node, angle):
>>>>>         """
>>>>>         Places the node so that it is in the direction angle from the
>>>>>         coordinate.  The node could be an arrowhead for example.
>>>>>         """
>>>>>
>>>>>     def convex_hulls(self):
>>>>>         """
>>>>>         Returns a list of convex hulls.  The convex hulls are used when
>>>>>         position one node or arrowhead flush with another using the
>>>>>         separating axis algorithm.
>>>>>         """
>>>>>
>>>>> class Tip:
>>>>>     """
>>>>>     Available Tip objects:
>>>>>         ButtCap (no tip, the default)
>>>>>         RectangleCap, TriangleCap, RoundCap
>>>>>         ArcBarb, Bar, Bracket, Hooks, Parenthesis,
>>>>>         StraightBarb, TeeBarb
>>>>>         Circle, Diamond, Ellipse, Kite, Arrow,
>>>>>         Rectangle, Square, Stealth, Triangle,
>>>>>         TurnedSquare
>>>>>         TipCombination (accepts multiple tips and merges them)
>>>>>     """
>>>>>     def __init__(self, draw=None, fill=True, reversed_=False):
>>>>>         pass
>>>>>
>>>>>     def convex_hulls(self, line_width):
>>>>>         """
>>>>>         Returns a list of convex hulls for use with placement
>>>>>         whereby the arrow faces right starting at the origin.
>>>>>         """
>>>>>
>>>>>     def transmute(self, line_width):
>>>>>         """
>>>>>         Returns a pair of lists (draw_path, fill_path).
>>>>>         """
>>>>>
>>>>>     @property
>>>>>     def draw_specification(self):
>>>>>         """
>>>>>         is a draw specification, or None to use the parent line's
>>>>>         """
>>>>>     def fill_specification(self):
>>>>>         """
>>>>>         Is a fill specification, or True to use defaults based
>>>>>         on the parent line's draw color, or False to use an open fill.
>>>>>         """
>>>>>
>>>>> -----
>>>>>
>>>>> Usage:
>>>>>
>>>>> # draw an arrow from point to point.
>>>>> ax.path([(x, y), (x2, y2)], draw={'tip': Arrow()})
>>>>>
>>>>> # Create a path.
>>>>> p = Path([(x, y), (x2, y2)])
>>>>>
>>>>> # Create a node along the path.
>>>>> n = p.node_at(Label("some label"))
>>>>>
>>>>> # Draw the path using an arrow, and the node.
>>>>> ax.path(p, draw={'tip': Arrow()})
>>>>> ax.node(n)
>>>>>
>>>>>
>>>>> On Wed, May 13, 2015 at 11:27 PM, Thomas Caswell <tca...@gm...>
>>>>>  wrote:
>>>>>
>>>>>> Sorry, I may have been being a bit dramatic
>>>>>>
>>>>>> In mpl.patches: Arrow, FancyArrow, YAArrow, FancyArrowPatch,
>>>>>> ConnectionPatch  + annotation related artists + some classes in axisartist
>>>>>> which now that I look at them are not really general purpose arrow tools.
>>>>>> I had not been counting quiver (or barbs) or sankey.
>>>>>>
>>>>>> Neil: Those are all great questions!  Much of the arrow related code
>>>>>> was written by Joe-Joon Lee who (by having read a good deal of his code)
>>>>>> has a habit of writing very power but very opaque python.
>>>>>>
>>>>>> I believe that the line join style is controlled by `joinstyle` on
>>>>>> the graphics context and it is up to the backends to implement that
>>>>>> correctly.
>>>>>>
>>>>>> Tom
>>>>>>
>>>>> On Wed, May 13, 2015 at 10:58 PM Neil Girdhar <mis...@gm...>
>>>>>> wrote:
>>>>>>
>>>>> Okay, I'm looking at this in more detail and there may be some design
>>>>>>> concerns:
>>>>>>>
>>>>>>> The arrow placement is decided without asking the arrow any
>>>>>>> questions, such as its bounding box.  Instead, the arrow should return a
>>>>>>> bounding box and then the line should retreat until the bounding box no
>>>>>>> longer intersects the target node.  Then the arrow should be placed.  This
>>>>>>> doesn't matter so much when you have a simple arrow like this: ---->, but
>>>>>>> it's a big deal when you have an arrow like ----| .  In this case, the
>>>>>>> sides of the arrow risk intersecting with the target node.
>>>>>>>
>>>>>>> I'm not keen on implementing every arrow three times: <-, ->, <->.
>>>>>>> This really should be handled by the code placing the arrows for many
>>>>>>> reasons:
>>>>>>> 1. It should also be possible to have a different arrowhead at
>>>>>>> either end of the line.
>>>>>>> 2. It should be possible to stack the arrows, for example having two
>>>>>>> heads one after another (to represent two kinds of relationships).  This is
>>>>>>> another reason to be able to ask the arrowhead its length and so on.
>>>>>>>
>>>>>>> I don't understand the "monolithic" keyword.  How can the arrow draw
>>>>>>> the line as well when it doesn't know the line style, color and so on?
>>>>>>>
>>>>>>> I think I like the design of the transmute function.  I'm curious:
>>>>>>> ultimately, where does the mutation_size come from?  Is it a global scale
>>>>>>> applied to the figure, or is it based on the linewidth, or?
>>>>>>>
>>>>>>> When you emit a set of lines, how are they joined?  If I draw a line
>>>>>>> having linewidth 0.1 from the origin to (1, 0), and back to (0, 0.5), what
>>>>>>> happens at the tip?  Are two rectangles drawn (each having width 0.1, but
>>>>>>> oriented differently)?  Is a bevel created?  A miter? Or is the tip
>>>>>>> rounded?  Can this be controlled?  See page 166 of the manual I sent
>>>>>>> earlier (search for tikz/line join).
>>>>>>>
>>>>>>> Best,
>>>>>>>
>>>>>>> Neil
>>>>>>>
>>>>>> On Wed, May 13, 2015 at 10:14 PM, Neil Girdhar <mis...@gm...
>>>>>>> > wrote:
>>>>>>>
>>>>>> Thanks, it works!
>>>>>>>>
>>>>>>>> I needed to add:
>>>>>>>>
>>>>>>>> import matplotlib.patches
>>>>>>>>
>>>>>>>> to one file and
>>>>>>>>
>>>>>>>> plt.show()
>>>>>>>>
>>>>>>>> to the other.
>>>>>>>>
>>>>>>>> Any word on the locations in the code of the seven arrow drawing
>>>>>>>> methods?
>>>>>>>>
>>>>>>>> I've located the arrow drawing code in tikz, and so I can start
>>>>>>>> porting it over.  I'm curious, do we know the linewidth of the edge being
>>>>>>>> decorated by the arrow?  To make arrows scale nicely, most of the arrow
>>>>>>>> dimensions are given in two pieces: an absolute value (in points for
>>>>>>>> example) and a line width factor.  The dimension is the absolute value plus
>>>>>>>> the line width factor times the line width.  The TikZ manual explains:
>>>>>>>> "This makes it easy to vary the size of an arrow tip in accordance with the
>>>>>>>> line width – usually a very good idea since thicker lines will need thicker
>>>>>>>> arrow tips."
>>>>>>>>
>>>>>>>> Best,
>>>>>>>>
>>>>>>>> Neil
>>>>>>>>
>>>>>>> On Wed, May 13, 2015 at 10:07 PM, Benjamin Reedlunn <
>>>>>>>> bre...@gm...> wrote:
>>>>>>>>
>>>>>>> Neil,
>>>>>>>>>
>>>>>>>>> I have attached code to draw the arrowhead.
>>>>>>>>>
>>>>>>>>> -Ben
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On May 13, 2015, at 7:44 PM, Neil Girdhar <mis...@gm...>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Do you have the code that you used to draw the arrowhead?  I'm up
>>>>>>>>> to date now on the development workflow (
>>>>>>>>> http://matplotlib.org/devel/gitwash/development_workflow.html),
>>>>>>>>> so I'm ready to start working.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Neil
>>>>>>>>>
>>>>>>>>> On Wed, May 13, 2015 at 9:10 PM, Benjamin Reedlunn <
>>>>>>>>> bre...@gm...> wrote:
>>>>>>>>>
>>>>>>>>> Yes, I fully agree that we need to unify the many different ways
>>>>>>>>>> to draw arrows.
>>>>>>>>>>
>>>>>>>>>> Neil, in case an example would be helpful for you, I have
>>>>>>>>>> attached a module that includes a custom arrowhead class.  The arrowhead
>>>>>>>>>> class works with the with the ax.annotate() method.  (I like the annotate
>>>>>>>>>> method because it allows me to easily mix and match coordinate systems for
>>>>>>>>>> arrow placement.)  As you can see in the attached pdf, the custom arrowhead
>>>>>>>>>> doesn't include fancy Bezier curves, but that could be added.
>>>>>>>>>>
>>>>>>>>>> -Ben
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On May 13, 2015, at 2:54 PM, Thomas Caswell <tca...@gm...>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> The other thing that should be done is to unify the (I think
>>>>>>>>>> 7?!?) unique ways to draw arrows in mpl.
>>>>>>>>>>
>>>>>>>>>> On Wed, May 13, 2015 at 4:52 PM Neil Girdhar <
>>>>>>>>>> mis...@gm...> wrote:
>>>>>>>>>>
>>>>>>>>>> Yes, I just noticed that as well.  That's how the tikz pgf code
>>>>>>>>>>> looks (a sequence of line_to and curve_to commands and so on) so it should
>>>>>>>>>>> be easy to port over the various shapes.
>>>>>>>>>>>
>>>>>>>>>>> On Wed, May 13, 2015 at 4:49 PM, Eric Firing <ef...@ha...
>>>>>>>>>>> > wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 2015/05/13 10:12 AM, Neil Girdhar wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> If you want to make arrowheads look at all decent, they really
>>>>>>>>>>>>> need to
>>>>>>>>>>>>> be enclosed in Bezier curves.  See the diagram here:
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Mpl paths support Bezier curves.
>>>>>>>>>>>> http://matplotlib.org/api/path_api.html?highlight=bezier
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://tex.stackexchange.com/questions/150289/how-do-you-accomplish-stealth-with-the-new-arrows-meta/230965#230965
>>>>>>>>>>>>>
>>>>>>>>>>>>> The first two look like garbage.  The last one is the only one
>>>>>>>>>>>>> that
>>>>>>>>>>>>> looks good imho.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> That depends on the application, and the observer.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Sure, but I may as well port them all of the tikz arrowheads
>>>>>>>>>>> over since most of the work would be figuring out how to do it.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Eric
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Neil
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, May 13, 2015 at 4:09 PM, Eric Firing <
>>>>>>>>>>>>> ef...@ha...
>>>>>>>>>>>>> <mailto:ef...@ha...>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>     On 2015/05/13 9:36 AM, Neil Girdhar wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>         I don't know matplotlib well enough (yet) to know what
>>>>>>>>>>>>> the
>>>>>>>>>>>>>         change would
>>>>>>>>>>>>>         consist of.
>>>>>>>>>>>>>
>>>>>>>>>>>>>         I suggest you take a look at the beautiful tikz manual:
>>>>>>>>>>>>>         http://pgf.sourceforge.net/pgf_CVS.pdf
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>     Very helpful, thank you.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>         The arrows.meta on page 201–212 are really
>>>>>>>>>>>>> well-designed and
>>>>>>>>>>>>>         beautiful.
>>>>>>>>>>>>>
>>>>>>>>>>>>>         Compare this with matplotlib's custom arrows:
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://stackoverflow.com/questions/16968007/custom-arrow-style-for-matplotlib-pyplot-annotate
>>>>>>>>>>>>>
>>>>>>>>>>>>>         How do I make tikz's arrowheads available for all
>>>>>>>>>>>>> backends?
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>     My guess offhand is that this is a matter of using the mpl
>>>>>>>>>>>>> API.  I
>>>>>>>>>>>>>     don't think we would want to add all of these types and
>>>>>>>>>>>>> options to
>>>>>>>>>>>>>     the mpl core; but a toolkit might be ideal for this.  The
>>>>>>>>>>>>> mpl API,
>>>>>>>>>>>>>     which generates the same results for all backends, is
>>>>>>>>>>>>> quite complete
>>>>>>>>>>>>>     and flexible.  Things like arrowheads are Patch objects,
>>>>>>>>>>>>> and you can
>>>>>>>>>>>>>     specify any path you want.  The main trick is figuring out
>>>>>>>>>>>>> how to
>>>>>>>>>>>>>     handle transforms--what kind of coordinates should the
>>>>>>>>>>>>> path be
>>>>>>>>>>>>>     specifying?  How should things scale as a figure is
>>>>>>>>>>>>> reshaped and
>>>>>>>>>>>>>     resized?
>>>>>>>>>>>>>
>>>>>>>>>>>>>     For many of these types you could also use mpl Line2D
>>>>>>>>>>>>> objects, for
>>>>>>>>>>>>>     which several properties including cap style can be
>>>>>>>>>>>>> specified.  Not
>>>>>>>>>>>>>     all of the TikZ options would be available, but perhaps
>>>>>>>>>>>>> enough.
>>>>>>>>>>>>>
>>>>>>>>>>>>>     Eric
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>> One dashboard for servers and applications across
>>>>>>>>>>> Physical-Virtual-Cloud
>>>>>>>>>>> Widest out-of-the-box monitoring support with 50+ applications
>>>>>>>>>>> Performance metrics, stats and reports that give you Actionable
>>>>>>>>>>> Insights
>>>>>>>>>>> Deep dive visibility with transaction tracing using APM Insight.
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Matplotlib-devel mailing list
>>>>>>>>>>> Mat...@li...
>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>> One dashboard for servers and applications across
>>>>>>>>>> Physical-Virtual-Cloud
>>>>>>>>>> Widest out-of-the-box monitoring support with 50+ applications
>>>>>>>>>> Performance metrics, stats and reports that give you Actionable
>>>>>>>>>> Insights
>>>>>>>>>> Deep dive visibility with transaction tracing using APM Insight.
>>>>>>>>>>
>>>>>>>>>> Matplotlib-devel mailing list
>>>>>>>>>> Mat...@li...
>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>> ​
>>>>>
>>>>
>