matplotlib-devel Mailing List for matplotlib

On Saturday 20 May 2006 15:47, Eric Firing wrote:
> Darren Dale wrote:
> > I have used floats to indicate color in many of my own scripts. I think
> > changing this would have a pretty big impact on the users.
> >
> > Darren
>
> Darren,
>
> Float as greyscale, right?

Yes, that's what I meant.

> Yes, I am concerned about breaking things, but maybe it is not too late
> to deprecate it, so that the transition could be made some time in the
> future.  I think it is worth considering this carefully now, while we
> are still pre-1.0.

slightly off-topic: Will mpl ever go 1.0? That's not meant to be flippant. I 
thought their was some pride in being beta.

> >>John,
> >>
> >>I think all the ambiguity that you mention below comes from one source:
> >>the use of a single float to indicate a greyscale.  Do we really need
> >>this? It is not supported by colors.looks_like_color().  It could be
> >>replaced by a string representation of the float (e.g., '0.75') or by a
> >>more specific string, such as 'g0.75' or 'grey0.75'.  I think this would
> >>be a big net gain for mpl.  We lose a lot of flexibility, convenience,
> >>and consistency by allowing the float-is-grey form.
> >>
> >>Eric
> >>
> >>John Hunter wrote:
> >>>>>>>>"Eric" == Eric Firing <ef...@ha...> writes:
> >>>
> >>>    Eric> John, Collections would be easier to use if they did not
> >>>    Eric> have the restriction (from the docstring):
> >>>
> >>>    Eric>      All color args to a collection are sequences of rgba
> >>>    Eric> tuples
> >>>
> >>>    Eric> It would be easy to remove this restriction; shall I do it,
> >>>    Eric> or is there a reason to leave the restriction in place?
> >>>    Eric> (The error message that results from violating the
> >>>    Eric> restriction is not helpful, and it would be as easy to
> >>>    Eric> remove the restriction as to improve the error handling.)
> >>>
> >>>I think it's fine to remove it, but note that you have to be careful
> >>>to avoid ambiguity.  How would you interpret
> >>>
> >>>  color = (0.25, 0.5, 0.75, 1.0)
> >>>
> >>>Is this one rgba color or 4 grayscales?
> >>>
> >>>Because mpl accepts lots of different types of args for colors, there
> >>>will probably be some ambiguous cases, thought these will be very rare
> >>>corner cases.  Just document what the behavior is, and everyone should
> >>>be happy.  I think you could do the same for the linewidths, etc.  Eg
> >>>if scalar, interpret as a single linewidth for all elements of the
> >>>collection?
> >>>
> >>>Or were you intending to preserve the requirement that one pass
> >>>sequences, but allow versatile color args in the sequence?
> >>>
> >>>JDH
> >>
> >>-------------------------------------------------------
> >>Using Tomcat but need to do more? Need to support web services, security?
> >>Get stuff done quickly with pre-integrated technology to make your job
> >>easier
> >>Download IBM WebSphere Application Server v.1.0.1 based on Apache
> >> Geronimo
> >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> >> _______________________________________________
> >>Matplotlib-devel mailing list
> >>Mat...@li...
> >>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

-- 
Darren S. Dale, Ph.D.
Cornell High Energy Synchrotron Source
Cornell University
200L Wilson Lab
Rt. 366 & Pine Tree Road
Ithaca, NY 14853

dd...@co...
office: (607) 255-9894
fax: (607) 255-9001

Darren Dale wrote:
> I have used floats to indicate color in many of my own scripts. I think
> changing this would have a pretty big impact on the users.
> 
> Darren

Darren,

Float as greyscale, right?

Yes, I am concerned about breaking things, but maybe it is not too late 
to deprecate it, so that the transition could be made some time in the 
future.  I think it is worth considering this carefully now, while we 
are still pre-1.0.

Eric

> 
> 
>>John,
>>
>>I think all the ambiguity that you mention below comes from one source:
>>the use of a single float to indicate a greyscale.  Do we really need
>>this? It is not supported by colors.looks_like_color().  It could be
>>replaced by a string representation of the float (e.g., '0.75') or by a
>>more specific string, such as 'g0.75' or 'grey0.75'.  I think this would
>>be a big net gain for mpl.  We lose a lot of flexibility, convenience,
>>and consistency by allowing the float-is-grey form.
>>
>>Eric
>>
>>John Hunter wrote:
>>
>>>>>>>>"Eric" == Eric Firing <ef...@ha...> writes:
>>>
>>>
>>>    Eric> John, Collections would be easier to use if they did not
>>>    Eric> have the restriction (from the docstring):
>>>
>>>    Eric>      All color args to a collection are sequences of rgba
>>>    Eric> tuples
>>>
>>>    Eric> It would be easy to remove this restriction; shall I do it,
>>>    Eric> or is there a reason to leave the restriction in place?
>>>    Eric> (The error message that results from violating the
>>>    Eric> restriction is not helpful, and it would be as easy to
>>>    Eric> remove the restriction as to improve the error handling.)
>>>
>>>I think it's fine to remove it, but note that you have to be careful
>>>to avoid ambiguity.  How would you interpret
>>>
>>>  color = (0.25, 0.5, 0.75, 1.0)
>>>
>>>Is this one rgba color or 4 grayscales?
>>>
>>>Because mpl accepts lots of different types of args for colors, there
>>>will probably be some ambiguous cases, thought these will be very rare
>>>corner cases.  Just document what the behavior is, and everyone should
>>>be happy.  I think you could do the same for the linewidths, etc.  Eg
>>>if scalar, interpret as a single linewidth for all elements of the
>>>collection?
>>>
>>>Or were you intending to preserve the requirement that one pass
>>>sequences, but allow versatile color args in the sequence?
>>>
>>>JDH
>>
>>
>>
>>-------------------------------------------------------
>>Using Tomcat but need to do more? Need to support web services, security?
>>Get stuff done quickly with pre-integrated technology to make your job
>>easier
>>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>>_______________________________________________
>>Matplotlib-devel mailing list
>>Mat...@li...
>>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
> 
> 
> 

I have used floats to indicate color in many of my own scripts. I think
changing this would have a pretty big impact on the users.

Darren

> John,
>
> I think all the ambiguity that you mention below comes from one source:
> the use of a single float to indicate a greyscale.  Do we really need
> this? It is not supported by colors.looks_like_color().  It could be
> replaced by a string representation of the float (e.g., '0.75') or by a
> more specific string, such as 'g0.75' or 'grey0.75'.  I think this would
> be a big net gain for mpl.  We lose a lot of flexibility, convenience,
> and consistency by allowing the float-is-grey form.
>
> Eric
>
> John Hunter wrote:
>>>>>>>"Eric" == Eric Firing <ef...@ha...> writes:
>>
>>
>>     Eric> John, Collections would be easier to use if they did not
>>     Eric> have the restriction (from the docstring):
>>
>>     Eric>      All color args to a collection are sequences of rgba
>>     Eric> tuples
>>
>>     Eric> It would be easy to remove this restriction; shall I do it,
>>     Eric> or is there a reason to leave the restriction in place?
>>     Eric> (The error message that results from violating the
>>     Eric> restriction is not helpful, and it would be as easy to
>>     Eric> remove the restriction as to improve the error handling.)
>>
>> I think it's fine to remove it, but note that you have to be careful
>> to avoid ambiguity.  How would you interpret
>>
>>   color = (0.25, 0.5, 0.75, 1.0)
>>
>> Is this one rgba color or 4 grayscales?
>>
>> Because mpl accepts lots of different types of args for colors, there
>> will probably be some ambiguous cases, thought these will be very rare
>> corner cases.  Just document what the behavior is, and everyone should
>> be happy.  I think you could do the same for the linewidths, etc.  Eg
>> if scalar, interpret as a single linewidth for all elements of the
>> collection?
>>
>> Or were you intending to preserve the requirement that one pass
>> sequences, but allow versatile color args in the sequence?
>>
>> JDH
>
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

John,

I think all the ambiguity that you mention below comes from one source: 
the use of a single float to indicate a greyscale.  Do we really need 
this? It is not supported by colors.looks_like_color().  It could be 
replaced by a string representation of the float (e.g., '0.75') or by a 
more specific string, such as 'g0.75' or 'grey0.75'.  I think this would 
be a big net gain for mpl.  We lose a lot of flexibility, convenience, 
and consistency by allowing the float-is-grey form.

Eric

John Hunter wrote:
>>>>>>"Eric" == Eric Firing <ef...@ha...> writes:
> 
> 
>     Eric> John, Collections would be easier to use if they did not
>     Eric> have the restriction (from the docstring):
> 
>     Eric>      All color args to a collection are sequences of rgba
>     Eric> tuples
> 
>     Eric> It would be easy to remove this restriction; shall I do it,
>     Eric> or is there a reason to leave the restriction in place?
>     Eric> (The error message that results from violating the
>     Eric> restriction is not helpful, and it would be as easy to
>     Eric> remove the restriction as to improve the error handling.)
> 
> I think it's fine to remove it, but note that you have to be careful
> to avoid ambiguity.  How would you interpret
> 
>   color = (0.25, 0.5, 0.75, 1.0)
> 
> Is this one rgba color or 4 grayscales?  
> 
> Because mpl accepts lots of different types of args for colors, there
> will probably be some ambiguous cases, thought these will be very rare
> corner cases.  Just document what the behavior is, and everyone should
> be happy.  I think you could do the same for the linewidths, etc.  Eg
> if scalar, interpret as a single linewidth for all elements of the
> collection?
> 
> Or were you intending to preserve the requirement that one pass
> sequences, but allow versatile color args in the sequence?
> 
> JDH