Re: [matplotlib-devel] [SciPy-user] recursion limit in plot
Neal Becker wrote: > What's wrong here? > This code snippet: > > from pylab import plot, show > print Id > print pout > > plot (Id, pout) > show() > > produces: > ['50', '100', '150', '200', '250', '300', '350', '400', '450', '500', '550', > '600', '650', '700', '750', '800', '850', '900', '950', '1000', '1050'] > ['0', '7.4', '11.4', '14.2', '16.3', '18.1', '19.3', '20.6', '21.6', '22.6', > '23.4', '24.1', '24.9', '25.4', '26.1', '26.5', '26.9', '27.1', '27.3', > '27.4', '27.4'] The problem here is that you're trying to plot lists of strings instead of lists of numbers. You need to convert all of these values to numbers. However, matplotlib could behave a bit more nicely in this case rather than simply recursing until it hits the limit. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [SciPy-user] recursion limit in plot
Ryan May wrote:
> Neal Becker wrote:
>> What's wrong here?
>> This code snippet:
>>
>> from pylab import plot, show
>> print Id
>> print pout
>>
>> plot (Id, pout)
>> show()
>>
>> produces:
>> ['50', '100', '150', '200', '250', '300', '350', '400', '450', '500', '550',
>> '600', '650', '700', '750', '800', '850', '900', '950', '1000', '1050']
>> ['0', '7.4', '11.4', '14.2', '16.3', '18.1', '19.3', '20.6', '21.6', '22.6',
>> '23.4', '24.1', '24.9', '25.4', '26.1', '26.5', '26.9', '27.1', '27.3',
>> '27.4', '27.4']
>
> The problem here is that you're trying to plot lists of strings instead of
> lists
> of numbers. You need to convert all of these values to numbers. However,
> matplotlib could behave a bit more nicely in this case rather than simply
> recursing until it hits the limit.
Ok, my debugging tells me the problem comes down to the units support,
specifically this code starting at line 130 in units.py:
if converter is None and iterable(x):
# if this is anything but an object array, we'll assume
# there are no custom units
if isinstance(x, np.ndarray) and x.dtype != np.object:
return None
for thisx in x:
converter = self.get_converter( thisx )
return converter
Because a string is iterable, and even a single character is considered
iterable,
this code recurses forever. I can think this can be solved by, in addition to
the iterable() check, make sure that x is not string like. If it is, this will
return None as the converter. Somehow, this actually will then plot properly.
I'm still trying to run down why this works, but I'm running out of time for the
day. I will say that the data set for the line2D object is indeed a masked
array
of dtype ('|S4').
Anyone object to adding the check?
In addition, why are we looping over thisx in x but returning inside the loop?
Wouldn't this *always* be the same as x[0]?
Ryan
--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [SciPy-user] recursion limit in plot
On Thu, Jan 15, 2009 at 4:58 PM, Ryan May wrote:
> Ok, my debugging tells me the problem comes down to the units support,
> specifically this code starting at line 130 in units.py:
>
>if converter is None and iterable(x):
># if this is anything but an object array, we'll assume
># there are no custom units
>if isinstance(x, np.ndarray) and x.dtype != np.object:
>return None
>
>for thisx in x:
>converter = self.get_converter( thisx )
>return converter
>
> Because a string is iterable, and even a single character is considered
> iterable,
> this code recurses forever. I can think this can be solved by, in addition to
> the iterable() check, make sure that x is not string like. If it is, this
> will
> return None as the converter. Somehow, this actually will then plot properly.
> I'm still trying to run down why this works, but I'm running out of time for
> the
> day. I will say that the data set for the line2D object is indeed a masked
> array
> of dtype ('|S4').
>
> Anyone object to adding the check?
Nope -- good idea
> In addition, why are we looping over thisx in x but returning inside the loop?
> Wouldn't this *always* be the same as x[0]?
The loop works for generic iterables that are not indexable and also
for length 0 iterables
JDH
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [SciPy-user] recursion limit in plot
Ryan May wrote:
> Ok, my debugging tells me the problem comes down to the units support,
> specifically this code starting at line 130 in units.py:
>
> if converter is None and iterable(x):
> # if this is anything but an object array, we'll assume
> # there are no custom units
> if isinstance(x, np.ndarray) and x.dtype != np.object:
> return None
>
> for thisx in x:
> converter = self.get_converter( thisx )
> return converter
>
> Because a string is iterable, and even a single character is considered
> iterable,
> this code recurses forever. I can think this can be solved by, in addition to
> the iterable() check, make sure that x is not string like. If it is, this
> will
Doing this check makes sense.
> return None as the converter. Somehow, this actually will then plot properly.
> I'm still trying to run down why this works, but I'm running out of time for
> the
> day. I will say that the data set for the line2D object is indeed a masked
> array
> of dtype ('|S4').
>
> Anyone object to adding the check?
>
> In addition, why are we looping over thisx in x but returning inside the loop?
> Wouldn't this *always* be the same as x[0]?
>
The idea is to base the converter selection on the first item instead of
checking every item, which would be very slow.
> Ryan
>
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [SciPy-user] recursion limit in plot
John Hunter wrote:
> On Thu, Jan 15, 2009 at 4:58 PM, Ryan May wrote:
>
>> Ok, my debugging tells me the problem comes down to the units support,
>> specifically this code starting at line 130 in units.py:
>>
>>if converter is None and iterable(x):
>># if this is anything but an object array, we'll assume
>># there are no custom units
>>if isinstance(x, np.ndarray) and x.dtype != np.object:
>>return None
>>
>>for thisx in x:
>>converter = self.get_converter( thisx )
>>return converter
>>
>> Because a string is iterable, and even a single character is considered
>> iterable,
>> this code recurses forever. I can think this can be solved by, in addition
>> to
>> the iterable() check, make sure that x is not string like. If it is, this
>> will
>> return None as the converter. Somehow, this actually will then plot
>> properly.
>> I'm still trying to run down why this works, but I'm running out of time for
>> the
>> day. I will say that the data set for the line2D object is indeed a masked
>> array
>> of dtype ('|S4').
>>
>> Anyone object to adding the check?
>
> Nope -- good idea
Ok, I'll check it in when I have a chance to run backend_driver.py and makes
sure
nothing breaks. (Not that it should). I'll also take a crack at adding a test.
For future reference, plotting lists/arrays of strings works (at least for
lines)
because Path calls .astype() on the arrays passed in, which will do the
conversion for us. So (part of) matplotlib actually does support plotting
sequences of string representations of numbers, it was just hindered by the unit
check.
>> In addition, why are we looping over thisx in x but returning inside the
>> loop?
>> Wouldn't this *always* be the same as x[0]?
>
> The loop works for generic iterables that are not indexable and also
> for length 0 iterables
Ok, that makes sense.
Ryan
--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
