[Scilab-users] plotplots() in Scilab

[Claus Futtrup]

I think cutaxes() will be a great extension of capabilities in Scilab.

/Claus

On 09-04-2021 17:19, Samuel Gougeon wrote:
> Hello,
>
> Le 02/04/2021 à 17:15, Samuel Gougeon a écrit :
>> Dear all,
>>
>> Thanks for your first feedbacks. I am somewhat answering in the body 
>> of this message:
>>
>> Le 02/04/2021 à 14:49, Antoine Monmayrant a écrit :
>>> On 02/04/2021 12:16, CRETE Denis wrote:
>>>>
>>>> Hello,
>>>>
>>>> I am also in favour of including this function in Scilab, with an 
>>>> “improved” name. However, as far as I know, an inset has very 
>>>> frequently its own pair of axes, as opposed to a ticks-switching in 
>>>> (only one of) the axes. Thus, I would not recommend a name with 
>>>> “inset” and reserve it for a function more closely implementing an 
>>>> inset.
>>>>
>>>> Zoom is quite appealing.
>>>>
>>>> I was wondering about “non-linear”_something…
>>>>
>>> Hello Denis,
>>>
>>> I'm with you here: this should be included, but the name is not well 
>>> matching the features of the function.
>>> Indeed, 'inset' is not at all what 'plot_plot' is offering.
>>> I was also thinking about "non-linear-axis" or something like that, 
>>> but I am not sure such a name will improve discoverability of the 
>>> function.
>>> But you are right: this is about having non-regular or non-linear axis.
>>>
>>> nonlinear-plot ? non-regular-plot ? All this is not convincing for me...
>>>
>> You know, i thought very hard about the plotplots() naming before 
>> finding and choosing this one and first publishing it ;-))
>>
>> Indeed, plotplots() is not at all about insets, although an actually 
>> zooming inset plotting separate function could also be useful (with 
>> the zooming box and possibly rays linking it to the inset).
>>
>> plotplots() is *not* about zooming or non-linear axis either: it can 
>> be used with different and only linear scales, without mixing log and 
>> lin ones.
>> So why "plotplots"? Typing "plot" in /Google Translate/ (from english 
>> to french), i've got and we still get:
>>
>> <Google's screenshot>
>>
>> So *"plots" is very frequently used with the meanings "parcels, 
>> pieces, patches, particles, shreds"*.
>> To me, this is just the right one, close to what the function 
>> actually addresses: plotting several parcels/pieces/patches of some 
>> given graphics.
>> This led me to this compact -- and i think talkative and meaningful 
>> -- plotplots() name, that's not (only) a word game.
>>
>> Other names i thought about were with "multiscaled", or thinks like 
>> "plot_multiscale". But to me, this could lead to some confusion with 
>> multiple axes covering the same whole graphic, as documented @ 
>> https://help.scilab.org/docs/6.1.0/en_US/plot_multiscaled.html.
>>
>> That's (almost) the whole story about this plotplots() name.
>> Is it more meaningful to you?
>>
>
> Apparently, the current plotplots() name used for 3 years is not so 
> bad. I agree with Denis in private mail that it could be a bit more 
> specific. Here are some other name suggestions:
>
> cutaxes
> plotcutaxes
> plotslicedaxes
> slicedaxes
> slice_axes
> sliceaxes
> plotfractional
>
> cutaxes() would have my own preferences:
>
>   * the "plot" prefix is not really required, as "axes" already
>     clearly refers to graphics. Moreover, plotplots() works as well on
>     an already plotted axes, to somewhat post-process it by cutting
>     and presenting it in another way. Actually, that's the main job of
>     the function, even when data to plot are provided instead of an
>     already plotted axes.
>
>   * it's short, and it clearly tells what it does and the result
>
>
> By the way, "cutaxes" almost means "cute axes" (with a french accent :-)
>
> After including the function in Scilab, the current plotplots as 
> external ATOMS module will no longer be maintained. If plotplots() is 
> renamed into cutaxes(), current plotplots() users will have to rename 
> it in their existing codes. This should not be a big deal, since a 
> find/replace will be able to detect occurrences and replace them.
>
> Final comments, suggestions and other feedbacks are still welcome!
>
> Samuel
>
>
> _______________________________________________
> users mailing list
> users at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20210409/67452c60/attachment.htm>