[changeset] clarification to pcolor doc-string

[Kai Habel]

Ben Abbott schrieb:
> On Tuesday, September 23, 2008, at 04:10PM, "Kai Habel" <kai.habel at gmx.de> wrote:
>   
>> Ben Abbott schrieb:
>>     
>>> On Tuesday, September 23, 2008, at 02:33PM, "John W. Eaton" <jwe at bevo.che.wisc.edu> wrote:
>>>   
>>>       
>>>> On 23-Sep-2008, Kai Habel wrote:
>>>>
>>>> | in 2007 I implemented the interp shading mode for the gnuplot backend.
>>>> | But it was so slow that I did not suggest a patch for that. If I
>>>> | remember correctly the usage of 'interpolate 3,3' for pm3d [1] has
>>>> | increased the time for a plot by a factor of ten. But for a really
>>>> | smooth plot something like interpolate 5,5 or even more would be
>>>> | necessary - with even longer plotting times.
>>>>
>>>> I can't seem to figure out how to make pm3d interpolation work at
>>>> all.  Using the command "set pm3d interpolate 10, 10" doesn't seem to
>>>> have any affect when I use it (I'm working directly in gnuplot).  Can
>>>> you post a simple example?  I'd like to see what it does, even if it
>>>> is slow.
>>>>
>>>> Thanks,
>>>>
>>>> jwe
>>>>
>>>>     
>>>>         
>>> Kai, you may be ahead of me, I'd not considered pm3d. I have used pm3d in the past (although its been a while), and don't recall using interpolation.
>>>
>>> Prior to the discussion of pm3d, I was planning to segment each rectangle a pair of triangles, segment the triangles into patches along the discrete bounds of the colormap, and then color each discrete patch as "flat" (no edgecolor). Finally, I thought I'd replace each patch with an hg group.
>>>
>>> Does this sound like a proper approach? ... or should most of that work  be off loaded to gnuplot (as well as the other backends)?
>>>   
>>>       
>> Ben,
>> to stay compatible with the other brand, pcolor should create an surface
>> object at z=0, so hggroup is not an option. You suggestion sounds
>> interesting and could work in 2d (for pcolor), but you would need
>> concave patches in 3d to support surfaces objects in general.
>>     
>
> Yes. I was stuck in the middle of my little problem and wasn't looking at the bigger picture.
>
>   
>>> I notice that the patch.m doc-string does not mention 3D patches, but that __patch__.m does appear to parse for "z". While playing with the patch command I encountered an error ...
>>>
>>>     error: gnuplot (as of v4.2) only supports 2D filled patches
>>>
>>> Which seems strange since the gnuplot I'm using does handle pm3d (if my memory serves anyway) ... and has no problem with "sombrero" (my view is obviously superficial and tainted by the proportion of my experience using from the perspective of a user).
>>>   
>>>       
>> Yes, but sombrero consists of convex patches only. The patch function
>> should support concave patches as well, which is not supported by
>> gnuplot, AFAIK.
>>     
>
> I understand the difference between concave and convex in 2D, but what is the definitive difference in 3D?
>   
The same, what I meant with "concave patch in 3d", is a flat concave
polygon arbitrarily oriented in 3d space - an this is not supported by
gnuplot, AFAIK.
> Do I infer correctly that you are skeptical that the gnuplot backend is capable of implementing this functionality?
>
>   
Yes, but maybe something has changed in gnuplot since last year.

Kai

[cut]