[Scilab-users] Wrong number of arguments?

[scilab . 20 . browseruk]

What am I doing wrong?

-->a=1:100;
-->b = a.^(1/9);
-->plot( a, b, 'ro-' );
 
-->c = loess( a, b, .05, 3 );
 !--error 58 
Wrong number of input arguments.at line  58 of function loess called by :  
c = loess( a, b, .05, 3 );


FREE ONLINE PHOTOSHARING - Share your photos online with your friends and 
family!
Visit http://www.inbox.com/photosharing to find out more!



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

Re: [Scilab-users] "Smoothing" very localised discontinuities in (scilab: to exclusive) (scilab: to exclusive) (scilab: to exclusive) (scilab: to exclusive) (scilab: to exclusive) curves.

[scilab . 20 . browseruk]

> Burk,
> I am sending results as Plain Text with attachments.

Thanks.

> 
> PS: the former pictures were embedded in a HTML-email which I could read
> fine.

I should have thought of that; but I didn't. 
Sorry to have put you to extra work.

> 
> Rgds
> Rafael

Buk (no r :)


Send any screenshot to your friends in seconds...
Works in all emails, instant messengers, blogs, forums and social networks.
TRY IM TOOLPACK at http://www.imtoolpack.com/default.aspx?rc=if2 for FREE



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

Re: [Scilab-users] "Smoothing" very localised discontinuities in (scilab: to exclusive) (scilab: to exclusive) (scilab: to exclusive) (scilab: to exclusive) curves.

[Perrichon]

1000 messages !


Before printing, think about ENVIRONMENTAL responsabity

-Message d'origine-
De : users [mailto:users-boun...@lists.scilab.org] De la part de Rafael
Guerra
Envoyé : lundi 4 avril 2016 22:24
À : 'Users mailing list for Scilab' 
Objet : Re: [Scilab-users] "Smoothing" very localised discontinuities in
(scilab: to exclusive) (scilab: to exclusive) (scilab: to exclusive)
(scilab: to exclusive) curves.

Burk.

I am sending results as Plain Text with attachments.

PS: the former pictures were embedded in a HTML-email which I could read
fine.

Rgds
Rafael

-Original Message-
From: users [mailto:users-boun...@lists.scilab.org] On Behalf Of
scilab.20.browse...@xoxy.net
Sent: Monday, April 04, 2016 8:43 PM
To: users@lists.scilab.org
Subject: Re: [Scilab-users] "Smoothing" very localised discontinuities in
(scilab: to exclusive) (scilab: to exclusive) (scilab: to exclusive)
(scilab: to
exclusive) curves.

Rafael,

> Buk.,
> 
> Tested the 3-point median filter solution on your data and results 
> seem Ok to> me:
> 
> 
> ZOOM around 0.4-0.5:
> 
> 
> Note that in my original example I had shifted (by 5e-3 one of my 
> curves for display purposes only, but no shift was applied the in 
> above displays)

This reads as though you've attached some "displays" to your post, but
nothng made it to me?

> 
> Regards,
> Rafael

I will try and replicate it here; but my unfamiliarity with SciLab means it
sometimes takes me a while to get these things to work :(

Thanks, Buk


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

Re: [Scilab-users] "Smoothing" very localised discontinuities in (scilab: to exclusive) (scilab: to exclusive) (scilab: to exclusive) (scilab: to exclusive) curves.

[Rafael Guerra]

Burk.

I am sending results as Plain Text with attachments.

PS: the former pictures were embedded in a HTML-email which I could read fine.

Rgds
Rafael

-Original Message-
From: users [mailto:users-boun...@lists.scilab.org] On Behalf Of
scilab.20.browse...@xoxy.net
Sent: Monday, April 04, 2016 8:43 PM
To: users@lists.scilab.org
Subject: Re: [Scilab-users] "Smoothing" very localised discontinuities in
(scilab: to exclusive) (scilab: to exclusive) (scilab: to exclusive) (scilab: to
exclusive) curves.

Rafael,

> Buk.,
> 
> Tested the 3-point median filter solution on your data and results seem
> Ok to> me:
> 
> 
> ZOOM around 0.4-0.5:
> 
> 
> Note that in my original example I had shifted (by 5e-3 one of my curves
> for display purposes only, but no shift was applied the in above displays)

This reads as though you've attached some "displays" to your post, but nothng
made it to me?

> 
> Regards,
> Rafael

I will try and replicate it here; but my unfamiliarity with SciLab means it
sometimes takes me a while to get these things to work :(

Thanks, Buk

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

Re: [Scilab-users] "Smoothing" very localised discontinuities in (scilab: to exclusive) (scilab: to exclusive) curves.

[Serge Steer]

Le 04/04/2016 20:38, scilab.20.browse...@xoxy.net a écrit :

Serge,



sgolay filter
(http://en.wikipedia.org/wiki/Savitzky%E2%80%93Golay_filter";>http://en.wikipedia.org/wiki/Savitzky-Golay_filter)otherwise
the loess regression
(http://cran.r-project.org/doc/contrib/Fox-Companion/appendix-nonparametric-regression.pdf)

That pdf does not seem to be available to me? (The requested URL was not found 
on this server)

You are right the URL is no more active
You can find it here
https://socserv.socsci.mcmaster.ca/jfox/Books/Companion/appendix/Appendix-Nonparametric-Regression.pdf 


may be tried .

Both methods and others  like medianfilter , sdfilter, ... are available
in the CWA scilab module...

'scuse my ignorance of these things; but it the "CWA scilab module" available 
as an ATOM? (If so, in which category?)

Data Analysis and  statistics
https://atoms.scilab.org/toolboxes/CWA

Or should I be looking somewhere else?




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

Re: [Scilab-users] "Smoothing" very localised discontinuities in (scilab: to exclusive) (scilab: to exclusive) curves.

[Tim Wescott]

In the graph that you posted some time back (sorry, I haven't been
saving emails), it appears that the x-axis numbers are not increasing
monotonically.  This is what led me (and, apparently, others) to assume
that the y-axis is the controlled variable.

If the machine is, indeed, stepping backwards when it's unhappy,
couldn't you just snip out the earlier instance of the same x-axis
value, and reorder as necessary?  Would this make for happy data?

I agree that asking the machine manufacturer what's what is best at this
point.  It does seem odd that they're not snipping out the data they
determine is bad -- if you're really lucky they're doing an outstanding
job, and you just need to figure out how to ask the machine to suppress
the bad data before you get it.

On Mon, 2016-04-04 at 10:38 -0800, scilab.20.browse...@xoxy.net wrote:
> Serge,
> 
> > 
> > If your data are regulary sampled along the y axis you can use the
> 
> The X-axis is the controlled variable, the Y-axis the dependent.
> 
> However, (from my understanding which is sketchy), the software controlling 
> the input has a feedback loop and attempts to adjust the rate and spacing of 
> the input to provide good data around the fine detail of the slope; so the 
> input isn't necessarily exactly linear, though if you inspect the output 
> closely, it seems to have a linear step size.
> 
> Indeed. I suspect that the discontinuities I'm seeing are a result of the 
> control software back-stepping around certain positions to correct for 
> detected 'external influences' (such as eddy current build-up or induction 
> lag). It is this hypothesis that I am going to try to get conformed by the 
> equipment manufacturer.
> 
> > sgolay filter
> > (http://en.wikipedia.org/wiki/Savitzky%E2%80%93Golay_filter";>http://en.wikipedia.org/wiki/Savitzky-Golay_filter)otherwise
> > the loess regression
> > (http://cran.r-project.org/doc/contrib/Fox-Companion/appendix-nonparametric-regression.pdf)
> 
> That pdf does not seem to be available to me? (The requested URL was not 
> found on this server)
> 
> > may be tried .
> > 
> > Both methods and others  like medianfilter , sdfilter, ... are available
> > in the CWA scilab module...
> 
> 'scuse my ignorance of these things; but it the "CWA scilab module" available 
> as an ATOM? (If so, in which category?)
> 
> Or should I be looking somewhere else?
> 
> > 
> > Serge Steer
> 
> Cheers, Buk.
> 
> 
> Can't remember your password? Do you need a strong and secure password?
> Use Password manager! It stores your passwords & protects your account.
> Check it out at http://mysecurelogon.com/password-manager
> 
> 
> 
> ___
> users mailing list
> users@lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users
> 
> 

-- 

Tim Wescott
www.wescottdesign.com
Control & Communications systems, circuit & software design.
Phone: 503.631.7815
Cell:  503.349.8432


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

Re: [Scilab-users] "Smoothing" very localised discontinuities in (scilab: to exclusive) (scilab: to exclusive) curves.

[Claus Futtrup]

Hi Buk

Thanks for sharing information about what you're doing. Quite 
interesting ... I sometimes work with magnetic simulations (but not FEMM).


Regarding "CWA Scilab", I ran a simple Google search for you:
https://atoms.scilab.org/toolboxes/CWA

Best regards,
Claus

On 04-04-2016 20:38, scilab.20.browse...@xoxy.net wrote:

Serge,


If your data are regulary sampled along the y axis you can use the

The X-axis is the controlled variable, the Y-axis the dependent.

However, (from my understanding which is sketchy), the software controlling the 
input has a feedback loop and attempts to adjust the rate and spacing of the 
input to provide good data around the fine detail of the slope; so the input 
isn't necessarily exactly linear, though if you inspect the output closely, it 
seems to have a linear step size.

Indeed. I suspect that the discontinuities I'm seeing are a result of the 
control software back-stepping around certain positions to correct for detected 
'external influences' (such as eddy current build-up or induction lag). It is 
this hypothesis that I am going to try to get conformed by the equipment 
manufacturer.


sgolay filter
(http://en.wikipedia.org/wiki/Savitzky%E2%80%93Golay_filter";>http://en.wikipedia.org/wiki/Savitzky-Golay_filter)otherwise
the loess regression
(http://cran.r-project.org/doc/contrib/Fox-Companion/appendix-nonparametric-regression.pdf)

That pdf does not seem to be available to me? (The requested URL was not found 
on this server)


may be tried .

Both methods and others  like medianfilter , sdfilter, ... are available
in the CWA scilab module...

'scuse my ignorance of these things; but it the "CWA scilab module" available 
as an ATOM? (If so, in which category?)

Or should I be looking somewhere else?


Serge Steer

Cheers, Buk.


Can't remember your password? Do you need a strong and secure password?
Use Password manager! It stores your passwords & protects your account.
Check it out at http://mysecurelogon.com/password-manager



___
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] "Smoothing" very localised discontinuities in (scilab: to exclusive) (scilab: to exclusive) (scilab: to exclusive) (scilab: to exclusive) curves.

[scilab . 20 . browseruk]

Rafael,

> Buk.,
> 
> Tested the 3-point median filter solution on your data and results seem
> Ok to> me:
> 
> 
> ZOOM around 0.4-0.5:
> 
> 
> Note that in my original example I had shifted (by 5e-3 one of my curves
> for display purposes only, but no shift was applied the in above displays)

This reads as though you've attached some "displays" to your post, but nothng 
made it to me?

> 
> Regards,
> Rafael

I will try and replicate it here; but my unfamiliarity with SciLab means it 
sometimes takes me a while to get these things to work :(

Thanks, Buk


Can't remember your password? Do you need a strong and secure password?
Use Password manager! It stores your passwords & protects your account.
Check it out at http://mysecurelogon.com/password-manager



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

Re: [Scilab-users] "Smoothing" very localised discontinuities in (scilab: to exclusive) (scilab: to exclusive) curves.

[scilab . 20 . browseruk]

Serge,

> 
> If your data are regulary sampled along the y axis you can use the

The X-axis is the controlled variable, the Y-axis the dependent.

However, (from my understanding which is sketchy), the software controlling the 
input has a feedback loop and attempts to adjust the rate and spacing of the 
input to provide good data around the fine detail of the slope; so the input 
isn't necessarily exactly linear, though if you inspect the output closely, it 
seems to have a linear step size.

Indeed. I suspect that the discontinuities I'm seeing are a result of the 
control software back-stepping around certain positions to correct for detected 
'external influences' (such as eddy current build-up or induction lag). It is 
this hypothesis that I am going to try to get conformed by the equipment 
manufacturer.

> sgolay filter
> (http://en.wikipedia.org/wiki/Savitzky%E2%80%93Golay_filter";>http://en.wikipedia.org/wiki/Savitzky-Golay_filter)otherwise
> the loess regression
> (http://cran.r-project.org/doc/contrib/Fox-Companion/appendix-nonparametric-regression.pdf)

That pdf does not seem to be available to me? (The requested URL was not found 
on this server)

> may be tried .
> 
> Both methods and others  like medianfilter , sdfilter, ... are available
> in the CWA scilab module...

'scuse my ignorance of these things; but it the "CWA scilab module" available 
as an ATOM? (If so, in which category?)

Or should I be looking somewhere else?

> 
> Serge Steer

Cheers, Buk.


Can't remember your password? Do you need a strong and secure password?
Use Password manager! It stores your passwords & protects your account.
Check it out at http://mysecurelogon.com/password-manager



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

Re: [Scilab-users] "Smoothing" very localised discontinuities in (scilab: to exclusive) curves.

[Tim Wescott]

I wish you'd made this response to the list.

Here's another thought, to address your overall problem:

* Find out what flavor of splines FEMM uses (there are subtleties).
* Figure out what Scilab calls them (naturally, everyone uses
  different names -- particularly when there's multiple countries
  and/or disciplines involved)
* Get your bad data point problem beaten to the ground
* Use Scilab to find the minimum number of points and their
  locations which, when smoothed with the right kind of
  splines, gives an acceptably close match to your B-H curve.
  Determining what's "acceptably close" is your job,
  of course.

You may find that minimizing the number of points helps the speed, you
may not -- it may just be that FEMM's numerical solver doesn't like a
large second derivative in the B-H data, in which case you'll just need
to smile and accept long solver times.

On Mon, 2016-04-04 at 08:43 -0800, scilab.20.browse...@xoxy.net wrote:
> Tim,
> 
> (sorry for the earlier "Tom"; finger trouble not name recognition problems :)
> 
> > If your FEM software can't handle non-monotonic data, can it handle
> > noisy data?
> 
> That's a good (and open) question.
> 
> The software is FEMM (www.femm.info) which is widely held in high esteem.
> 
> When entering BH curve values into the materials definitions for those with 
> non-linear magnetic properties, the program simply won't allow you to enter 
> non-monotonic data; hence my need to remove these discontinuities before I 
> can progress my project.
> 
> Once given data it will accept, it then manipulates the data to allow it to 
> ... "do its thang". It's easier (and far more accurate) for me to quote David 
> Meaker here than try to paraphrase him:
> 
> "Since FEMM interpolates between your B-H points using cubic splines, it is 
> possible to get a bad curve if you haven’t entered an adequate number of 
> points. “Weird” B-H curves can result if you have entered too few points 
> around relatively sudden changes in the B-H curve. Femm “takes care of” bad 
> B-H data (i.e. B-H data that would result in a cubic spline fit that is not 
> single-valued) by repeatedly smoothing the B-H data using a three-point 
> moving average filter until a fit is obtained that is single-valued. This 
> approach is robust in the sense that it always yields a single-valued curve, 
> but the result might be a poor match to the original B-H data. It may also be 
> important to note that FEMM extrapolates linearly off the end of your B-H 
> curve if the program encounters flux density/field intensity levels that are 
> out of the range of the values that you have entered. This extrapolation may 
> make the material look more permeable than it “really” is at high flux 
> densities. You have to be careful to enter enough B-H values to get an 
> accurate solution in highly saturated structures so that the program is 
> interpolating between your entered data points, rather than extrapolating. 
> Also in the nonlinear parameters box is a parameter, φhmax. For nonlinear 
> problems, the hys-teresis lag is assumed to be proportional to the effective 
> permeability. At the highest effective permeability, the hysteresis angle is 
> assumed to reach its maximal value of φhmax. This idea can be represented by 
> the formula: φh(B) = ( µe f f (B) ) / ( µe f f ,max ) φhmax "
> 
> So the first goal is to get data that FEMM will accept. After that there are 
> other criteria that may require the raw data to be further manipulated.
> 
> I've demonstrated that 'inconveniently real-world' data can interact badly in 
> (at least) two different ways. with FEMMs manipulation and use of that data 
> in its Tensor equations:
> 
> 1) Unless the final points approach a slope of 0 very closely, it can 
> extrapolate the data to produce ludicrously high B values. (Eg. the 'best# I 
> achieved was 67.7T!)
> 
> 2) Unless the data values works with FEMM's interpolations rather than 
> against them; it can result in extraordinarily long processing times as the 
> Newton-Ralphson iterations oscillate and converge very slowly. 
> 
> The former is fairly easy to deal with by simply appending a few artificial 
> values to the dataset that ensure a very near 0 slope.
> 
> The latter is far harder to get a handle on. One of the reasons I'm being 
> quite adamant about making a little change to the real data as possible is so 
> as to give me a chance to determine the absolute minimum requirements for 
> ensuring accurate simulations with minimal run times.
> 
> The typical approach to the latter problem seems to be to approximate the 
> data using some nicely behaving mathematical approximations (1-exp( tanh ) or 
> similar), and feed those values as the materials definition. 
> 
> The problem with that is that it throws away much of the subtlety of the 
> data; which for silicon steel laminates doesn't matter; but for 
> amorphous/nono-crystalline  metals, can mask important parts of their 
> desirable behaviours.
> 
> I

Re: [Scilab-users] "Smoothing" very localised discontinuities in (scilab: to exclusive) curves.

[scilab . 20 . browseruk]

Tim,

(sorry for the earlier "Tom"; finger trouble not name recognition problems :)

> If your FEM software can't handle non-monotonic data, can it handle
> noisy data?

That's a good (and open) question.

The software is FEMM (www.femm.info) which is widely held in high esteem.

When entering BH curve values into the materials definitions for those with 
non-linear magnetic properties, the program simply won't allow you to enter 
non-monotonic data; hence my need to remove these discontinuities before I can 
progress my project.

Once given data it will accept, it then manipulates the data to allow it to ... 
"do its thang". It's easier (and far more accurate) for me to quote David 
Meaker here than try to paraphrase him:

"Since FEMM interpolates between your B-H points using cubic splines, it is 
possible to get a bad curve if you haven’t entered an adequate number of 
points. “Weird” B-H curves can result if you have entered too few points around 
relatively sudden changes in the B-H curve. Femm “takes care of” bad B-H data 
(i.e. B-H data that would result in a cubic spline fit that is not 
single-valued) by repeatedly smoothing the B-H data using a three-point moving 
average filter until a fit is obtained that is single-valued. This approach is 
robust in the sense that it always yields a single-valued curve, but the result 
might be a poor match to the original B-H data. It may also be important to 
note that FEMM extrapolates linearly off the end of your B-H curve if the 
program encounters flux density/field intensity levels that are out of the range 
of the values that you have entered. This extrapolation may make the material 
look more permeable than it “really” is at high flux densities. You have to be 
careful to enter enough B-H values to get an accurate solution in highly 
saturated structures so that the program is interpolating between your entered 
data points, rather than extrapolating. Also in the nonlinear parameters box is 
a parameter, φhmax. For nonlinear problems, the hys-teresis lag is assumed to 
be proportional to the effective permeability. At the highest effective 
permeability, the hysteresis angle is assumed to reach its maximal value of 
φhmax. This idea can be represented by the formula: φh(B) = ( µe f f (B) ) / ( 
µe f f ,max ) φhmax "

So the first goal is to get data that FEMM will accept. After that there are 
other criteria that may require the raw data to be further manipulated.

I've demonstrated that 'inconveniently real-world' data can interact badly in 
(at least) two different ways. with FEMMs manipulation and use of that data in 
its Tensor equations:

1) Unless the final points approach a slope of 0 very closely, it can 
extrapolate the data to produce ludicrously high B values. (Eg. the 'best# I 
achieved was 67.7T!)

2) Unless the data values works with FEMM's interpolations rather than against 
them; it can result in extraordinarily long processing times as the 
Newton-Ralphson iterations oscillate and converge very slowly. 

The former is fairly easy to deal with by simply appending a few artificial 
values to the dataset that ensure a very near 0 slope.

The latter is far harder to get a handle on. One of the reasons I'm being quite 
adamant about making a little change to the real data as possible is so as to 
give me a chance to determine the absolute minimum requirements for ensuring 
accurate simulations with minimal run times.

The typical approach to the latter problem seems to be to approximate the data 
using some nicely behaving mathematical approximations (1-exp( tanh ) or 
similar), and feed those values as the materials definition. 

The problem with that is that it throws away much of the subtlety of the data; 
which for silicon steel laminates doesn't matter; but for 
amorphous/nono-crystalline  metals, can mask important parts of their desirable 
behaviours.

Indeed, my entire foray into learning SciLab is to try and establish a good 
method for pre-processing these kind of curves so that it strikes the balance 
between horrendous run times; and using artificial substitutes that ignore 
those subtleties.

And yes. You've certainly given me food for thought :)



> 
> I'm taking "smoothing" to mean "filtering" here.
> 
> In general the filtering problem is to decide on the characteristics of
> your desired signal, the characteristics of your noise, and then make
> some mathematical transformation that minimizes the effects of anything
> with noise-like characteristics while retaining as much of anything with
> desired-signal-like characteristics.
> 
> This has two salient corollaries: first, you have to know what the
> characteristics of your signal and noise are; and second, the more that
> your signal resembles your noise, the less of it you will be able to
> recover.
> 
> You can spin off from there in a number of different directions, leading
> you to a number of different filtering techniques.
> 
> It appears that you're doing your measurem

Re: [Scilab-users] "Smoothing" very localised discontinuities in (scilab: to exclusive) (scilab: to exclusive) curves.

[tim]

This is kind of in line with what I said about deciding what your noise 
characteristics are and taking them into account.  In this case you feel 
that the "noise" mostly very small but occasionally huge.  If that's the 
case then the correct thing to do is to toss that measurement out (with 
patching things up left as another step).


I should be working so I may be telling you to do what you're already 
doing, but one approach to take would be to filter the data, probably 
with a filter of limited horizons (i.e. a linear FIR filter or a median 
filter), then compare the difference between the filtered and measured 
data point-by-point.  Any place where the difference is larger than a 
threshold, call that point bad.


In Scilab-ish pseudo-code:

x = independent axis (your vertical axis, I think)
y = dependent axis

yf = filter(y) // insert correct filtering algorithm here

// From here on it could be real Scilab code
goodix = find(abs(y - yf) < threshold);

// This assumes no interpolation to replace bad points
x_good = x[goodix];
y_good = y[goodix];

You may need to use log(y) for this to work (i.e., use yf = 
filter(log(y))) -- I noticed that in the graph you posted the horizontal 
axis was in logarithms.  If the error is always in one direction you may 
want to do your comparison without the "abs" operator -- use your 
judgment in this regard.


On wording your letter -- I suggest just a straightforward description 
of what you're seeing, and a request for information on whether they've 
seen it before.  It may well be that it's either something that happens 
in some corner cases and you're lucky, or that you only _think_ that 
you're following directions.  Speaking as a guy who spends a lot of time 
designing circuits and writing embedded software, it's also always 
possible that they've made some nifty upgrade to something and in the 
process introduced a bug -- in that case, unless they're stupidly 
arrogant, they'd like to hear from a sympathetic, cooperative user to 
help them clear things up.


On 2016-04-04 07:45, scilab.20.browse...@xoxy.net wrote:

Rafael/Stepahane/Tom,

The problem with using a median filter -- and actually any continuous
filter -- is that it implies that the median value of any n-group of
adjacent values is "more reliable" than the actual value *for every
value in the dataset*. And I'm really not convinced that is true for
this data.

In other words. Continuous filtering can adjust all the values in the
dataset; rather than just adjusting or rejecting the anomalous ones.
One (large) erroneous data point early in the dataset would impose an
influence upon the rest of the entire dataset causing a subtle shift
in one direction or the other. If there are multiple erroneous values
that all tend to be in the same direction -- as appears to be the case
with these data -- then that shift accumulates through the dataset.

And as an engineer, that feels wrong. If you're taking a set of
measurements and some external influence messes with one of them -- a
fly blocks your sensor -- you reject that single data point; not
spread some percentage of it through the rest of your readings.

I'm going to put in a request to the manufacturer of the equipment
that produces this data, to request an explanation of the cause of the
discontinuities; in the hope that might shed some light on the best
way to deal with them. (With luck they'll have some standard mechanism
for doing so.)

(I've been trying to word the request all weekend, but its difficult
to phrase it correctly.  These are the pre-eminent people in their
field; they don't know me, and I don't have an introduction; and their
equipment defines the standard for these types of measurements. It is
extremely difficult to formulate the request such that it does not
imply some shortcoming in their equipment or techniques.)

The data is magnetic field intensity vs field strength for samples of
amorphous metal. The measurement involves ramping the surrounding
field with one set of coils, and measuring the field strength induced
in the material with another set of coils. The samples have
hysteresis; the coils have hysteresis; the ambient surrounding can
influence. The equipment goes to great pains to adjust the speed of
ramping and sampling to try and eliminate discontinuities due to
hysteresis and eddy current effects.

I believe (at this point) that the discontinuities are due to these
effects "settling out"; and the right thing to do is to essentially
ignore them. My problem is how to go about that.

I've come up with something. (It almost certainly can be written in a
less prosaic way; but I'm still finding my feet in SciLab):

plot2d(  ptype, h*1000, b, style = [ rgb( i ) ] );
e = gce(); e.children.mark_style = 2;

h1 = [h(1)]; b1 = [b(1)];
for n=2:size(h,'r')
if( (b(n) - b(n-1)) / (h(n) - h(n-1) + %eps) > 0 ) then
 h1 = [ h1, h(n) ]; b1 = [ b1, b(n) ];
end
end
plot2d( ptype, h1*1000, b1, s

Re: [Scilab-users] "Smoothing" very localised discontinuities in (scilab: to exclusive) (scilab: to exclusive) (scilab: to exclusive) curves.

[Rafael Guerra]

Buk.,
 
Tested the 3-point median filter solution on your data and results seem Ok to
me:
 

ZOOM around 0.4-0.5:

 
Note that in my original example I had shifted (by 5e-3 one of my curves for
display purposes only, but no shift was applied the in above displays)
 
Regards,
Rafael
 
-Original Message-
From: users [mailto:users-boun...@lists.scilab.org] On Behalf Of
scilab.20.browse...@xoxy.net
Sent: Monday, April 04, 2016 5:53 PM
To: users@lists.scilab.org
Subject: Re: [Scilab-users] "Smoothing" very localised discontinuities in
(scilab: to exclusive) (scilab: to exclusive) (scilab: to exclusive) curves.
 
Rafael,
 
> Could you please provide the data points in your example so that we can
> test different methods.
 
See attachment.
 
___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] "Smoothing" very localised discontinuities in (scilab: to exclusive) (scilab: to exclusive) (scilab: to exclusive) curves.

[scilab . 20 . browseruk]

Rafael,

> Could you please provide the data points in your example so that we can
> test different methods.

See attachment.

To view an example of the discontinuities, zoom in on the interval between 0.4 
and 0.5 T (Y-scale). I normally have to zoom twice to get a good spread.

> 
> Note that in the moving median filter solution presented there is no
> propagation of errors because the original dataset is always used and 
> only one filtering pass is made using a very short 3-point filter.

Okay. I see that (now). However, looking at my data, I don't think that a 
single pass with a window of 3 will produce the results I need. That means 
either widening the window, or iterating the filter (AFAIK?).

> 
> Regards,
> Rafael
> 

Thanks for looking at this. Buk.


Can't remember your password? Do you need a strong and secure password?
Use Password manager! It stores your passwords & protects your account.
Check it out at http://mysecurelogon.com/password-manager


HB1M_Core25_No_Field_No_Epoxy_800Am.initial.rdat
Description: Binary data
___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] "Smoothing" very localised discontinuities in (scilab: to exclusive) (scilab: to exclusive) curves.

[Rafael Guerra]

Buk.

Could you please provide the data points in your example so that we can test
different methods.

Note that in the moving median filter solution presented there is no propagation
of errors because the original dataset is always used and only one filtering
pass is made using a very short 3-point filter.

Regards,
Rafael

-Original Message-
From: users [mailto:users-boun...@lists.scilab.org] On Behalf Of
scilab.20.browse...@xoxy.net
Sent: Monday, April 04, 2016 4:45 PM
To: users@lists.scilab.org
Subject: Re: [Scilab-users] "Smoothing" very localised discontinuities in
(scilab: to exclusive) (scilab: to exclusive) curves.

Rafael/Stepahane/Tom,

The problem with using a median filter -- and actually any continuous filter --
is that it implies that the median value of any n-group of adjacent values is
"more reliable" than the actual value *for every value in the dataset*. And I'm
really not convinced that is true for this data.

In other words. Continuous filtering can adjust all the values in the dataset;
rather than just adjusting or rejecting the anomalous ones. One (large)
erroneous data point early in the dataset would impose an influence upon the
rest of the entire dataset causing a subtle shift in one direction or the other.
If there are multiple erroneous values that all tend to be in the same direction
-- as appears to be the case with these data -- then that shift accumulates
through the dataset.

And as an engineer, that feels wrong. If you're taking a set of measurements and
some external influence messes with one of them -- a fly blocks your sensor --
you reject that single data point; not spread some percentage of it through the
rest of your readings.

I'm going to put in a request to the manufacturer of the equipment that produces
this data, to request an explanation of the cause of the discontinuities; in the
hope that might shed some light on the best way to deal with them. (With luck
they'll have some standard mechanism for doing so.) 

(I've been trying to word the request all weekend, but its difficult to phrase
it correctly.  These are the pre-eminent people in their field; they don't know
me, and I don't have an introduction; and their equipment defines the standard
for these types of measurements. It is extremely difficult to formulate the
request such that it does not imply some shortcoming in their equipment or
techniques.)

The data is magnetic field intensity vs field strength for samples of amorphous
metal. The measurement involves ramping the surrounding field with one set of
coils, and measuring the field strength induced in the material with another set
of coils. The samples have hysteresis; the coils have hysteresis; the ambient
surrounding can influence. The equipment goes to great pains to adjust the speed
of ramping and sampling to try and eliminate discontinuities due to hysteresis
and eddy current effects. 

I believe (at this point) that the discontinuities are due to these effects
"settling out"; and the right thing to do is to essentially ignore them. My
problem is how to go about that.

I've come up with something. (It almost certainly can be written in a less
prosaic way; but I'm still finding my feet in SciLab):

plot2d(  ptype, h*1000, b, style = [ rgb( i ) ] );
e = gce(); e.children.mark_style = 2;

h1 = [h(1)]; b1 = [b(1)];
for n=2:size(h,'r') 
if( (b(n) - b(n-1)) / (h(n) - h(n-1) + %eps) > 0 ) then
 h1 = [ h1, h(n) ]; b1 = [ b1, b(n) ];
end
end
plot2d( ptype, h1*1000, b1, style = [ rgb( i + 1 ) ] );

h = h1'; b = b1'; 
h1 = [h(1)]; b1 = [b(1)];
for n=2:size(h,'r') 
if( (b(n) - b(n-1)) / (h(n) - h(n-1) + %eps) > 0 ) then
 h1 = [ h1, h(n) ]; b1 = [ b1, b(n) ];
end
end
plot2d( ptype, h1*1000, b1, style = [ rgb( i + 2 ) ] );

See the attached png. The black Xs are the raw data. 
The red is the results of the first pass.
The green is the results of the second pass.
The purple are hand-drawn "what I think I'd like" lines.

What I like about this is that it only adjust (currently omits; but it could
interpolate replacements) points that fall outside the criteria. As you said of
the median filter; it doesn't guarantee monotonicity after one pass (or even 2),
but it only makes changes where they are strictly required, leaving most of the
raw data intact. 

(Note: At this stage I'm not saying that is the right thing to do; just that it
seems to be :)

I'm not entirely happy with the results:

a) I think the had-drawn purple lines are a better representation of the
replaced data; but I can't divine the criteria to produce those?
b) I've hard coded two passes for this particular dataset; but I need to repeat
until no negative slopes remain; and I haven't worked out how to do that yet.

Comments; rebuttals; referrals to the abuse of SciLab/math police; along with
better implementations of what I have; or better criteria for solving my problem
all actively sought.

T

Re: [Scilab-users] "Smoothing" very localised discontinuities in (scilab: to exclusive) (scilab: to exclusive) curves.

[Stéphane Mottelet]

Hello,

The last time I had used a median filter, it was to locate peaks in a 
frequency DSP. The idea was to substract the median-filtered spectrum to 
the original one, and treshold the difference. This was enough to locate 
the peaks. Maybe you could use the same idea there.


S.

Le 04/04/2016 16:45, scilab.20.browse...@xoxy.net a écrit :

Rafael/Stepahane/Tom,

The problem with using a median filter -- and actually any continuous filter -- is that 
it implies that the median value of any n-group of adjacent values is "more 
reliable" than the actual value *for every value in the dataset*. And I'm really not 
convinced that is true for this data.

In other words. Continuous filtering can adjust all the values in the dataset; 
rather than just adjusting or rejecting the anomalous ones. One (large) 
erroneous data point early in the dataset would impose an influence upon the 
rest of the entire dataset causing a subtle shift in one direction or the 
other. If there are multiple erroneous values that all tend to be in the same 
direction -- as appears to be the case with these data -- then that shift 
accumulates through the dataset.

And as an engineer, that feels wrong. If you're taking a set of measurements 
and some external influence messes with one of them -- a fly blocks your sensor 
-- you reject that single data point; not spread some percentage of it through 
the rest of your readings.

I'm going to put in a request to the manufacturer of the equipment that 
produces this data, to request an explanation of the cause of the 
discontinuities; in the hope that might shed some light on the best way to deal 
with them. (With luck they'll have some standard mechanism for doing so.)

(I've been trying to word the request all weekend, but its difficult to phrase 
it correctly.  These are the pre-eminent people in their field; they don't know 
me, and I don't have an introduction; and their equipment defines the standard 
for these types of measurements. It is extremely difficult to formulate the 
request such that it does not imply some shortcoming in their equipment or 
techniques.)

The data is magnetic field intensity vs field strength for samples of amorphous 
metal. The measurement involves ramping the surrounding field with one set of 
coils, and measuring the field strength induced in the material with another 
set of coils. The samples have hysteresis; the coils have hysteresis; the 
ambient surrounding can influence. The equipment goes to great pains to adjust 
the speed of ramping and sampling to try and eliminate discontinuities due to 
hysteresis and eddy current effects.

I believe (at this point) that the discontinuities are due to these effects 
"settling out"; and the right thing to do is to essentially ignore them. My 
problem is how to go about that.

I've come up with something. (It almost certainly can be written in a less 
prosaic way; but I'm still finding my feet in SciLab):

 plot2d(  ptype, h*1000, b, style = [ rgb( i ) ] );
 e = gce(); e.children.mark_style = 2;

 h1 = [h(1)]; b1 = [b(1)];
 for n=2:size(h,'r')
 if( (b(n) - b(n-1)) / (h(n) - h(n-1) + %eps) > 0 ) then
  h1 = [ h1, h(n) ]; b1 = [ b1, b(n) ];
 end
 end
 plot2d( ptype, h1*1000, b1, style = [ rgb( i + 1 ) ] );

 h = h1'; b = b1';
 h1 = [h(1)]; b1 = [b(1)];
 for n=2:size(h,'r')
 if( (b(n) - b(n-1)) / (h(n) - h(n-1) + %eps) > 0 ) then
  h1 = [ h1, h(n) ]; b1 = [ b1, b(n) ];
 end
 end
 plot2d( ptype, h1*1000, b1, style = [ rgb( i + 2 ) ] );

See the attached png. The black Xs are the raw data.
The red is the results of the first pass.
The green is the results of the second pass.
The purple are hand-drawn "what I think I'd like" lines.

What I like about this is that it only adjust (currently omits; but it could 
interpolate replacements) points that fall outside the criteria. As you said of 
the median filter; it doesn't guarantee monotonicity after one pass (or even 
2), but it only makes changes where they are strictly required, leaving most of 
the raw data intact.

(Note: At this stage I'm not saying that is the right thing to do; just that it 
seems to be :)

I'm not entirely happy with the results:

a) I think the had-drawn purple lines are a better representation of the 
replaced data; but I can't divine the criteria to produce those?
b) I've hard coded two passes for this particular dataset; but I need to repeat 
until no negative slopes remain; and I haven't worked out how to do that yet.

Comments; rebuttals; referrals to the abuse of SciLab/math police; along with 
better implementations of what I have; or better criteria for solving my 
problem all actively sought.

Thanks, Buk.




-Original Message-
From: scilab.browseruk.b28bd2e902.jrafaelbguerra#hotmail@ob.0sg.net
Sent: Mon, 4 Apr 2016 14:58:47 +0200
To: users@lists.scilab.org
Subject: Re: [Scilab-users] "Smoothing" very localised discontinuit

Re: [Scilab-users] "Smoothing" very localised discontinuities in (scilab: to exclusive) (scilab: to exclusive) curves.

[scilab . 20 . browseruk]

Rafael/Stepahane/Tom,

The problem with using a median filter -- and actually any continuous filter -- 
is that it implies that the median value of any n-group of adjacent values is 
"more reliable" than the actual value *for every value in the dataset*. And I'm 
really not convinced that is true for this data.

In other words. Continuous filtering can adjust all the values in the dataset; 
rather than just adjusting or rejecting the anomalous ones. One (large) 
erroneous data point early in the dataset would impose an influence upon the 
rest of the entire dataset causing a subtle shift in one direction or the 
other. If there are multiple erroneous values that all tend to be in the same 
direction -- as appears to be the case with these data -- then that shift 
accumulates through the dataset.

And as an engineer, that feels wrong. If you're taking a set of measurements 
and some external influence messes with one of them -- a fly blocks your sensor 
-- you reject that single data point; not spread some percentage of it through 
the rest of your readings.

I'm going to put in a request to the manufacturer of the equipment that 
produces this data, to request an explanation of the cause of the 
discontinuities; in the hope that might shed some light on the best way to deal 
with them. (With luck they'll have some standard mechanism for doing so.) 

(I've been trying to word the request all weekend, but its difficult to phrase 
it correctly.  These are the pre-eminent people in their field; they don't know 
me, and I don't have an introduction; and their equipment defines the standard 
for these types of measurements. It is extremely difficult to formulate the 
request such that it does not imply some shortcoming in their equipment or 
techniques.)

The data is magnetic field intensity vs field strength for samples of amorphous 
metal. The measurement involves ramping the surrounding field with one set of 
coils, and measuring the field strength induced in the material with another 
set of coils. The samples have hysteresis; the coils have hysteresis; the 
ambient surrounding can influence. The equipment goes to great pains to adjust 
the speed of ramping and sampling to try and eliminate discontinuities due to 
hysteresis and eddy current effects. 

I believe (at this point) that the discontinuities are due to these effects 
"settling out"; and the right thing to do is to essentially ignore them. My 
problem is how to go about that.

I've come up with something. (It almost certainly can be written in a less 
prosaic way; but I'm still finding my feet in SciLab):

plot2d(  ptype, h*1000, b, style = [ rgb( i ) ] );
e = gce(); e.children.mark_style = 2;

h1 = [h(1)]; b1 = [b(1)];
for n=2:size(h,'r') 
if( (b(n) - b(n-1)) / (h(n) - h(n-1) + %eps) > 0 ) then
 h1 = [ h1, h(n) ]; b1 = [ b1, b(n) ];
end
end
plot2d( ptype, h1*1000, b1, style = [ rgb( i + 1 ) ] );

h = h1'; b = b1'; 
h1 = [h(1)]; b1 = [b(1)];
for n=2:size(h,'r') 
if( (b(n) - b(n-1)) / (h(n) - h(n-1) + %eps) > 0 ) then
 h1 = [ h1, h(n) ]; b1 = [ b1, b(n) ];
end
end
plot2d( ptype, h1*1000, b1, style = [ rgb( i + 2 ) ] );

See the attached png. The black Xs are the raw data. 
The red is the results of the first pass.
The green is the results of the second pass.
The purple are hand-drawn "what I think I'd like" lines.

What I like about this is that it only adjust (currently omits; but it could 
interpolate replacements) points that fall outside the criteria. As you said of 
the median filter; it doesn't guarantee monotonicity after one pass (or even 
2), but it only makes changes where they are strictly required, leaving most of 
the raw data intact. 

(Note: At this stage I'm not saying that is the right thing to do; just that it 
seems to be :)

I'm not entirely happy with the results:

a) I think the had-drawn purple lines are a better representation of the 
replaced data; but I can't divine the criteria to produce those?
b) I've hard coded two passes for this particular dataset; but I need to repeat 
until no negative slopes remain; and I haven't worked out how to do that yet.

Comments; rebuttals; referrals to the abuse of SciLab/math police; along with 
better implementations of what I have; or better criteria for solving my 
problem all actively sought.

Thanks, Buk.



> -Original Message-
> From: scilab.browseruk.b28bd2e902.jrafaelbguerra#hotmail@ob.0sg.net
> Sent: Mon, 4 Apr 2016 14:58:47 +0200
> To: users@lists.scilab.org
> Subject: Re: [Scilab-users] "Smoothing" very localised discontinuities in
> (scilab: to exclusive) (scilab: to exclusive) curves.
> 
> If your data is not recorded in real-time, you can sort it (along the
> x-axis)
> and this does not imply that the "y(x) function" will become monotonous.
> See
> below.
> 
> As suggested, by Stephane Mottelet, see one 3-point median filter
> solution below
> applied to data simi

Re: [Scilab-users] "Smoothing" very localised discontinuities in (scilab: to exclusive) curves.

[Serge Steer]

If your data are regulary sampled along the y axis you can use the 
sgolay filter 
(http://en.wikipedia.org/wiki/Savitzky%E2%80%93Golay_filter";>http://en.wikipedia.org/wiki/Savitzky-Golay_filter)otherwise 
the loess regression 
(http://cran.r-project.org/doc/contrib/Fox-Companion/appendix-nonparametric-regression.pdf) 
may be tried .


Both methods and others  like medianfilter , sdfilter, ... are available 
in the CWA scilab module...


Serge Steer

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

Re: [Scilab-users] "Smoothing" very localised discontinuities in (scilab: to exclusive) curves.

[Rafael Guerra]

If your data is not recorded in real-time, you can sort it (along the x-axis)
and this does not imply that the "y(x) function" will become monotonous. See
below.
 
As suggested, by Stephane Mottelet, see one 3-point median filter solution below
applied to data similar to yours:
 
 
M = [1.0  -0.2;
1.4   0.0;
2.1   0.2;
1.7   0.45;
2.45  0.5;  
2.95  0.6;
2.5   0.75;
3.0   0.8;
3.3   1.2];
x0 = M(:,1);
y0 = M(:,2);
clf();
plot2d(x0,[y0 y0],style=[5 -9]);
[x,ix] = gsort(x0,'g','i'); // sorting input x-axis
y = y0(ix);
k =1; // median filter half-lenght
n = length(x);
x(2:n+1)=x; y(2:n+1)=y;
x(1)=x(2); y(1)=y(2);
x(n+2)=x(n+1); y(n+2)=y(n+1);
n = length(x);
for j = 1:n
j1 = max(1,j-k);
j2 = min(n,j+k);
ym(j) = median(y(j1:j2));
end
plot2d(x,ym+5e-3,style=[3],leg="3-point median filtering@"); // shift for
display purposes
 
 
 
This gets rid of obvious outliers but does not guarantee a monotonous output
(idem for the more robust LOWESS technique, that can be googled).
 
Rafael
 
-Original Message-
From: users [mailto:users-boun...@lists.scilab.org] On Behalf Of
scilab.20.browse...@xoxy.net  
Sent: Monday, April 04, 2016 1:05 PM
To: users@lists.scilab.org  
Subject: Re: [Scilab-users] "Smoothing" very localised discontinuities in
(scilab: to exclusive) curves.
 
Yes.
 
C:\Motor>graphRdat T HB1M_Core25_No_Field_No_Epoxy_800Am.rdat
   s = splin( h', b', 'monotone' );
!--error 999
splin: Wrong value for input argument #1: Not (strictly) increasing or +-inf
detected.
at line  22 of exec file called by :
 
Since there are no inf values in the data; that kind of implies that it requires

monotonic input in order to produce monotonic output; which ain't so useful.
 
That said, I get that same error message whichever variation of the splin()
function I try
 
Which suggests there's something wrong with my data, but that stupid cos the
data is real.
The math has to adapt to the data not the other way around.
 
 
___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] "Smoothing" very localised discontinuities in (scilab: to exclusive) curves.

[scilab . 20 . browseruk]

Yes.

C:\Motor>graphRdat T HB1M_Core25_No_Field_No_Epoxy_800Am.rdat
s = splin( h', b', 'monotone' );
!--error 999
splin: Wrong value for input argument #1: Not (strictly) increasing or +-inf 
detected.
at line  22 of exec file called by :

Since there are no inf values in the data; that kind of implies that it 
requires 
monotonic input in order to produce monotonic output; which ain't so useful.

That said, I get that same error message whichever variation of the splin() 
function I try

Which suggests there's something wrong with my data, but that stupid cos the 
data is real.
The math has to adapt to the data not the other way around.




> -Original Message-
> From: scilab.browseruk.b28bd2e902.jrafaelbguerra#hotmail@ob.0sg.net
> Sent: Mon, 4 Apr 2016 11:20:13 +0200
> To: users@lists.scilab.org
> Subject: Re: [Scilab-users] "Smoothing" very localised discontinuities in
> (scilab: to exclusive) curves.
> 
> Hi Buk.
> 
> Have you tried Scilab's cubic splines using the "monotone" option?
> 
> Regards,
> Rafael
> 
> -Original Message-
> From: users [mailto:users-boun...@lists.scilab.org] On Behalf Of
> scilab.20.browse...@xoxy.net
> Sent: Sunday, April 03, 2016 9:09 PM
> To: users@lists.scilab.org
> Subject: [Scilab-users] "Smoothing" very localised discontinuities in
> curves.
> 
> HI,
> 
> The data I'm dealing with is experimentally produced; and thus contains
> occasional, localised discontinuities (inflections), that I need to
> remove
> before that data is suitable for is use in FEM modeling software, which
> requires
> that it be strictly monotonic. The attachment shows the full curve plus a
> close
> up of a couple of examples of the type of discontinuity I need to deal
> with.
> 
> I haven't yet decided whether to simply omit points (thus connect A to F
> & G to
> J) or whether to retain the same number of points by interpolating new
> points
> onto that line as shown in red.
> 
> I've looked and played several of the smoothing, convolution and
> interpolation
> routines that scilab provides, but (besides that I don't understand the
> output
> some of them produce) they also seem to affect the data more than I would
> like.
> Some seem to introduce a 'phase shift'; others smooth out larger scale
> bumps in
> the curve that need to be retained; and others generate many extra points
> which
> I don't think is helpful, the FEM software is going to do its own
> interpolations
> anyway.
> 
> 
> But the bit I'm asking about here is how to detect point A&F and G&J?
> 
> Any thoughts or pointers as to a) the algorithm to use; b) how to
> implement it
> in SciLab?
> 
> Cheers, Buk.
> 
> 
> Can't remember your password? Do you need a strong and secure password?
> Use Password manager! It stores your passwords & protects your account.
> Check it out at http://mysecurelogon.com/password-manager
> 
> ___
> users mailing list
> users@lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users


FREE ONLINE PHOTOSHARING - Share your photos online with your friends and 
family!
Visit http://www.inbox.com/photosharing to find out more!



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

Re: [Scilab-users] "Smoothing" very localised discontinuities in curves.

[Rafael Guerra]

Hi Buk.

Have you tried Scilab's cubic splines using the "monotone" option?

Regards,
Rafael

-Original Message-
From: users [mailto:users-boun...@lists.scilab.org] On Behalf Of
scilab.20.browse...@xoxy.net
Sent: Sunday, April 03, 2016 9:09 PM
To: users@lists.scilab.org
Subject: [Scilab-users] "Smoothing" very localised discontinuities in curves.

HI,

The data I'm dealing with is experimentally produced; and thus contains
occasional, localised discontinuities (inflections), that I need to remove
before that data is suitable for is use in FEM modeling software, which requires
that it be strictly monotonic. The attachment shows the full curve plus a close
up of a couple of examples of the type of discontinuity I need to deal with.

I haven't yet decided whether to simply omit points (thus connect A to F & G to
J) or whether to retain the same number of points by interpolating new points
onto that line as shown in red.

I've looked and played several of the smoothing, convolution and interpolation
routines that scilab provides, but (besides that I don't understand the output
some of them produce) they also seem to affect the data more than I would like.
Some seem to introduce a 'phase shift'; others smooth out larger scale bumps in
the curve that need to be retained; and others generate many extra points which
I don't think is helpful, the FEM software is going to do its own interpolations
anyway.


But the bit I'm asking about here is how to detect point A&F and G&J? 

Any thoughts or pointers as to a) the algorithm to use; b) how to implement it
in SciLab?

Cheers, Buk.


Can't remember your password? Do you need a strong and secure password?
Use Password manager! It stores your passwords & protects your account.
Check it out at http://mysecurelogon.com/password-manager

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

Re: [Scilab-users] scilab 6.0.0-beta-1 on Mac OS X El Capitan

[Clément David]

Hello,

I guess there might be a bug on that support. You can add yourself to the CC 
list on the bugzilla
interface to be alerted on change.

--
Clément

Le dimanche 03 avril 2016 à 06:04 -0700, jaipur a écrit :
> Thank you.
> I understand that scilab 6.0.0-beta-1 does not support Mac OS X El Capitan.
> 
> 
> 
> 
> --
> View this message in context: 
> http://mailinglists.scilab.org/scilab-6-0-0-beta-1-on-Mac-OS-X-El-Ca
> pitan-tp4033887p4033893.html
> Sent from the Scilab users - Mailing Lists Archives mailing list archive at 
> Nabble.com.
> ___
> 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