Re: [Scilab-users] Fix of bug #4953 (behavior of clean() with %inf)

[Samuel Gougeon]

Hello,

Le 28/06/2018 à 17:41, Stéphane Mottelet a écrit :

Hello all,

A fix proposal is under review @ 
https://codereview.scilab.org/#/c/20204/2, in order to consider the 
actual behavior of clean() when the argument has some infinite values:


In Scilab 6.0.1:


--> clean([%inf 1])
 ans  =

   0.   0.

By a argument of continuity, since

--> clean([1.79e308 1])
 ans  =

   1.79D+308   0.

the fixed behavior would be

--> clean([%inf 1])
 ans  =

   Inf   0.

Please give your opinion if you feel concerned.



IMO, setting to  zero all finite values of an array as soon as one of 
them is %inf is abusive and counter-productive.

Let
--> A = 10.^grand(4,4,"unf",-10,5); A(2,2) = %inf;
 A  =
   4.3699094   0.014   0.67061 6.095D-09
   6503.1214   Inf 4.5767598   0.0006926
   20.907407   1.5687011   2.749D-08   0.0029886
   129.70759   1.102D-10   0.4564722   40.621591

The proposed implementation would lead to

--> clean(A)//  A(abs(A)~=%inf & A==A)=0
 ans  =
   0.   0.0.   0.
   0.   Inf   0.   0.
   0.   0.0.   0.
   0.   0.0.   0.

With that, no more processing or linear algebra can be done, just 
getting exclusively some zeros, %inf, and Nan.
The same can be done with A(abs(A)~=%inf) = 0. This is a poor and 
stopping result.


Instead, cleaning values *with respect to the max |finite| one* will yield

--> clean(A) // B = A; A(abs(A)An array may have all its |values| around and below the max 1.79D+308 by 
some small factors, then arithmetic can still be possible with them, and 
%inf will still be a special value with a special processing.


This is why i do not agree with the proposed clean() update.

Best regards
Samuel


___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] Simple Date & Time Plotting

[Samuel Gougeon]

Le 20/07/2018 à 18:33, Samuel Gougeon a écrit :


My PS meant that there is no equivalence of gcf().resizefcn for 
zooming. So, recalling labxdtv() must be done /intentionnally, by 
hand,/ after zooming or spanning an axes.


Please read "zooming and *p*anning"




.../...

I find quite important that the graduation on the figure is still 
relying on datenum, as it is the right underlying numerical format to 
show date time information.



IMO, the input format should be customizable though an input option :

  * absolute formats : unix time, julian days, excel time, ... +
linear (s, days, s..) vs vectorized (datenum, etc)
  * relative formats (without origin) : in s, mn, h, days



May be speaking about absolute/relative *scales*, in a linearized or 
vectorized *format* would be clearer.



___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] Simple Date & Time Plotting

[Samuel Gougeon]

Le 20/07/2018 à 15:27, CHEZE David 227480 a écrit :


Hi samuel,

Thank you for your prompt comments, I fully agree that it’s not 
trivial to have a really nice function with the features you pointed out.


I would find hardly acceptable, from common excel coming users point 
of view, that Scilab can’t offer at least a raw feature to manage this 
very common task when processing data with timestamps over weeks, 
months, years therefore I proposed this raw approach.




The problem with proposing an official function in a only raw version is 
that it becomes a commitment.
Then changing it is more difficult because backcompatibility issues must 
be avoided or/and handled.
This is why, to me, it is better to propose such a version on the 
fileexchange, that is more informal.




An extra comments about the function labxdtv:labxdtv uses the 
automatic x-ticks locations caluclated from datenum values and convert 
into datevec-Like formats eg YY/MM/DD , MM/DD.hh, DD.hh:mm, hh:mm:ss 
according to the max span of the level of zoom in the current display.


If the axis is zoomed or the window size changed, call again labxdtv 
so that it re-graduates this x-axis (according to datenum values) and 
convert the new x-ticks into appropriate datevec and automatic choice 
of the format YY/MM/DD , MM/DD.hh, DD.hh:mm, hh:mm:ss according to the 
max span of the x-axis.




My PS meant that there is no equivalence of gcf().resizefcn for zooming. 
So, recalling labxdtv() must be done /intentionnally, by hand,/ after 
zooming or spanning an axes.




In your first comment, I ‘m not sure to get your point about :

mailbox:///C:/Users/Samuel/AppData/Roaming/Thunderbird/Profiles/dm9cexq8.default/Mail/Local%20Folders/_Scilab.sbd/users@?number=97209056=quotebody=1.1.2=image001.png

  * there should not be any shift 17 => 18 => 19. This means that
subticking must be completely customized, with a polyline
superimposed to the axis, since it is irregular.

In the above example 17, 18 and 19 are years , not days so it’s rather 
normal display.




My fault! As aa/bb/cc is in french the common format for dd/mm/yy, I 
paid attention only to the first aa/bb, taking them for days/months. 
Beside this misunderstanding, the discussion and remarks remain the 
same: then we could rather expect majors ticks always on 1st of some 
months, and smart subticks accordingly.



At this level of zoom we have YY/MM/DD but if you manually zoom and 
change the window size and call again labxdtv() afterwards, you may 
obtain the following, which allow to see when you :


And zoom-in further around 2017 October, then labxdtv() called you may 
quickly obtain the figure below, so you can read directly that the 
format is automatically adapted to “MM/DD.HH”  It’s not so common 
format but acceptable to analyze the data on the fly.




Usual commonly spread formats are quite known and shared.
AFAIK, the most standard one is -MM-DD HH:MN:SS., with possible 
truncation.



.../...

I find quite important that the graduation on the figure is still 
relying on datenum, as it is the right underlying numerical format to 
show date time information.



IMO, the input format should be customizable though an input option :

 * absolute formats : unix time, julian days, excel time, ... + linear
   (s, days, s..) vs vectorized (datenum, etc)
 * relative formats (without origin) : in s, mn, h, days

Best regards
Samuel

___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] Simple Date & Time Plotting

[CHEZE David 227480]

Hi samuel,

Thank you for your prompt comments, I fully agree that it's not trivial to have 
a really nice function with the features you pointed out.
I would find hardly acceptable, from common excel coming users point of view, 
that Scilab can't offer at least a raw feature to manage this very common task 
when processing data with timestamps over weeks, months, years therefore I 
proposed this raw approach.

An extra comments about the function labxdtv: labxdtv uses the automatic 
x-ticks locations caluclated from datenum values and convert into datevec-Like 
formats eg YY/MM/DD , MM/DD.hh, DD.hh:mm, hh:mm:ss according to the max span of 
the level of zoom in the current  display.
If the axis is zoomed or the window size changed, call again labxdtv so that it 
re-graduates this x-axis (according to datenum values) and convert the new 
x-ticks into appropriate datevec and automatic choice of the format YY/MM/DD , 
MM/DD.hh, DD.hh:mm, hh:mm:ss according to the max span of the x-axis.


In your first comment, I 'm not sure to get your point about :
[cid:image001.png@01D4203B.B4E40A30]

  *   there should not be any shift 17 => 18 => 19. This means that subticking 
must be completely customized, with a polyline superimposed to the axis, since 
it is irregular.
In the above example 17, 18 and 19 are years , not days so it's rather normal 
display. At this level of zoom we have YY/MM/DD but if you manually zoom and 
change the window size and call again labxdtv() afterwards, you may obtain the 
following, which allow to see when you :
[cid:image002.png@01D4203E.390F6B40]
And zoom-in further around 2017 October, then labxdtv() called you may quickly 
obtain the figure below, so you can read directly that the format is 
automatically adapted to "MM/DD.HH"  It's not so common format but acceptable 
to analyze the data on the fly.
[cid:image004.png@01D4203E.390F6B40]
I find quite important that the graduation on the figure is still relying on 
datenum, as it is the right underlying numerical format to show date time 
information.

Cheers,

David

___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] Function "locate" for 3d graphs

[Samuel Gougeon]

Le 20/07/2018 à 12:20, Izabela Wójcik-Grząba a écrit :
As Samuel GOUGEON suggested I reported a wish to upgrede function 
locate for 3d graphs on Bugzilla:


https://bugzilla.scilab.org/show_bug.cgi?id=15674


This could be implemented for Scilab 6.1 after the commit fixing 
locate() in 2D, pending for 80 days still without review is validated, 
integrated in Scilab 6.0.2, and transfered to Scilab 6.1.



___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] Simple Date & Time Plotting

[Samuel Gougeon]

Le 20/07/2018 à 14:40, Samuel Gougeon a écrit :

Le 20/07/2018 à 12:20, David Chèze a écrit :

Hi Pat and all,

I was looking for similar simple feature for plotting time series with
readable date time format and I can share an intermediate approach to update
the x-ticks with a call to function labxdtv(), cf linked file  labxdtv.sci
   
There's no callback function, the function is called after the plot action

and after every changes in windows size or zoom level : initial plot is like
plot2(dtnm,Donnees), with dtnm a vector of datenum values and Donnees a
matrix of related data to plot. After the figure is plot at first time or
after every changes in windows size or level of zoom, call again labxdtv, it
regraduates automatically the x-axis according to the datanum span and
convert the datenum in readable date time vector format (auto_ticks are set
to on in the function).

Would be great to have in scilab a more powerful/flexible builtin
function... :)


Sure, but it's a rather complex function. The need was reported 10 
years ago @ http://bugzilla.scilab.org/6228
labxdtv() gives a rather raw idea of the task. On it's showcase 
example, ticks are every 3 months over one year:


But they are not nice:

  * At this scale, major ticks should rather be on the 1st of months.
  * there should not be any shift 17 => 18 => 19. This means that
subticking must be completely customized, with a polyline
superimposed to the axis, since it is irregular.
  * here there is only one subtick instead of rather two (for an
automatic handling)



Even better, subticks could match weeks, for instance on each monday 
00:00:00 (as the default, or as a subticking option).
This means that the first subtick after a major on the 1st at 00:00:00 
will be shifted wrt its leading major, with a shift not equal from a 
major to the next.
Here, having 11-12 weekly subticks between 2 major ticks would be the 
right subticking scale.
If we use some subticks every 10 days instead of weekly ones, there will 
be also some irregularities for 28|29|31-days-long months for setting 
the last subtick.
All these details -- and others -- must be properly processed to really 
have a workable function.


___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] Simple Date & Time Plotting

[Samuel Gougeon]

Le 20/07/2018 à 12:20, David Chèze a écrit :

Hi Pat and all,

I was looking for similar simple feature for plotting time series with
readable date time format and I can share an intermediate approach to update
the x-ticks with a call to function labxdtv(), cf linked file  labxdtv.sci

There's no callback function, the function is called after the plot action
and after every changes in windows size or zoom level : initial plot is like
plot2(dtnm,Donnees), with dtnm a vector of datenum values and Donnees a
matrix of related data to plot. After the figure is plot at first time or
after every changes in windows size or level of zoom, call again labxdtv, it
regraduates automatically the x-axis according to the datanum span and
convert the datenum in readable date time vector format (auto_ticks are set
to on in the function).

Would be great to have in scilab a more powerful/flexible builtin
function... :)


Sure, but it's a rather complex function. The need was reported 10 years 
ago @ http://bugzilla.scilab.org/6228
labxdtv() gives a rather raw idea of the task. On it's showcase example, 
ticks are every 3 months over one year:


But they are not nice:

 * At this scale, major ticks should rather be on the 1st of months.
 * there should not be any shift 17 => 18 => 19. This means that
   subticking must be completely customized, with a polyline
   superimposed to the axis, since it is irregular.
 * here there is only one subtick instead of rather two (for an
   automatic handling)
 * etc..

So yes, a powerful function formating dates would be nice. But 
implementing a really nice and useful one is definitely not trivial.


Cheers
Samuel

PS : there is presently no event triggered by zooming or panning an axes.

___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] How to keep figure active with x_mdialog window open?

[Izabela Wójcik-Grząba]

Thank you for the explanation and suggestions. I will have to put my 
x_mdialog into another graphic window.


Iza




W dniu 19.07.2018 20:43, Samuel Gougeon napisał(a):

Hello Izabela,

What you wish to do is not possible with x_mdialog(), that is a modal
dialog: it pauses everything else until the dialog is quit.

To do what you want, it's possible to create your own dialog box based
on uicontrol("style", "edit") or other interactive components.
Basically, you may have a look at the demos demo_gui(): GUI =>
Uicontrosl1 or Uicontrols2. Both have a "View-code" link in their menu
bar.

Best regards
Samuel

Le 19/07/2018 à 14:13, Izabela Wójcik-Grząba a écrit :

Hi all,

I have another problem. In my program I create an initial plot which 
is a basis for the input implemented by x_mdialog command. The problem 
is that when the x_mdialog window pops up the figure window bocomes 
inactive. It means that I can't zoom or rotate the plot which is 
necessary to correctly enter the data to x_mdialog matrix. Is there 
any solution to this? Is it possible to keep the figure active when 
other windows occur?


Thanks in advance,
Iza
___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users



___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] Function "locate" for 3d graphs

[Izabela Wójcik-Grząba]

As Samuel GOUGEON suggested I reported a wish to upgrede function locate 
for 3d graphs on Bugzilla:


https://bugzilla.scilab.org/show_bug.cgi?id=15674

Iza
___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] Simple Date & Time Plotting

[David Chèze]

Hi Pat and all,

I was looking for similar simple feature for plotting time series with
readable date time format and I can share an intermediate approach to update
the x-ticks with a call to function labxdtv(), cf linked file  labxdtv.sci
  
There's no callback function, the function is called after the plot action
and after every changes in windows size or zoom level : initial plot is like
plot2(dtnm,Donnees), with dtnm a vector of datenum values and Donnees a
matrix of related data to plot. After the figure is plot at first time or
after every changes in windows size or level of zoom, call again labxdtv, it
regraduates automatically the x-axis according to the datanum span and
convert the datenum in readable date time vector format (auto_ticks are set
to on in the function).

Would be great to have in scilab a more powerful/flexible builtin
function... :) 

David



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

Re: [Scilab-users] Changing polyline properties in param3d1

[Izabela Wójcik-Grząba]

I'm glad that my problem can help to improve Scilab and looking forward 
to use the new version :-)


Iza




W dniu 19.07.2018 23:57, Samuel Gougeon napisał(a):

Le 19/07/2018 à 21:30, Samuel Gougeon a écrit :


Le 18/07/2018 à 15:19, Izabela Wójcik-Grząba a écrit :


Hello,

I am looking for an elegant and simple way to manage with changing
properties of polylines in a param3d1 plot. The problem is that
sometimes (in case of specific data) there is only one polyline to
draw but in most cases there are many polylines. By now I solved
this problem by using "if" statement like below:

param3d1(X,Y,Z);

if size(X,'c')==1 then
gce().polyline_style=4;
gce().thickness=2;
gce().foreground=32;
else
gce().children.polyline_style=4;
gce().children.thickness=2;
gce().children.foreground=32;
end


You are right: it would be preferable to get always the same
graphical structure, whatever is the number of plotted curves, as it
is the case with plot2d():

--> plot2d(1:10)
--> gce()
ans  =

Handle of type "Compound" with properties:
==
parent: Axes
children: "Polyline"
visible = "on"
user_data = []
tag = ""

--> clf, plot2d([1:10 ; 1:10]')
--> gce()
ans  =
Handle of type "Compound" with properties:
==
parent: Axes
children: ["Polyline";"Polyline"]
visible = "on"
user_data = []
tag = ""

So, the same stable architecture shall be reached for param3d1().
Such a change won't be back-compatible, but searching for "param3d1"
in all existing programs and updating them will be easy.
This change can be proposed for Scilab 6.1.


This bug about param3d1() unstable hierarchy is now reported there
[1].



Links:
--
[1] http://bugzilla.scilab.org/show_bug.cgi?id=15671
___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

[Scilab-users] Settings for page scrolling with mouse wheel

[lupo]

Hello dear Scilab team!

Since Scilab 6 one single scroll with the mouse wheel pages up/down a
complete page in the scilab help and in scinotes. I am asking myself if one
can change this behaviour and change it to the number of lines that should
be scrolled (like in the windows mouse settings).

Kind regards
Lukas




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