[Scilab-users] Confusion about types (typeof vs. Variabe Browser)

[Samuel Gougeon]

This is already hijacking the initial thread. I won't go on here after 
this message.

Le 06/12/2019 à 11:17, Antoine Monmayrant a écrit :
>
> Le 06/12/2019 à 08:41, Stéphane Mottelet a écrit :
>> Please think about the future of Scilab, not always its past. 

For my part, i think about future, taking into account the present.
And the past is also interesting to learn from past successes, and failures.


>
>
> I do agree with you.
> I mentioned in the past that the default colormap was so ugly it 
> should be considered a bug ( 
> http://bugzilla.scilab.org/show_bug.cgi?id=11054 ).
>
The problem was and is not that the default colormap is ugly, but that 
it holds for the whole figure, instead of per axes.

> I proposed changing the default colormap to something sensible and 
> also proposed adding decent replacement to the abomination that is 
> jetcolormap.
>

jetcolormap() is jetcolormap(), and is used as a jetcolormap swatch in 
many other softwares, noticeably thermal imaging ones.
It is one very standard colormap among other ones. I don't see the point 
about any abomination.

> The answer was: "but we can't: backward compatibility".
>
> I think scilab is one of the only plotting soft that is still using 
> horrible defaults (matlab, python.matplotib, ... all have evolved and 
> changed to reasonable defaults).


This is why i am wondering why my open post about changing the default 
grid style in axes 
<http://mailinglists.scilab.org/Scilab-users-A-new-smarter-default-grid-style-for-Scilab-6-1-0-SEP-tt4037595.html> 
has received strictly no answer, noticably from futurologists. Is it OK 
with the current defaults? Not for me.
Was it OK with the default ticks and grid style of bode() up to 6.0.1 
<https://help.scilab.org/docs/6.0.1/en_US/bode.html>? Not for me. This 
is why changing them was proposed 
<https://codereview.scilab.org/#/c/20634/> and accepted in 6.0.2 
<https://help.scilab.org/docs/6.0.2/en_US/bode.html>.
Etc, etc etc.

There were actually extremely conservative positions or 
actions/inactions about some cases -- i am wondering for instance about 
the disp() inversion --, hardly believable, because almost or definitely 
without rationale. And we can hope that, for this case, it will be 
corrected soon.

But these extreme cases -- that are even hard to consider as naive -- do 
no allow any extreme positions in the opposite, whose main processing 
could aim to avoid providing rationale as well, in the pretendly 
opposite direction but for the same reason: it's shorter, and at first 
sight, it looks easier.

Regards
Samuel


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20191206/92c44848/attachment.htm>