From sgougeon at free.fr  Thu Apr  1 22:06:52 2021
From: sgougeon at free.fr (Samuel Gougeon)
Date: Thu, 1 Apr 2021 22:06:52 +0200
Subject: [Scilab-users] plotplots() in Scilab
Message-ID: <d92c7a09-ffc8-51cc-0e51-e7771a01b6da@free.fr>

Dear all,

I would like to propose to include the plotplots() graphical function 
into Scilab.

For now 3 years, plotplots() is distributed alone in its own external 
module <https://atoms.scilab.org/toolboxes/plotplots>, with a fair 
number of downloads for a single function.

Its embedded documentation is as well provided online as PDF, in english 
<https://atoms.scilab.org/toolboxes/plotplots/2.0/files/plotplots_en_US.pdf> 
and in french 
<https://atoms.scilab.org/toolboxes/plotplots/2.0/files/plotplots_fr_FR.pdf>.

As soon as a function has a local singularity or/and an asymptotical 
behavior (that's quite common), plotplots() is very helpful to 
illustrate its specific behaviors without masking more "regular" 
features with a crushing graphical scale.

Every comment is welcome about the current plotplots status, and about 
the proposal to include it as a native Scilab function.


Hope reading you,

Best regards

Samuel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20210401/07b552bf/attachment.htm>

From Clement.David at esi-group.com  Fri Apr  2 11:19:42 2021
From: Clement.David at esi-group.com (=?utf-8?B?Q2zDqW1lbnQgRGF2aWQ=?=)
Date: Fri, 2 Apr 2021 09:19:42 +0000
Subject: [Scilab-users] plotplots() in Scilab
In-Reply-To: <d92c7a09-ffc8-51cc-0e51-e7771a01b6da@free.fr>
References: <d92c7a09-ffc8-51cc-0e51-e7771a01b6da@free.fr>
Message-ID: <PR2PR09MB356237D3D8BBE8C66C15E780B07A9@PR2PR09MB3562.eurprd09.prod.outlook.com>

Hello Samuel, hello all,

First thanks for the request for inclusion, that?s always good to have more features into Scilab itself. However, I have a few remarks regarding this function.


  1.  The function name plotplots() does not seem well known nor easy to find ; after a few research I found similar behavior for Matlab and Matplotlib worded as ?zoomed? or ?zoomed_inset_axes? which better represent the behavior.

  *   https://stackoverflow.com/questions/13583153/how-to-zoomed-a-portion-of-image-and-insert-in-the-same-plot-in-matplotlib
  *   https://fr.mathworks.com/matlabcentral/fileexchange/59857-zoomplot
  *   https://fr.mathworks.com/matlabcentral/answers/349042-zoomed-plot-in-the-same-figure

What about using `plot_zoomed()`, `plot_inset()` or `plot_inside()` ?


  1.  I found the need to have a second axe (example 1) different to recompute ticks (example 2). I might have miss something, could you clarify these two usage ?

Thanks,

Cl?ment


From: users <users-bounces at lists.scilab.org> On Behalf Of Samuel Gougeon
Sent: Thursday, April 1, 2021 10:07 PM
To: International users mailing list for Scilab. <users at lists.scilab.org>
Subject: [Scilab-users] plotplots() in Scilab


Dear all,
I would like to propose to include the plotplots() graphical function into Scilab.

For now 3 years, plotplots() is distributed alone in its own external module<https://atoms.scilab.org/toolboxes/plotplots>, with a fair number of downloads for a single function.

Its embedded documentation is as well provided online as PDF, in english<https://atoms.scilab.org/toolboxes/plotplots/2.0/files/plotplots_en_US.pdf> and in french<https://atoms.scilab.org/toolboxes/plotplots/2.0/files/plotplots_fr_FR.pdf>.

As soon as a function has a local singularity or/and an asymptotical behavior (that's quite common), plotplots() is very helpful to illustrate its specific behaviors without masking more "regular" features with a crushing graphical scale.

Every comment is welcome about the current plotplots status, and about the proposal to include it as a native Scilab function.

Hope reading you,

Best regards

Samuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20210402/ee2785a2/attachment.htm>

From arctica1963 at gmail.com  Fri Apr  2 11:53:31 2021
From: arctica1963 at gmail.com (arctica1963)
Date: Fri, 2 Apr 2021 02:53:31 -0700 (MST)
Subject: [Scilab-users] Int3D / Triple integration
In-Reply-To: <1616690702752-0.post@n3.nabble.com>
References: <1616690702752-0.post@n3.nabble.com>
Message-ID: <1617357211131-0.post@n3.nabble.com>

Hello all,

An update on a solution. Following e-mail correspondence with a fellow
Scilab user (Javier Domingo), he has worked out a general solution to
vectorising the X,Y,Z arrays for the tetrahedrons required by int3d. So
taking this part of the code and adding a call to int3d within a function we
get a simpler route to doing triple integrals given a function (f) and lower
and upper limits of integration defined by x1,x2,y1,y2,z1,z2:

function [Integral, Error] = Integral_3d (f, x1, x2, y1, y2, z1, z2)
// Divide prism (given by abscissa: x1, x2, ordinate: y1 to y2 and z1 to z2)
into
// 12 tetrahedra (not regular), starting from the center of the prism, cover
all its volume;
// providing the array IX (abscissa of the vertices of the triangles),
// and the array IY (ordinate of the vertices of the triangles).
   xc = (x1 + x2) / 2; yc = (y1 + y2) / 2; zc = (z1 + z2) / 2; // center of
prism
// coordinates of the prism tips (2 prisms on each face)
// bottom -top- right -left- front -rear-
   LX = [xc, xc, xc, xc, xc, xc, xc, xc, xc, xc, xc, xc;
       x1, x1, x1, x1, x2, x2, x1, x1, x1, x1, x1, x1;
       x2, x1, x2, x1, x2, x2, x1, x1, x2, x1, x2, x1;
       x2, x2, x2, x2, x2, x2, x1, x1, x2, x2, x2, x2];
   LY = [yc, yc, yc, yc, yc, yc, yc, yc, yc, yc, yc, yc;
       y1, y1, y1, y1, y1, y2, y1, y2, y1, y1, y2, y2;
       y1, y2, y1, y2, y2, y2, y2, y2, y1, y1, y2, y2;
       y2, y2, y2, y2, y1, y1, y1, y1, y1, y1, y2, y2];
   LZ = [zc, zc, zc, zc, zc, zc, zc, zc, zc, zc, zc, zc;
       z1, z1, z2, z2, z1, z2, z1, z2, z1, z1, z1, z1;
       z1, z1, z2, z2, z1, z1, z1, z1, z1, z2, z1, z2;
       z1, z1, z2, z2, z2, z2, z2, z2, z2, z2, z2, z2];
       
[Integral, Error] = int3d (LX, LY, LZ, f, 1, [0,100000,1.d-5,1.d-7]);

endfunction

As a simple test one can define a function v=x^2 + y^2 + z^2 with limits of
0 to 1 - which simplifies to 1.0 as the sum of the iterated integrals.

deff('v=f(xyz,numfun)','v=xyz(1)^2+xyz(2)^2+xyz(3)^2')
x1=0;x2=1;y1=0;y2=1;z1=0;z2=1;

--> [Integral, Error] = Integral_3d (f, x1, x2, y1, y2, z1, z2)
 Integral  = 

   1.
 Error  = 

   1.110D-14

Thanks to Javier for his work on defining/clarifying the X,Y,Z arrays and
logic for defining the equation in Scilab. As a suggestion it would seem
reasonable to have this aspect either built into the function (int3d) or for
a separate mesh3d function to build tetrahedrons in a format compatible with
int3d.

Always great to exchange ideas to formulate a solution to a problem.

Code tested under Scilab version 6.1.0

Lester




--
Sent from: http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html


From stephane.mottelet at utc.fr  Fri Apr  2 12:01:59 2021
From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=)
Date: Fri, 2 Apr 2021 12:01:59 +0200
Subject: [Scilab-users] Int3D / Triple integration
In-Reply-To: <1617357211131-0.post@n3.nabble.com>
References: <1616690702752-0.post@n3.nabble.com>
 <1617357211131-0.post@n3.nabble.com>
Message-ID: <4efed4fd-9f7d-b8ed-e287-cb48e9ea416f@utc.fr>

Hi Lester,

If I understand well, you are only interested by integrating on

[x1,x2] x [y1,y2] x [z1,z2]

and not a general volume, that's it ?

S.

Le 02/04/2021 ? 11:53, arctica1963 a ?crit?:
> Hello all,
>
> An update on a solution. Following e-mail correspondence with a fellow
> Scilab user (Javier Domingo), he has worked out a general solution to
> vectorising the X,Y,Z arrays for the tetrahedrons required by int3d. So
> taking this part of the code and adding a call to int3d within a function we
> get a simpler route to doing triple integrals given a function (f) and lower
> and upper limits of integration defined by x1,x2,y1,y2,z1,z2:
>
> function [Integral, Error] = Integral_3d (f, x1, x2, y1, y2, z1, z2)
> // Divide prism (given by abscissa: x1, x2, ordinate: y1 to y2 and z1 to z2)
> into
> // 12 tetrahedra (not regular), starting from the center of the prism, cover
> all its volume;
> // providing the array IX (abscissa of the vertices of the triangles),
> // and the array IY (ordinate of the vertices of the triangles).
>     xc = (x1 + x2) / 2; yc = (y1 + y2) / 2; zc = (z1 + z2) / 2; // center of
> prism
> // coordinates of the prism tips (2 prisms on each face)
> // bottom -top- right -left- front -rear-
>     LX = [xc, xc, xc, xc, xc, xc, xc, xc, xc, xc, xc, xc;
>         x1, x1, x1, x1, x2, x2, x1, x1, x1, x1, x1, x1;
>         x2, x1, x2, x1, x2, x2, x1, x1, x2, x1, x2, x1;
>         x2, x2, x2, x2, x2, x2, x1, x1, x2, x2, x2, x2];
>     LY = [yc, yc, yc, yc, yc, yc, yc, yc, yc, yc, yc, yc;
>         y1, y1, y1, y1, y1, y2, y1, y2, y1, y1, y2, y2;
>         y1, y2, y1, y2, y2, y2, y2, y2, y1, y1, y2, y2;
>         y2, y2, y2, y2, y1, y1, y1, y1, y1, y1, y2, y2];
>     LZ = [zc, zc, zc, zc, zc, zc, zc, zc, zc, zc, zc, zc;
>         z1, z1, z2, z2, z1, z2, z1, z2, z1, z1, z1, z1;
>         z1, z1, z2, z2, z1, z1, z1, z1, z1, z2, z1, z2;
>         z1, z1, z2, z2, z2, z2, z2, z2, z2, z2, z2, z2];
>         
> [Integral, Error] = int3d (LX, LY, LZ, f, 1, [0,100000,1.d-5,1.d-7]);
>
> endfunction
>
> As a simple test one can define a function v=x^2 + y^2 + z^2 with limits of
> 0 to 1 - which simplifies to 1.0 as the sum of the iterated integrals.
>
> deff('v=f(xyz,numfun)','v=xyz(1)^2+xyz(2)^2+xyz(3)^2')
> x1=0;x2=1;y1=0;y2=1;z1=0;z2=1;
>
> --> [Integral, Error] = Integral_3d (f, x1, x2, y1, y2, z1, z2)
>   Integral  =
>
>     1.
>   Error  =
>
>     1.110D-14
>
> Thanks to Javier for his work on defining/clarifying the X,Y,Z arrays and
> logic for defining the equation in Scilab. As a suggestion it would seem
> reasonable to have this aspect either built into the function (int3d) or for
> a separate mesh3d function to build tetrahedrons in a format compatible with
> int3d.
>
> Always great to exchange ideas to formulate a solution to a problem.
>
> Code tested under Scilab version 6.1.0
>
> Lester
>
>
>
>
> --
> Sent from: https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html
> _______________________________________________
> users mailing list
> users at lists.scilab.org
> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users

-- 
St?phane Mottelet
Ing?nieur de recherche
EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable
D?partement G?nie des Proc?d?s Industriels
Sorbonne Universit?s - Universit? de Technologie de Compi?gne
CS 60319, 60203 Compi?gne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet



From denis.crete at thalesgroup.com  Fri Apr  2 12:16:43 2021
From: denis.crete at thalesgroup.com (CRETE Denis)
Date: Fri, 2 Apr 2021 10:16:43 +0000
Subject: [Scilab-users] plotplots() in Scilab
In-Reply-To: <PR2PR09MB356237D3D8BBE8C66C15E780B07A9@PR2PR09MB3562.eurprd09.prod.outlook.com>
References: <d92c7a09-ffc8-51cc-0e51-e7771a01b6da@free.fr>
 <PR2PR09MB356237D3D8BBE8C66C15E780B07A9@PR2PR09MB3562.eurprd09.prod.outlook.com>
Message-ID: <125f7946caff40648d8ad2e734a91d82@thalesgroup.com>

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?

Thank you for your developments
Denis

De : users <users-bounces at lists.scilab.org> De la part de Cl?ment David
Envoy? : vendredi 2 avril 2021 11:20
? : sgougeon at free.fr; Users mailing list for Scilab <users at lists.scilab.org>
Objet : Re: [Scilab-users] plotplots() in Scilab

Hello Samuel, hello all,

First thanks for the request for inclusion, that?s always good to have more features into Scilab itself. However, I have a few remarks regarding this function.

1.       The function name plotplots() does not seem well known nor easy to find ; after a few research I found similar behavior for Matlab and Matplotlib worded as ?zoomed? or ?zoomed_inset_axes? which better represent the behavior.
?       https://stackoverflow.com/questions/13583153/how-to-zoomed-a-portion-of-image-and-insert-in-the-same-plot-in-matplotlib
?       https://fr.mathworks.com/matlabcentral/fileexchange/59857-zoomplot
?       https://fr.mathworks.com/matlabcentral/answers/349042-zoomed-plot-in-the-same-figure

What about using `plot_zoomed()`, `plot_inset()` or `plot_inside()` ?

2.       I found the need to have a second axe (example 1) different to recompute ticks (example 2). I might have miss something, could you clarify these two usage ?

Thanks,

Cl?ment


From: users <users-bounces at lists.scilab.org<mailto:users-bounces at lists.scilab.org>> On Behalf Of Samuel Gougeon
Sent: Thursday, April 1, 2021 10:07 PM
To: International users mailing list for Scilab. <users at lists.scilab.org<mailto:users at lists.scilab.org>>
Subject: [Scilab-users] plotplots() in Scilab


Dear all,
I would like to propose to include the plotplots() graphical function into Scilab.

For now 3 years, plotplots() is distributed alone in its own external module<https://atoms.scilab.org/toolboxes/plotplots>, with a fair number of downloads for a single function.

Its embedded documentation is as well provided online as PDF, in english<https://atoms.scilab.org/toolboxes/plotplots/2.0/files/plotplots_en_US.pdf> and in french<https://atoms.scilab.org/toolboxes/plotplots/2.0/files/plotplots_fr_FR.pdf>.

As soon as a function has a local singularity or/and an asymptotical behavior (that's quite common), plotplots() is very helpful to illustrate its specific behaviors without masking more "regular" features with a crushing graphical scale.

Every comment is welcome about the current plotplots status, and about the proposal to include it as a native Scilab function.

Hope reading you,

Best regards

Samuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20210402/4cb1525e/attachment.htm>

From arctica1963 at gmail.com  Fri Apr  2 12:53:42 2021
From: arctica1963 at gmail.com (arctica1963)
Date: Fri, 2 Apr 2021 03:53:42 -0700 (MST)
Subject: [Scilab-users] Int3D / Triple integration
In-Reply-To: <4efed4fd-9f7d-b8ed-e287-cb48e9ea416f@utc.fr>
References: <1616690702752-0.post@n3.nabble.com>
 <1617357211131-0.post@n3.nabble.com>
 <4efed4fd-9f7d-b8ed-e287-cb48e9ea416f@utc.fr>
Message-ID: <1617360822330-0.post@n3.nabble.com>

Hi Stephane,

At the moment I am just trying to understand how Scilab works with triple
integration of f(x,y,z) with limits for xyz. 

Lester



--
Sent from: http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html


From stephane.mottelet at utc.fr  Fri Apr  2 14:02:56 2021
From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=)
Date: Fri, 2 Apr 2021 14:02:56 +0200
Subject: [Scilab-users] Int3D / Triple integration
In-Reply-To: <1617360822330-0.post@n3.nabble.com>
References: <1616690702752-0.post@n3.nabble.com>
 <1617357211131-0.post@n3.nabble.com>
 <4efed4fd-9f7d-b8ed-e287-cb48e9ea416f@utc.fr>
 <1617360822330-0.post@n3.nabble.com>
Message-ID: <d297fb3d-e6d9-d9ed-0b53-e76041df0f2a@utc.fr>


Le 02/04/2021 ? 12:53, arctica1963 a ?crit?:
> Hi Stephane,
>
> At the moment I am just trying to understand how Scilab works with triple
> integration of f(x,y,z) with limits for xyz.

Ok, when you say "limits" for xyz you mean that each variable varies in 
a given constant interval, that's what I meant by the rectangular 
parallelepiped [x1,x2] x [y1,y2] x [z1,z2]. In fact it is a pity that 
Scilab does not handle this case but only the more general case of a 
collection of (eventually disconnected) tetrahedrons. However, cutting 
your parallepiped in 5 (https://www.geogebra.org/m/C3TjXxFY)? is enough 
to use int3d, since they will be recursively divided to attain the 
required precision:

deff('v=f(xyz,numfun)','v=xyz(1)^2+xyz(2)^2+xyz(3)^2')
xlim=[0  1];
ylim=[0  1];
zlim=[0  1];
[x,y,z]=ndgrid(xlim,ylim,zlim);
i  =  [5  8  2  3
      5  8  2  6
      5  8  3  7
      5  2  3  1
      2  3  8  4]';
[result,err]  =  int3d(x(i),y(i),z(i),f) --> result result = 1.0000000 --> err err = 
1.110D-14

S.

> Lester
>
>
>
> --
> Sent from: https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html
> _______________________________________________
> users mailing list
> users at lists.scilab.org
> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users

-- 
St?phane Mottelet
Ing?nieur de recherche
EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable
D?partement G?nie des Proc?d?s Industriels
Sorbonne Universit?s - Universit? de Technologie de Compi?gne
CS 60319, 60203 Compi?gne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

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

From antoine.monmayrant at laas.fr  Fri Apr  2 14:49:53 2021
From: antoine.monmayrant at laas.fr (Antoine Monmayrant)
Date: Fri, 2 Apr 2021 14:49:53 +0200
Subject: [Scilab-users] plotplots() in Scilab
In-Reply-To: <125f7946caff40648d8ad2e734a91d82@thalesgroup.com>
References: <d92c7a09-ffc8-51cc-0e51-e7771a01b6da@free.fr>
 <PR2PR09MB356237D3D8BBE8C66C15E780B07A9@PR2PR09MB3562.eurprd09.prod.outlook.com>
 <125f7946caff40648d8ad2e734a91d82@thalesgroup.com>
Message-ID: <fa4bc10f-0d23-dc91-ed1c-0a794dfa34ab@laas.fr>


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...

By the way, we have developed some ugly hacks in the past to get 
'non-linear' or 'non-regular' colormaps for the same reason than Samuel.
The idea was to rescale the data to Sgrayplot such that one could map 
exact intermediate Z_values to some colors of existing or new colormap:

[0, 0.1, 1, 2, 100] -> [black, red, orange, yellow, white]

One of the key advantage is that you could be sure that a certain value 
(like z=0) was exactly corresponding to a certain color (like white) 
which is sometime necessary (for plotting? asymmetric waves or fields 
with a red-white-blue colormap for example).

Antoine

> Thank you for your developments
>
> Denis
>
> *De?:*users <users-bounces at lists.scilab.org> *De la part de* Cl?ment David
> *Envoy??:* vendredi 2 avril 2021 11:20
> *??:* sgougeon at free.fr; Users mailing list for Scilab 
> <users at lists.scilab.org>
> *Objet?:* Re: [Scilab-users] plotplots() in Scilab
>
> Hello Samuel, hello all,
>
> First thanks for the request for inclusion, that?s always good to have 
> more features into Scilab itself. However, I have a few remarks 
> regarding this function.
>
> 1.The function name plotplots() does not seem well known nor easy to 
> find ; after a few research I found similar behavior for Matlab and 
> Matplotlib worded as ?zoomed? or ?zoomed_inset_axes? which better 
> represent the behavior.
>
> ?https://stackoverflow.com/questions/13583153/how-to-zoomed-a-portion-of-image-and-insert-in-the-same-plot-in-matplotlib
>
> ?https://fr.mathworks.com/matlabcentral/fileexchange/59857-zoomplot
>
> ?https://fr.mathworks.com/matlabcentral/answers/349042-zoomed-plot-in-the-same-figure
>
> What about using `plot_zoomed()`, `plot_inset()` or `plot_inside()` ?
>
> 2.I found the need to have a second axe (example 1) different to 
> recompute ticks (example 2). I might have miss something, could you 
> clarify these two usage ?
>
> Thanks,
>
> Cl?ment
>
> *From:*users <users-bounces at lists.scilab.org 
> <mailto:users-bounces at lists.scilab.org>> *On Behalf Of *Samuel Gougeon
> *Sent:* Thursday, April 1, 2021 10:07 PM
> *To:* International users mailing list for Scilab. 
> <users at lists.scilab.org <mailto:users at lists.scilab.org>>
> *Subject:* [Scilab-users] plotplots() in Scilab
>
> Dear all,
>
> I would like to propose to include the plotplots() graphical function 
> into Scilab.
>
> For now 3 years, plotplots() is distributed alone in its own external 
> module <https://atoms.scilab.org/toolboxes/plotplots>, with a fair 
> number of downloads for a single function.
>
> Its embedded documentation is as well provided online as PDF, in 
> english 
> <https://atoms.scilab.org/toolboxes/plotplots/2.0/files/plotplots_en_US.pdf>and 
> in french 
> <https://atoms.scilab.org/toolboxes/plotplots/2.0/files/plotplots_fr_FR.pdf>.
>
> As soon as a function has a local singularity or/and an asymptotical 
> behavior (that's quite common), plotplots() is very helpful to 
> illustrate its specific behaviors without masking more "regular" 
> features with a crushing graphical scale.
>
> Every comment is welcome about the current plotplots status, and about 
> the proposal to include it as a native Scilab function.
>
>
> Hope reading you,
>
> Best regards
>
> 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/20210402/5cc2e1f2/attachment.htm>

From arctica1963 at gmail.com  Fri Apr  2 15:02:26 2021
From: arctica1963 at gmail.com (arctica1963)
Date: Fri, 2 Apr 2021 06:02:26 -0700 (MST)
Subject: [Scilab-users] Int3D / Triple integration
In-Reply-To: <d297fb3d-e6d9-d9ed-0b53-e76041df0f2a@utc.fr>
References: <1616690702752-0.post@n3.nabble.com>
 <1617357211131-0.post@n3.nabble.com>
 <4efed4fd-9f7d-b8ed-e287-cb48e9ea416f@utc.fr>
 <1617360822330-0.post@n3.nabble.com>
 <d297fb3d-e6d9-d9ed-0b53-e76041df0f2a@utc.fr>
Message-ID: <1617368546798-0.post@n3.nabble.com>

Hi Stephane,

Thanks for the information and methodology, useful to know. Learn something
new all the time with Scilab!

Kind regards

Lester



--
Sent from: http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html


From arctica1963 at gmail.com  Fri Apr  2 15:49:21 2021
From: arctica1963 at gmail.com (arctica1963)
Date: Fri, 2 Apr 2021 06:49:21 -0700 (MST)
Subject: [Scilab-users] Int3D / Triple integration
In-Reply-To: <1617368546798-0.post@n3.nabble.com>
References: <1616690702752-0.post@n3.nabble.com>
 <1617357211131-0.post@n3.nabble.com>
 <4efed4fd-9f7d-b8ed-e287-cb48e9ea416f@utc.fr>
 <1617360822330-0.post@n3.nabble.com>
 <d297fb3d-e6d9-d9ed-0b53-e76041df0f2a@utc.fr>
 <1617368546798-0.post@n3.nabble.com>
Message-ID: <1617371361295-0.post@n3.nabble.com>

Quick query re: your code,

How is the index (i) defined?
i = [5 8 2 3
     5 8 2 6
     5 8 3 7
     5 2 3 1
     2 3 8 4]';

Just trying to fully understand your method.

Lester



--
Sent from: http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html


From stephane.mottelet at utc.fr  Fri Apr  2 15:53:30 2021
From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=)
Date: Fri, 2 Apr 2021 15:53:30 +0200
Subject: [Scilab-users] Int3D / Triple integration
In-Reply-To: <1617371361295-0.post@n3.nabble.com>
References: <1616690702752-0.post@n3.nabble.com>
 <1617357211131-0.post@n3.nabble.com>
 <4efed4fd-9f7d-b8ed-e287-cb48e9ea416f@utc.fr>
 <1617360822330-0.post@n3.nabble.com>
 <d297fb3d-e6d9-d9ed-0b53-e76041df0f2a@utc.fr>
 <1617368546798-0.post@n3.nabble.com> <1617371361295-0.post@n3.nabble.com>
Message-ID: <cec57900-5c63-887d-534b-ea5c7022f3ac@utc.fr>

They are the number of the vertices of the cube, as generated by ndgrid:

--> [(1:8)' x(:) y(:) z(:)]
 ?ans? =

 ?? 1.?? 0.?? 0.?? 0.
 ?? 2.?? 1.?? 0.?? 0.
 ?? 3.?? 0.?? 1.?? 0.
 ?? 4.?? 1.?? 1.?? 0.
 ?? 5.?? 0.?? 0.?? 1.
 ?? 6.?? 1.?? 0.?? 1.
 ?? 7.?? 0.?? 1.?? 1.
 ?? 8.?? 1.?? 1.?? 1.

S.

Le 02/04/2021 ? 15:49, arctica1963 a ?crit?:
> Quick query re: your code,
>
> How is the index (i) defined?
> i = [5 8 2 3
>       5 8 2 6
>       5 8 3 7
>       5 2 3 1
>       2 3 8 4]';
>
> Just trying to fully understand your method.
>
> Lester
>
>
>
> --
> Sent from: https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html
> _______________________________________________
> users mailing list
> users at lists.scilab.org
> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users

-- 
St?phane Mottelet
Ing?nieur de recherche
EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable
D?partement G?nie des Proc?d?s Industriels
Sorbonne Universit?s - Universit? de Technologie de Compi?gne
CS 60319, 60203 Compi?gne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet



From sgougeon at free.fr  Fri Apr  2 17:15:39 2021
From: sgougeon at free.fr (Samuel Gougeon)
Date: Fri, 2 Apr 2021 17:15:39 +0200
Subject: [Scilab-users] plotplots() in Scilab
In-Reply-To: <fa4bc10f-0d23-dc91-ed1c-0a794dfa34ab@laas.fr>
References: <d92c7a09-ffc8-51cc-0e51-e7771a01b6da@free.fr>
 <PR2PR09MB356237D3D8BBE8C66C15E780B07A9@PR2PR09MB3562.eurprd09.prod.outlook.com>
 <125f7946caff40648d8ad2e734a91d82@thalesgroup.com>
 <fa4bc10f-0d23-dc91-ed1c-0a794dfa34ab@laas.fr>
Message-ID: <1f6ad60f-749f-1149-bab7-68cc8878dd6b@free.fr>

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:

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?

Samuel


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20210402/1554618c/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fdglmfeibhaoppio.png
Type: image/png
Size: 48990 bytes
Desc: not available
URL: <https://lists.scilab.org/pipermail/users/attachments/20210402/1554618c/attachment.png>

From sgougeon at free.fr  Fri Apr  2 17:23:45 2021
From: sgougeon at free.fr (Samuel Gougeon)
Date: Fri, 2 Apr 2021 17:23:45 +0200
Subject: [Scilab-users] plotplots() in Scilab
In-Reply-To: <PR2PR09MB356237D3D8BBE8C66C15E780B07A9@PR2PR09MB3562.eurprd09.prod.outlook.com>
References: <d92c7a09-ffc8-51cc-0e51-e7771a01b6da@free.fr>
 <PR2PR09MB356237D3D8BBE8C66C15E780B07A9@PR2PR09MB3562.eurprd09.prod.outlook.com>
Message-ID: <4e636fe3-bf4b-db0d-4cb3-74d39d36bc52@free.fr>

Le 02/04/2021 ? 11:19, Cl?ment David a ?crit?:
> ../..
>
>  2. I found the need to have a second axe (example 1) different to
>     recompute ticks (example 2). I might have miss something, could
>     you clarify these two usage ?
>
I am afraid to not understand your query. Could you elaborate, please?


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

From arctica1963 at gmail.com  Wed Apr  7 09:25:47 2021
From: arctica1963 at gmail.com (arctica1963)
Date: Wed, 7 Apr 2021 00:25:47 -0700 (MST)
Subject: [Scilab-users] Filled polygons from polylines
Message-ID: <1617780347939-0.post@n3.nabble.com>

Hello,

I have script that reads a csv file containing the data and uses that to
calculate subsidence from well information. This all works fine, but it is
not the best way to display the result. Is it possible to take the polyline
output and generate filled polygons (similar to attached image)?

I am not sure how it is possible from the existing code to close the output
result used in the plot function to create a closed polygon. Essentially it
needs extra points otherwise you would just tie the end point and start
point of the polyline.

It would be good to get some other ideas and whether it is actually
possible. Original code was in Matlab and had all of the data within the
script, so I took that out and stored in a separate data file for ease of
use.

Thanks for any suggestions.

Lester

Backstrip_1D_v1.sce
<http://mailinglists.scilab.org/file/t495709/Backstrip_1D_v1.sce>  
A1-NC198.csv <http://mailinglists.scilab.org/file/t495709/A1-NC198.csv>  
Backstrip_1D_filled-plot.jpg
<http://mailinglists.scilab.org/file/t495709/Backstrip_1D_filled-plot.jpg>  



--
Sent from: http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html


From denis.crete at thalesgroup.com  Wed Apr  7 10:57:25 2021
From: denis.crete at thalesgroup.com (CRETE Denis)
Date: Wed, 7 Apr 2021 08:57:25 +0000
Subject: [Scilab-users] Filled polygons from polylines
In-Reply-To: <1617780347939-0.post@n3.nabble.com>
References: <1617780347939-0.post@n3.nabble.com>
Message-ID: <b37af6df67f1497abbfff1478bf24d25@thalesgroup.com>

Hello, 
The filled area is defined by 2 curves apparently; one is the top border and one is the lower border. Is it possible to construct a closed polygon using the points of both curves (something like C=[C1;C2] ) ?
HTH
Denis

-----Message d'origine-----
De?: users <users-bounces at lists.scilab.org> De la part de arctica1963
Envoy??: mercredi 7 avril 2021 09:26
??: users at lists.scilab.org
Objet?: [Scilab-users] Filled polygons from polylines

Hello,

I have script that reads a csv file containing the data and uses that to calculate subsidence from well information. This all works fine, but it is not the best way to display the result. Is it possible to take the polyline output and generate filled polygons (similar to attached image)?

I am not sure how it is possible from the existing code to close the output result used in the plot function to create a closed polygon. Essentially it needs extra points otherwise you would just tie the end point and start point of the polyline.

It would be good to get some other ideas and whether it is actually possible. Original code was in Matlab and had all of the data within the script, so I took that out and stored in a separate data file for ease of use.

Thanks for any suggestions.

Lester

Backstrip_1D_v1.sce
<http://mailinglists.scilab.org/file/t495709/Backstrip_1D_v1.sce>
A1-NC198.csv <http://mailinglists.scilab.org/file/t495709/A1-NC198.csv>
Backstrip_1D_filled-plot.jpg
<http://mailinglists.scilab.org/file/t495709/Backstrip_1D_filled-plot.jpg>  



--
Sent from: http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html
_______________________________________________
users mailing list
users at lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users


From antoine.monmayrant at laas.fr  Wed Apr  7 11:16:26 2021
From: antoine.monmayrant at laas.fr (Antoine Monmayrant)
Date: Wed, 7 Apr 2021 11:16:26 +0200
Subject: [Scilab-users] Filled polygons from polylines
In-Reply-To: <b37af6df67f1497abbfff1478bf24d25@thalesgroup.com>
References: <1617780347939-0.post@n3.nabble.com>
 <b37af6df67f1497abbfff1478bf24d25@thalesgroup.com>
Message-ID: <f3755e0a-cc18-e912-9b0d-359734917157@laas.fr>

Hello all,

I think I answered this question before on this mailing list...

Ah, yes I did:

http://mailinglists.scilab.org/Reg-Area-Between-two-curves-td3393261.html#a4026721

Get the source for "[h,epoly,ey1,ey2]=BetweenCurves(x,y1,y2,varargin)" 
in the thread.

Hope it helps,

Antoine

On 07/04/2021 10:57, CRETE Denis wrote:
> Hello,
> The filled area is defined by 2 curves apparently; one is the top border and one is the lower border. Is it possible to construct a closed polygon using the points of both curves (something like C=[C1;C2] ) ?
> HTH
> Denis
>
> -----Message d'origine-----
> De?: users <users-bounces at lists.scilab.org> De la part de arctica1963
> Envoy??: mercredi 7 avril 2021 09:26
> ??: users at lists.scilab.org
> Objet?: [Scilab-users] Filled polygons from polylines
>
> Hello,
>
> I have script that reads a csv file containing the data and uses that to calculate subsidence from well information. This all works fine, but it is not the best way to display the result. Is it possible to take the polyline output and generate filled polygons (similar to attached image)?
>
> I am not sure how it is possible from the existing code to close the output result used in the plot function to create a closed polygon. Essentially it needs extra points otherwise you would just tie the end point and start point of the polyline.
>
> It would be good to get some other ideas and whether it is actually possible. Original code was in Matlab and had all of the data within the script, so I took that out and stored in a separate data file for ease of use.
>
> Thanks for any suggestions.
>
> Lester
>
> Backstrip_1D_v1.sce
> <http://mailinglists.scilab.org/file/t495709/Backstrip_1D_v1.sce>
> A1-NC198.csv <http://mailinglists.scilab.org/file/t495709/A1-NC198.csv>
> Backstrip_1D_filled-plot.jpg
> <http://mailinglists.scilab.org/file/t495709/Backstrip_1D_filled-plot.jpg>
>
>
>
> --
> Sent from: http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html
> _______________________________________________
> users mailing list
> users at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users
> _______________________________________________
> users mailing list
> users at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users
>


From denis.crete at thalesgroup.com  Wed Apr  7 11:36:16 2021
From: denis.crete at thalesgroup.com (CRETE Denis)
Date: Wed, 7 Apr 2021 09:36:16 +0000
Subject: [Scilab-users] Filled polygons from polylines
In-Reply-To: <f3755e0a-cc18-e912-9b0d-359734917157@laas.fr>
References: <1617780347939-0.post@n3.nabble.com>
 <b37af6df67f1497abbfff1478bf24d25@thalesgroup.com>
 <f3755e0a-cc18-e912-9b0d-359734917157@laas.fr>
Message-ID: <0afc53a5b5a44cf885a513165013d18d@thalesgroup.com>

Hello, I did not look carefully at the function "BetweenCurves", but it requires y1 and y2 to share the same x data. Isn't it a limitation ? Would it be useful to extend it to the case where x1 and x2 are not identical ?
Best regards
Denis
-----Message d'origine-----
De?: users <users-bounces at lists.scilab.org> De la part de Antoine Monmayrant
Envoy??: mercredi 7 avril 2021 11:16
??: users at lists.scilab.org
Objet?: Re: [Scilab-users] Filled polygons from polylines

Hello all,

I think I answered this question before on this mailing list...

Ah, yes I did:

http://mailinglists.scilab.org/Reg-Area-Between-two-curves-td3393261.html#a4026721

Get the source for "[h,epoly,ey1,ey2]=BetweenCurves(x,y1,y2,varargin)" 
in the thread.

Hope it helps,

Antoine

On 07/04/2021 10:57, CRETE Denis wrote:
> Hello,
> The filled area is defined by 2 curves apparently; one is the top border and one is the lower border. Is it possible to construct a closed polygon using the points of both curves (something like C=[C1;C2] ) ?
> HTH
> Denis
>
> -----Message d'origine-----
> De?: users <users-bounces at lists.scilab.org> De la part de arctica1963 
> Envoy??: mercredi 7 avril 2021 09:26 ??: users at lists.scilab.org Objet?
> : [Scilab-users] Filled polygons from polylines
>
> Hello,
>
> I have script that reads a csv file containing the data and uses that to calculate subsidence from well information. This all works fine, but it is not the best way to display the result. Is it possible to take the polyline output and generate filled polygons (similar to attached image)?
>
> I am not sure how it is possible from the existing code to close the output result used in the plot function to create a closed polygon. Essentially it needs extra points otherwise you would just tie the end point and start point of the polyline.
>
> It would be good to get some other ideas and whether it is actually possible. Original code was in Matlab and had all of the data within the script, so I took that out and stored in a separate data file for ease of use.
>
> Thanks for any suggestions.
>
> Lester
>
> Backstrip_1D_v1.sce
> <http://mailinglists.scilab.org/file/t495709/Backstrip_1D_v1.sce>
> A1-NC198.csv 
> <http://mailinglists.scilab.org/file/t495709/A1-NC198.csv>
> Backstrip_1D_filled-plot.jpg
> <http://mailinglists.scilab.org/file/t495709/Backstrip_1D_filled-plot.
> jpg>
>
>
>
> --
> Sent from: 
> http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f26
> 02246.html _______________________________________________
> users mailing list
> users at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users
> _______________________________________________
> users mailing list
> users at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users
>
_______________________________________________
users mailing list
users at lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

From arctica1963 at gmail.com  Wed Apr  7 18:01:29 2021
From: arctica1963 at gmail.com (arctica1963)
Date: Wed, 7 Apr 2021 09:01:29 -0700 (MST)
Subject: [Scilab-users] Filled polygons from polylines
In-Reply-To: <f3755e0a-cc18-e912-9b0d-359734917157@laas.fr>
References: <1617780347939-0.post@n3.nabble.com>
 <b37af6df67f1497abbfff1478bf24d25@thalesgroup.com>
 <f3755e0a-cc18-e912-9b0d-359734917157@laas.fr>
Message-ID: <1617811289984-0.post@n3.nabble.com>

Hello Antoine,

Your code does seem to work since the x locations are constant for each
curve. However, I cannot see where exactly to apply the code for each layer
within my existing code and how to apply different fill colours.

This works to fill between the 2nd and 3rd polylines (see image):
[epoly,ey1,ey2]=BetweenCurves(-t,-xu(2,1:n),-xu(3,1:n)) // x=time,
y=subsidence

Sure it is something to do with the figure (f) and axes (a) handles.

Could you clarify where things go.

Many thanks

Lester

<http://mailinglists.scilab.org/file/t495709/Filled_curves.png> 



--
Sent from: http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html


From arctica1963 at gmail.com  Wed Apr  7 18:40:04 2021
From: arctica1963 at gmail.com (arctica1963)
Date: Wed, 7 Apr 2021 09:40:04 -0700 (MST)
Subject: [Scilab-users] Filled polygons from polylines
In-Reply-To: <1617811289984-0.post@n3.nabble.com>
References: <1617780347939-0.post@n3.nabble.com>
 <b37af6df67f1497abbfff1478bf24d25@thalesgroup.com>
 <f3755e0a-cc18-e912-9b0d-359734917157@laas.fr>
 <1617811289984-0.post@n3.nabble.com>
Message-ID: <1617813604060-0.post@n3.nabble.com>

Think I spotted it...

figure(1), clf

f=gcf();
f.figure_size=[1024,800];
f.figure_name = "Subsidence of the Kufrah Basin Well A1-NC198";
f.background=8 // white background


title ('Subsidence of the Kufrah Basin Well A1-NC198') // Figure title

subplot (2,1,1)

a=gca();
a.font_size=3

[f,epoly,ey1,ey2]=BetweenCurves(-t,-xu(2,1:n),-xu(3,1:n),'Handle',f,'axis',a,
'foreground', 12 ) // for each interval

plot (-t,-xu(2,1:n),'b-o',..
      -t,-xu(3,1:n),'b-o',..
      -t,-xu(4,1:n),'b-o',.. etc





--
Sent from: http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html


From johan.lafitte at gmail.com  Fri Apr  9 09:35:09 2021
From: johan.lafitte at gmail.com (johan64)
Date: Fri, 9 Apr 2021 00:35:09 -0700 (MST)
Subject: [Scilab-users] xcos_simulate()
In-Reply-To: <1614513346933-0.post@n3.nabble.com>
References: <CAP8EK979XoE5+_knU2khZ6P9WYvpxDgBhks8rhhwgfVnO1JnTQ@mail.gmail.com>
 <1614513346933-0.post@n3.nabble.com>
Message-ID: <1617953709352-0.post@n3.nabble.com>

Hi,

Quick demonstration of the system :

https://youtu.be/_E3ElQalODI <https://youtu.be/_E3ElQalODI>  

I 've used the tool AnimaGIF. Because the sampling frequency of the scilab
model is 10Hz < 24 frames/sec
i've used slowmoVideo to interpolate "missing frames". This freeware uses
optical flow method.

It could be a good way to make fluent animation in addition to AnimaGIF.

Cordialy



--
Sent from: http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html


From Clement.David at esi-group.com  Fri Apr  9 10:13:03 2021
From: Clement.David at esi-group.com (=?utf-8?B?Q2zDqW1lbnQgRGF2aWQ=?=)
Date: Fri, 9 Apr 2021 08:13:03 +0000
Subject: [Scilab-users] xcos_simulate()
In-Reply-To: <1614513346933-0.post@n3.nabble.com>
References: <CAP8EK979XoE5+_knU2khZ6P9WYvpxDgBhks8rhhwgfVnO1JnTQ@mail.gmail.com>
 <1614513346933-0.post@n3.nabble.com>
Message-ID: <PR2PR09MB356255BFC20607EE97CEFA3CB0739@PR2PR09MB3562.eurprd09.prod.outlook.com>

Hi Johan,

First, sorry for the delay I tagged your mails to be read later but took some time to reach them ?. Your last mail bumped the full conversation.

To better understand the simulation time, let me describe you what happens when you click play. After creating the schema you basically have a set of blocks with parameter values set at edition time and a set of links that connect blocks. Before simulation happens there is still work to do:
 1. As parameters can change the structure of blocks, we need to refresh/evaluate all blocks to set a parameters to the current values.
 2. A flatten copy is created to resolve inputs/outputs ports on subsystem
 3. The schedule of the graph is computed and a "compiled" cpr structure is created

On the simulation phase, you can only use this cpr structure to run ODE solvers on your system and produce results.

If you want to do multiple simulation of the same system changing only parameters *and* keeping the same diagram structure, I suggest you to use `Info = scicos_simulate(scs_m, Info)` where Info is defined as : Info = list(%tcur, %cpr, alreadyran, needstart, needcompile, %state0) . This seems not documented enough.

You can update parameters on Info(2) , the cpr, or Info(6) , the states, by yourself. This will remove all "compilation time" without using the internal scicosim  and let you change final time or filter parameters for example. For customers, we used this approach to do some optimization on filter coefficient.

Hope this will help you,
Regards,

Cl?ment


-----Original Message-----
From: users <users-bounces at lists.scilab.org> On Behalf Of johan64
Sent: Sunday, February 28, 2021 12:56 PM
To: users at lists.scilab.org
Subject: Re: [Scilab-users] xcos_simulate()

Hi,

I am sorry, there is a mistake in my first post. Please, don't care about the script described in italic.

My need is to compile my xcos diagram one time, simulate, then change context parameters and run other simulations (in order to perform parametric optimization on a large xcos model with many parameters and about 10-15 state variables).

I did some research and tests. To sum up :

1/xcos_simulate(scs_m,needcompile) : According to the Scilab Help, needcompil is "DEPRECATED". Therefore, compilation is needed each times.

//////////////////////////////
2/scicos_simulate(scs_m,Info). I tried the PID optimization example method.
https://wiki.scilab.org/Xcos/Examples/PID
<https://wiki.scilab.org/Xcos/Examples/PID>  

Execute my model with
///Lancement de la simulation
disp("lancement")
 tic();
Info=scicos_simulate(scs_m,list())
disp( "Dur?e simulation1",toc());
tic();
Info=scicos_simulate(scs_m,Info)
 disp( "Dur?e simulation2",toc())/

Gives

/"lancement"    
"Dur?e simulation1"     83.604448    
"Dur?e simulation2"     81.738820/
Therefore, I win just 2 seconds with this method

/////////////////////////////////////////////////////
3/scicosim(); It seems to be the holy grail.
/
disp("lancement")
tic();
cpr=xcos_simulate(scs_m,4)
//cpr = xcos_compile(scs_m);
disp( "Simulation time 1 =",toc());
//Exploitation des donn?es de compilation state0=cpr.state; // cpr variable came from the compilation sim=cpr.sim; //Param?tre de simulation tf=111; atol=1.e-6; rtol=1.e-6; ttol=1.e-10; deltat=tf; scale=0; solver=0; hmax=0.1;

tol=[atol,rtol,ttol,deltat,scale,solver,hmax];

//Enregistrement des r?sultats
//save(pathu_result);

tic();
// initialisation
[state,t]=scicosim(state0,0,tf,sim,'start',tol);
// run
[state,t]=scicosim(state,t,tf,sim,'run',tol)
//end
[state,t]=scicosim(state,t,tf,sim,'finish',tol);
disp("Simulation time 2"+" = ",toc());
/
Gives
/
"Simulation time 1 ="

   83.815849

  "Simulation time 2 = "

   0.9816021
/ 

I win about 83 seconds!!! 

Unfortunately, after running xcos_simulate one time, I don't find simple way to change context parameters without launch xcos_simulate again (using
scs_m.props.context...) which wastes simulation time.
cpr.sim.rpar seems to contain block parameters but without symbolic expression.

does anyone have an idea?

Thank you for your help






--
Sent from: http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html
_______________________________________________
users mailing list
users at lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

From Clement.David at esi-group.com  Fri Apr  9 10:17:46 2021
From: Clement.David at esi-group.com (=?utf-8?B?Q2zDqW1lbnQgRGF2aWQ=?=)
Date: Fri, 9 Apr 2021 08:17:46 +0000
Subject: [Scilab-users] xcos_simulate()
In-Reply-To: <CAP8EK979XoE5+_knU2khZ6P9WYvpxDgBhks8rhhwgfVnO1JnTQ@mail.gmail.com>
References: <CAP8EK979XoE5+_knU2khZ6P9WYvpxDgBhks8rhhwgfVnO1JnTQ@mail.gmail.com>
Message-ID: <PR2PR09MB3562227750685E754F5FAD16B0739@PR2PR09MB3562.eurprd09.prod.outlook.com>

Hi (again Johan),

For your information, we track/fix issue on big models by testing them in internal workbench. If you have simulation issue, we can add your model on this non-opensource set to try to improve the compilation time for it. Don?t hesitate to mail it to me (might be a partial or without parameter knowledge).

Regards,

Cl?ment

From: users <users-bounces at lists.scilab.org> On Behalf Of Johan Lafitte
Sent: Wednesday, February 10, 2021 6:41 PM
To: users at lists.scilab.org
Subject: [Scilab-users] xcos_simulate()

Hi,

My xcos model becomes quite large and takes time to compile. In order to launch batches and optimisation process, it seems possible to compile the model juste one time.
However, I meet the same difficulties as described in this post :

http://mailinglists.scilab.org/xcos-xcos-simulate-scs-m-1-or-xcos-simulate-scs-m-4-td4031207.html#a4031274">http://mailinglists.scilab.org/xcos-xcos-simulate-scs-m-1-or-xcos-simulate-scs-m-4-td4031207.html#a4031274

Indeed, the following script...
  ___________________________________
loadXcosLibs;
importXcosDiagram("C:\Users\johan\OneDrive\Micro entreprise\Technique\Kayak guide\Mod?lisation\Scilab\optimisation"+"\mod?le physique et commande simple_10_opti.zcos");
tic();
xcos_simulate(scs_m, 4);
disp("m?thode 2",toc());

tic();
%cpr = xcos_compile(scs_m);
disp( "Dur?e compilation",toc());

tic();
xcos_simulate(scs_m,1)
disp( "m?thode 1",toc());
  ___________________________________

...gives the following results :
 ___________________________________
"scicos_simulate step 1"
   50.813412 s

  "scicos_simulate step 2"
   57.440604 s

  "xcos_simulate(scs_m, 4) m?thode 2"
   58.808546 s

  "Compilation duration"
   55.615238 s

  "xcos_simulate(scs_m,1) m?thode 1"
   61.133700 s
 ______________________________

It seems the compilation step is done in all these cases.

Thank you for your time and for your help

Johan

note 1 : when the final time of the simulation is set from 20s to 200s, the execution time increases about 15s

note 2 : according to the windows task manager, CPUs seem to be used about 30% during compilation and about 100% during simulation which takes few seconds
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20210409/31f6c1b6/attachment.htm>

From sgougeon at free.fr  Fri Apr  9 17:19:56 2021
From: sgougeon at free.fr (Samuel Gougeon)
Date: Fri, 9 Apr 2021 17:19:56 +0200
Subject: [Scilab-users] plotplots() in Scilab
In-Reply-To: <1f6ad60f-749f-1149-bab7-68cc8878dd6b@free.fr>
References: <d92c7a09-ffc8-51cc-0e51-e7771a01b6da@free.fr>
 <PR2PR09MB356237D3D8BBE8C66C15E780B07A9@PR2PR09MB3562.eurprd09.prod.outlook.com>
 <125f7946caff40648d8ad2e734a91d82@thalesgroup.com>
 <fa4bc10f-0d23-dc91-ed1c-0a794dfa34ab@laas.fr>
 <1f6ad60f-749f-1149-bab7-68cc8878dd6b@free.fr>
Message-ID: <1f72c89a-5e55-6084-f26c-cf14337e3131@free.fr>

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

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

From sgougeon at free.fr  Fri Apr  9 17:57:12 2021
From: sgougeon at free.fr (Samuel Gougeon)
Date: Fri, 9 Apr 2021 17:57:12 +0200
Subject: [Scilab-users] Precedence rules for concurrent native and external
 builtin homonymous functions?
Message-ID: <f411d60c-4799-1c5f-37ca-8945111803af@free.fr>

Dear all,

I am wondering about precedence rules when a user's defined builtin 
(possibly from an ATOMS external module) has the same name than a native 
Scilab builtin function.
The case appeared (and maybe still) when using the scicv external 
module, that redefined a write() function that already exists in Scilab.

Does anyone know how such conflicts are managed by Scilab?
Thanks

Samuel

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

From antoine.monmayrant at laas.fr  Fri Apr  9 18:08:44 2021
From: antoine.monmayrant at laas.fr (Antoine Monmayrant)
Date: Fri, 9 Apr 2021 18:08:44 +0200
Subject: [Scilab-users] Precedence rules for concurrent native and
 external builtin homonymous functions?
In-Reply-To: <f411d60c-4799-1c5f-37ca-8945111803af@free.fr>
References: <f411d60c-4799-1c5f-37ca-8945111803af@free.fr>
Message-ID: <37d06d48-5793-9131-a6a4-db628cf5c7aa@laas.fr>


On 09/04/2021 17:57, Samuel Gougeon wrote:
>
> Dear all,
>
> I am wondering about precedence rules when a user's defined builtin 
> (possibly from an ATOMS external module) has the same name than a 
> native Scilab builtin function.
> The case appeared (and maybe still) when using the scicv external 
> module, that redefined a write() function that already exists in Scilab.
>
> Does anyone know how such conflicts are managed by Scilab?
>
Poorly or not at all according to my own painful experience with grocer 
and scicv that caused weird behaviours by overloading existing functions...

Qntoine

> Thanks
>
> 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/60bbd75d/attachment.htm>

From sgougeon at free.fr  Fri Apr  9 18:14:04 2021
From: sgougeon at free.fr (Samuel Gougeon)
Date: Fri, 9 Apr 2021 18:14:04 +0200
Subject: [Scilab-users] Precedence rules for concurrent native and
 external builtin homonymous functions?
In-Reply-To: <37d06d48-5793-9131-a6a4-db628cf5c7aa@laas.fr>
References: <f411d60c-4799-1c5f-37ca-8945111803af@free.fr>
 <37d06d48-5793-9131-a6a4-db628cf5c7aa@laas.fr>
Message-ID: <cf298f3b-93c4-e57a-18d7-c6cff3d1cc04@free.fr>

Le 09/04/2021 ? 18:08, Antoine Monmayrant a ?crit?:
>
>
> On 09/04/2021 17:57, Samuel Gougeon wrote:
>>
>> Dear all,
>>
>> I am wondering about precedence rules when a user's defined builtin 
>> (possibly from an ATOMS external module) has the same name than a 
>> native Scilab builtin function.
>> The case appeared (and maybe still) when using the scicv external 
>> module, that redefined a write() function that already exists in Scilab.
>>
>> Does anyone know how such conflicts are managed by Scilab?
>>
> Poorly or not at all according to my own painful experience with 
> grocer and scicv that caused weird behaviours by overloading existing 
> functions...
>
Doesn't Grocer use only macros, not a single builtin function?
My question is only about hard-coded (so called builtin or "primitive") 
functions.

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

From stephane.mottelet at utc.fr  Fri Apr  9 18:15:44 2021
From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=)
Date: Fri, 9 Apr 2021 18:15:44 +0200
Subject: [Scilab-users] Precedence rules for concurrent native and
 external builtin homonymous functions?
In-Reply-To: <f411d60c-4799-1c5f-37ca-8945111803af@free.fr>
References: <f411d60c-4799-1c5f-37ca-8945111803af@free.fr>
Message-ID: <bf7ef8aa-044d-3240-39e0-c2c2cf38d35d@utc.fr>

Samuel, I think the problem is about gateways not user macros right ?

What I experienced is that the new gateways have precedence over the 
previously linked gateways with the same name.

Hence, there is no conflict is the API is respected...

S.

Le 09/04/2021 ? 17:57, Samuel Gougeon a ?crit?:
>
> Dear all,
>
> I am wondering about precedence rules when a user's defined builtin 
> (possibly from an ATOMS external module) has the same name than a 
> native Scilab builtin function.
> The case appeared (and maybe still) when using the scicv external 
> module, that redefined a write() function that already exists in Scilab.
>
> Does anyone know how such conflicts are managed by Scilab?
> Thanks
>
> Samuel
>
>
> _______________________________________________
> users mailing list
> users at lists.scilab.org
> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users

-- 
St?phane Mottelet
Ing?nieur de recherche
EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable
D?partement G?nie des Proc?d?s Industriels
Sorbonne Universit?s - Universit? de Technologie de Compi?gne
CS 60319, 60203 Compi?gne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

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

From cfuttrup at gmail.com  Fri Apr  9 18:18:31 2021
From: cfuttrup at gmail.com (Claus Futtrup)
Date: Fri, 9 Apr 2021 18:18:31 +0200
Subject: [Scilab-users] plotplots() in Scilab
In-Reply-To: <1f72c89a-5e55-6084-f26c-cf14337e3131@free.fr>
References: <d92c7a09-ffc8-51cc-0e51-e7771a01b6da@free.fr>
 <PR2PR09MB356237D3D8BBE8C66C15E780B07A9@PR2PR09MB3562.eurprd09.prod.outlook.com>
 <125f7946caff40648d8ad2e734a91d82@thalesgroup.com>
 <fa4bc10f-0d23-dc91-ed1c-0a794dfa34ab@laas.fr>
 <1f6ad60f-749f-1149-bab7-68cc8878dd6b@free.fr>
 <1f72c89a-5e55-6084-f26c-cf14337e3131@free.fr>
Message-ID: <5eb662fd-99ff-98e3-2d86-658f377c9fef@gmail.com>


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>

From sgougeon at free.fr  Fri Apr  9 18:32:45 2021
From: sgougeon at free.fr (Samuel Gougeon)
Date: Fri, 9 Apr 2021 18:32:45 +0200
Subject: [Scilab-users] find and locate local maxima
In-Reply-To: <C1165F01A4B61C48AF8B97D1C4AB348B9D387021@EXDAG0-B2.intra.cea.fr>
References: <C1165F01A4B61C48AF8B97D1C4AB348B9D386905@EXDAG0-B2.intra.cea.fr>
 <PR2PR09MB3562946C4F0820D8EC92D948B06B9@PR2PR09MB3562.eurprd09.prod.outlook.com>
 <C1165F01A4B61C48AF8B97D1C4AB348B9D3869B5@EXDAG0-B2.intra.cea.fr>
 <db8455b3-1b4c-2717-03dd-ecbb90bb7a3e@utc.fr>
 <9dce5c0e-4d74-6966-0e94-e8658cb50f9e@gmail.com>
 <PR2PR09MB35628B073202B60D2644EBE9B06A9@PR2PR09MB3562.eurprd09.prod.outlook.com>
 <d4c36f27-9518-a28d-8030-8e4baff8e6ee@utc.fr>
 <C1165F01A4B61C48AF8B97D1C4AB348B9D387021@EXDAG0-B2.intra.cea.fr>
Message-ID: <0d2cc0bc-106f-dfe7-a390-9a44eae78651@free.fr>

Le 18/03/2021 ? 12:43, CHEZE David 227480 a ?crit?:
> Hi all,
>
> I?d be glad obviously to download the whole package to test it and 
> report my experience :? I?m not use with the ?review interface? is 
> there any way to download the whole package or I just retrieve files 
> one by one ?

For another occasion on https://codereview.scilab.org : unfortunately, 
AFAIK it is not possible to download the whole set of listed files 
(so-called a "Patch Set" (of files)) and only them.
Either one has to download files one by one. Or to download the whole 
Scilab source code including the Patch Set files (in their proposed 
version):
Click on "*Download*" on the top right ; then use the "*Archive"* links.



I agree that for people that just want to use the web interface of the 
forge, being able to download the whole Patch Set and only it would be 
helpful.

Samuel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20210409/d4da013d/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kbgdlmnlckicglpe.png
Type: image/png
Size: 31831 bytes
Desc: not available
URL: <https://lists.scilab.org/pipermail/users/attachments/20210409/d4da013d/attachment.png>

From sgougeon at free.fr  Fri Apr  9 19:51:23 2021
From: sgougeon at free.fr (Samuel Gougeon)
Date: Fri, 9 Apr 2021 19:51:23 +0200
Subject: [Scilab-users] Filled polygons from polylines
In-Reply-To: <1617780347939-0.post@n3.nabble.com>
References: <1617780347939-0.post@n3.nabble.com>
Message-ID: <12180b4a-771c-3ab6-c255-54de0354825d@free.fr>

Le 07/04/2021 ? 09:25, arctica1963 a ?crit?:
> Hello,
>
> I have script that reads a csv file containing the data and uses that to
> calculate subsidence from well information. This all works fine, but it is
> not the best way to display the result. Is it possible to take the polyline
> output and generate filled polygons (similar to attached image)?
>
> I am not sure how it is possible from the existing code to close the output
> result used in the plot function to create a closed polygon. Essentially it
> needs extra points otherwise you would just tie the end point and start
> point of the polyline.
>
> It would be good to get some other ideas and whether it is actually
> possible. Original code was in Matlab and had all of the data within the
> script, so I took that out and stored in a separate data file for ease of
> use.
>
> Thanks for any suggestions.
>
> Lester
>
> Backstrip_1D_v1.sce
> <http://mailinglists.scilab.org/file/t495709/Backstrip_1D_v1.sce>
> A1-NC198.csv <http://mailinglists.scilab.org/file/t495709/A1-NC198.csv>
> Backstrip_1D_filled-plot.jpg
> <http://mailinglists.scilab.org/file/t495709/Backstrip_1D_filled-plot.jpg>


Here is a simple example:

y = rand(1,20);
y2 = rand(1,20)+1;
y3 = rand(1,20)+2;
clf, plot([0 y3 0])
plot([0 y2 0])
plot([0 y 0])
gca().children.children.fill_mode = "on";
gca().children.children.background = [color("grey30") ; color("grey50") 
; color("grey70")];

Samuel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20210409/4cbfb855/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jdoocbpkmhcmpnmg.png
Type: image/png
Size: 10081 bytes
Desc: not available
URL: <https://lists.scilab.org/pipermail/users/attachments/20210409/4cbfb855/attachment.png>

From sgougeon at free.fr  Fri Apr  9 19:58:37 2021
From: sgougeon at free.fr (Samuel Gougeon)
Date: Fri, 9 Apr 2021 19:58:37 +0200
Subject: [Scilab-users] Filled polygons from polylines
In-Reply-To: <12180b4a-771c-3ab6-c255-54de0354825d@free.fr>
References: <1617780347939-0.post@n3.nabble.com>
 <12180b4a-771c-3ab6-c255-54de0354825d@free.fr>
Message-ID: <7ced9bbb-2501-4f66-5bb0-ace5010563c0@free.fr>

Or better, to avoid artfefacts on boundaries:

y  =  rand(1,20);
y2  =  rand(1,20)+1;
y3  =  rand(1,20)+2;
x  =  [1  1:20  20];
clf,  plot(x,  [0  y3  0])
plot(x,  [0  y2  0])
plot(x,  [0  y  0])
gca().children.children.fill_mode= "on"
gca().children.children.background= [color("grey30"); color("grey50") ; 
color("grey70")];


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20210409/3e97cba5/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ihleoghhfekhnfnb.png
Type: image/png
Size: 7601 bytes
Desc: not available
URL: <https://lists.scilab.org/pipermail/users/attachments/20210409/3e97cba5/attachment.png>

From sgougeon at free.fr  Fri Apr  9 20:29:15 2021
From: sgougeon at free.fr (Samuel Gougeon)
Date: Fri, 9 Apr 2021 20:29:15 +0200
Subject: [Scilab-users] Why window() provides only symmetric weighting?
In-Reply-To: <c79312b9-0333-cc0e-f7ec-e6cbe0bcf844@fceia.unr.edu.ar>
References: <c79312b9-0333-cc0e-f7ec-e6cbe0bcf844@fceia.unr.edu.ar>
Message-ID: <bcc908b0-947c-ca22-5a70-ed2fa95cb75e@free.fr>

Dear Federico,

Thank you for the proposal.
I am afraid that the "symmetric" and "periodic" flag names are not 
intuitive to me.
Indeed, the generated window is /always/ both periodic and symmetric. It 
is anyway "algorithmically seen" as periodic (from a spectral point of 
view), since it is regularly sampled, while regular-sampling and 
periodicity are FT-dual.

The point is that it is either *open*, or *closed* (what is rather 
expected, for a window. Sorry for the (serious) joke :-), with a closing 
point at the same level as the opening one.

I know from where these "symmetric" and "periodic" keyworks come from.
But, sorry, i can't resolve myself blindly copy others without 
discussion. Badly naming things usually become counterproductive, 
noticeably when teaching (here signal processing).

For contribution,

Best regards
Samuel


Le 11/02/2021 ? 08:12, Federico Miyara a ?crit?:
>
> Dear All,
>
> I wonder why windowing functions such as Hann, Hamming, etc., provided 
> by window(), are only symmetric.
>
> When used for spectral analysis by subsequent use of fft(), the 
> periodic weighting is better than the symmetric one. The symmetric 
> window is mainly used in the design of FIR filters, which I guess is a 
> less frequent application than spectral analysis.
>
> While it is true that an easy workaround to get a periodic window of 
> length n is, for instance
>
> w = window("hn", n+1)(1:$-1);
>
> a syntax such as this
>
> w = window("hn", n, "per");
>
> would be easier.Setting "sym" as the default option, no backward 
> compatibility issues would possibly arise.
>
> Regards,
>
> Federico Miyara
>
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 
> 	Libre de virus. www.avast.com 
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 
>
>
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> _______________________________________________
> 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/a42f213d/attachment.htm>

From sgougeon at free.fr  Fri Apr  9 20:56:57 2021
From: sgougeon at free.fr (Samuel Gougeon)
Date: Fri, 9 Apr 2021 20:56:57 +0200
Subject: [Scilab-users] Overarching subplot title for graphic window
In-Reply-To: <1615412419386-0.post@n3.nabble.com>
References: <1615412419386-0.post@n3.nabble.com>
Message-ID: <2d9f5948-6e74-0544-4d54-dcd52caf6e5e@free.fr>

Le 10/03/2021 ? 22:40, bty22 a ?crit?:
> Hello,
>
> I have been trying to figure out a way to add an overarching title on the
> graphic window that goes above the subplots? I have titles over each of my
> subplots, but I want one that is the title of the graphic window where the
> subplots are shown. I want to have the title to give a summary of what the
> subplots are of.
>
> I know it can be done in matlab through suptitle, but I couldn't find a
> respective equivalent for scilab.
>
> Thank you for your response in advance.


The following simple code should work, but a subplot's bug prevents it. 
Let's fix it for the next scilab version:

clf,  title  "The  overall  title"  fontsize  4
subplot(1,2,1),  Matplot1,  title  "Plot  #1",  xlabel  ""
subplot(1,2,2),  param3d,  title  "Plot  #2"

The position of the main title can be tuned afterwards.

Samuel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20210409/bb56aae1/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: epinogfjeifamdjn.png
Type: image/png
Size: 53196 bytes
Desc: not available
URL: <https://lists.scilab.org/pipermail/users/attachments/20210409/bb56aae1/attachment.png>

From heinznabielek at me.com  Fri Apr  9 23:55:23 2021
From: heinznabielek at me.com (Heinz Nabielek)
Date: Fri, 9 Apr 2021 23:55:23 +0200
Subject: [Scilab-users] xfpoly: would wish that the filling colour could be
	made transparent.
In-Reply-To: <2d9f5948-6e74-0544-4d54-dcd52caf6e5e@free.fr>
References: <1615412419386-0.post@n3.nabble.com>
 <2d9f5948-6e74-0544-4d54-dcd52caf6e5e@free.fr>
Message-ID: <921C1491-5590-4FC5-977E-4224506196A1@me.com>

xfpoly does generally a good job for me, sometimes I would wish that the filling colour could be made transparent.
Heinz

PS 1: Is there a new version of the 2011 BetweenCurves around?

PS 2: Any suggestion to make my clumsy coding more elegent, is highly welcome

PS 2: BTW, since the recent lockdown, infection rates are coming down in Austria.....


A=[12.628    13.942    17.077    17.054    15.594    14.976    14.796    11.875    13.448    16.504    17.717    19.447    16.099    13.302    13.762    16.032    19.492    22.098    20.425    21.087    20.649    14.268    19.402    22.525    26.862    23.514    27.603    23.851    15.830    21.570    28.682    26.109    29.974    28.727    24.705    21.458    27.087    28.401    33.670    35.119    33.962    28.120    21.301    27.244    37.467    37.715    39.490    37.569    30.480    27.098    38.366    36.951    35.097    43.759    39.299]';
d=(1:length(A))';
up=10^(d/53);
M=[ones(up) up];
aa=M\A;
B=inv(M'*M);
DD=(1:110)';
U=10^(DD/53);
MM=[ones(U) U];
yh = M*aa;     //Fitted values yh to approximate measured y's
e=A-yh;     //Errors or residuals
SSE=e'*e;     //Sum of squared errors
ybar=mean(A); R2=1-SSE/sum((A-ybar)^2);
[m n]=size(M);
MSE = SSE/(m-n-1);     //Mean square error
C=MSE*B  // covariance matrix
sig=sqrt(MSE);
seb=sqrt(diag(C));
[aa seb]
[n pp]=size(M);
CONF=.95; alpha=1-CONF;
ta2 = cdft('T',n-pp,1-alpha/2,alpha/2);     //t-value for alpha/2
yhh= MM*aa;
p=sig*sqrt(diag(1+MM*B*MM'));
N=[yhh+ta2*p  yhh-ta2*p];
polyX = [DD;flipdim(DD,1)];
polyY = [N(:,1);flipdim(N(:,2),1)];
plot2d([0 80],[1 100], style=0,logflag = "nl");
xgrid;
xfpoly(polyX, polyY,6);
plot(DD,MM*aa,'g.-');
plot(d,A,'b.') ;
title('AUSTRIA daily infection rates per 100,000','fontsize',5);
xlabel('days since 1 Feb 2021','fontsize',3);
ylabel('number of infections per day per 100,000','fontsize',3);
legend('data from Johns Hopkins GitHub','95% confidence range','model prediction','AUSTRIA recorded',4);


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20210409/5bb888b0/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AUSTRIA daily infection rates per 100,000 + confidence.pdf
Type: application/pdf
Size: 51769 bytes
Desc: not available
URL: <https://lists.scilab.org/pipermail/users/attachments/20210409/5bb888b0/attachment.pdf>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20210409/5bb888b0/attachment-0001.htm>

From antoine.monmayrant at laas.fr  Sat Apr 10 08:10:03 2021
From: antoine.monmayrant at laas.fr (Antoine Monmayrant)
Date: Sat, 10 Apr 2021 08:10:03 +0200
Subject: [Scilab-users] xfpoly: would wish that the filling colour could
 be made transparent.
In-Reply-To: <921C1491-5590-4FC5-977E-4224506196A1@me.com>
References: <1615412419386-0.post@n3.nabble.com>
 <2d9f5948-6e74-0544-4d54-dcd52caf6e5e@free.fr>
 <921C1491-5590-4FC5-977E-4224506196A1@me.com>
Message-ID: <75595f62-031a-d0a6-a82c-35899509ad31@laas.fr>


On 09/04/2021 23:55, Heinz Nabielek wrote:
> xfpoly does generally a good job for me, sometimes I would wish that 
> the filling colour could be made transparent.
This is a much needed improvement of the scilab graphical stack that 
currently does not provide any transparency.
I think this is not an easy improvement.
At the moment, my workaround is to plot everything I need, export as svg 
and than add the transparency I need in the svg using inkscape or 
directly editing the svg file with a text editor...
> Heinz
>
> PS 1: Is there a new version of the 2011?BetweenCurves around?
Er, no, it was just a dirty hack I needed for my own publications and I 
think 2011 is the most recent one.
I can try to see how to improve it if this can improve scilab...
>
> PS 2: Any suggestion to make my clumsy coding more elegent, is highly 
> welcome
>
> PS 2: BTW, since the recent lockdown, infection rates are coming down 
> in Austria.....
>
>
> A=[12.628     13.942     17.077     17.054     15.594     14.976     14.796     11.875     13.448     16.504     17.717     19.447     16.099     13.302     13.762     16.032     19.492     22.098     20.425     21.087     20.649     14.268     19.402     22.525     26.862     23.514     27.603     23.851     15.830     21.570     28.682     26.109     29.974     28.727     24.705     21.458     27.087     28.401     33.670     35.119     33.962     28.120     21.301     27.244     37.467     37.715     39.490     37.569     30.480     27.098     38.366     36.951     35.097     43.759     39.299]';
> d=(1:length(A))';
> up=10^(d/53);
> M=[ones(up)  up];
> aa=M\A;
> B=inv(M'*M);
> DD=(1:110)';
> U=10^(DD/53);
> MM=[ones(U)  U];
> yh  =  M*aa;      //Fitted values yh to approximate measured y's
> e=A-yh;      //Errors or residuals
> SSE=e'*e;      //Sum of squared errors
> ybar=mean(A);  R2=1-SSE/sum((A-ybar)^2);
> [m  n]=size(M);
> MSE  =  SSE/(m-n-1);      //Mean square error
> C=MSE*B   // covariance matrix
> sig=sqrt(MSE);
> seb=sqrt(diag(C));
> [aa  seb]
> [n  pp]=size(M);
> CONF=.95;  alpha=1-CONF;
> ta2  =  cdft('T',n-pp,1-alpha/2,alpha/2);      //t-value for alpha/2
> yhh=  MM*aa;
> p=sig*sqrt(diag(1+MM*B*MM'));
> N=[yhh+ta2*p   yhh-ta2*p];
> polyX  =  [DD;flipdim(DD,1)];
> polyY  =  [N(:,1);flipdim(N(:,2),1)];
> plot2d([0  80],[1  100],  style=0,logflag  =  "nl");
> xgrid;
> xfpoly(polyX,  polyY,6);
> plot(DD,MM*aa,'g.-');
> plot(d,A,'b.')  ;
> title('AUSTRIA daily infection rates per 100,000','fontsize',5);
> xlabel('days since 1 Feb 2021','fontsize',3);
> ylabel('number of infections per day per 100,000','fontsize',3);
> legend('data from Johns Hopkins GitHub','95% confidence range','model 
> prediction','AUSTRIA recorded',4);
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20210410/d5e66e18/attachment.htm>

From sgougeon at free.fr  Sat Apr 10 11:17:53 2021
From: sgougeon at free.fr (Samuel Gougeon)
Date: Sat, 10 Apr 2021 11:17:53 +0200
Subject: [Scilab-users] Improving atomsInstall()
Message-ID: <f1f20876-22b2-613a-af98-01973e909afc@free.fr>

Dear all,

When we install an external ATOMS toolbox, the installation does /not/ 
load it. Then the toolbox is not readily usable. The loading is an extra 
operation to do afterward.
The installation and removal should be improved in the next scilab 
version: now the Toolboxes menu will be updated, without restarting Scilab.

What about going further? Don't we expect the just installed toolbox to 
be right away usable -- that is to say, already loaded at the end?
If so, IMHO there are 2 situations:

  * either the toolbox was not already installed, for no version of it.
    Then its installation could end with automatically loading it.
  * or another version of the toolbox is already installed. The new
    installation is about another concurrent version. Then the new
    installation could end with a warning message telling that it is not
    loaded because of the other version.

Another improvement would be to be able to provide a "noautoloading" 
option to atomsInstall().

What's your own feeling and usage about atomsInstall()?

Regards
Samuel

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

From heinznabielek at me.com  Sat Apr 10 23:58:16 2021
From: heinznabielek at me.com (Heinz Nabielek)
Date: Sat, 10 Apr 2021 23:58:16 +0200
Subject: [Scilab-users] xfpoly: would wish that the filling colour could
 be made transparent.
In-Reply-To: <75595f62-031a-d0a6-a82c-35899509ad31@laas.fr>
References: <1615412419386-0.post@n3.nabble.com>
 <2d9f5948-6e74-0544-4d54-dcd52caf6e5e@free.fr>
 <921C1491-5590-4FC5-977E-4224506196A1@me.com>
 <75595f62-031a-d0a6-a82c-35899509ad31@laas.fr>
Message-ID: <AEB11672-0B9D-45D3-9109-38EF91F92581@me.com>

On 10.04.2021, at 08:10, Antoine Monmayrant <antoine.monmayrant at laas.fr> wrote:
> 
> 
> On 09/04/2021 23:55, Heinz Nabielek wrote:
>> xfpoly does generally a good job for me, sometimes I would wish that the filling colour could be made transparent.
> This is a much needed improvement of the scilab graphical stack that currently does not provide any transparency.
> I think this is not an easy improvement.
> At the moment, my workaround is to plot everything I need, export as svg and than add the transparency I need in the svg using inkscape or directly editing the svg file with a text editor...
>> Heinz
>> 
>> PS 1: Is there a new version of the 2011 BetweenCurves around?
> Er, no, it was just a dirty hack I needed for my own publications and I think 2011 is the most recent one.
> I can try to see how to improve it if this can improve scilab...




I had initiated by log vs lin plot with 
>> plot2d([0 80],[1 100], style=0,logflag = "nl");

but BetweenCurves starts with its own plot and here I would not know, what to do...
Heinz

BTW, how do the French infection rates look like?

>> 
>> PS 2: Any suggestion to make my clumsy coding more elegent, is highly welcome
>> 
>> PS 2: BTW, since the recent lockdown, infection rates are coming down in Austria.....
>> 
>> 
>> A=[12.628    13.942    17.077    17.054    15.594    14.976    14.796    11.875    13.448    16.504    17.717    19.447    16.099    13.302    13.762    16.032    19.492    22.098    20.425    21.087    20.649    14.268    19.402    22.525    26.862    23.514    27.603    23.851    15.830    21.570    28.682    26.109    29.974    28.727    24.705    21.458    27.087    28.401    33.670    35.119    33.962    28.120    21.301    27.244    37.467    37.715    39.490    37.569    30.480    27.098    38.366    36.951    35.097    43.759    39.299]';
>> d=(1:length(A))';
>> up=10^(d/53);
>> M=[ones(up) up];
>> aa=M\A;
>> B=inv(M'*M);
>> DD=(1:110)';
>> U=10^(DD/53);
>> MM=[ones(U) U];
>> yh = M*aa;     //Fitted values yh to approximate measured y's
>> e=A-yh;     //Errors or residuals
>> SSE=e'*e;     //Sum of squared errors
>> ybar=mean(A); R2=1-SSE/sum((A-ybar)^2);
>> [m n]=size(M);
>> MSE = SSE/(m-n-1);     //Mean square error
>> C=MSE*B  // covariance matrix
>> sig=sqrt(MSE);
>> seb=sqrt(diag(C));
>> [aa seb]
>> [n pp]=size(M);
>> CONF=.95; alpha=1-CONF;
>> ta2 = cdft('T',n-pp,1-alpha/2,alpha/2);     //t-value for alpha/2
>> yhh= MM*aa;
>> p=sig*sqrt(diag(1+MM*B*MM'));
>> N=[yhh+ta2*p  yhh-ta2*p];
>> polyX = [DD;flipdim(DD,1)];
>> polyY = [N(:,1);flipdim(N(:,2),1)];
>> plot2d([0 80],[1 100], style=0,logflag = "nl");
>> xgrid;
>> xfpoly(polyX, polyY,6);
>> plot(DD,MM*aa,'g.-');
>> plot(d,A,'b.') ;
>> title('AUSTRIA daily infection rates per 100,000','fontsize',5);
>> xlabel('days since 1 Feb 2021','fontsize',3);
>> ylabel('number of infections per day per 100,000','fontsize',3);
>> legend('data from Johns Hopkins GitHub','95% confidence range','model prediction','AUSTRIA recorded',4);
>> 
>> 
>> 
> _______________________________________________
> users mailing list
> users at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users



From fmiyara at fceia.unr.edu.ar  Sun Apr 11 02:07:49 2021
From: fmiyara at fceia.unr.edu.ar (Federico Miyara)
Date: Sat, 10 Apr 2021 21:07:49 -0300
Subject: [Scilab-users] Why window() provides only symmetric weighting?
In-Reply-To: <bcc908b0-947c-ca22-5a70-ed2fa95cb75e@free.fr>
References: <c79312b9-0333-cc0e-f7ec-e6cbe0bcf844@fceia.unr.edu.ar>
 <bcc908b0-947c-ca22-5a70-ed2fa95cb75e@free.fr>
Message-ID: <d6725c96-fa29-1018-cac0-d22ec1b37bd4@fceia.unr.edu.ar>


Samuel,

Like it or not, I guess these keywords come from Matlab, and as Matlab 
still seems to dominate the market, many people, including those willing 
to quit Matlab (as I did several years ago), are quite used to those 
keywords. Other software such as Octave and scipy.signal (Python) adhere 
to this style, so it is already sort of a standard. "Open" and "closed" 
might have been an option when there was still no name for the concept, 
but now it doesn't seem advisable.

That some name be intuitive or not may depend on the circumstances one 
was exposed to that name. I myself find it intuitive enough, or at least 
not counterintuitive.

I'm not sure whether it is correct to say that the generated window is 
both symmetric and periodic. Probably it is either symmetric or 
asymmetric, but never periodic per se, since it doesn't repeat itself. 
It tacitly becomes periodic when used along with an FFT, but just 
because the FFT assumes a periodic model of the signal, so what 
"periodic" means is just that its "natural" period is equal to its 
length. But even this can be challenged: What is the "natural" period of 
a function? I guess this makes sense mainly in the case of windows that 
are derived from cosines, such as many of the most successful windows 
(e.g. Hann, Blackman, Blackman-Harris and several flat-tops)

Regards,

Federico



On 09/04/2021 15:29, Samuel Gougeon wrote:
> Dear Federico,
>
> Thank you for the proposal.
> I am afraid that the "symmetric" and "periodic" flag names are not 
> intuitive to me.
> Indeed, the generated window is /always/ both periodic and symmetric. 
> It is anyway "algorithmically seen" as periodic (from a spectral point 
> of view), since it is regularly sampled, while regular-sampling and 
> periodicity are FT-dual.
>
> The point is that it is either *open*, or *closed* (what is rather 
> expected, for a window. Sorry for the (serious) joke :-), with a 
> closing point at the same level as the opening one.
>
> I know from where these "symmetric" and "periodic" keyworks come from.
> But, sorry, i can't resolve myself blindly copy others without 
> discussion. Badly naming things usually become counterproductive, 
> noticeably when teaching (here signal processing).
>
> For contribution,
>
> Best regards
> Samuel
>
>
> Le 11/02/2021 ? 08:12, Federico Miyara a ?crit?:
>>
>> Dear All,
>>
>> I wonder why windowing functions such as Hann, Hamming, etc., 
>> provided by window(), are only symmetric.
>>
>> When used for spectral analysis by subsequent use of fft(), the 
>> periodic weighting is better than the symmetric one. The symmetric 
>> window is mainly used in the design of FIR filters, which I guess is 
>> a less frequent application than spectral analysis.
>>
>> While it is true that an easy workaround to get a periodic window of 
>> length n is, for instance
>>
>> w = window("hn", n+1)(1:$-1);
>>
>> a syntax such as this
>>
>> w = window("hn", n, "per");
>>
>> would be easier.Setting "sym" as the default option, no backward 
>> compatibility issues would possibly arise.
>>
>> Regards,
>>
>> Federico Miyara
>>
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 
>> 	Libre de virus. www.avast.com 
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 
>>
>>
>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>
>> _______________________________________________
>> users mailing list
>> users at lists.scilab.org
>> http://lists.scilab.org/mailman/listinfo/users
>
>
>
> _______________________________________________
> users mailing list
> users at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users



-- 
El software de antivirus Avast ha analizado este correo electr?nico en busca de virus.
https://www.avast.com/antivirus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20210410/84947ee2/attachment.htm>

From heinznabielek at me.com  Sun Apr 11 17:34:40 2021
From: heinznabielek at me.com (Heinz Nabielek)
Date: Sun, 11 Apr 2021 17:34:40 +0200
Subject: [Scilab-users] xfpoly: would wish that the filling colour could
 be made transparent.
In-Reply-To: <75595f62-031a-d0a6-a82c-35899509ad31@laas.fr>
References: <1615412419386-0.post@n3.nabble.com>
 <2d9f5948-6e74-0544-4d54-dcd52caf6e5e@free.fr>
 <921C1491-5590-4FC5-977E-4224506196A1@me.com>
 <75595f62-031a-d0a6-a82c-35899509ad31@laas.fr>
Message-ID: <BC93466B-0816-4D0F-B485-E21143631CBA@me.com>

On 10.04.2021, at 08:10, Antoine Monmayrant <antoine.monmayrant at laas.fr <mailto:antoine.monmayrant at laas.fr>> wrote:
> 
> 
> On 09/04/2021 23:55, Heinz Nabielek wrote:
>> xfpoly does generally a good job for me, sometimes I would wish that the filling colour could be made transparent.
> This is a much needed improvement of the scilab graphical stack that currently does not provide any transparency.
> I think this is not an easy improvement.
> At the moment, my workaround is to plot everything I need, export as svg and than add the transparency I need in the svg using inkscape or directly editing the svg file with a text editor...
>> Heinz
>> 
>> PS 1: Is there a new version of the 2011 BetweenCurves around?
> Er, no, it was just a dirty hack I needed for my own publications and I think 2011 is the most recent one.
> I can try to see how to improve it if this can improve scilab...




I had initiated by log vs lin plot with 
>> plot2d([0 80],[1 100], style=0,logflag = "nl");

but BetweenCurves starts with its own plot and here I would not know, what to do...
Heinz

BTW, how do the French infection rates look like?

>> 
>> PS 2: Any suggestion to make my clumsy coding more elegent, is highly welcome
>> 
>> PS 2: BTW, since the recent lockdown, infection rates are coming down in Austria.....
>> 
>> 
>> A=[12.628    13.942    17.077    17.054    15.594    14.976    14.796    11.875    13.448    16.504    17.717    19.447    16.099    13.302    13.762    16.032    19.492    22.098    20.425    21.087    20.649    14.268    19.402    22.525    26.862    23.514    27.603    23.851    15.830    21.570    28.682    26.109    29.974    28.727    24.705    21.458    27.087    28.401    33.670    35.119    33.962    28.120    21.301    27.244    37.467    37.715    39.490    37.569    30.480    27.098    38.366    36.951    35.097    43.759    39.299]';
>> d=(1:length(A))';
>> up=10^(d/53);
>> M=[ones(up) up];
>> aa=M\A;
>> B=inv(M'*M);
>> DD=(1:110)';
>> U=10^(DD/53);
>> MM=[ones(U) U];
>> yh = M*aa;     //Fitted values yh to approximate measured y's
>> e=A-yh;     //Errors or residuals
>> SSE=e'*e;     //Sum of squared errors
>> ybar=mean(A); R2=1-SSE/sum((A-ybar)^2);
>> [m n]=size(M);
>> MSE = SSE/(m-n-1);     //Mean square error
>> C=MSE*B  // covariance matrix
>> sig=sqrt(MSE);
>> seb=sqrt(diag(C));
>> [aa seb]
>> [n pp]=size(M);
>> CONF=.95; alpha=1-CONF;
>> ta2 = cdft('T',n-pp,1-alpha/2,alpha/2);     //t-value for alpha/2
>> yhh= MM*aa;
>> p=sig*sqrt(diag(1+MM*B*MM'));
>> N=[yhh+ta2*p  yhh-ta2*p];
>> polyX = [DD;flipdim(DD,1)];
>> polyY = [N(:,1);flipdim(N(:,2),1)];
>> plot2d([0 80],[1 100], style=0,logflag = "nl");
>> xgrid;
>> xfpoly(polyX, polyY,6);
>> plot(DD,MM*aa,'g.-');
>> plot(d,A,'b.') ;
>> title('AUSTRIA daily infection rates per 100,000','fontsize',5);
>> xlabel('days since 1 Feb 2021','fontsize',3);
>> ylabel('number of infections per day per 100,000','fontsize',3);
>> legend('data from Johns Hopkins GitHub','95% confidence range','model prediction','AUSTRIA recorded',4);
>> 
>> 
>> 
> _______________________________________________
> users mailing list
> users at lists.scilab.org <mailto:users at lists.scilab.org>
> http://lists.scilab.org/mailman/listinfo/users <http://lists.scilab.org/mailman/listinfo/users>

_______________________________________________
users mailing list
users at lists.scilab.org <mailto:users at lists.scilab.org>
http://lists.scilab.org/mailman/listinfo/users <http://lists.scilab.org/mailman/listinfo/users>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20210411/2d44d403/attachment.htm>

From fmiyara at fceia.unr.edu.ar  Mon Apr 12 07:39:44 2021
From: fmiyara at fceia.unr.edu.ar (Federico Miyara)
Date: Mon, 12 Apr 2021 02:39:44 -0300
Subject: [Scilab-users] plot2d3()
Message-ID: <4975d334-413e-517b-9e3f-35e66033e143@fceia.unr.edu.ar>


Dear All,

I'm trying to get a plot like this:

where I intend to get a line plot where the lines come from the bottom 
of the plot instead of coming from 0 as is the normal way using plot2d3().

To get this with plot2d3() I had to plot the y axis data + 50 in order 
to make the botom of the plot coincident with 0, and then fake the 
labels using


gca()..y_ticks.labels = 
["-50","-45","-40","-35","-30","-25","-20","-15","-10","-5","0","5","10"]';


To get the circles I had to use plot() with "o" as third argument since 
plot2d3() doesn't accept it.

Is there a more direct way to get such result

Is a there some way of achieving this in a more tative way?

Thanks!

Regards,

Federico Miyara



-- 
El software de antivirus Avast ha analizado este correo electr?nico en busca de virus.
https://www.avast.com/antivirus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20210412/f962abd9/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bjohlbeipdpbnclh.png
Type: image/png
Size: 10483 bytes
Desc: not available
URL: <https://lists.scilab.org/pipermail/users/attachments/20210412/f962abd9/attachment.png>

From denis.crete at thalesgroup.com  Mon Apr 12 08:39:18 2021
From: denis.crete at thalesgroup.com (CRETE Denis)
Date: Mon, 12 Apr 2021 06:39:18 +0000
Subject: [Scilab-users] plot2d3()
In-Reply-To: <4975d334-413e-517b-9e3f-35e66033e143@fceia.unr.edu.ar>
References: <4975d334-413e-517b-9e3f-35e66033e143@fceia.unr.edu.ar>
Message-ID: <aedf1b2c00554e1bbc13e0b615efb44b@thalesgroup.com>

Hello ,
What about using ? errbar ? function, something like errbar(x,y 50+y, 0) ?
HTH
Denis

De : users <users-bounces at lists.scilab.org> De la part de Federico Miyara
Envoy? : lundi 12 avril 2021 07:40
? : Users mailing list for Scilab <users at lists.scilab.org>
Objet : [Scilab-users] plot2d3()


Dear All,

I'm trying to get a plot like this:
[cid:image001.jpg at 01D72F77.52FA2D60]
where I intend to get a line plot where the lines come from the bottom of the plot instead of coming from 0 as is the normal way using plot2d3().

To get this with plot2d3() I had to plot the y axis data + 50 in order to make the botom of the plot coincident with 0, and then fake the labels using


gca()..y_ticks.labels = ["-50","-45","-40","-35","-30","-25","-20","-15","-10","-5","0","5","10"]';


To get the circles I had to use plot() with "o" as third argument since plot2d3() doesn't accept it.

Is there a more direct way to get such result

Is a there some way of achieving this in a more tative way?

Thanks!

Regards,

Federico Miyara

[https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif]<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>

Libre de virus. www.avast.com<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20210412/7bff9954/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 29595 bytes
Desc: image001.jpg
URL: <https://lists.scilab.org/pipermail/users/attachments/20210412/7bff9954/attachment.jpg>

From Clement.David at esi-group.com  Mon Apr 12 09:04:03 2021
From: Clement.David at esi-group.com (=?utf-8?B?Q2zDqW1lbnQgRGF2aWQ=?=)
Date: Mon, 12 Apr 2021 07:04:03 +0000
Subject: [Scilab-users] Precedence rules for concurrent native and
 external builtin homonymous functions?
In-Reply-To: <bf7ef8aa-044d-3240-39e0-c2c2cf38d35d@utc.fr>
References: <f411d60c-4799-1c5f-37ca-8945111803af@free.fr>
 <bf7ef8aa-044d-3240-39e0-c2c2cf38d35d@utc.fr>
Message-ID: <PR2PR09MB356222D8675F20E784E439D3B0709@PR2PR09MB3562.eurprd09.prod.outlook.com>

Hi all,

From my usage, the precedence rule is simple and act similarly as function re-definition: the last function wins. In practice it depends on the loading order, custom code execution order and so on.

Regards,

Cl?ment

From: users <users-bounces at lists.scilab.org> On Behalf Of St?phane Mottelet
Sent: Friday, April 9, 2021 6:16 PM
To: users at lists.scilab.org
Subject: Re: [Scilab-users] Precedence rules for concurrent native and external builtin homonymous functions?


Samuel, I think the problem is about gateways not user macros right ?

What I experienced is that the new gateways have precedence over the previously linked gateways with the same name.

Hence, there is no conflict is the API is respected...

S.
Le 09/04/2021 ? 17:57, Samuel Gougeon a ?crit :

Dear all,

I am wondering about precedence rules when a user's defined builtin (possibly from an ATOMS external module) has the same name than a native Scilab builtin function.
The case appeared (and maybe still) when using the scicv external module, that redefined a write() function that already exists in Scilab.

Does anyone know how such conflicts are managed by Scilab?
Thanks

Samuel



_______________________________________________

users mailing list

users at lists.scilab.org<mailto:users at lists.scilab.org>

https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users

--

St?phane Mottelet

Ing?nieur de recherche

EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable

D?partement G?nie des Proc?d?s Industriels

Sorbonne Universit?s - Universit? de Technologie de Compi?gne

CS 60319, 60203 Compi?gne cedex

Tel : +33(0)344234688

http://www.utc.fr/~mottelet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20210412/1a80ce4c/attachment.htm>

From Christophe.Dang at sidel.com  Mon Apr 12 09:22:40 2021
From: Christophe.Dang at sidel.com (Dang Ngoc Chan, Christophe)
Date: Mon, 12 Apr 2021 07:22:40 +0000
Subject: [Scilab-users] Why window() provides only symmetric weighting?
In-Reply-To: <d6725c96-fa29-1018-cac0-d22ec1b37bd4@fceia.unr.edu.ar>
References: <c79312b9-0333-cc0e-f7ec-e6cbe0bcf844@fceia.unr.edu.ar>
 <bcc908b0-947c-ca22-5a70-ed2fa95cb75e@free.fr>
 <d6725c96-fa29-1018-cac0-d22ec1b37bd4@fceia.unr.edu.ar>
Message-ID: <DB8PR07MB63155030B1368401B3C96947E5709@DB8PR07MB6315.eurprd07.prod.outlook.com>

Hello,

> De : Federico Miyara
> Envoy? : dimanche 11 avril 2021 02:08
>
> Like it or not, I guess these keywords come from Matlab, and as Matlab
> still seems to dominate the market, many people, including those
> willing to quit Matlab (as I did several years ago), are quite used to
> those keywords

I don't agree with this argument.
If a way of doing is wrong, then just keep on going because "everybody does so" is just an argumentum ad populum

https://en.wikipedia.org/wiki/Argumentum_ad_populum

which is a fallacious argument.

Regards.


--
Christophe Dang Ngoc Chan
Mechanical calculation engineer


General
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error), please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

From Christophe.Dang at sidel.com  Mon Apr 12 09:28:40 2021
From: Christophe.Dang at sidel.com (Dang Ngoc Chan, Christophe)
Date: Mon, 12 Apr 2021 07:28:40 +0000
Subject: [Scilab-users] xfpoly: would wish that the filling colour could
 be made transparent.
In-Reply-To: <AEB11672-0B9D-45D3-9109-38EF91F92581@me.com>
References: <1615412419386-0.post@n3.nabble.com>
 <2d9f5948-6e74-0544-4d54-dcd52caf6e5e@free.fr>
 <921C1491-5590-4FC5-977E-4224506196A1@me.com>
 <75595f62-031a-d0a6-a82c-35899509ad31@laas.fr>
 <AEB11672-0B9D-45D3-9109-38EF91F92581@me.com>
Message-ID: <DB8PR07MB6315AA0F8E811991BE7325A4E5709@DB8PR07MB6315.eurprd07.prod.outlook.com>

Hello Heinz,

> De : Heinz Nabielek
> Envoy? : samedi 10 avril 2021 23:58
>
> BTW, how do the French infection rates look like?

Thanks for caring (-:

You'll probanbly find the answer here:

https://www.gouvernement.fr/info-coronavirus/carte-et-donnees

the second curve on the left is the incidence rate which is probably close to what you call infection rate.

Best regards

--
Christophe Dang Ngoc Chan
Mechanical calculation engineer



General
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error), please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.


From antoine.monmayrant at laas.fr  Mon Apr 12 15:25:12 2021
From: antoine.monmayrant at laas.fr (Antoine Monmayrant)
Date: Mon, 12 Apr 2021 15:25:12 +0200
Subject: [Scilab-users] xfpoly: would wish that the filling colour could
 be made transparent.
In-Reply-To: <AEB11672-0B9D-45D3-9109-38EF91F92581@me.com>
References: <1615412419386-0.post@n3.nabble.com>
 <2d9f5948-6e74-0544-4d54-dcd52caf6e5e@free.fr>
 <921C1491-5590-4FC5-977E-4224506196A1@me.com>
 <75595f62-031a-d0a6-a82c-35899509ad31@laas.fr>
 <AEB11672-0B9D-45D3-9109-38EF91F92581@me.com>
Message-ID: <55852205-cb4c-efb6-ef22-94fa84755ebb@laas.fr>


On 10/04/2021 23:58, Heinz Nabielek wrote:
> On 10.04.2021, at 08:10, Antoine Monmayrant <antoine.monmayrant at laas.fr> wrote:
>>
>> On 09/04/2021 23:55, Heinz Nabielek wrote:
>>> xfpoly does generally a good job for me, sometimes I would wish that the filling colour could be made transparent.
>> This is a much needed improvement of the scilab graphical stack that currently does not provide any transparency.
>> I think this is not an easy improvement.
>> At the moment, my workaround is to plot everything I need, export as svg and than add the transparency I need in the svg using inkscape or directly editing the svg file with a text editor...
>>> Heinz
>>>
>>> PS 1: Is there a new version of the 2011 BetweenCurves around?
>> Er, no, it was just a dirty hack I needed for my own publications and I think 2011 is the most recent one.
>> I can try to see how to improve it if this can improve scilab...
>
>
>
> I had initiated by log vs lin plot with
>>> plot2d([0 80],[1 100], style=0,logflag = "nl");
> but BetweenCurves starts with its own plot and here I would not know, what to do...

Hello,

There are two options:

(1) If you already have a handle "h0" to a plot and want BetweenCurves 
to use it, you can do:

    [h,epoly,ey1,ey2]=BetweenCurves(x,y1,y2,handle, h0)

(2) you can also do:

    [h,epoly,ey1,ey2]=BetweenCurves(x,y1,y2,handle, h0)

 ?and then use

    h.children(1).log_flags='nln'

to change from linear to log y axis.

Is this what you have in mind?

Antoine

> Heinz
>
> BTW, how do the French infection rates look like?
I must admit it is not a metric I track.
For the trend in France I go here 
https://coronavirus.politologue.com/coronavirus-france.FR and for a more 
global view there: https://coronavirus.politologue.com/100k-habitants/
>
>>> PS 2: Any suggestion to make my clumsy coding more elegent, is highly welcome
>>>
>>> PS 2: BTW, since the recent lockdown, infection rates are coming down in Austria.....
>>>
>>>
>>> A=[12.628    13.942    17.077    17.054    15.594    14.976    14.796    11.875    13.448    16.504    17.717    19.447    16.099    13.302    13.762    16.032    19.492    22.098    20.425    21.087    20.649    14.268    19.402    22.525    26.862    23.514    27.603    23.851    15.830    21.570    28.682    26.109    29.974    28.727    24.705    21.458    27.087    28.401    33.670    35.119    33.962    28.120    21.301    27.244    37.467    37.715    39.490    37.569    30.480    27.098    38.366    36.951    35.097    43.759    39.299]';
>>> d=(1:length(A))';
>>> up=10^(d/53);
>>> M=[ones(up) up];
>>> aa=M\A;
>>> B=inv(M'*M);
>>> DD=(1:110)';
>>> U=10^(DD/53);
>>> MM=[ones(U) U];
>>> yh = M*aa;     //Fitted values yh to approximate measured y's
>>> e=A-yh;     //Errors or residuals
>>> SSE=e'*e;     //Sum of squared errors
>>> ybar=mean(A); R2=1-SSE/sum((A-ybar)^2);
>>> [m n]=size(M);
>>> MSE = SSE/(m-n-1);     //Mean square error
>>> C=MSE*B  // covariance matrix
>>> sig=sqrt(MSE);
>>> seb=sqrt(diag(C));
>>> [aa seb]
>>> [n pp]=size(M);
>>> CONF=.95; alpha=1-CONF;
>>> ta2 = cdft('T',n-pp,1-alpha/2,alpha/2);     //t-value for alpha/2
>>> yhh= MM*aa;
>>> p=sig*sqrt(diag(1+MM*B*MM'));
>>> N=[yhh+ta2*p  yhh-ta2*p];
>>> polyX = [DD;flipdim(DD,1)];
>>> polyY = [N(:,1);flipdim(N(:,2),1)];
>>> plot2d([0 80],[1 100], style=0,logflag = "nl");
>>> xgrid;
>>> xfpoly(polyX, polyY,6);
>>> plot(DD,MM*aa,'g.-');
>>> plot(d,A,'b.') ;
>>> title('AUSTRIA daily infection rates per 100,000','fontsize',5);
>>> xlabel('days since 1 Feb 2021','fontsize',3);
>>> ylabel('number of infections per day per 100,000','fontsize',3);
>>> legend('data from Johns Hopkins GitHub','95% confidence range','model prediction','AUSTRIA recorded',4);
>>>
>>>
>>>
>> _______________________________________________
>> 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/20210412/b35f30f4/attachment.htm>

From antoine.monmayrant at laas.fr  Mon Apr 12 15:33:52 2021
From: antoine.monmayrant at laas.fr (Antoine Monmayrant)
Date: Mon, 12 Apr 2021 15:33:52 +0200
Subject: [Scilab-users] =?utf-8?q?Pr=C3=A9cision_DRE?=
Message-ID: <866f2647-8506-c61a-13de-5c2fbf534509@laas.fr>

Hello Nicolas,

J'ai une un retour en direct de la troposph?re du CNRS:

- Oui, il y a la volont? d'ouverture ? des postes DR ext?rieurs.
- Il faut candidater dans une section, typiquement une section qui 
correspond bien au labo que tu vises.
- Si tu es class? sur la liste principale lors du jury d'admissibilit?, 
ta candidature passeras devant le jury d'admission DR, qui est commun ? 
tous les institutes (ie toutes les sections)
- Il est d'usage d'informer en avance de phase le DAS de l'institut de 
rattachement du labo que tu vises, en envoyant un mail+CV.

Voil? pour les informations que j'ai pu glaner.

Allez, je retourne ? la non pr?paration de mon concours DR que je 
pr?vois de bien foirer la semaine prochaine! :-)

Antoine



From cfuttrup at gmail.com  Mon Apr 12 16:23:34 2021
From: cfuttrup at gmail.com (Claus Futtrup)
Date: Mon, 12 Apr 2021 16:23:34 +0200
Subject: [Scilab-users] Why window() provides only symmetric weighting?
In-Reply-To: <DB8PR07MB63155030B1368401B3C96947E5709@DB8PR07MB6315.eurprd07.prod.outlook.com>
References: <c79312b9-0333-cc0e-f7ec-e6cbe0bcf844@fceia.unr.edu.ar>
 <bcc908b0-947c-ca22-5a70-ed2fa95cb75e@free.fr>
 <d6725c96-fa29-1018-cac0-d22ec1b37bd4@fceia.unr.edu.ar>
 <DB8PR07MB63155030B1368401B3C96947E5709@DB8PR07MB6315.eurprd07.prod.outlook.com>
Message-ID: <2e537c07-c828-d936-7b3e-91a3035a8ecf@gmail.com>

Dear friends

I believe the initial question is related to giving more options to the 
window functions, such that it can continue how it is today (aka 
'symmetric') but also offer alternatives. If these additional options 
makes sense, and can default such that they are not required (existing 
code continues to work unaffected), and the additional options are 
useful and meaningful in a mathematical sense, then I'm all for adding 
these options.

When it comes to naming schemes, then Scilab is not required to strictly 
follow the Matlab regime. We can choose what we find most correct and 
concise. In some cases Scilab is 'better' than our competition, which is 
a pleasure. It is true that some users come from Matlab and sometimes we 
read Matlab code to convert its functionality into Scilab - in these 
cases it works perfectly good for me to make a Matlab-to-Scilab 
translation somewhere in the documentation.

Therefore, I hope we can have a good discussion about which name is the 
most meaningful.

With kind regards,
Claus

On 12-04-2021 09:22, Dang Ngoc Chan, Christophe wrote:
> Hello,
>
>> De : Federico Miyara
>> Envoy? : dimanche 11 avril 2021 02:08
>>
>> Like it or not, I guess these keywords come from Matlab, and as Matlab
>> still seems to dominate the market, many people, including those
>> willing to quit Matlab (as I did several years ago), are quite used to
>> those keywords
> I don't agree with this argument.
> If a way of doing is wrong, then just keep on going because "everybody does so" is just an argumentum ad populum
>
> https://en.wikipedia.org/wiki/Argumentum_ad_populum
>
> which is a fallacious argument.
>
> Regards.
>
>
> --
> Christophe Dang Ngoc Chan
> Mechanical calculation engineer
>
>
> General
> This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error), please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
> _______________________________________________
> users mailing list
> users at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users




From fmiyara at fceia.unr.edu.ar  Mon Apr 12 17:19:08 2021
From: fmiyara at fceia.unr.edu.ar (Federico Miyara)
Date: Mon, 12 Apr 2021 12:19:08 -0300
Subject: [Scilab-users] Why window() provides only symmetric weighting?
In-Reply-To: <DB8PR07MB63155030B1368401B3C96947E5709@DB8PR07MB6315.eurprd07.prod.outlook.com>
References: <c79312b9-0333-cc0e-f7ec-e6cbe0bcf844@fceia.unr.edu.ar>
 <bcc908b0-947c-ca22-5a70-ed2fa95cb75e@free.fr>
 <d6725c96-fa29-1018-cac0-d22ec1b37bd4@fceia.unr.edu.ar>
 <DB8PR07MB63155030B1368401B3C96947E5709@DB8PR07MB6315.eurprd07.prod.outlook.com>
Message-ID: <f797e2c6-c662-fe44-65d8-babf22097f30@fceia.unr.edu.ar>


Samuel:

As a general concept, you are right ... but with nuances. The problem is 
deciding when something is really wrong and when it is just a question 
of opinion or personal preference. It is wrong to say the Earth is flat, 
no matter how many people say it. But is it right or wrong to call 
something just a conventional name?

For instance: Is it right to call the derivative of a function 
"derivative"? Probably not, because "derivative" is a general concept 
which seems to have no relationship with its meaning in math. Probably 
in its origins it was more related to grammar than to math. But once 
established for centuries, it wouldn't be convenient to change it on the 
basis that it is "wrong".

By the same token, calling "periodic" a window function obtained from 
periodic functions (cosines) whose period is equal to its length doesn't 
seem intrinsically wrong to me. Calling it "closed" would be worse since 
one immediately thinks either of a closed set, which is not, or a closed 
curve, which isn't either.

But even if we found a better word, changing it would very likely create 
an unnecessary cognitive dissonance to thousands or millions of 
practitioners.

Anyway, if a much better and cristal-clear word (i.e., whose meaning 
would be immediately obvious in its context) were found and gained 
consensus, no problem to use it instead of "periodic". The important 
thing in my proposal was to include in the window() function the 
feature, not how we call it.

Regards,

Federico Miyara



On 12/04/2021 04:22, Dang Ngoc Chan, Christophe wrote:
> Hello,
>
>> De : Federico Miyara
>> Envoy? : dimanche 11 avril 2021 02:08
>>
>> Like it or not, I guess these keywords come from Matlab, and as Matlab
>> still seems to dominate the market, many people, including those
>> willing to quit Matlab (as I did several years ago), are quite used to
>> those keywords
> I don't agree with this argument.
> If a way of doing is wrong, then just keep on going because "everybody does so" is just an argumentum ad populum
>
> https://en.wikipedia.org/wiki/Argumentum_ad_populum
>
> which is a fallacious argument.
>
> Regards.
>
>
> --
> Christophe Dang Ngoc Chan
> Mechanical calculation engineer
>
>
> General
> This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error), please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
> _______________________________________________
> users mailing list
> users at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users
>
>



-- 
El software de antivirus Avast ha analizado este correo electr?nico en busca de virus.
https://www.avast.com/antivirus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20210412/126bf2fa/attachment.htm>

From fmiyara at fceia.unr.edu.ar  Mon Apr 12 18:37:08 2021
From: fmiyara at fceia.unr.edu.ar (Federico Miyara)
Date: Mon, 12 Apr 2021 13:37:08 -0300
Subject: [Scilab-users] Fwd: Re: Why window() provides only symmetric
 weighting?
In-Reply-To: <f797e2c6-c662-fe44-65d8-babf22097f30@fceia.unr.edu.ar>
References: <f797e2c6-c662-fe44-65d8-babf22097f30@fceia.unr.edu.ar>
Message-ID: <47a3a9a2-6f13-9d68-4a90-ad1dee977276@fceia.unr.edu.ar>


Samuel (and Christophe),

I apologize for mixing up your names. My reply was intended for 
Christophe, not Samuel.

Regards,

Federico Miyara


-------- Forwarded Message --------
Subject: 	Re: [Scilab-users] Why window() provides only symmetric 
weighting?
Date: 	Mon, 12 Apr 2021 12:19:08 -0300
From: 	Federico Miyara <fmiyara at fceia.unr.edu.ar>
Reply-To: 	Users mailing list for Scilab <users at lists.scilab.org>
To: 	users at lists.scilab.org




Samuel:

As a general concept, you are right ... but with nuances. The problem is 
deciding when something is really wrong and when it is just a question 
of opinion or personal preference. It is wrong to say the Earth is flat, 
no matter how many people say it. But is it right or wrong to call 
something just a conventional name?

For instance: Is it right to call the derivative of a function 
"derivative"? Probably not, because "derivative" is a general concept 
which seems to have no relationship with its meaning in math. Probably 
in its origins it was more related to grammar than to math. But once 
established for centuries, it wouldn't be convenient to change it on the 
basis that it is "wrong".

By the same token, calling "periodic" a window function obtained from 
periodic functions (cosines) whose period is equal to its length doesn't 
seem intrinsically wrong to me. Calling it "closed" would be worse since 
one immediately thinks either of a closed set, which is not, or a closed 
curve, which isn't either.

But even if we found a better word, changing it would very likely create 
an unnecessary cognitive dissonance to thousands or millions of 
practitioners.

Anyway, if a much better and cristal-clear word (i.e., whose meaning 
would be immediately obvious in its context) were found and gained 
consensus, no problem to use it instead of "periodic". The important 
thing in my proposal was to include in the window() function the 
feature, not how we call it.

Regards,

Federico Miyara



On 12/04/2021 04:22, Dang Ngoc Chan, Christophe wrote:
> Hello,
>
>> De : Federico Miyara
>> Envoy? : dimanche 11 avril 2021 02:08
>>
>> Like it or not, I guess these keywords come from Matlab, and as Matlab
>> still seems to dominate the market, many people, including those
>> willing to quit Matlab (as I did several years ago), are quite used to
>> those keywords
> I don't agree with this argument.
> If a way of doing is wrong, then just keep on going because "everybody does so" is just an argumentum ad populum
>
> https://en.wikipedia.org/wiki/Argumentum_ad_populum
>
> which is a fallacious argument.
>
> Regards.
>
>
> --
> Christophe Dang Ngoc Chan
> Mechanical calculation engineer
>
>
> General
> This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error), please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
> _______________________________________________
> users mailing list
> users at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users
>
>


<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 
	Libre de virus. www.avast.com 
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 


<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>


-- 
El software de antivirus Avast ha analizado este correo electr?nico en busca de virus.
https://www.avast.com/antivirus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20210412/2648ef90/attachment.htm>

From cfuttrup at gmail.com  Mon Apr 12 18:37:28 2021
From: cfuttrup at gmail.com (Claus Futtrup)
Date: Mon, 12 Apr 2021 18:37:28 +0200
Subject: [Scilab-users] Why window() provides only symmetric weighting?
In-Reply-To: <f797e2c6-c662-fe44-65d8-babf22097f30@fceia.unr.edu.ar>
References: <c79312b9-0333-cc0e-f7ec-e6cbe0bcf844@fceia.unr.edu.ar>
 <bcc908b0-947c-ca22-5a70-ed2fa95cb75e@free.fr>
 <d6725c96-fa29-1018-cac0-d22ec1b37bd4@fceia.unr.edu.ar>
 <DB8PR07MB63155030B1368401B3C96947E5709@DB8PR07MB6315.eurprd07.prod.outlook.com>
 <f797e2c6-c662-fe44-65d8-babf22097f30@fceia.unr.edu.ar>
Message-ID: <03232727-dcad-2adf-61ae-baf93423699c@gmail.com>

Hi Federico

Thank you for being open to finding the right word.
I think other members of our small group should also be open.

For me the plurality is not so important - but let's say it's the 
wording used in all our educational books (in English) ... just dig into 
any Signal Analysis book, etc., and what we're trying to name here is 
exactly that, then it would be bad for Scilab to give it a different 
name. Renaming something that is universally defined otherwise is an 
uphill battle we cannot win.

Asymmetric window functions is new to me.I googled about window 
functions and found (stumbled upon):
https://journals.sagepub.com/doi/pdf/10.1260/1748-3018.9.4.389
Conclusion: Asymmetric window functions have a purpose. When there's 
asymmetric windows, then there must also be symmetric windows.
Here's a short list of symmetric window functions: 
https://mathworld.wolfram.com/ApodizationFunction.html

Best regards,
Claus

On 12-04-2021 17:19, Federico Miyara wrote:
>
> Samuel:
>
> As a general concept, you are right ... but with nuances. The problem 
> is deciding when something is really wrong and when it is just a 
> question of opinion or personal preference. It is wrong to say the 
> Earth is flat, no matter how many people say it. But is it right or 
> wrong to call something just a conventional name?
>
> For instance: Is it right to call the derivative of a function 
> "derivative"? Probably not, because "derivative" is a general concept 
> which seems to have no relationship with its meaning in math. Probably 
> in its origins it was more related to grammar than to math. But once 
> established for centuries, it wouldn't be convenient to change it on 
> the basis that it is "wrong".
>
> By the same token, calling "periodic" a window function obtained from 
> periodic functions (cosines) whose period is equal to its length 
> doesn't seem intrinsically wrong to me. Calling it "closed" would be 
> worse since one immediately thinks either of a closed set, which is 
> not, or a closed curve, which isn't either.
>
> But even if we found a better word, changing it would very likely 
> create an unnecessary cognitive dissonance to thousands or millions of 
> practitioners.
>
> Anyway, if a much better and cristal-clear word (i.e., whose meaning 
> would be immediately obvious in its context) were found and gained 
> consensus, no problem to use it instead of "periodic". The important 
> thing in my proposal was to include in the window() function the 
> feature, not how we call it.
>
> Regards,
>
> Federico Miyara
>
>
>
> On 12/04/2021 04:22, Dang Ngoc Chan, Christophe wrote:
>> Hello,
>>
>>> De : Federico Miyara
>>> Envoy? : dimanche 11 avril 2021 02:08
>>>
>>> Like it or not, I guess these keywords come from Matlab, and as Matlab
>>> still seems to dominate the market, many people, including those
>>> willing to quit Matlab (as I did several years ago), are quite used to
>>> those keywords
>> I don't agree with this argument.
>> If a way of doing is wrong, then just keep on going because "everybody does so" is just an argumentum ad populum
>>
>> https://en.wikipedia.org/wiki/Argumentum_ad_populum
>>
>> which is a fallacious argument.
>>
>> Regards.
>>
>>
>> --
>> Christophe Dang Ngoc Chan
>> Mechanical calculation engineer
>>
>>
>> General
>> This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error), please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
>> _______________________________________________
>> users mailing list
>> users at lists.scilab.org
>> http://lists.scilab.org/mailman/listinfo/users
>>
>>
>
>
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 
> 	Libre de virus. www.avast.com 
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 
>
>
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> _______________________________________________
> 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/20210412/1095976b/attachment.htm>

From fmiyara at fceia.unr.edu.ar  Mon Apr 12 23:17:01 2021
From: fmiyara at fceia.unr.edu.ar (Federico Miyara)
Date: Mon, 12 Apr 2021 18:17:01 -0300
Subject: [Scilab-users] Why window() provides only symmetric weighting?
In-Reply-To: <2e537c07-c828-d936-7b3e-91a3035a8ecf@gmail.com>
References: <c79312b9-0333-cc0e-f7ec-e6cbe0bcf844@fceia.unr.edu.ar>
 <bcc908b0-947c-ca22-5a70-ed2fa95cb75e@free.fr>
 <d6725c96-fa29-1018-cac0-d22ec1b37bd4@fceia.unr.edu.ar>
 <DB8PR07MB63155030B1368401B3C96947E5709@DB8PR07MB6315.eurprd07.prod.outlook.com>
 <2e537c07-c828-d936-7b3e-91a3035a8ecf@gmail.com>
Message-ID: <0bc917a4-e940-3bb1-2bcf-27e4ede28e15@fceia.unr.edu.ar>


There are several software packages, not only Matlab, that call this 
concept "periodic", for instance Octave, Scipy (from Python), DADiSP. 
Regarding the last one, I've found an interesting reference:

https://www.dadisp.com/webhelp/mergedProjects/refman2/FncrefFK/FLATTOP.htm

Here, along with a description of the function, it mentions that 
"periodic" can also be called "iso" since there is ISO Standard 18431-1 
dealing with vibrations (Mechanical vibration and shock ? Signal 
processing Part 1: General introduction), which seemingly makes some 
related normative prescriptions. Unfortunately the standard is too 
expensive for me to even attempt to buy it, but perhaps some member of 
this list has university access to these Standards.

I'm pretty sure that the ISO doesn't suggest that the name of this type 
of window is "iso", but I'm in doubt whether they call it "periodic" or 
they just introduce the recommended formula or algorithm.

Anyway, "iso" would be even more obscure than "periodic", if only 
because there are literally thousands of ISO standards and most users 
probably don't even suspect there is one covering this.

Regards,

Federico Miyara


On 12/04/2021 11:23, Claus Futtrup wrote:
> Dear friends
>
> I believe the initial question is related to giving more options to 
> the window functions, such that it can continue how it is today (aka 
> 'symmetric') but also offer alternatives. If these additional options 
> makes sense, and can default such that they are not required (existing 
> code continues to work unaffected), and the additional options are 
> useful and meaningful in a mathematical sense, then I'm all for adding 
> these options.
>
> When it comes to naming schemes, then Scilab is not required to 
> strictly follow the Matlab regime. We can choose what we find most 
> correct and concise. In some cases Scilab is 'better' than our 
> competition, which is a pleasure. It is true that some users come from 
> Matlab and sometimes we read Matlab code to convert its functionality 
> into Scilab - in these cases it works perfectly good for me to make a 
> Matlab-to-Scilab translation somewhere in the documentation.
>
> Therefore, I hope we can have a good discussion about which name is 
> the most meaningful.
>
> With kind regards,
> Claus
>
> On 12-04-2021 09:22, Dang Ngoc Chan, Christophe wrote:
>> Hello,
>>
>>> De : Federico Miyara
>>> Envoy? : dimanche 11 avril 2021 02:08
>>>
>>> Like it or not, I guess these keywords come from Matlab, and as Matlab
>>> still seems to dominate the market, many people, including those
>>> willing to quit Matlab (as I did several years ago), are quite used to
>>> those keywords
>> I don't agree with this argument.
>> If a way of doing is wrong, then just keep on going because 
>> "everybody does so" is just an argumentum ad populum
>>
>> https://en.wikipedia.org/wiki/Argumentum_ad_populum
>>
>> which is a fallacious argument.
>>
>> Regards.
>>
>>
>> -- 
>> Christophe Dang Ngoc Chan
>> Mechanical calculation engineer
>>
>>
>> General
>> This e-mail may contain confidential and/or privileged information. 
>> If you are not the intended recipient (or have received this e-mail 
>> in error), please notify the sender immediately and destroy this 
>> e-mail. Any unauthorized copying, disclosure or distribution of the 
>> material in this e-mail is strictly forbidden.
>> _______________________________________________
>> users mailing list
>> users at lists.scilab.org
>> http://lists.scilab.org/mailman/listinfo/users
>
>
> _______________________________________________
> users mailing list
> users at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users
>
>


-- 
El software de antivirus Avast ha analizado este correo electr?nico en busca de virus.
https://www.avast.com/antivirus



From fmiyara at fceia.unr.edu.ar  Tue Apr 13 04:17:41 2021
From: fmiyara at fceia.unr.edu.ar (Federico Miyara)
Date: Mon, 12 Apr 2021 23:17:41 -0300
Subject: [Scilab-users] Why window() provides only symmetric weighting?
In-Reply-To: <03232727-dcad-2adf-61ae-baf93423699c@gmail.com>
References: <c79312b9-0333-cc0e-f7ec-e6cbe0bcf844@fceia.unr.edu.ar>
 <bcc908b0-947c-ca22-5a70-ed2fa95cb75e@free.fr>
 <d6725c96-fa29-1018-cac0-d22ec1b37bd4@fceia.unr.edu.ar>
 <DB8PR07MB63155030B1368401B3C96947E5709@DB8PR07MB6315.eurprd07.prod.outlook.com>
 <f797e2c6-c662-fe44-65d8-babf22097f30@fceia.unr.edu.ar>
 <03232727-dcad-2adf-61ae-baf93423699c@gmail.com>
Message-ID: <36218158-3836-2437-1abe-50a8d991ac24@fceia.unr.edu.ar>


Claus,

> For me the plurality is not so important - but let's say it's the 
> wording used in all our educational books (in English) ... just dig 
> into any Signal Analysis book, etc., and what we're trying to name 
> here is exactly that, then it would be bad for Scilab to give it a 
> different name. Renaming something that is universally defined 
> otherwise is an uphill battle we cannot win.

As I implied earlier, nomenclature could hardly be right or wrong since 
it is mostly arbitrary. But there could be more logical or less logical 
choices.

When it is well established, it is also a battle that is not worth 
fighting, especially if there is some sort of rationale behind it.

> Asymmetric window functions is new to me.I googled about window 
> functions and found (stumbled upon):
> https://journals.sagepub.com/doi/pdf/10.1260/1748-3018.9.4.389

This is another kind of asymmetry. "Periodic" window functions are only 
slightly asymmetric. I don't think they qualify for the kind of windows 
treated in that paper.

Asymmetric windows seem to be a good choice to smooth out the spectrum 
if phase response is not important. Scilab doesn't have any asymmetric 
function, but if a plan to add new windows were approved, they could be 
included along with several more traditional window functions currently 
not covered (such as Blackman, Blackman-Harris or a number of flat-tops).

Symmetric windows are used for FIR filter design. Periodic windows are 
used for spectrum analysis.

Regards,

Federico Miyara

> Conclusion: Asymmetric window functions have a purpose. When there's 
> asymmetric windows, then there must also be symmetric windows.
> Here's a short list of symmetric window functions: 
> https://mathworld.wolfram.com/ApodizationFunction.html
>
> Best regards,
> Claus
>
> On 12-04-2021 17:19, Federico Miyara wrote:
>>
>> Samuel:
>>
>> As a general concept, you are right ... but with nuances. The problem 
>> is deciding when something is really wrong and when it is just a 
>> question of opinion or personal preference. It is wrong to say the 
>> Earth is flat, no matter how many people say it. But is it right or 
>> wrong to call something just a conventional name?
>>
>> For instance: Is it right to call the derivative of a function 
>> "derivative"? Probably not, because "derivative" is a general concept 
>> which seems to have no relationship with its meaning in math. 
>> Probably in its origins it was more related to grammar than to math. 
>> But once established for centuries, it wouldn't be convenient to 
>> change it on the basis that it is "wrong".
>>
>> By the same token, calling "periodic" a window function obtained from 
>> periodic functions (cosines) whose period is equal to its length 
>> doesn't seem intrinsically wrong to me. Calling it "closed" would be 
>> worse since one immediately thinks either of a closed set, which is 
>> not, or a closed curve, which isn't either.
>>
>> But even if we found a better word, changing it would very likely 
>> create an unnecessary cognitive dissonance to thousands or millions 
>> of practitioners.
>>
>> Anyway, if a much better and cristal-clear word (i.e., whose meaning 
>> would be immediately obvious in its context) were found and gained 
>> consensus, no problem to use it instead of "periodic". The important 
>> thing in my proposal was to include in the window() function the 
>> feature, not how we call it.
>>
>> Regards,
>>
>> Federico Miyara
>>
>>
>>
>> On 12/04/2021 04:22, Dang Ngoc Chan, Christophe wrote:
>>> Hello,
>>>
>>>> De : Federico Miyara
>>>> Envoy? : dimanche 11 avril 2021 02:08
>>>>
>>>> Like it or not, I guess these keywords come from Matlab, and as Matlab
>>>> still seems to dominate the market, many people, including those
>>>> willing to quit Matlab (as I did several years ago), are quite used to
>>>> those keywords
>>> I don't agree with this argument.
>>> If a way of doing is wrong, then just keep on going because "everybody does so" is just an argumentum ad populum
>>>
>>> https://en.wikipedia.org/wiki/Argumentum_ad_populum
>>>
>>> which is a fallacious argument.
>>>
>>> Regards.
>>>
>>>
>>> --
>>> Christophe Dang Ngoc Chan
>>> Mechanical calculation engineer
>>>
>>>
>>> General
>>> This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error), please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
>>> _______________________________________________
>>> users mailing list
>>> users at lists.scilab.org
>>> http://lists.scilab.org/mailman/listinfo/users
>>>
>>>
>>
>>
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 
>> 	Libre de virus. www.avast.com 
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 
>>
>>
>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>
>> _______________________________________________
>> users mailing list
>> users at lists.scilab.org
>> http://lists.scilab.org/mailman/listinfo/users
>
>
>
> _______________________________________________
> users mailing list
> users at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users



-- 
El software de antivirus Avast ha analizado este correo electr?nico en busca de virus.
https://www.avast.com/antivirus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20210412/7c782b81/attachment.htm>

From johan.lafitte at gmail.com  Tue Apr 13 08:49:49 2021
From: johan.lafitte at gmail.com (johan64)
Date: Mon, 12 Apr 2021 23:49:49 -0700 (MST)
Subject: [Scilab-users] xcos_simulate()
In-Reply-To: <PR2PR09MB3562227750685E754F5FAD16B0739@PR2PR09MB3562.eurprd09.prod.outlook.com>
References: <CAP8EK979XoE5+_knU2khZ6P9WYvpxDgBhks8rhhwgfVnO1JnTQ@mail.gmail.com>
 <PR2PR09MB3562227750685E754F5FAD16B0739@PR2PR09MB3562.eurprd09.prod.outlook.com>
Message-ID: <1618296589038-0.post@n3.nabble.com>

Hi Clement,

Thank you for you answer. I 've tried the  scicos_simulate function again.
In this test initial conditions and inputs are set to 0. Normally, in this
case, state variables don't consume simulation time but I have no tools to
watch out  its activity.

1/ I've succeed in changing parameters between the two simulation. OK

2/The simulation time is not improve in the second execution (using "Info")
whereas nothing was changed. Maybe it is not a compilation problem?

I prefer contact you by email and sent you the model and make a sum up after
on this mailing list.

Thank you for your time. 

///Lancement de la simulation
    disp("lancement")
    tic();
    Info=scicos_simulate(scs_m,list())
    disp("Dur?e de simulation = ",toc());
    //Affichage
    exec(pwd()+"\Sc?narios"+"\Postraitement_commande simple.sce",-1);
pause
xdel(winsid())
//Lancement de la simulation 2
    tic();
    Info=scicos_simulate(scs_m,Info)
    disp( "Dur?e simulation2",toc())
    //Affichage
    exec(pwd()+"\Sc?narios"+"\Postraitement_commande simple.sce",-1);/



--
Sent from: http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html


From arctica1963 at gmail.com  Tue Apr 13 17:22:34 2021
From: arctica1963 at gmail.com (arctica1963)
Date: Tue, 13 Apr 2021 08:22:34 -0700 (MST)
Subject: [Scilab-users] Filled polygons from polylines
In-Reply-To: <7ced9bbb-2501-4f66-5bb0-ace5010563c0@free.fr>
References: <1617780347939-0.post@n3.nabble.com>
 <12180b4a-771c-3ab6-c255-54de0354825d@free.fr>
 <7ced9bbb-2501-4f66-5bb0-ace5010563c0@free.fr>
Message-ID: <1618327354236-0.post@n3.nabble.com>

Hi Samuel,

Thanks for the suggestion. I have not managed to get it working with the
existing code as it generates an invalid index error; not sure what is going
on. I tidied up the file for clarity.

Following your example,

plot(x, [0 y3 0]) would be plot(-t, [0 -xu(1,1:n) 0] ) in this code, but
this generates an invalid index. Not sure what is falling over?

I did note that some vertices close to the top border are coincident, which
could cause issues. Will keep working on the problem, but any pointers would
be helpful.

Cheers

Lester

Backstrip_1D_v2.sce
<http://mailinglists.scilab.org/file/t495709/Backstrip_1D_v2.sce>  Lester



--
Sent from: http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html


From arctica1963 at gmail.com  Wed Apr 14 12:17:02 2021
From: arctica1963 at gmail.com (arctica1963)
Date: Wed, 14 Apr 2021 03:17:02 -0700 (MST)
Subject: [Scilab-users] Filled polygons from polylines
In-Reply-To: <1618327354236-0.post@n3.nabble.com>
References: <1617780347939-0.post@n3.nabble.com>
 <12180b4a-771c-3ab6-c255-54de0354825d@free.fr>
 <7ced9bbb-2501-4f66-5bb0-ace5010563c0@free.fr>
 <1618327354236-0.post@n3.nabble.com>
Message-ID: <1618395422662-0.post@n3.nabble.com>

Hi Samuel,

Sorted out the code and it works.Had to manually set the filled areas upper
time limit (t=97) (plot(-[97 t], [0 y1]) ). Set two graphic handles for
upper and lower plot. Just random colours to test!

Is there a way to do a loop over the curves to save multiple plots

Thanks

Lester

<http://mailinglists.scilab.org/file/t495709/Backstrip_filled-plot_3.png> 

<http://mailinglists.scilab.org/file/t495709/Backstrip_line-plot1.png> 

Backstrip_1D_v2filltest.sce
<http://mailinglists.scilab.org/file/t495709/Backstrip_1D_v2filltest.sce>  



--
Sent from: http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html


From arctica1963 at gmail.com  Wed Apr 14 12:18:18 2021
From: arctica1963 at gmail.com (arctica1963)
Date: Wed, 14 Apr 2021 03:18:18 -0700 (MST)
Subject: [Scilab-users] Filled polygons from polylines
In-Reply-To: <1618327354236-0.post@n3.nabble.com>
References: <1617780347939-0.post@n3.nabble.com>
 <12180b4a-771c-3ab6-c255-54de0354825d@free.fr>
 <7ced9bbb-2501-4f66-5bb0-ace5010563c0@free.fr>
 <1618327354236-0.post@n3.nabble.com>
Message-ID: <1618395498311-0.post@n3.nabble.com>

Truncated plot at t=97

<http://mailinglists.scilab.org/file/t495709/Backstrip_filled-plot_3a.png> 



--
Sent from: http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html


From antoine.monmayrant at laas.fr  Wed Apr 14 13:40:35 2021
From: antoine.monmayrant at laas.fr (Antoine Monmayrant)
Date: Wed, 14 Apr 2021 13:40:35 +0200
Subject: [Scilab-users] Filled polygons from polylines
In-Reply-To: <1618395422662-0.post@n3.nabble.com>
References: <1617780347939-0.post@n3.nabble.com>
 <12180b4a-771c-3ab6-c255-54de0354825d@free.fr>
 <7ced9bbb-2501-4f66-5bb0-ace5010563c0@free.fr>
 <1618327354236-0.post@n3.nabble.com> <1618395422662-0.post@n3.nabble.com>
Message-ID: <ec35ba00-0f01-9733-28a2-954c9c979086@laas.fr>

Hello Lester,

On 14/04/2021 12:17, arctica1963 wrote:
> Is there a way to do a loop over the curves to save multiple plots
What do you want to do exactly?
Do you want to get several image files with only part of the lines or 
surfaces visible?

Because you can do that by playing with the "visible" field of the 
different curves in your graph...

Antoine



From arctica1963 at gmail.com  Wed Apr 14 14:21:58 2021
From: arctica1963 at gmail.com (arctica1963)
Date: Wed, 14 Apr 2021 05:21:58 -0700 (MST)
Subject: [Scilab-users] Filled polygons from polylines
In-Reply-To: <ec35ba00-0f01-9733-28a2-954c9c979086@laas.fr>
References: <1617780347939-0.post@n3.nabble.com>
 <12180b4a-771c-3ab6-c255-54de0354825d@free.fr>
 <7ced9bbb-2501-4f66-5bb0-ace5010563c0@free.fr>
 <1618327354236-0.post@n3.nabble.com> <1618395422662-0.post@n3.nabble.com>
 <ec35ba00-0f01-9733-28a2-954c9c979086@laas.fr>
Message-ID: <1618402918400-0.post@n3.nabble.com>

Sorry, I did not make it clear.

Instead of the following which updates the existing graphic to generate the
final plot (y1 to y10);

plot(-[t(n) t], [0 y1])
plot(-[t(n) t], [0 y2])
plot(-[t(n) t], [0 y3])
plot(-[t(n) t], [0 y4])
plot(-[t(n) t], [0 y5])
plot(-[t(n) t], [0 y6])
plot(-[t(n) t], [0 y7])
plot(-[t(n) t], [0 y8])
plot(-[t(n) t], [0 y9])
plot(-[t(n) t], [0 y10])

Can a loop (y) be made to simplify the above for clarity as a single plot
command? Not a big issue but would be good to know.

Lester



--
Sent from: http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html


From antoine.monmayrant at laas.fr  Wed Apr 14 14:34:09 2021
From: antoine.monmayrant at laas.fr (Antoine Monmayrant)
Date: Wed, 14 Apr 2021 14:34:09 +0200
Subject: [Scilab-users] Filled polygons from polylines
In-Reply-To: <1618402918400-0.post@n3.nabble.com>
References: <1617780347939-0.post@n3.nabble.com>
 <12180b4a-771c-3ab6-c255-54de0354825d@free.fr>
 <7ced9bbb-2501-4f66-5bb0-ace5010563c0@free.fr>
 <1618327354236-0.post@n3.nabble.com> <1618395422662-0.post@n3.nabble.com>
 <ec35ba00-0f01-9733-28a2-954c9c979086@laas.fr>
 <1618402918400-0.post@n3.nabble.com>
Message-ID: <b3556430-38e0-a470-8a2a-8b6e4b23b8ad@laas.fr>


On 14/04/2021 14:21, arctica1963 wrote:
> Sorry, I did not make it clear.
>
> Instead of the following which updates the existing graphic to generate the
> final plot (y1 to y10);
>
> plot(-[t(n) t], [0 y1])
> plot(-[t(n) t], [0 y2])
> plot(-[t(n) t], [0 y3])
> plot(-[t(n) t], [0 y4])
> plot(-[t(n) t], [0 y5])
> plot(-[t(n) t], [0 y6])
> plot(-[t(n) t], [0 y7])
> plot(-[t(n) t], [0 y8])
> plot(-[t(n) t], [0 y9])
> plot(-[t(n) t], [0 y10])
>
> Can a loop (y) be made to simplify the above for clarity as a single plot
> command? Not a big issue but would be good to know.

Sure:

plot(-[t(n) t], [[0 y1];[0 y2];[0 y3];[0 y4];[0 y5];[0 y6];[0 y7];[0 y8];[0 y9];[0 y10]])

Antoine

>
> Lester
>
>
>
> --
> Sent from: http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html
> _______________________________________________
> users mailing list
> users at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users
>


From stephane.mottelet at utc.fr  Wed Apr 14 14:56:08 2021
From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=)
Date: Wed, 14 Apr 2021 14:56:08 +0200
Subject: [Scilab-users] Scilab and newer Mac M1 machines
Message-ID: <c13bd1a3-5d8d-bd1c-e29f-6dd80006671f@utc.fr>

Hi all,

I have updated the Scilab for macOS page with new instructions for the 
situation where Scilab is the very first application compiled for Intel 
architecture run on a Mac M1. To successfully launch Scilab you have to 
manually install the Apple Rosetta 2 binary traduction engine from the 
command line. See https://www.utc.fr/~mottelet/scilab_for_macOS.html for 
the details.

Regards,

-- 
St?phane Mottelet
Ing?nieur de recherche
EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable
D?partement G?nie des Proc?d?s Industriels
Sorbonne Universit?s - Universit? de Technologie de Compi?gne
CS 60319, 60203 Compi?gne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet



From arctica1963 at gmail.com  Wed Apr 14 16:31:39 2021
From: arctica1963 at gmail.com (arctica1963)
Date: Wed, 14 Apr 2021 07:31:39 -0700 (MST)
Subject: [Scilab-users] Filled polygons from polylines
In-Reply-To: <b3556430-38e0-a470-8a2a-8b6e4b23b8ad@laas.fr>
References: <1617780347939-0.post@n3.nabble.com>
 <12180b4a-771c-3ab6-c255-54de0354825d@free.fr>
 <7ced9bbb-2501-4f66-5bb0-ace5010563c0@free.fr>
 <1618327354236-0.post@n3.nabble.com> <1618395422662-0.post@n3.nabble.com>
 <ec35ba00-0f01-9733-28a2-954c9c979086@laas.fr>
 <1618402918400-0.post@n3.nabble.com>
 <b3556430-38e0-a470-8a2a-8b6e4b23b8ad@laas.fr>
Message-ID: <1618410699267-0.post@n3.nabble.com>

Many thanks Antoine

Lester



--
Sent from: http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html


From stephane.mottelet at utc.fr  Mon Apr 19 10:43:27 2021
From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=)
Date: Mon, 19 Apr 2021 10:43:27 +0200
Subject: [Scilab-users] fmincon toolbox update
Message-ID: <d104858f-e2ad-bc35-1c1d-7d4c594b6736@utc.fr>

Hi all,

I would like to inform you that the fmincon toolbox has been updated 
(https://atoms.scilab.org/toolboxes/fmincon/1.0.2) and now includes a 
major feature:? the Efficient Computation of Sparse Hessian using 
Coloring algorithm (scicolpack is now a? dependency of fmincon). This 
feature was missing and now allows fmincon to consider really big 
problems. A example of such is given in the "minimal surface demo" which 
compares 3 different approaches of the problem: one with finite 
differences gradient, and BFGS Hessian, one with exact gradient and BFGS 
Hessian, and the last with exact gradient and finite differences sparse 
Hessian. The time factor between the first and the third approchach is 
around 200 for a 21x21 square but you can edit the demo file and 
increase this value. For a 51x51 square the third approach takes only 
0.45 seconds and is 2500 times faster. For a 101x101 square the first 
approach takes forever and the third ones takes less than 2 seconds and 
is still 10 times faster than the second one.

If some of you still use other softwares for large scale optimization, 
maybe you can now give Scilab a try. If you need a better control on 
parameters and/or if you are not a former/actual user of Matlab's 
fmincon, I recommend using directly ipopt (from sci_ipopt toolbox). But 
the fmincon api is quite easy to use. Don't hesitate to took at the code 
of the several new demos.

Don't hesitate to contact me if you have some problems using fmincon of 
just to say that you are using it with success !

Regards,

-- 
St?phane Mottelet
Ing?nieur de recherche
EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable
D?partement G?nie des Proc?d?s Industriels
Sorbonne Universit?s - Universit? de Technologie de Compi?gne
CS 60319, 60203 Compi?gne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet



From cfuttrup at gmail.com  Mon Apr 19 15:58:45 2021
From: cfuttrup at gmail.com (Claus Futtrup)
Date: Mon, 19 Apr 2021 15:58:45 +0200
Subject: [Scilab-users] fmincon toolbox update
In-Reply-To: <d104858f-e2ad-bc35-1c1d-7d4c594b6736@utc.fr>
References: <d104858f-e2ad-bc35-1c1d-7d4c594b6736@utc.fr>
Message-ID: <e2d00c7c-0b86-ba7f-8098-7566ad267d72@gmail.com>


It sounds great!

:-D

/Claus


On 19-04-2021 10:43, St?phane Mottelet wrote:
> Hi all,
>
> I would like to inform you that the fmincon toolbox has been updated 
> (https://atoms.scilab.org/toolboxes/fmincon/1.0.2) and now includes a 
> major feature:? the Efficient Computation of Sparse Hessian using 
> Coloring algorithm (scicolpack is now a? dependency of fmincon). This 
> feature was missing and now allows fmincon to consider really big 
> problems. A example of such is given in the "minimal surface demo" 
> which compares 3 different approaches of the problem: one with finite 
> differences gradient, and BFGS Hessian, one with exact gradient and 
> BFGS Hessian, and the last with exact gradient and finite differences 
> sparse Hessian. The time factor between the first and the third 
> approchach is around 200 for a 21x21 square but you can edit the demo 
> file and increase this value. For a 51x51 square the third approach 
> takes only 0.45 seconds and is 2500 times faster. For a 101x101 square 
> the first approach takes forever and the third ones takes less than 2 
> seconds and is still 10 times faster than the second one.
>
> If some of you still use other softwares for large scale optimization, 
> maybe you can now give Scilab a try. If you need a better control on 
> parameters and/or if you are not a former/actual user of Matlab's 
> fmincon, I recommend using directly ipopt (from sci_ipopt toolbox). 
> But the fmincon api is quite easy to use. Don't hesitate to took at 
> the code of the several new demos.
>
> Don't hesitate to contact me if you have some problems using fmincon 
> of just to say that you are using it with success !
>
> Regards,
>



From parravicini.anna at gmail.com  Tue Apr 20 13:09:04 2021
From: parravicini.anna at gmail.com (anna28)
Date: Tue, 20 Apr 2021 04:09:04 -0700 (MST)
Subject: [Scilab-users] save and load
Message-ID: <1618916944209-0.post@n3.nabble.com>

Hello,

I'm looking for a help in using "save" and "load" functions.

Briefly (here below the full code), I create a plot, then I change x-axis
ticks locations and labels.
I save the figure with "save("foo6.scg", "a")".
When I use "load("foo6.scg", "a")", the figure is shown correctly except
that x-axis ticks are missing at all.
Is there any way to save the x-axis ticks, too?

thanks in advance,
anna

***

scf();
f=gcf;
f.figure_position=[10,10]
f.figure_size=[1000,700]
clf;
title(plane+" mean POSITIONS - ccode "+ccEn+" - particle "+particle,
'fontsize',4);

xsetech([0,0,1,0.95]);

for j=1:size(puName,'c')
    plot(loc(:),orbitMean(:,j),mark(j),'thickness',2);
    // usando 'loc' come asse x, plotta le misure distanziate correttamente
nel tempo
end

xgrid(33);
xlabel('measurement date [yyyymmdd_hh]','fontsize',3);
ylabel(posRange+" position [mm]",'fontsize',3);
legend(puNames_and_stat(:),-4);
a=gca();
a.x_ticks = tlist(["ticks" "locations", "labels"],loc(:),labels_rot(:));
a.font_size=3; 

save("foo6.scg", "a");



--
Sent from: http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html


From antoine.monmayrant at laas.fr  Tue Apr 20 14:53:53 2021
From: antoine.monmayrant at laas.fr (Antoine Monmayrant)
Date: Tue, 20 Apr 2021 14:53:53 +0200
Subject: [Scilab-users] save and load
In-Reply-To: <1618916944209-0.post@n3.nabble.com>
References: <1618916944209-0.post@n3.nabble.com>
Message-ID: <e6006dde-b2f8-426b-370c-296b4065e210@laas.fr>

Hello Anna,

3 points:

(1) Could you post a minimum working example?
Because your code below cannot run, many variables are missing.

(2) Usually, you'd better use xload/xsave to save & restore graphics

(3) There seems to be a bug, as the following code:

    h=scf()
    plot()
    h.children(1).x_ticks.labels="Anna"+h.children(1).x_ticks.labels;
    sleep(100)// just in case it's a race condition
    xsave(TMPDIR+"/tata.sod",h);
    xdel(winsid())
    xload(TMPDIR+"/tata.sod")

Does not restore the modified x_ticks properly...

Does anyone know whether this is a known bug?

Antoine

Le 20/04/2021 ? 13:09, anna28 a ?crit?:
> scf();
> f=gcf;
> f.figure_position=[10,10]
> f.figure_size=[1000,700]
> clf;
> title(plane+" mean POSITIONS - ccode "+ccEn+" - particle "+particle,
> 'fontsize',4);
>
> xsetech([0,0,1,0.95]);
>
> for j=1:size(puName,'c')
>      plot(loc(:),orbitMean(:,j),mark(j),'thickness',2);
>      // usando 'loc' come asse x, plotta le misure distanziate correttamente
> nel tempo
> end
>
> xgrid(33);
> xlabel('measurement date [yyyymmdd_hh]','fontsize',3);
> ylabel(posRange+" position [mm]",'fontsize',3);
> legend(puNames_and_stat(:),-4);
> a=gca();
> a.x_ticks = tlist(["ticks" "locations", "labels"],loc(:),labels_rot(:));
> a.font_size=3;
>
> save("foo6.scg", "a");
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20210420/357f90f0/attachment.htm>

From parravicini.anna at gmail.com  Tue Apr 20 16:06:18 2021
From: parravicini.anna at gmail.com (anna28)
Date: Tue, 20 Apr 2021 07:06:18 -0700 (MST)
Subject: [Scilab-users] save and load
In-Reply-To: <e6006dde-b2f8-426b-370c-296b4065e210@laas.fr>
References: <1618916944209-0.post@n3.nabble.com>
 <e6006dde-b2f8-426b-370c-296b4065e210@laas.fr>
Message-ID: <1618927578354-0.post@n3.nabble.com>

Hello Antoine,

the point is exactly what you point out with your example (here below you
can find my working script, but your example is enough to understand my
problem).

If I don't modify the x-label ticks, everything is fine. If I modify x-label
ticks, they are not loaded.

I use "xsave" and "load"... if I use "xload" a blank rectangle  appears over
the loaded figure and I cannot see my graph.

cheers
Anna


===
f=scf();
f.figure_position=[10,10]
f.figure_size=[1000,700]
clf;
title("positions", 'fontsize',4);

xsetech([0,0,1,0.95]);
mark=['r.-','g.-','k.-','b.-','m.-','r:.','g:.','k:.','b:.',,'m:.','.r-.','.g-.'];
puName=["aa" "bb" "cc" "dd" "ee" "ff" "gg" "hh" "ii"];
loc=[12008.0;12011.0;12012.0;12013.0;12014.0;12015.0;12016.0;12017.0;12018.0;12019.0;12020.0;12032.0;12033.0;12035.0;12036.0;12037.0;12038.0;12039.0;12040.0;12041.0];
orbitMean=[1.11       -2.362       3.1155      4.261      -0.8815     -3.22      
-2.552      -0.673       3.709    
   1.1284     -2.3604      3.1156      4.2544     -0.8862     -3.2234    
-2.5524     -0.6836      3.7182   
   1.1098889  -2.3558889   3.102       4.2385556  -0.8864444  -3.2128889 
-2.5352222  -0.6823333   3.7017778
   1.1025     -2.355       3.1005      4.2335     -0.8845     -3.21275   
-2.5325     -0.6815      3.69825  
   1.102      -2.3515      3.104       4.226      -0.8845     -3.209     
-2.522      -0.678       3.695    
   1.1104     -2.3438      3.0876      4.2264     -0.8766     -3.1932    
-2.5194     -0.6836      3.681    
   1.122      -2.3498      3.1012      4.2384     -0.8872     -3.2168    
-2.5398     -0.6776      3.706    
   1.1143333  -2.3473333   3.095       4.2253333  -0.8743333  -3.199     
-2.5246667  -0.6826667   3.69     
   1.1053333  -2.3556667   3.1038333   4.2415     -0.879      -3.2081667 
-2.5393333  -0.6815      3.7086667
   1.0955     -2.3615      3.0965      4.24       -0.891      -3.2275    
-2.5625     -0.668       3.7165   
   1.0872857  -2.358       3.0995714   4.2322857  -0.8851429  -3.2104286 
-2.5382857  -0.6798571   3.7028571
   1.1075     -2.35225     3.1015      4.258      -0.882375   -3.19875   
-2.557375   -0.68825     3.707    
   1.0935     -2.3458333   3.1081667   4.2461667  -0.8866667  -3.2165    
-2.5461667  -0.6761667   3.7065   
   1.1035     -2.3513333   3.1016667   4.2533333  -0.8846667  -3.2125    
-2.5488333  -0.6783333   3.7081667
   1.088      -2.3536667   3.1093333   4.2466667  -0.8923333  -3.2266667 
-2.548      -0.6673333   3.7136667
   1.0926667  -2.3453333   3.105       4.2456667  -0.881      -3.2176667 
-2.5413333  -0.673       3.7006667
   1.0963333  -2.3546667   3.11        4.2496667  -0.8893333  -3.2033333 
-2.546      -0.676       3.707    
   1.097625   -2.352625    3.1065      4.250375   -0.885625   -3.21425   
-2.5495     -0.67675     3.7115   
   1.1111429  -2.347       3.1092857   4.2537143  -0.889      -3.227     
-2.5605714  -0.6768571   3.7221429
   1.09775    -2.34325     3.10125     4.236      -0.88675    -3.222     
-2.53925    -0.672       3.695    ]
for j=1:size(puName,'c')
    plot(loc(:),orbitMean(:,j),mark(j),'thickness',2);
    // usando 'loc' come asse x, plotta le misure distanziate correttamente
nel tempo
end
labels_rot=["$\texttt {\rotatebox{90}{20210415h08}}$";"$\texttt
{\rotatebox{90}{20210415h11}}$";"$\texttt
{\rotatebox{90}{20210415h12}}$";"$\texttt
{\rotatebox{90}{20210415h13}}$";"$\texttt
{\rotatebox{90}{20210415h14}}$";"$\texttt
{\rotatebox{90}{20210415h15}}$";"$\texttt
{\rotatebox{90}{20210415h16}}$";"$\texttt
{\rotatebox{90}{20210415h17}}$";"$\texttt
{\rotatebox{90}{20210415h18}}$";"$\texttt
{\rotatebox{90}{20210415h19}}$";"$\texttt
{\rotatebox{90}{20210415h20}}$";"$\texttt
{\rotatebox{90}{20210416h08}}$";"$\texttt
{\rotatebox{90}{20210416h09}}$";"$\texttt
{\rotatebox{90}{20210416h11}}$";"$\texttt
{\rotatebox{90}{20210416h12}}$";"$\texttt {\rotatebox{90}{20210416h13}}$";
"$\texttt {\rotatebox{90}{20210416h14}}$";"$\texttt
{\rotatebox{90}{20210416h15}}$";"$\texttt
{\rotatebox{90}{20210416h16}}$";"$\texttt {\rotatebox{90}{20210416h17}}$"];
xgrid(33);
xlabel('measurement date [yyyymmdd_hh]','fontsize',3);
ylabel(" position [mm]",'fontsize',3);
legend(puName,-4);
a=gca();
a.x_ticks = tlist(["ticks" "locations", "labels"],loc(:),labels_rot(:));
a.font_size=3; 
xsave("foo.sod", f);



--
Sent from: http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html


From sgougeon at free.fr  Sat Apr 24 18:44:02 2021
From: sgougeon at free.fr (Samuel Gougeon)
Date: Sat, 24 Apr 2021 18:44:02 +0200
Subject: [Scilab-users] save and load
In-Reply-To: <e6006dde-b2f8-426b-370c-296b4065e210@laas.fr>
References: <1618916944209-0.post@n3.nabble.com>
 <e6006dde-b2f8-426b-370c-296b4065e210@laas.fr>
Message-ID: <2462cde3-6c76-036e-34c2-43e72e8fe5d6@free.fr>

Le 20/04/2021 ? 14:53, Antoine Monmayrant a ?crit?:
>
> Hello Anna,
>
> 3 points:
>
> (1) Could you post a minimum working example?
> Because your code below cannot run, many variables are missing.
>
> (2) Usually, you'd better use xload/xsave to save & restore graphics
>
> (3) There seems to be a bug, as the following code:
>
>     h=scf()
>     plot()
>     h.children(1).x_ticks.labels="Anna"+h.children(1).x_ticks.labels;
>     sleep(100)// just in case it's a race condition
>     xsave(TMPDIR+"/tata.sod",h);
>     xdel(winsid())
>     xload(TMPDIR+"/tata.sod")
>
> Does not restore the modified x_ticks properly...
>
> Does anyone know whether this is a known bug?
>
It is not yet reported. It is a regression brought by Scilab 6.0.0

There is a likely related strange feature:

plot2d()
ax  =  gca();
ax.x_ticks.labels="Anna"+ax.x_ticks.labels;
// See new labels
ax.auto_ticks(1)   // automatically set to "off"by manual setting
ax.auto_ticks(1)  =  "on";
// See restored numeric labels
// AND NOW:
ax.auto_ticks(1)  =  "off";
// Former "Anna"ed labels restored! So they were kept somewhere, despite the
// ax.auto_ticks(1) = "on"; restoration in the mean time...

Samuel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20210424/840e5bd4/attachment.htm>

From sgougeon at free.fr  Sat Apr 24 19:39:28 2021
From: sgougeon at free.fr (Samuel Gougeon)
Date: Sat, 24 Apr 2021 19:39:28 +0200
Subject: [Scilab-users] plot2d3()
In-Reply-To: <4975d334-413e-517b-9e3f-35e66033e143@fceia.unr.edu.ar>
References: <4975d334-413e-517b-9e3f-35e66033e143@fceia.unr.edu.ar>
Message-ID: <3b8c6824-f1b6-61b7-fbf6-c400c5f2a33e@free.fr>

Le 12/04/2021 ? 07:39, Federico Miyara a ?crit?:
>
> Dear All,
>
> I'm trying to get a plot like this:
>

Nice plot (a Power Spectrum Density after applying an open window()..? :-))


> where I intend to get a line plot where the lines come from the bottom 
> of the plot instead of coming from 0 as is the normal way using 
> plot2d3().
>
> To get this with plot2d3() I had to plot the y axis data + 50 in order 
> to make the botom of the plot coincident with 0, and then fake the 
> labels using
>
>
> gca()..y_ticks.labels = 
> ["-50","-45","-40","-35","-30","-25","-20","-15","-10","-5","0","5","10"]';
>
>
> To get the circles I had to use plot() with "o" as third argument 
> since plot2d3() doesn't accept it.
>
> Is there a more direct way to get such result
>
> Is a there some way of achieving this in a more tative way?


Good question!
I see two issues with this trial:

  * setting y_ticks labels by hand cancels the auto_ticking mode for
    ordinates, if we resize the graphic window
  * The y value on datatips becomes wrong

There could be a solution using gca().ticks_st(:,2), but... 
gca().ticks_st does not work <http://bugzilla.scilab.org/14790> (no 
workaround found to make it working).
When this will be fixed, the following code could be tested:

[n,  ybase]  =  (10,  -12);
y  =  ybase  +  9*grand(1,n,"def");
clf,  plot(y(:),  "-o")
set(gce().children,  "polyline_style",3,  "line_mode","off");
gca().axes_reverse(2)  =  "on";
gca().ticks_st(:, 2)  =  [-1;-14];

It should set correct -- and auto_ticked -- y values, with lines 
starting from the bottom.
But i wonder if default datatips take the .ticks_st property into 
account to display correct values.

In the meantime, here is another possible workaround, that is both 
auto_ticking and with correct datatiped values:

// Raw data [n,  ybase]  =  (10,  -12);
y  =  ybase  +  9*grand(1,n,"def");
// Actual data y  =  [ybase*ones(y);  y  ;  ybase*ones(y)];
x  =  (1:n)  .*.  [1  1  1];
// Plotting clf,  plot(x(:),  y(:),  "-o")
set(gce().children,  "mark_stride",3,  "mark_offset",1);

Regards
Samuel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20210424/66185c78/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bjohlbeipdpbnclh.png
Type: image/png
Size: 10483 bytes
Desc: not available
URL: <https://lists.scilab.org/pipermail/users/attachments/20210424/66185c78/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lfignlgimicaeben.png
Type: image/png
Size: 10469 bytes
Desc: not available
URL: <https://lists.scilab.org/pipermail/users/attachments/20210424/66185c78/attachment-0001.png>

From stephane.mottelet at utc.fr  Mon Apr 26 09:41:51 2021
From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=)
Date: Mon, 26 Apr 2021 09:41:51 +0200
Subject: [Scilab-users] Toolboxes startup
Message-ID: <f1cd304c-2a9c-bb87-6213-d50be10b90c8@utc.fr>

Hi all,

I just made available for macOS and Linux the toolboxes stixbox depends 
upon for macOS (distfun and linalg) and my remark is that when a lot of 
modules are loaded at startup then the output can become very long and 
sometimes messy, since we don't impose a normalized output:

*Scilab branch-6.1 (Apr 19 2021, 23:19:29)**
*

*Start Distfun**
**
**Start Helptbx**
**
**Start Specfun**
**
**Start Makematrix**
**
**Start Apifun**
**??? Load macros**
**??? Type "help apifun_overview" for a quick start.**
**
**Start Linalg**
**
**Start Stixbox*

I would rather expect something like:


*Scilab branch-6.1 (Apr 19 2021, 23:19:29)**
*

*Start modules: Distfun, Helptbx, Specfun, Makematrix, Apifun, Linalg, 
Stixbox.*

*--> *

The verbosity level of the output (with the above default)? could be 
defined in user preferences, and checked in module startup script in 
order to output the required amount of information.

That's just a propostion to be discussed, of course.

S.

-- 
St?phane Mottelet
Ing?nieur de recherche
EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable
D?partement G?nie des Proc?d?s Industriels
Sorbonne Universit?s - Universit? de Technologie de Compi?gne
CS 60319, 60203 Compi?gne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20210426/3968ab81/attachment.htm>

From Christophe.Dang at sidel.com  Mon Apr 26 09:42:57 2021
From: Christophe.Dang at sidel.com (Dang Ngoc Chan, Christophe)
Date: Mon, 26 Apr 2021 07:42:57 +0000
Subject: [Scilab-users] plot2d3()
In-Reply-To: <3b8c6824-f1b6-61b7-fbf6-c400c5f2a33e@free.fr>
References: <4975d334-413e-517b-9e3f-35e66033e143@fceia.unr.edu.ar>
 <3b8c6824-f1b6-61b7-fbf6-c400c5f2a33e@free.fr>
Message-ID: <DB8PR07MB63151550097EA1A5BE0D19ADE5429@DB8PR07MB6315.eurprd07.prod.outlook.com>

Hello,

> De : fmiyara
> I'm trying to get a plot like this:

[...]

Maybe you should try with xpolys(), e.g.

----------

[n, ybase] = (10, -12);

y = ybase + 9*grand(1,n,"def");

x=1:n;

Y=[y ; ybase*ones(y)];

X=[x ; x]

scf(0);

clf();

xpolys(X, Y, ones(y));

plot(x, y, "o");

gcf().children.data_bounds(1, 2) = ybase;

----------

But it mays have some drawbacks.

HTH


--
Christophe Dang Ngoc Chan
Mechanical calculation engineer


General
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error), please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

From Clement.David at esi-group.com  Mon Apr 26 10:57:42 2021
From: Clement.David at esi-group.com (=?utf-8?B?Q2zDqW1lbnQgRGF2aWQ=?=)
Date: Mon, 26 Apr 2021 08:57:42 +0000
Subject: [Scilab-users] Toolboxes startup
In-Reply-To: <f1cd304c-2a9c-bb87-6213-d50be10b90c8@utc.fr>
References: <f1cd304c-2a9c-bb87-6213-d50be10b90c8@utc.fr>
Message-ID: <DU2PR09MB5261ECC9B5D8B4790D36DDEAB0429@DU2PR09MB5261.eurprd09.prod.outlook.com>

Hi all,

Thanks for the proposal Stephane, this is a good idea!

As a reminder, currently each toolbox is free to display anything at startup and the toolbox skeleton provides a default ?Start ? + TOOLBOX_NAME then display information that ease development (gateways, help and so on). Migrating to another display is only a matter of convention, for example by checking if the global %toolboxes variable is available than do not display anything.

Cl?ment

From: users <users-bounces at lists.scilab.org> On Behalf Of St?phane Mottelet
Sent: Monday, April 26, 2021 9:42 AM
To: Users mailing list for Scilab <users at lists.scilab.org>
Subject: [Scilab-users] Toolboxes startup


Hi all,

I just made available for macOS and Linux the toolboxes stixbox depends upon for macOS (distfun and linalg) and my remark is that when a lot of modules are loaded at startup then the output can become very long and sometimes messy, since we don't impose a normalized output:

Scilab branch-6.1 (Apr 19 2021, 23:19:29)

Start Distfun

Start Helptbx

Start Specfun

Start Makematrix

Start Apifun
    Load macros
    Type "help apifun_overview" for a quick start.

Start Linalg

Start Stixbox

I would rather expect something like:



Scilab branch-6.1 (Apr 19 2021, 23:19:29)

Start modules: Distfun, Helptbx, Specfun, Makematrix, Apifun, Linalg, Stixbox.

-->

The verbosity level of the output (with the above default)  could be defined in user preferences, and checked in module startup script in order to output the required amount of information.

That's just a propostion to be discussed, of course.

S.

--

St?phane Mottelet

Ing?nieur de recherche

EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable

D?partement G?nie des Proc?d?s Industriels

Sorbonne Universit?s - Universit? de Technologie de Compi?gne

CS 60319, 60203 Compi?gne cedex

Tel : +33(0)344234688

http://www.utc.fr/~mottelet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20210426/6fd90d67/attachment.htm>

From stephane.mottelet at utc.fr  Mon Apr 26 11:38:28 2021
From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=)
Date: Mon, 26 Apr 2021 11:38:28 +0200
Subject: [Scilab-users] Toolboxes startup
In-Reply-To: <DU2PR09MB5261ECC9B5D8B4790D36DDEAB0429@DU2PR09MB5261.eurprd09.prod.outlook.com>
References: <f1cd304c-2a9c-bb87-6213-d50be10b90c8@utc.fr>
 <DU2PR09MB5261ECC9B5D8B4790D36DDEAB0429@DU2PR09MB5261.eurprd09.prod.outlook.com>
Message-ID: <4c529dc6-4641-bcc2-fb0e-d9a957740536@utc.fr>

Is %toolboxes already used ? If so where is it documented ?

S.

Le 26/04/2021 ? 10:57, Cl?ment David a ?crit?:
>
> Hi all,
>
> Thanks for the proposal Stephane, this is a good idea!
>
> As a reminder, currently each toolbox is free to display anything at 
> startup and the toolbox skeleton provides a default ?Start ? + 
> TOOLBOX_NAME then display information that ease development (gateways, 
> help and so on). Migrating to another display is only a matter of 
> convention, for example by checking if the global %toolboxes variable 
> is available than do not display anything.
>
> Cl?ment
>
> *From:* users <users-bounces at lists.scilab.org> *On Behalf Of *St?phane 
> Mottelet
> *Sent:* Monday, April 26, 2021 9:42 AM
> *To:* Users mailing list for Scilab <users at lists.scilab.org>
> *Subject:* [Scilab-users] Toolboxes startup
>
> Hi all,
>
> I just made available for macOS and Linux the toolboxes stixbox 
> depends upon for macOS (distfun and linalg) and my remark is that when 
> a lot of modules are loaded at startup then the output can become very 
> long and sometimes messy, since we don't impose a normalized output:
>
> *Scilab branch-6.1 (Apr 19 2021, 23:19:29)*
>
> *Start Distfun
>
> Start Helptbx
>
> Start Specfun
>
> Start Makematrix
>
> Start Apifun
> ??? Load macros
> ??? Type "help apifun_overview" for a quick start.
>
> Start Linalg
>
> Start Stixbox*
>
> I would rather expect something like:
>
> *Scilab branch-6.1 (Apr 19 2021, 23:19:29)*
>
> *Start modules: Distfun, Helptbx, Specfun, Makematrix, Apifun, Linalg, 
> Stixbox.*
>
> *--> *
>
> The verbosity level of the output (with the above default) could be 
> defined in user preferences, and checked in module startup script in 
> order to output the required amount of information.
>
> That's just a propostion to be discussed, of course.
>
> S.
>
> -- 
> St?phane Mottelet
> Ing?nieur de recherche
> EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable
> D?partement G?nie des Proc?d?s Industriels
> Sorbonne Universit?s - Universit? de Technologie de Compi?gne
> CS 60319, 60203 Compi?gne cedex
> Tel : +33(0)344234688
> http://www.utc.fr/~mottelet  <https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/www.utc.fr/~mottelet>
>
> _______________________________________________
> users mailing list
> users at lists.scilab.org
> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users

-- 
St?phane Mottelet
Ing?nieur de recherche
EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable
D?partement G?nie des Proc?d?s Industriels
Sorbonne Universit?s - Universit? de Technologie de Compi?gne
CS 60319, 60203 Compi?gne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20210426/95f0902e/attachment.htm>

From Clement.David at esi-group.com  Mon Apr 26 11:55:27 2021
From: Clement.David at esi-group.com (=?utf-8?B?Q2zDqW1lbnQgRGF2aWQ=?=)
Date: Mon, 26 Apr 2021 09:55:27 +0000
Subject: [Scilab-users] Toolboxes startup
In-Reply-To: <4c529dc6-4641-bcc2-fb0e-d9a957740536@utc.fr>
References: <f1cd304c-2a9c-bb87-6213-d50be10b90c8@utc.fr>
 <DU2PR09MB5261ECC9B5D8B4790D36DDEAB0429@DU2PR09MB5261.eurprd09.prod.outlook.com>
 <4c529dc6-4641-bcc2-fb0e-d9a957740536@utc.fr>
Message-ID: <DU2PR09MB526146CECFFA80EFAFAC47FFB0429@DU2PR09MB5261.eurprd09.prod.outlook.com>

It is not documented but there is some reference to it on atomsLoad and etc/Scilab.start . IMHO we can make it widely available and document it for this usage.

Cl?ment

From: users <users-bounces at lists.scilab.org> On Behalf Of St?phane Mottelet
Sent: Monday, April 26, 2021 11:38 AM
To: users at lists.scilab.org
Subject: Re: [Scilab-users] Toolboxes startup


Is %toolboxes already used ? If so where is it documented ?

S.
Le 26/04/2021 ? 10:57, Cl?ment David a ?crit :
Hi all,

Thanks for the proposal Stephane, this is a good idea!

As a reminder, currently each toolbox is free to display anything at startup and the toolbox skeleton provides a default ?Start ? + TOOLBOX_NAME then display information that ease development (gateways, help and so on). Migrating to another display is only a matter of convention, for example by checking if the global %toolboxes variable is available than do not display anything.

Cl?ment

From: users <users-bounces at lists.scilab.org><mailto:users-bounces at lists.scilab.org> On Behalf Of St?phane Mottelet
Sent: Monday, April 26, 2021 9:42 AM
To: Users mailing list for Scilab <users at lists.scilab.org><mailto:users at lists.scilab.org>
Subject: [Scilab-users] Toolboxes startup


Hi all,

I just made available for macOS and Linux the toolboxes stixbox depends upon for macOS (distfun and linalg) and my remark is that when a lot of modules are loaded at startup then the output can become very long and sometimes messy, since we don't impose a normalized output:

Scilab branch-6.1 (Apr 19 2021, 23:19:29)

Start Distfun

Start Helptbx

Start Specfun

Start Makematrix

Start Apifun
    Load macros
    Type "help apifun_overview" for a quick start.

Start Linalg

Start Stixbox

I would rather expect something like:



Scilab branch-6.1 (Apr 19 2021, 23:19:29)

Start modules: Distfun, Helptbx, Specfun, Makematrix, Apifun, Linalg, Stixbox.

-->

The verbosity level of the output (with the above default)  could be defined in user preferences, and checked in module startup script in order to output the required amount of information.

That's just a propostion to be discussed, of course.

S.

--

St?phane Mottelet

Ing?nieur de recherche

EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable

D?partement G?nie des Proc?d?s Industriels

Sorbonne Universit?s - Universit? de Technologie de Compi?gne

CS 60319, 60203 Compi?gne cedex

Tel : +33(0)344234688

http://www.utc.fr/~mottelet<https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/www.utc.fr/~mottelet>



_______________________________________________

users mailing list

users at lists.scilab.org<mailto:users at lists.scilab.org>

https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users

--

St?phane Mottelet

Ing?nieur de recherche

EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable

D?partement G?nie des Proc?d?s Industriels

Sorbonne Universit?s - Universit? de Technologie de Compi?gne

CS 60319, 60203 Compi?gne cedex

Tel : +33(0)344234688

http://www.utc.fr/~mottelet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20210426/4b3bc29a/attachment.htm>

From sgougeon at free.fr  Mon Apr 26 12:38:51 2021
From: sgougeon at free.fr (Samuel Gougeon)
Date: Mon, 26 Apr 2021 12:38:51 +0200
Subject: [Scilab-users] Toolboxes startup
In-Reply-To: <f1cd304c-2a9c-bb87-6213-d50be10b90c8@utc.fr>
References: <f1cd304c-2a9c-bb87-6213-d50be10b90c8@utc.fr>
Message-ID: <b85299ec-de54-4477-dfa2-c76157623207@free.fr>

Hello,

Le 26/04/2021 ? 09:41, St?phane Mottelet a ?crit?:
>
> Hi all,
>
> I just made available for macOS and Linux the toolboxes stixbox 
> depends upon for macOS (distfun and linalg) and my remark is that when 
> a lot of modules are loaded at startup then the output can become very 
> long and sometimes messy, since we don't impose a normalized output:
>
> *Scilab branch-6.1 (Apr 19 2021, 23:19:29)**
> *
>
> *Start Distfun**
> **
> **Start Helptbx**
> **
> **Start Specfun**
> **
> **Start Makematrix**
> **
> **Start Apifun**
> **??? Load macros**
> **??? Type "help apifun_overview" for a quick start.**
> **
> **Start Linalg**
> **
> **Start Stixbox*
>
> I would rather expect something like:
>
>
> *Scilab branch-6.1 (Apr 19 2021, 23:19:29)**
> *
>
> *Start modules: Distfun, Helptbx, Specfun, Makematrix, Apifun, Linalg, 
> Stixbox.*
>
> *--> *
>
> The verbosity level of the output (with the above default) could be 
> defined in user preferences, and checked in module startup script in 
> order to output the required amount of information.
>
> That's just a propostion to be discussed, of course.
>

Such a wish was reported 10 years ago as bug 6801 
<http://bugzilla.scilab.org/show_bug.cgi?id=6801>.

To me, the only way to overcome any mprintf or disp made in *.start 
files of external modules would be to become able to redirect the 
standard output to null (or anywhere else as in a file, as with diary, 
that forks the stream instead of redirecting it).
I don't think that %toolboxes aims to become public. atomsGetInstalled() 
and atomsGetLoaded() (and others) would likely be more suited to test 
the atoms status.

For contribution,
Samuel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20210426/2ddca5e7/attachment.htm>

From stephane.mottelet at utc.fr  Mon Apr 26 14:15:21 2021
From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=)
Date: Mon, 26 Apr 2021 14:15:21 +0200
Subject: [Scilab-users] Toolboxes startup
In-Reply-To: <b85299ec-de54-4477-dfa2-c76157623207@free.fr>
References: <f1cd304c-2a9c-bb87-6213-d50be10b90c8@utc.fr>
 <b85299ec-de54-4477-dfa2-c76157623207@free.fr>
Message-ID: <26a6b036-7a07-430d-be95-fab451a2257f@utc.fr>

Hello again,

Le 26/04/2021 ? 12:38, Samuel Gougeon a ?crit?:
> Hello,
>
> Le 26/04/2021 ? 09:41, St?phane Mottelet a ?crit?:
>>
>> Hi all,
>>
>> I just made available for macOS and Linux the toolboxes stixbox 
>> depends upon for macOS (distfun and linalg) and my remark is that 
>> when a lot of modules are loaded at startup then the output can 
>> become very long and sometimes messy, since we don't impose a 
>> normalized output:
>>
>> *Scilab branch-6.1 (Apr 19 2021, 23:19:29)**
>> *
>>
>> *Start Distfun**
>> **
>> **Start Helptbx**
>> **
>> **Start Specfun**
>> **
>> **Start Makematrix**
>> **
>> **Start Apifun**
>> **??? Load macros**
>> **??? Type "help apifun_overview" for a quick start.**
>> **
>> **Start Linalg**
>> **
>> **Start Stixbox*
>>
>> I would rather expect something like:
>>
>>
>> *Scilab branch-6.1 (Apr 19 2021, 23:19:29)**
>> *
>>
>> *Start modules: Distfun, Helptbx, Specfun, Makematrix, Apifun, 
>> Linalg, Stixbox.*
>>
>> *--> *
>>
>> The verbosity level of the output (with the above default) could be 
>> defined in user preferences, and checked in module startup script in 
>> order to output the required amount of information.
>>
>> That's just a propostion to be discussed, of course.
>>
>
> Such a wish was reported 10 years ago as bug 6801 
> <https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/bugzilla.scilab.org/show_bug.cgi?id=6801>.
>
> To me, the only way to overcome any mprintf or disp made in *.start 
> files of external modules would be to become able to redirect the 
> standard output to null (or anywhere else as in a file, as with diary, 
> that forks the stream instead of redirecting it).
> I don't think that %toolboxes aims to become public. 
> atomsGetInstalled() and atomsGetLoaded() (and others) would likely be 
> more suited to test the atoms status.
>
> For contribution,
> Samuel

Yeah that's the idea. But better than redirection of the standard 
output, all the stuff displayed in the .start file should go in a 
Journal, to which display methods can be associated. So instead of 
explicitely calling disp or mprinf, etc. the .start script should just 
add some stuff + associated verbosity level to the journal. What would 
be actually really displayed will depend on the level of the used 
Journal. That's the way the output is controlled in Ipopt, for example 
(but at the C++ level).

S.


>
>
> _______________________________________________
> users mailing list
> users at lists.scilab.org
> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users

-- 
St?phane Mottelet
Ing?nieur de recherche
EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable
D?partement G?nie des Proc?d?s Industriels
Sorbonne Universit?s - Universit? de Technologie de Compi?gne
CS 60319, 60203 Compi?gne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

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

From sgougeon at free.fr  Mon Apr 26 14:51:19 2021
From: sgougeon at free.fr (Samuel Gougeon)
Date: Mon, 26 Apr 2021 14:51:19 +0200
Subject: [Scilab-users] Toolboxes startup
In-Reply-To: <26a6b036-7a07-430d-be95-fab451a2257f@utc.fr>
References: <f1cd304c-2a9c-bb87-6213-d50be10b90c8@utc.fr>
 <b85299ec-de54-4477-dfa2-c76157623207@free.fr>
 <26a6b036-7a07-430d-be95-fab451a2257f@utc.fr>
Message-ID: <aa3b4d46-d613-4643-ab38-084a1b47a0f9@free.fr>

Le 26/04/2021 ? 14:15, St?phane Mottelet a ?crit?:
>> .../...
>>
>> Such a wish was reported 10 years ago as bug 6801 
>> <https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/bugzilla.scilab.org/show_bug.cgi?id=6801>.
>>
>> To me, the only way to overcome any mprintf or disp made in *.start 
>> files of external modules would be to become able to redirect the 
>> standard output to null (or anywhere else as in a file, as with 
>> diary, that forks the stream instead of redirecting it).
>> I don't think that %toolboxes aims to become public. 
>> atomsGetInstalled() and atomsGetLoaded() (and others) would likely be 
>> more suited to test the atoms status.
>>
>> For contribution,
>> Samuel
>
> Yeah that's the idea. But better than redirection of the standard 
> output, all the stuff displayed in the .start file should go in a 
> Journal, to which display methods can be associated. So instead of 
> explicitely calling disp or mprinf, etc. the .start script should just 
> add some stuff + associated verbosity level to the journal. What would 
> be actually really displayed will depend on the level of the used 
> Journal. That's the way the output is controlled in Ipopt, for example 
> (but at the C++ level).
>
We can't prevent authors to actually add and use mprintf or/and disp in 
their .start external file. They will be always free to use such 
statements? in the .start file template instanciated for their actual 
toolbox.
Now, if for instance a special syntax and parsing on .start comments is 
proposed, it could be comprehensive enough to be actually and 
exclusively used.
But, likely, only static information would be possible in comments. 
Formatted information like with printf placeholders could not be provided.

By the way, i am not sure that the most compact display should be the 
default mode. Out of the only module name, information displayed when 
loading might be important.

We tend to consider these displays as boring. But i am wondering that 
this is because loading can be quite long... unrelated to the display.
When working afterward in the session, any displayed matrix or handle 
gets most often immediately taller in the console than any initial 
autoloading information (that occurs only once).
So, to me, this is not really critical.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20210426/68620f8e/attachment.htm>

From sgougeon at free.fr  Mon Apr 26 15:15:10 2021
From: sgougeon at free.fr (Samuel Gougeon)
Date: Mon, 26 Apr 2021 15:15:10 +0200
Subject: [Scilab-users] Toolboxes startup
In-Reply-To: <aa3b4d46-d613-4643-ab38-084a1b47a0f9@free.fr>
References: <f1cd304c-2a9c-bb87-6213-d50be10b90c8@utc.fr>
 <b85299ec-de54-4477-dfa2-c76157623207@free.fr>
 <26a6b036-7a07-430d-be95-fab451a2257f@utc.fr>
 <aa3b4d46-d613-4643-ab38-084a1b47a0f9@free.fr>
Message-ID: <8e8ea9f1-ad01-5f4f-3b8d-181e32aee934@free.fr>

Le 26/04/2021 ? 14:51, Samuel Gougeon a ?crit?:
> Le 26/04/2021 ? 14:15, St?phane Mottelet a ?crit?:
>>> .../...
>>>
>>> Such a wish was reported 10 years ago as bug 6801 
>>> <https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/bugzilla.scilab.org/show_bug.cgi?id=6801>.
>>>
>>> To me, the only way to overcome any mprintf or disp made in *.start 
>>> files of external modules would be to become able to redirect the 
>>> standard output to null (or anywhere else as in a file, as with 
>>> diary, that forks the stream instead of redirecting it).
>>> I don't think that %toolboxes aims to become public. 
>>> atomsGetInstalled() and atomsGetLoaded() (and others) would likely 
>>> be more suited to test the atoms status.
>>>
>>> For contribution,
>>> Samuel
>>
>> Yeah that's the idea. But better than redirection of the standard 
>> output, all the stuff displayed in the .start file should go in a 
>> Journal, to which display methods can be associated. So instead of 
>> explicitely calling disp or mprinf, etc. the .start script should 
>> just add some stuff + associated verbosity level to the journal. What 
>> would be actually really displayed
>>
Whatever is the method -- redirection of stdout to a file or special 
diary? --, i am afraid that the analysis of contents vs verbosity would 
then be done only after completing the whole loading process.
This would prevent displaying information in a progressive way : 
immediately after loading macros, then after loading the documentation, 
etc... that will anyway be required in some occasion.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20210426/3f5d1603/attachment.htm>

From stephane.mottelet at utc.fr  Mon Apr 26 16:26:04 2021
From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=)
Date: Mon, 26 Apr 2021 16:26:04 +0200
Subject: [Scilab-users] Toolboxes startup
In-Reply-To: <8e8ea9f1-ad01-5f4f-3b8d-181e32aee934@free.fr>
References: <f1cd304c-2a9c-bb87-6213-d50be10b90c8@utc.fr>
 <b85299ec-de54-4477-dfa2-c76157623207@free.fr>
 <26a6b036-7a07-430d-be95-fab451a2257f@utc.fr>
 <aa3b4d46-d613-4643-ab38-084a1b47a0f9@free.fr>
 <8e8ea9f1-ad01-5f4f-3b8d-181e32aee934@free.fr>
Message-ID: <23905973-a3df-e3b2-f3af-fb6e162a1cff@utc.fr>


Le 26/04/2021 ? 15:15, Samuel Gougeon a ?crit?:
> Le 26/04/2021 ? 14:51, Samuel Gougeon a ?crit?:
>> Le 26/04/2021 ? 14:15, St?phane Mottelet a ?crit?:
>>>> .../...
>>>>
>>>> Such a wish was reported 10 years ago as bug 6801 
>>>> <https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/bugzilla.scilab.org/show_bug.cgi?id=6801>.
>>>>
>>>> To me, the only way to overcome any mprintf or disp made in *.start 
>>>> files of external modules would be to become able to redirect the 
>>>> standard output to null (or anywhere else as in a file, as with 
>>>> diary, that forks the stream instead of redirecting it).
>>>> I don't think that %toolboxes aims to become public. 
>>>> atomsGetInstalled() and atomsGetLoaded() (and others) would likely 
>>>> be more suited to test the atoms status.
>>>>
>>>> For contribution,
>>>> Samuel
>>>
>>> Yeah that's the idea. But better than redirection of the standard 
>>> output, all the stuff displayed in the .start file should go in a 
>>> Journal, to which display methods can be associated. So instead of 
>>> explicitely calling disp or mprinf, etc. the .start script should 
>>> just add some stuff + associated verbosity level to the journal. 
>>> What would be actually really displayed
>>>
> Whatever is the method -- redirection of stdout to a file or special 
> diary? --, i am afraid that the analysis of contents vs verbosity 
> would then be done only after completing the whole loading process.
> This would prevent displaying information in a progressive way : 
> immediately after loading macros, then after loading the 
> documentation, etc... that will anyway be required in some occasion.
>
A Journal is not a diary, neither a redirection to a file and there is 
no analysis of content for verbosity of user output. The verbosity is 
chosen when creating the journal. Here is a small example of what I meant:

function  j=journal(level, fun)
     j  =  mlist(["journal","level","displayfun"],level,fun)
endfunction

function  out=%journal_e(varargin)
     j  =  varargin($);
     level  =  varargin(1);
     if  level  <=  j.level
         j.displayfun(varargin(2:$-1));
     end
     out=[];
endfunction

function  loadmacros(jnl)
     jnl(3,"\t Warning library MD5SUM invalid 
abf4bffa3651a44fdd550e2dbffbe912\n")
     jnl(3,"\t-->Warning, macros are obsolete, rebuild lib please\n")
endfunction

function  loadhelp(jnl)
     jnl(3,"\t-->Help files traduction courtesy of W. Shakespeare\n")
endfunction

function  loaddemos(jnl)
     jnl(3,"\t-->TODO: awesome demo missing\n")
endfunction

function  start(jnl)
     jnl(1,"Start Apifun %s\n","0.4")
     jnl(2,"\tLoad macros\n")
     loadmacros(jnl)
     jnl(2,"\tLoad help\n")
     loadhelp(jnl)
     jnl(2,"\tLoad demos\n")
     loaddemos(jnl)
endfunction

console1  =  journal(1,mprintf);
console2  =  journal(2,mprintf);
console3  =  journal(3,mprintf);

mprintf("\n-----Level 1-----\n\n")
start(console1)

mprintf("\n-----Level 2-----\n\n")
start(console2)

mprintf("\n-----Level 3-----\n\n")
start(console3) -----Level 1----- Start Apifun 0.4 -----Level 2----- 
Start Apifun 0.4 Load macros Load help Load demos -----Level 3----- 
Start Apifun 0.4 Load macros Warning library MD5SUM invalid 
abf4bffa3651a44fdd550e2dbffbe912 --> Warning, macros are obsolete, 
rebuild lib please Load help --> Help files traduction courtesy of W. 
Shakespeare Load demos --> TODO: awesome demo missing S.

>
>
> _______________________________________________
> users mailing list
> users at lists.scilab.org
> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users

-- 
St?phane Mottelet
Ing?nieur de recherche
EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable
D?partement G?nie des Proc?d?s Industriels
Sorbonne Universit?s - Universit? de Technologie de Compi?gne
CS 60319, 60203 Compi?gne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20210426/998f7fcd/attachment.htm>

From stephane.mottelet at utc.fr  Wed Apr 28 18:15:41 2021
From: stephane.mottelet at utc.fr (=?UTF-8?Q?St=c3=a9phane_Mottelet?=)
Date: Wed, 28 Apr 2021 18:15:41 +0200
Subject: [Scilab-users] Toolboxes startup
In-Reply-To: <23905973-a3df-e3b2-f3af-fb6e162a1cff@utc.fr>
References: <f1cd304c-2a9c-bb87-6213-d50be10b90c8@utc.fr>
 <b85299ec-de54-4477-dfa2-c76157623207@free.fr>
 <26a6b036-7a07-430d-be95-fab451a2257f@utc.fr>
 <aa3b4d46-d613-4643-ab38-084a1b47a0f9@free.fr>
 <8e8ea9f1-ad01-5f4f-3b8d-181e32aee934@free.fr>
 <23905973-a3df-e3b2-f3af-fb6e162a1cff@utc.fr>
Message-ID: <0cb38369-e177-183d-f414-7ad8d65493dd@utc.fr>

So, did you understand the concept of a journal ?

S.

Le 26/04/2021 ? 16:26, St?phane Mottelet a ?crit?:
>
>
> Le 26/04/2021 ? 15:15, Samuel Gougeon a ?crit?:
>> Le 26/04/2021 ? 14:51, Samuel Gougeon a ?crit?:
>>> Le 26/04/2021 ? 14:15, St?phane Mottelet a ?crit?:
>>>>> .../...
>>>>>
>>>>> Such a wish was reported 10 years ago as bug 6801 
>>>>> <https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/bugzilla.scilab.org/show_bug.cgi?id=6801>.
>>>>>
>>>>> To me, the only way to overcome any mprintf or disp made in 
>>>>> *.start files of external modules would be to become able to 
>>>>> redirect the standard output to null (or anywhere else as in a 
>>>>> file, as with diary, that forks the stream instead of redirecting it).
>>>>> I don't think that %toolboxes aims to become public. 
>>>>> atomsGetInstalled() and atomsGetLoaded() (and others) would likely 
>>>>> be more suited to test the atoms status.
>>>>>
>>>>> For contribution,
>>>>> Samuel
>>>>
>>>> Yeah that's the idea. But better than redirection of the standard 
>>>> output, all the stuff displayed in the .start file should go in a 
>>>> Journal, to which display methods can be associated. So instead of 
>>>> explicitely calling disp or mprinf, etc. the .start script should 
>>>> just add some stuff + associated verbosity level to the journal. 
>>>> What would be actually really displayed
>>>>
>> Whatever is the method -- redirection of stdout to a file or special 
>> diary? --, i am afraid that the analysis of contents vs verbosity 
>> would then be done only after completing the whole loading process.
>> This would prevent displaying information in a progressive way : 
>> immediately after loading macros, then after loading the 
>> documentation, etc... that will anyway be required in some occasion.
>>
> A Journal is not a diary, neither a redirection to a file and there is 
> no analysis of content for verbosity of user output. The verbosity is 
> chosen when creating the journal. Here is a small example of what I meant:
>
> function  j=journal(level, fun)
>      j  =  mlist(["journal","level","displayfun"],level,fun)
> endfunction
>
> function  out=%journal_e(varargin)
>      j  =  varargin($);
>      level  =  varargin(1);
>      if  level  <=  j.level
>          j.displayfun(varargin(2:$-1));
>      end
>      out=[];
> endfunction
>
> function  loadmacros(jnl)
>      jnl(3,"\t Warning library MD5SUM invalid 
> abf4bffa3651a44fdd550e2dbffbe912\n")
>      jnl(3,"\t-->Warning, macros are obsolete, rebuild lib please\n")
> endfunction
>
> function  loadhelp(jnl)
>      jnl(3,"\t-->Help files traduction courtesy of W. Shakespeare\n")
> endfunction
>
> function  loaddemos(jnl)
>      jnl(3,"\t-->TODO: awesome demo missing\n")
> endfunction
>
> function  start(jnl)
>      jnl(1,"Start Apifun %s\n","0.4")
>      jnl(2,"\tLoad macros\n")
>      loadmacros(jnl)
>      jnl(2,"\tLoad help\n")
>      loadhelp(jnl)
>      jnl(2,"\tLoad demos\n")
>      loaddemos(jnl)
> endfunction
>
> console1  =  journal(1,mprintf);
> console2  =  journal(2,mprintf);
> console3  =  journal(3,mprintf);
>
> mprintf("\n-----Level 1-----\n\n")
> start(console1)
>
> mprintf("\n-----Level 2-----\n\n")
> start(console2)
>
> mprintf("\n-----Level 3-----\n\n")
> start(console3) -----Level 1----- Start Apifun 0.4 -----Level 2----- 
> Start Apifun 0.4 Load macros Load help Load demos -----Level 3----- 
> Start Apifun 0.4 Load macros Warning library MD5SUM invalid 
> abf4bffa3651a44fdd550e2dbffbe912 --> Warning, macros are obsolete, 
> rebuild lib please Load help --> Help files traduction courtesy of W. 
> Shakespeare Load demos --> TODO: awesome demo missing S.
>
>>
>>
>> _______________________________________________
>> users mailing list
>> users at lists.scilab.org
>> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users
> -- 
> St?phane Mottelet
> Ing?nieur de recherche
> EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable
> D?partement G?nie des Proc?d?s Industriels
> Sorbonne Universit?s - Universit? de Technologie de Compi?gne
> CS 60319, 60203 Compi?gne cedex
> Tel : +33(0)344234688
> http://www.utc.fr/~mottelet
>
> _______________________________________________
> users mailing list
> users at lists.scilab.org
> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users

-- 
St?phane Mottelet
Ing?nieur de recherche
EA 4297 Transformations Int?gr?es de la Mati?re Renouvelable
D?partement G?nie des Proc?d?s Industriels
Sorbonne Universit?s - Universit? de Technologie de Compi?gne
CS 60319, 60203 Compi?gne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

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

From fmiyara at fceia.unr.edu.ar  Thu Apr 29 04:53:11 2021
From: fmiyara at fceia.unr.edu.ar (Federico Miyara)
Date: Wed, 28 Apr 2021 23:53:11 -0300
Subject: [Scilab-users] plot2d3()
In-Reply-To: <3b8c6824-f1b6-61b7-fbf6-c400c5f2a33e@free.fr>
References: <4975d334-413e-517b-9e3f-35e66033e143@fceia.unr.edu.ar>
 <3b8c6824-f1b6-61b7-fbf6-c400c5f2a33e@free.fr>
Message-ID: <40c2246c-1db2-571b-38c8-fc82451bf265@fceia.unr.edu.ar>


Samuel,

>>
>
> Nice plot (a Power Spectrum Density after applying an open window()..? 
> :-))
>

Actually, it is the FFT of a short tone burst (completely open, boxcar 
window :) ) with thrice its length zero-padding


> I see two issues with this trial:
>
>   * setting y_ticks labels by hand cancels the auto_ticking mode for
>     ordinates, if we resize the graphic window
>   * The y value on datatips becomes wrong
>

This is true, I just needed it to export once to SVG so I ensured the 
desired size before actually running the workaround (which, by the way I 
mproved to avoid having to enter the values by hand)

> In the meantime, here is another possible workaround, that is both 
> auto_ticking and with correct datatiped values:
> // Raw data [n,  ybase]  =  (10,  -12);
> y  =  ybase  +  9*grand(1,n,"def");
> // Actual data y  =  [ybase*ones(y);  y  ;  ybase*ones(y)];
> x  =  (1:n)  .*.  [1  1  1];
> // Plotting clf,  plot(x(:),  y(:),  "-o")
> set(gce().children,  "mark_stride",3,  "mark_offset",1);
>

This seems a very good workaround! Probably it would be better if 
drawing first the lines and then the circles only for the original data.

Thanks!

Federico


-- 
El software de antivirus Avast ha analizado este correo electr?nico en busca de virus.
https://www.avast.com/antivirus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20210428/e9ba68a1/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bjohlbeipdpbnclh.png
Type: image/png
Size: 10483 bytes
Desc: not available
URL: <https://lists.scilab.org/pipermail/users/attachments/20210428/e9ba68a1/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lfignlgimicaeben.png
Type: image/png
Size: 10469 bytes
Desc: not available
URL: <https://lists.scilab.org/pipermail/users/attachments/20210428/e9ba68a1/attachment-0001.png>