From francois.granade at scilab-enterprises.com Thu Oct 1 18:37:10 2015 From: francois.granade at scilab-enterprises.com (=?iso-8859-1?Q?Fran=E7ois_Granade?=) Date: Thu, 1 Oct 2015 18:37:10 +0200 Subject: [Scilab-Dev] Input requested on a few behaviors for Scilab 6... Message-ID: <50B673B3-DCE1-4DC9-B077-6FE9BC831761@scilab-enterprises.com> Hi all, We're working on Scilab 6, as you may know :); part of the goal is to correct some weird behaviors of Scilab. We're thinking of changing a few inconvenient/inconsistent behaviors. And before we implement, and release them, we'd like to make sure that: a) the new solution is better (we're quite sure, but not 100%), and b) the change will not cause too many hassle for existing users. So your feedback is really welcome on the following three points... Thank you in advance, For the Scilab team, Fran?ois Granade 1. set ieee(2) by default instead of ieee(0) ----------- This would raise neither a warning, nor an error, when running invalid numerical operation (eg. divide by zero), but instead use NaN as often as possible. This would be consistent with matlab and other platforms; but it could break existing scripts that rely on this behavior This would only change the *default* behavior: it would still be possible to override is by simply adding "ieee(0)" at a beginning of a script, or in "ini" file for the user. 2. Make operations with the empty matrix more consistent ----------- In particular, change: 1 + [] to return [] in 6.0, instead of 1 in 5.5.2; and same for 1 - []. This would be more consistent with other operations ( 1*[], 1.^[] ...). More generally: A + [] would return [] for A of any Scilab basic type; same for other binary numerical operators. It would avoid weird behaviors with using find() to replace values, for example in this snippet: A = ones(1, 5); idx = find( A > 3 ); A(idx + 1) = 2; currently change A(1) to 2 (in 5.5.2), which is very strange. It even creates a bug (kudos to Alain Lamy for finding it): idx = find(B > 0) B(idx + 1) = B(idx) will remove B(1) iff B is all negative in 5.5.2. 3. Clarify "a:b:c" ranges when one of a, b or c is infinite (%inf) or Not a Number (%nan); or when b is 0. -------------- Currently there are many inconsistencies in some cases, for example: -%inf:1:%inf // returns %nan 2:0:5 // return [] // but: %nan:1:5 // returns %nan In 6.0, we're thinking of fixing things according to the following rules: i) if start or step or end is %inf or %nan => return [] ii) step == 0 => return [] iii) start < end && step < 0 => return [] iv) start > end && step > 0 => return [] v) normal computation otherwise From Serge.Steer at inria.fr Thu Oct 1 19:05:29 2015 From: Serge.Steer at inria.fr (Serge Steer) Date: Thu, 01 Oct 2015 19:05:29 +0200 Subject: [Scilab-Dev] Input requested on a few behaviors for Scilab 6... In-Reply-To: <50B673B3-DCE1-4DC9-B077-6FE9BC831761@scilab-enterprises.com> References: <50B673B3-DCE1-4DC9-B077-6FE9BC831761@scilab-enterprises.com> Message-ID: <560D67D9.1050208@inria.fr> Le 01/10/2015 18:37, Fran?ois Granade a ?crit : > Hi all, > > We're working on Scilab 6, as you may know :); part of the goal is to correct some weird behaviors of Scilab. We're thinking of changing a few inconvenient/inconsistent behaviors. And before we implement, and release them, we'd like to make sure that: > a) the new solution is better (we're quite sure, but not 100%), and > b) the change will not cause too many hassle for existing users. > > So your feedback is really welcome on the following three points... > > Thank you in advance, > > For the Scilab team, > Fran?ois Granade > > > 1. set ieee(2) by default instead of ieee(0) > ----------- > > This would raise neither a warning, nor an error, when running invalid numerical operation (eg. divide by zero), but instead use NaN as often as possible. This would be consistent with matlab and other platforms; but it could break existing scripts that rely on this behavior > > This would only change the *default* behavior: it would still be possible to override is by simply adding "ieee(0)" at a beginning of a script, or in "ini" file for the user. I my opinion it should be better to keep the current behavior. When an algorithm produces an inf or a Nan it is very often due to an algorithm defaut and it is convenient to be informed as soon as possible. If one really want to produce nan or inf it is safer to toggle the ieee mode locally. One improvement should be to make the ieee mode change only for the active function and the called ones instead of changing the global behavior. > > 2. Make operations with the empty matrix more consistent > ----------- > > In particular, change: > > 1 + [] > > to return [] in 6.0, instead of 1 in 5.5.2; and same for 1 - []. This would be more consistent with other operations ( 1*[], 1.^[] ...). > > More generally: > > A + [] > > would return [] for A of any Scilab basic type; same for other binary numerical operators. > > It would avoid weird behaviors with using find() to replace values, for example in this snippet: > A = ones(1, 5); > idx = find( A > 3 ); > A(idx + 1) = 2; > currently change A(1) to 2 (in 5.5.2), which is very strange. It even creates a bug (kudos to Alain Lamy for finding it): > idx = find(B > 0) > B(idx + 1) = B(idx) > will remove B(1) iff B is all negative in 5.5.2. > > > 3. Clarify "a:b:c" ranges when one of a, b or c is infinite (%inf) or Not a Number (%nan); or when b is 0. > -------------- > > Currently there are many inconsistencies in some cases, for example: > > -%inf:1:%inf // returns %nan > 2:0:5 // return [] > // but: > %nan:1:5 // returns %nan > > In 6.0, we're thinking of fixing things according to the following rules: > > i) if start or step or end is %inf or %nan => return [] > ii) step == 0 => return [] > iii) start < end && step < 0 => return [] > iv) start > end && step > 0 => return [] for i and ii may be it should be better to throw an error. without the stacksize limit 1:1e-30:2 will create a huge array , it should be useful to add a limit iii and iv is the current behavior nothing has to be changed > v) normal computation otherwise > > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev > From sgougeon at free.fr Thu Oct 1 22:06:52 2015 From: sgougeon at free.fr (Samuel Gougeon) Date: Thu, 1 Oct 2015 22:06:52 +0200 Subject: [Scilab-Dev] Input requested on a few behaviors for Scilab 6... In-Reply-To: <50B673B3-DCE1-4DC9-B077-6FE9BC831761@scilab-enterprises.com> References: <50B673B3-DCE1-4DC9-B077-6FE9BC831761@scilab-enterprises.com> Message-ID: <560D925C.3000709@free.fr> Hello Fran?ois, Thanks for calling for comments: Le 01/10/2015 18:37, Fran?ois Granade a ?crit : > .../... > 1. set ieee(2) by default instead of ieee(0) +1: http://bugzilla.scilab.org/11527 > .../... > 2. Make operations with the empty matrix more consistent * Discussion also @ http://bugzilla.scilab.org/12661 * See also: http://bugzilla.scilab.org/2432 > .../... > > 3. Clarify "a:b:c" ranges when one of a, b or c is infinite (%inf) or Not a Number (%nan); or when b is 0. > -------------- > > Currently there are many inconsistencies in some cases, for example: > > -%inf:1:%inf // returns %nan > 2:0:5 // return [] > // but: > %nan:1:5 // returns %nan > > In 6.0, we're thinking of fixing things according to the following rules: > > i) if start or step or end is %inf or %nan => return [] > ii) step == 0 => return [] > iii) start < end && step < 0 => return [] > iv) start > end && step > 0 => return [] > v) normal computation otherwise What about this alternative?: By decreasing priority (read "else" at the end of each line): a) if stop is %nan => error b) if start or step is %nan => returns %nan c) = iii): if start < end && step < 0 => return [], even if start, step or stop is/are inf/-inf d) = iv): if start > end && step > 0 => return [], even if start, step or stop is/are inf/-inf e) if neither |start| nor |stop| are inf, && |step|==inf => return start f) if start or stop or both are inf or -inf => error, even when |step| is inf HTH Samuel Gougeon From sgougeon at free.fr Thu Oct 1 22:20:00 2015 From: sgougeon at free.fr (Samuel Gougeon) Date: Thu, 1 Oct 2015 22:20:00 +0200 Subject: [Scilab-Dev] Input requested on a few behaviors for Scilab 6... In-Reply-To: <560D925C.3000709@free.fr> References: <50B673B3-DCE1-4DC9-B077-6FE9BC831761@scilab-enterprises.com> <560D925C.3000709@free.fr> Message-ID: <560D9570.8030606@free.fr> Le 01/10/2015 22:06, Samuel Gougeon a ?crit : >> .../... >> >> 3. Clarify "a:b:c" ranges when one of a, b or c is infinite (%inf) or >> Not a Number (%nan); or when b is 0. >> .../.. > > What about this alternative?: > By decreasing priority (read "else" at the end of each line): > a) if stop is %nan => error > b) if start or step is %nan => returns %nan > c) = iii): if start < end && step < 0 => return [], even if start, > step or stop is/are inf/-inf > d) = iv): if start > end && step > 0 => return [], even if start, step > or stop is/are inf/-inf > e) if neither |start| nor |stop| are inf, && |step|==inf => return start . Actually, even if |start| is inf, returning start (so +/-inf) would be relevant. Updated proposal: a) if stop is %nan => error b) if start or step is %nan => returns %nan c) = iii): if start < end && step < 0 => return [], even if start, step or stop is/are inf/-inf d) = iv): if start > end && step > 0 => return [], even if start, step or stop is/are inf/-inf e) if|stop| ~= inf && |step|==inf => return start (even if it is +-inf) f) if start or stop or both are inf or -inf => error, even when |step| is inf g) otherwise: normal computation. Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Thu Oct 1 22:34:36 2015 From: sgougeon at free.fr (Samuel Gougeon) Date: Thu, 1 Oct 2015 22:34:36 +0200 Subject: [Scilab-Dev] Input requested on a few behaviors for Scilab 6... In-Reply-To: <560D9570.8030606@free.fr> References: <50B673B3-DCE1-4DC9-B077-6FE9BC831761@scilab-enterprises.com> <560D925C.3000709@free.fr> <560D9570.8030606@free.fr> Message-ID: <560D98DC.2060804@free.fr> Le 01/10/2015 22:20, Samuel Gougeon a ?crit : > .../... > a) if stop is %nan => error > b) if start or step is %nan => returns %nan . could be split into b1) if start is %nan => return %nan b2) if step is %nan => return start: the first element is well defined and could be returned. > > c) = iii): if start < end && step < 0 => return [], even if start, > step or stop is/are inf/-inf > d) = iv): if start > end && step > 0 => return [], even if start, step > or stop is/are inf/-inf > e) if|stop| ~= inf && |step|==inf => return start (even if it is +-inf) > f) if start or stop or both are inf or -inf => error, even when |step| > is inf > g) otherwise: normal computation. > > Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgougeon at free.fr Thu Oct 1 23:23:22 2015 From: sgougeon at free.fr (Samuel Gougeon) Date: Thu, 1 Oct 2015 23:23:22 +0200 Subject: [Scilab-Dev] Input requested on a few behaviors for Scilab 6... In-Reply-To: <50B673B3-DCE1-4DC9-B077-6FE9BC831761@scilab-enterprises.com> References: <50B673B3-DCE1-4DC9-B077-6FE9BC831761@scilab-enterprises.com> Message-ID: <560DA44A.8010401@free.fr> Le 01/10/2015 18:37, Fran?ois Granade a ?crit : > .../.. > 2. Make operations with the empty matrix more consistent > ----------- > > In particular, change: > > 1 + [] > > to return [] in 6.0, instead of 1 in 5.5.2; and same for 1 - []. +1 vote, whether it is possible to yield a warning each time that this case is met, for all releases 6.x.y < 6.2 Without warnings, many bugs hard to detect and fix would appear. Samuel Gougeon From sgougeon at free.fr Thu Oct 1 23:43:12 2015 From: sgougeon at free.fr (Samuel Gougeon) Date: Thu, 1 Oct 2015 23:43:12 +0200 Subject: [Scilab-Dev] Input requested on a few behaviors for Scilab 6... In-Reply-To: <560D98DC.2060804@free.fr> References: <50B673B3-DCE1-4DC9-B077-6FE9BC831761@scilab-enterprises.com> <560D925C.3000709@free.fr> <560D9570.8030606@free.fr> <560D98DC.2060804@free.fr> Message-ID: <560DA8F0.8090207@free.fr> Forgotten case step==0 is reintroduced: .../... a) if stop is %nan => error b) if start or step is %nan => returns %nan could be split into b1) if start is %nan => return %nan b2) if step is %nan => return start: the first element is well defined and could be returned. c) = iii): if start < end && step < 0 => return [], even if start, step or stop is/are inf/-inf d) = iv): if start > end && step > 0 => return [], even if start, step or stop is/are inf/-inf e) if |stop| ~= inf && |step|==inf => return start (even if it is +-inf) f) if start or stop or both are inf or -inf => error, even when |step| is inf g) if step==0: g1) if start~=stop => error g2) else => return start h) otherwise: normal computation. Sorry for the noise. SG From sgougeon at free.fr Fri Oct 2 00:36:59 2015 From: sgougeon at free.fr (Samuel Gougeon) Date: Fri, 2 Oct 2015 00:36:59 +0200 Subject: [Scilab-Dev] Input requested on a few behaviors for Scilab 6... In-Reply-To: <50B673B3-DCE1-4DC9-B077-6FE9BC831761@scilab-enterprises.com> References: <50B673B3-DCE1-4DC9-B077-6FE9BC831761@scilab-enterprises.com> Message-ID: <560DB58B.9070706@free.fr> Le 01/10/2015 18:37, Fran?ois Granade a ?crit : > .../... > > 2. Make operations with the empty matrix more consistent > ----------- > > In particular, change: > > 1 + [] > > to return [] in 6.0, instead of 1 in 5.5.2; and same for 1 - []. This would be more consistent with other operations ( 1*[], 1.^[] ...). > > More generally: > > A + [] > > would return [] for A of any Scilab basic type; same for other binary numerical operators. . Here is a debatable question: Are you considering this rule only whether A is scalar: 1 + [] == [] or as well whether A is a vector or matrix: [2 1 -3] + [] == [] ? This discussion started @ http://bugzilla.scilab.org/12661 It looks to be a hard one. From nicolas.fezans at gmail.com Fri Oct 2 09:30:40 2015 From: nicolas.fezans at gmail.com (Nicolas FEZANS) Date: Fri, 2 Oct 2015 09:30:40 +0200 Subject: [Scilab-Dev] Input requested on a few behaviors for Scilab 6... In-Reply-To: <560DB58B.9070706@free.fr> References: <50B673B3-DCE1-4DC9-B077-6FE9BC831761@scilab-enterprises.com> <560DB58B.9070706@free.fr> Message-ID: Hi, first on point 2) A) [1 2 3] + 1 (as a scalar) makes mathematically no sense but can be seen as some syntax sugar to avoid having users constantly writing things like: "A+scalar*ones(size(A))" B) [1 2 3] + [4 5] makes no sense and there is no clear way of understanding what the user wanted to do and actually in most cases this means that something went wrong earlier and that the matrices being added do not have the dimension that the user thought that would have at that stage. An error is certainly the right thing to do to prevent the code from throwing an error much later and forcing the user to search backwards. C) [] + 1 = [] makes sense to me as an extension of rule A) D) [2 1 -3] + [] is to my mind as wrong than B) and should not be allowed then on point 3) I agree with Serge: the sooner you get a feedback about an error the better. This even brings me to ask why not throwing a real error instead of falling back to %nan? I think the first thing to consider is that the sign of the step always need to match the sign of the difference end-start. If not that is clearly an error. %inf and %nan are also errors when talking about such ranges. Bringing answer like %nan or [] is such cases usually only make the program blow up some time later and that is not helpful. If someone really wants to make something very special, then he should be forced to specify it in his code, but the default behavior should (to my mind) be as safe, straightforward, and self-explaining as possible. I would however expect [1:0:1] to be [1] since this makes sense and could easily happen when computing bounds like this: "start:stepSize:start+NBsteps*stepSize" when NBsteps is set to 0 (I agree that this is not very elegant but it is very readable for a human being) If we would decide that [1:0:1] = [1] is OK, that would open the question of making a similar exception for %inf:0:%inf and for -%inf:0:-%inf . My opinion is however that with %inf or -%inf that would still be an error. Regards Nicolas On Fri, Oct 2, 2015 at 12:36 AM, Samuel Gougeon wrote: > Le 01/10/2015 18:37, Fran?ois Granade a ?crit : >> >> .../... >> >> 2. Make operations with the empty matrix more consistent >> ----------- >> >> In particular, change: >> >> 1 + [] >> >> to return [] in 6.0, instead of 1 in 5.5.2; and same for 1 - []. This >> would be more consistent with other operations ( 1*[], 1.^[] ...). >> >> More generally: >> >> A + [] >> >> would return [] for A of any Scilab basic type; same for other binary >> numerical operators. > > . > Here is a debatable question: Are you considering this rule only whether A > is scalar: 1 + [] == [] > or as well whether A is a vector or matrix: [2 1 -3] + [] == [] > ? This discussion started @ http://bugzilla.scilab.org/12661 > It looks to be a hard one. > > > > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev From antoine.monmayrant+scilab at laas.fr Fri Oct 2 09:52:50 2015 From: antoine.monmayrant+scilab at laas.fr (antoine.monmayrant+scilab at laas.fr) Date: Fri, 2 Oct 2015 09:52:50 +0200 Subject: [Scilab-Dev] Input requested on a few behaviors for Scilab 6... In-Reply-To: References: <50B673B3-DCE1-4DC9-B077-6FE9BC831761@scilab-enterprises.com> <560DB58B.9070706@free.fr> Message-ID: <560E37D2.2010802@laas.fr> Le 10/02/2015 09:30 AM, Nicolas FEZANS a ?crit : > I think the first thing to consider is that the sign of the step > always need to match the sign of the difference end-start. If not that > is clearly an error. %inf and %nan are also errors when talking about > such ranges Hi all, I don't really agree with this. I find it quite natural for [x_start:x_step:x_stop] to be an empty matrix [] when sign(x_stop-x_start)~=sign(x_step). I don't see why an error should be thrown, returning an empty matrix is fine I think. Antoine From Serge.Steer at inria.fr Mon Oct 5 10:29:49 2015 From: Serge.Steer at inria.fr (Serge Steer) Date: Mon, 05 Oct 2015 10:29:49 +0200 Subject: [Scilab-Dev] Input requested on a few behaviors for Scilab 6... In-Reply-To: References: <50B673B3-DCE1-4DC9-B077-6FE9BC831761@scilab-enterprises.com> <560DB58B.9070706@free.fr> Message-ID: <561234FD.4080302@inria.fr> Le 02/10/2015 09:30, Nicolas FEZANS a ?crit : > Hi, > > first on point 2) > > A) [1 2 3] + 1 (as a scalar) makes mathematically no sense but can be > seen as some syntax sugar to avoid having users constantly writing > things like: "A+scalar*ones(size(A))" > > B) [1 2 3] + [4 5] makes no sense and there is no clear way of > understanding what the user wanted to do and actually in most cases > this means that something went wrong earlier and that the matrices > being added do not have the dimension that the user thought that would > have at that stage. An error is certainly the right thing to do to > prevent the code from throwing an error much later and forcing the > user to search backwards. > > C) [] + 1 = [] makes sense to me as an extension of rule A) It depends on how this operation is interpreted: - if it is considered as adding 1 to an array then the answer should be [] according to A):( the scalar is added to all elements of the array) - if it is considered as adding [] to an array then the answer should be an error according to B) or D) (dimensions do not agree) in Matlab the answer is [] > > D) [2 1 -3] + [] is to my mind as wrong than B) and should not be allowed > In Scilab552 the answer is [2 1 -3] according to the rule A+[] =A whatever A is. In Matlab the answer is an error. I think it should be better to change the Scilab behavior in case A is not a scalar nor ans empty array > then on point 3) > > I agree with Serge: the sooner you get a feedback about an error the > better. > This even brings me to ask why not throwing a real error > instead of falling back to %nan? Sometimes a programmer may really want to produce Inf and Nans > I think the first thing to consider is that the sign of the step > always need to match the sign of the difference end-start. I do not agree with that 0:-1:1 should be an empty array. It is also the Matlab answer > If not that > is clearly an error. %inf and %nan are also errors when talking about > such ranges. > > Bringing answer like %nan or [] is such cases usually only make the > program blow up some time later and that is not helpful. If someone > really wants to make something very special, then he should be forced > to specify it in his code, but the default behavior should (to my > mind) be as safe, straightforward, and self-explaining as possible. > > I would however expect [1:0:1] to be [1] since this makes sense and > could easily happen when computing bounds like this: > "start:stepSize:start+NBsteps*stepSize" when NBsteps is set to 0 (I > agree that this is not very elegant but it is very readable for a > human being) I agree with this point, but in Matlab the answer is an empty array as in Scilab5.5.2 > If we would decide that [1:0:1] = [1] is OK, that would open the > question of making a similar exception for %inf:0:%inf and for > -%inf:0:-%inf . My opinion is however that with %inf or -%inf that > would still be an error. according to the : definition a:0:a must return a so in my opinion %inf:0:%inf should return %inf (similarily for -%inf) . It is still unclear for me what should be the answer of %nan:0:%nan as %nan is not equal to itself (in Matlab the answer is NaN) Serge From nicolas.fezans at gmail.com Thu Oct 8 23:08:32 2015 From: nicolas.fezans at gmail.com (Nicolas Fezans) Date: Thu, 8 Oct 2015 23:08:32 +0200 Subject: [Scilab-Dev] Input requested on a few behaviors for Scilab 6... In-Reply-To: <560D67D9.1050208@inria.fr> References: <50B673B3-DCE1-4DC9-B077-6FE9BC831761@scilab-enterprises.com> <560D67D9.1050208@inria.fr> Message-ID: On Thu, Oct 1, 2015 at 7:05 PM, Serge Steer wrote: > Le 01/10/2015 18:37, Fran?ois Granade a ?crit : >> Hi all, >> >> We're working on Scilab 6, as you may know :); part of the goal is to correct some weird behaviors of Scilab. We're thinking of changing a few inconvenient/inconsistent behaviors. And before we implement, and release them, we'd like to make sure that: >> a) the new solution is better (we're quite sure, but not 100%), and >> b) the change will not cause too many hassle for existing users. >> >> So your feedback is really welcome on the following three points... >> >> Thank you in advance, >> >> For the Scilab team, >> Fran?ois Granade >> >> >> 1. set ieee(2) by default instead of ieee(0) >> ----------- >> >> This would raise neither a warning, nor an error, when running invalid numerical operation (eg. divide by zero), but instead use NaN as often as possible. This would be consistent with matlab and other platforms; but it could break existing scripts that rely on this behavior >> >> This would only change the *default* behavior: it would still be possible to override is by simply adding "ieee(0)" at a beginning of a script, or in "ini" file for the user. > I my opinion it should be better to keep the current behavior. When an > algorithm produces an inf or a Nan it is very often due to an algorithm > defaut and it is convenient to be informed as soon as possible. > If one really want to produce nan or inf it is safer to toggle the ieee > mode locally. > One improvement should be to make the ieee mode change only for the > active function and the called ones instead of changing the global behavior. >> Well, here I think that returning NaN is not a bad default behavior in that case because if you do a bunch of batch computations on Monte Carlo simulations you often huge series of independent computations and having one crashing for some numerical reason (let say for instance that in that area of the parameter space, the system you considered is unstable), you don't want the whole program that has been running for days to hang up causing possibly to loose a lot of valid results. Taking care of those failed cases in the post-processing is often a better user experience I think. This actually makes me have a second thought about my previous answer for number 3) and to go there also for more tolerance in the default behavior (so basically what Serge proposed) In that case I would however propose to have the possibility to change the behavior for a strict(er) one, e.g. as would be the activation of ieee(0) then. Such that if things go wrong while developing/testing a program, you do not need to trace back the chain of %inf and %nan back to the source but can have Scilab directly tell you where the possibly questionnable numerical operations began.This would introduce some kind of "debug" functionality for which it might be helpful to not directly throw an error by to prompt the user whether this operation - that would have not generated an error otherwise - should be tolerated this time or not. So you can look for what happens next, and next... in many cases you would be able to find the problem very quickly but without even having to set any breakpoints manually. Regards Nicolas From shamika.i.nair at gmail.com Wed Oct 14 05:39:10 2015 From: shamika.i.nair at gmail.com (Shamika Mohanan) Date: Wed, 14 Oct 2015 09:09:10 +0530 Subject: [Scilab-Dev] Struct and Cell Array API functions Message-ID: Hi, I'm using Scilab API in C++ code. I have to return struct and cell array values to Scilab environment. As there are no Scilab API functions for struct and cell array data types, is there any other way to do it? If I do have to write API functions, would list/mlist be the best way to deal with structs and cell arrays? Shamika -------------- next part -------------- An HTML attachment was scrubbed... URL: From laurent.berger at univ-lemans.fr Thu Oct 15 10:18:52 2015 From: laurent.berger at univ-lemans.fr (Laurent Berger) Date: Thu, 15 Oct 2015 10:18:52 +0200 Subject: [Scilab-Dev] About contrib folder In-Reply-To: References: Message-ID: <561F616C.3010601@univ-lemans.fr> About contrib folder I have a module anaspec installed in contrib folder (https://github.com/D-BookeR/Traitement_du_signal_avec_Scilab) with a script called anaSpecEga.sce. I am using windows 7 32 bits. Anaspec is installed in scilab menu Modules. I have installed in folder in c:/program files/scilab 5.2.2/contrib/Anaspec with administrator priivilege. I have changed privileges like this I can modify script without using administrator privilege. An user select item anaspec to launch it and It works. Now I want to modify this script so I changed some lines in this script. If I use notepad I can see my update in this file but nothing when I run script in scilab. Yes nothing this file is not used by scilab it is another files. But scilab does not know. When scilab ask this files to virtual machine something change path I think it is windows. Files given to scilab is in C:\Users\laurent\AppData\Local\VirtualStore\Program Files\scilab-5.5.2 This behavior does not exists when I use windows 10 64 bits and I think it does not happen with windows 7 or 8 64 bits. -- Laurent Berger From clement.david at scilab-enterprises.com Fri Oct 16 08:32:54 2015 From: clement.david at scilab-enterprises.com (=?ISO-8859-1?Q?Cl=E9ment?= David) Date: Fri, 16 Oct 2015 08:32:54 +0200 Subject: [Scilab-Dev] About contrib folder In-Reply-To: <561F616C.3010601@univ-lemans.fr> References: <561F616C.3010601@univ-lemans.fr> Message-ID: <1444977174.2598.5.camel@scilab-enterprises.com> Hello Laurent, In Scilab 5, each macro '.sci' file is compiled (or transformed to bytecode) to '.bin' before execution. In my understanding, you modified the '.sci' file but forgot to update the '.bin' file and thus on execution you observe the old behavior (from the old '.bin' file). Apart from this issue, I strongly suggest you to retrieve the source version of the module and make modification on it directly (publicly if possible). This will be easier to manage on a long period. Regards, -- Cl?ment Le jeudi 15 octobre 2015 ? 10:18 +0200, Laurent Berger a ?crit : > About contrib folder > > I have a module anaspec installed in contrib folder > (https://github.com/D-BookeR/Traitement_du_signal_avec_Scilab) with a > script called anaSpecEga.sce. I am using windows 7 32 bits. Anaspec > is > installed in scilab menu Modules. I have installed in folder in > c:/program files/scilab 5.2.2/contrib/Anaspec with administrator > priivilege. I have changed privileges like this I can modify script > without using administrator privilege. An user select item anaspec to > launch it and It works. > > Now I want to modify this script so I changed some lines in this > script. If I use notepad I can see my update in this file but nothing > when I run script in scilab. Yes nothing this file is not used by > scilab > it is another files. But scilab does not know. When scilab ask this > files to virtual machine something change path I think it is windows. > Files given to scilab is in > C:\Users\laurent\AppData\Local\VirtualStore\Program Files\scilab > -5.5.2 > > This behavior does not exists when I use windows 10 64 bits and I > think > it does not happen with windows 7 or 8 64 bits. > > From Laurent.Berger at univ-lemans.fr Fri Oct 16 15:54:10 2015 From: Laurent.Berger at univ-lemans.fr (Laurent Berger) Date: Fri, 16 Oct 2015 15:54:10 +0200 Subject: [Scilab-Dev] About contrib folder In-Reply-To: <1444977174.2598.5.camel@scilab-enterprises.com> References: <561F616C.3010601@univ-lemans.fr> <1444977174.2598.5.camel@scilab-enterprises.com> Message-ID: <20151016155410.12794ghgpg1bvsmc@entmail2.univ-lemans.fr> No It's an sce file. When I modify this sce file in VirtualStore everything is fine and logical without exiting scilab jus select item in AnaSpec in menu module ----- Message de clement.david at scilab-enterprises.com --------- Date?: Fri, 16 Oct 2015 08:32:54 +0200 De?: Cl?ment David R?pondre ??: List dedicated to the development of Scilab Objet?: Re: [Scilab-Dev] About contrib folder ??: List dedicated to the development of Scilab > Hello Laurent, > > In Scilab 5, each macro '.sci' file is compiled (or transformed to > bytecode) to '.bin' before execution. In my understanding, you modified > the '.sci' file but forgot to update the '.bin' file and thus on > execution you observe the old behavior (from the old '.bin' file). > > Apart from this issue, I strongly suggest you to retrieve the source > version of the module and make modification on it directly (publicly if > possible). This will be easier to manage on a long period. > > Regards, > > -- > Cl?ment > > Le jeudi 15 octobre 2015 ? 10:18 +0200, Laurent Berger a ?crit : >> About contrib folder >> >> I have a module anaspec installed in contrib folder >> (https://github.com/D-BookeR/Traitement_du_signal_avec_Scilab) with a >> script called anaSpecEga.sce. I am using windows 7 32 bits. Anaspec >> is >> installed in scilab menu Modules. I have installed in folder in >> c:/program files/scilab 5.2.2/contrib/Anaspec with administrator >> priivilege. I have changed privileges like this I can modify script >> without using administrator privilege. An user select item anaspec to >> launch it and It works. >> >> Now I want to modify this script so I changed some lines in this >> script. If I use notepad I can see my update in this file but nothing >> when I run script in scilab. Yes nothing this file is not used by >> scilab >> it is another files. But scilab does not know. When scilab ask this >> files to virtual machine something change path I think it is windows. >> Files given to scilab is in >> C:\Users\laurent\AppData\Local\VirtualStore\Program Files\scilab >> -5.5.2 >> >> This behavior does not exists when I use windows 10 64 bits and I >> think >> it does not happen with windows 7 or 8 64 bits. >> >> > _______________________________________________ > dev mailing list > dev at lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev > ----- Fin du message de clement.david at scilab-enterprises.com ----- -- Laurent Berger Enseignant Chercheur I.U.T. Le Mans T?l : 33(0)2 43 83 37 09 From vaibhavgupta2708 at gmail.com Tue Oct 20 11:46:49 2015 From: vaibhavgupta2708 at gmail.com (Vaibhav Gupta) Date: Tue, 20 Oct 2015 15:16:49 +0530 Subject: [Scilab-Dev] Sending Email in order to post to the mailing list Message-ID: vaibhavgupta2708 at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: