### Email Archive: octave-dev (read-only)

 Re: [OctDev] Developer Registration Request From: Carlo de Falco - 2009-06-07 12:53 ```On 7 Jun 2009, at 00:25, dmelliott wrote: > > Dear Mr. de Falco, > > While it does not have a singularity on the path of > integration, it does at x = +/- i/5. Thus the radius of > convergence, from zero, interferes with the construction > of a polynomial approximation therefrom. This is also > early calculus, and not subtle. > > In the real world data comes to you as it comes to you, > usually on an equal step domain and often without > tolerance (necessary for any coherent data processing). > If you can convince the all manufacturers of measuring > equipment to modify all their machines, I am sure we > would all be better off. The Octave routines that give > this type of output might be a place to start. > > If you have a better method for equal step integration, > it would indeed be of great value. > > > dmelliott On 7 Jun 2009, at 00:25, dmelliott wrote: > > Dear Mr. de Falco, > > While it does not have a singularity on the path of > integration, it does at x = +/- i/5. Thus the radius of > convergence, from zero, interferes with the construction > of a polynomial approximation therefrom. This is also > early calculus, and not subtle. The counterexample I proposed is indeed a very well-known one (usually referred to as "Runge's counterexample") you can find in any elementary text book on numerical analysis, see for example [1], page 390 example 9.3. But complex roots in the denominator do not have anything to do with the poor performance of high order Newton-Cotes formulae. The reason why Runge's function exposes the limitations of Lagrange interpolation on equispaced nodes (and therefore of quadrature rules based on this kind of interpolation) has rather to do, to put it simply, with the fact that it has large areas near the ends of the integration interval where it is nearly flat so that high order, highly oscillating polynomials are not able to approximate it correctly. You should see the same effect by substituting a gaussian curve for Runge's function in the example. > In the real world data comes to you as it comes to you, > usually on an equal step domain and often without > tolerance (necessary for any coherent data processing). > If you can convince the all manufacturers of measuring > equipment to modify all their machines, I am sure we > would all be better off. The Octave routines that give > this type of output might be a place to start. I did not object your idea to provide a function for doing quadrature on (equispaced) data samples. I just wanted to put out a warning that increasing the order of the quadrature formula does not always improve the accuracy, in the extreme case of Runge's function it's even the other way around. That being said, I have nothing to object about your approach as long as the docs explain exactly what your function is doing: it is then left to the user to apply it wisely. > If you have a better method for equal step integration, > it would indeed be of great value. My suggestion was to simply use composit formulae of a fixed order and let the users choose the order depending on whatever a-priori knowledge they might have about how the data they are analyzing were generated. An example of how to do this is in the attached function, you can see a test by typing "demo integ1samp" I'm not proposing this as a substitute for your approach, it is just a quick hack to explain my idea, do whatever you wish with it as I'm not willing to pursue this subject any further. c. > > dmelliott [1] A. Quarteroni, R. Sacco, F. Saleri, Numerical Mathematics, secon edition. Springer Verlag (2007) ```

### Thread View

Thread Author Date
[OctDev] Developer Registration Request dmelliott <dmelliott@ch...>
 Re: [OctDev] Developer Registration Request From: Søren Hauberg - 2009-05-31 14:57 ```fre, 29 05 2009 kl. 22:19 -0500, skrev dmelliott: [snip] > These routines are both small and fast. > > > Please find the routines enclosed. Thanks :-) I'm no expert in this field, so I'd rather not comment on the actual functions. Does anybody have any comments on these functions? Where do you think these functions should go (in which package)? I'm not sure I'm too fond of the copyright, though. The basic problem is that no "Octave organisation" exist. Is there a reason for you not to claim copyright of these files? The demo 'integrator_verifier' should probably be rewritten as a demo using '%!demo'. Otherwise we easily end up with a lot of functions in the global namespace that really shouldn't be used for programming. Søren ```

 Re: [OctDev] Developer Registration Request From: Søren Hauberg - 2009-05-31 22:08 ```Hi Please remember to reply-to-all such that everybody on the list can take part in the discussion. søn, 31 05 2009 kl. 16:49 -0500, skrev dmelliott: > Dear Mr. Hauberg, Call me Søren; no need to be formal :-) > Thank you for your kind consideration. > > The package placement decision is up to anybody who is > familiar with your overall organizational system, and thus > competent to make it; this is certainly not myself. I'm also asking the other developers for advice. Would the 'Integration' package be a suitable place? > Along these lines, please feel totally free to rename to > make consistent with the existing scheme. Is the name, 'integrator', specific enough? It sounds very general to me, but as I said, I'm no expert in the field. > Copyright: First, I don't think that this is copyrightable in > the same sense that the value of "e" is not, and the concepts > are straight from the first week of everybody's Numerical > Analysis 101. However, the programming itself is not a > fact of nature, and thus might be. Sounds like you would prefer to put this function in the public domain. If that's what you prefer, then this is just fine. > Second, my goal is to help make Octave the most solid > numerical analysis application available. For this to be > true, there need be as few people involved in any potential > legal conflicts as possible. But as long as no Octave organisation exist I don't think it makes sense to assign copyright to it. If you assign copyright to a non-existing party then I guess (I'm no lawyer) nobody owns the copyright, which sounds like a legal nightmare to me. Søren > > > dmelliott > > ```

 Re: [OctDev] Developer Registration Request From: dmelliott - 2009-06-01 02:38 ```----- Original Message ----- From: Søren Hauberg To: dmelliott ; octave-dev@... Sent: Sunday, May 31, 2009 5:08 PM Subject: Re: [OctDev] Developer Registration Request Hi Please remember to reply-to-all such that everybody on the list can take part in the discussion. søn, 31 05 2009 kl. 16:49 -0500, skrev dmelliott: > Dear Mr. Hauberg, Call me Søren; no need to be formal :-) > Thank you for your kind consideration. > > The package placement decision is up to anybody who is > familiar with your overall organizational system, and thus > competent to make it; this is certainly not myself. I'm also asking the other developers for advice. Would the 'Integration' package be a suitable place? > Along these lines, please feel totally free to rename to > make consistent with the existing scheme. Is the name, 'integrator', specific enough? It sounds very general to me, but as I said, I'm no expert in the field. > Copyright: First, I don't think that this is copyrightable in > the same sense that the value of "e" is not, and the concepts > are straight from the first week of everybody's Numerical > Analysis 101. However, the programming itself is not a > fact of nature, and thus might be. Sounds like you would prefer to put this function in the public domain. If that's what you prefer, then this is just fine. > Second, my goal is to help make Octave the most solid > numerical analysis application available. For this to be > true, there need be as few people involved in any potential > legal conflicts as possible. But as long as no Octave organisation exist I don't think it makes sense to assign copyright to it. If you assign copyright to a non-existing party then I guess (I'm no lawyer) nobody owns the copyright, which sounds like a legal nightmare to me. Søren > > > dmelliott > > Dear Søren, As long as it becomes part of what is available to Octave users, I don't have any preferences about the logistics. If it would be preferable for Octave that I claim copyright, then we can talk about that. The only item of vanity would be listing my name as author. In this country, copyrights, like patents, are in and of themselves nothing. Anyone can get one on anything. They only achieve power after being tested in court. Thier main feature is the threat of being taken to court if the material is copied without permission. Since I would cave like a pasteboard box under a falling bowling ball, my copyright is not much of a threat. I have my name on four patents, but perforce the company I worked for, and wished to continue working for at the time, is, at \$1.00 apiece, the actual holder. This does not affend my vanity since I had no intention of manufacturing, selling, and distributing these items myself. Their existance with my name as author made them as useful to me as they could be. If this is a sticking point, I will certainly take advice. dmelliott ```

 Re: [OctDev] Developer Registration Request From: dmelliott - 2009-06-01 03:38 ```Dear Søren, More on copyright. Wikipedia's article on copyright: http://en.wikipedia.org/wiki/Copyright#Obtaining_and_enforcing_copyright states that in the US, where I am, registering a copyright after a chalange entitles one to only damages and lost profits. Since I am not going to pay for registration beforehand, and the whole thing is non-profit, there seems to be little point in doing this. The laws are diferent in other countries. dmelliott ```

 Re: [OctDev] Developer Registration Request From: James K. Lowden - 2009-06-02 04:52 ```Søren Hauberg wrote: > But as long as no Octave organisation exist I don't think it makes sense > to assign copyright to it. If you assign copyright to a non-existing > party then I guess (I'm no lawyer) nobody owns the copyright, which > sounds like a legal nightmare to me. Is it not simple enough to put at the top of the file: "Contributed to the public domain by Douglas M. Elliott in May 2009"? For another approach that many lawyers have vetted, cf. http://www.sqlite.org/cvstrac/fileview?f=sqlite/src/mem2.c&v=1.45. HTH.  --jkl ```

 Re: [OctDev] Developer Registration Request From: dmelliott - 2009-06-02 19:12 ```Dear Søren, More thoughts: The idea of this routine is that it integrates existing data in its most ususal form. That is, it does not need a function to call, and, since, for better or for worse, most data comes on a domain of equally sized steps, this is what it uses. This is an attempt to make it compatable whith most experimantal data, and the outputs of other routines, e.g. sales by week, Fourie analysed amplitudes by frequency, actuarial data by age, etc. The patrial interval integrals, including cumulative, can be achieved by looping or otherwise manipulating the endpoint values. The best way to see its worth is to compare it to the available routine for existing data, by editing the "integrator_verifier" to use the "trapz" routine. The latter is only of first order, and even for as many as 500 points on [0,1] yields a 2.01e-6 relative error for the next higher order, the second. For higher orders higher than second it is even more useless. There probably should a caution appended to the instructions about this. The problem with a copyright in the U.S. (it is different in many other places) is that if you do not want to spend the money to register and fight a challange, you may end up with a legal record of having lost a copyright infringement suit. The government here does not proctively protect copyright claims, even if registered. With respect to the name, perhaps integratores for "integrator, even steps", or some such thing, would be more suitable. I note that the names in the integration package go by internal workings insted of giving a clue as to what they are for. What is the name of the "ø" character? I have asked all my second generation Dansk relatives, but they do not know for some reason. dmelliott ```

 Re: [OctDev] Developer Registration Request From: Søren Hauberg - 2009-06-02 19:35 ```tir, 02 06 2009 kl. 14:12 -0500, skrev dmelliott: > The idea of this routine is that it integrates existing data in its most > ususal form. That is, it does not need a function to call, and, since, for > better or for worse, most data comes on a domain of equally sized steps, > this is what it uses. This is an attempt to make it compatable whith most > experimantal data, and the outputs of other routines, e.g. sales by week, > Fourie analysed amplitudes by frequency, actuarial data by age, etc. The > patrial interval integrals, including cumulative, can be achieved by looping > or otherwise manipulating the endpoint values. Sounds sensible. Most of the data I work with are equidistantly spaced, so I can related :-) > The best way to see its worth is to compare it to the available routine > for existing data, by editing the "integrator_verifier" to use the "trapz" > routine. The latter is only of first order, and even for as many as 500 > points on [0,1] yields a 2.01e-6 relative error for the next higher order, > the second. For higher orders higher than second it is even more useless. > There probably should a caution appended to the instructions about this. OK. It would probably be wise to write a bit about this in the documentation of the function. Could you do this? > The problem with a copyright in the U.S. (it is different in many other > places) is that if you do not want to spend the money to register and fight > a challange, you may end up with a legal record of having lost a copyright > infringement suit. The government here does not proctively protect > copyright claims, even if registered. My knowledge about (and interest in) copyright law is very limited. I think it is perfectly fine if you don't want to claim copyright of some of your work. What is wrong with putting your work in the public domain, then? Then you're bypassing copyright law (as far as I understand). > With respect to the name, perhaps integratores for "integrator, even > steps", or some such thing, would be more suitable. I note that the names > in the integration package go by internal workings insted of giving a clue > as to what they are for. That is probably because several of the functions are trying to solve the exact same problem, so it is hard to come up with discriminative names for the different algorithms. Does your approach have a standard name? Can it be explained in terms commonly used in numerical integration? If so, then it might be easier to come up with a name. Also, does it work in N-dimensions? If it is only for 1D data, then it should probably end with '1' to signal this. > What is the name of the "ø" character? I have asked all my second > generation Dansk relatives, but they do not know for some reason. Well the character is named "ø" :-) The English name for the character is "o slash" (i.e. an "o" with a slash through). The sound of the character has no corresponding sound in English. Basically, that sound is not part of the English language. You can hear the different pronunciations of the letter at http://udtale.dansk.nu/ Recently, it was pointed out that we have a bug in Octave in the 'fscanf' function, that could be triggered by the letter "ø" :-) Søren ```

 Re: [OctDev] Developer Registration Request From: Carlo de Falco - 2009-06-02 20:15 ```On 2 Jun 2009, at 21:12, dmelliott wrote: > > Dear Søren, > > More thoughts: > > > The idea of this routine is that it integrates existing data in > its most > ususal form. That is, it does not need a function to call, and, > since, for > better or for worse, most data comes on a domain of equally sized > steps, > this is what it uses. This is an attempt to make it compatable > whith most > experimantal data, and the outputs of other routines, e.g. sales by > week, > Fourie analysed amplitudes by frequency, actuarial data by age, > etc. The > patrial interval integrals, including cumulative, can be achieved by > looping > or otherwise manipulating the endpoint values. > > The best way to see its worth is to compare it to the available > routine > for existing data, by editing the "integrator_verifier" to use the > "trapz" > routine. The latter is only of first order, and even for as many as > 500 > points on [0,1] yields a 2.01e-6 relative error for the next higher > order, > the second. For higher orders higher than second it is even more > useless. > There probably should a caution appended to the instructions about > this. Douglas, It seems to me there is one detail you are missing here: experimental data are not always polynomials, actually most often you don't even have a way to tell wether they are smooth, if all you have are equispaced samples. Using a high order quadrature rule only makes sense if you know a- priori your data can be accurately approximated by a polynomial, e.g. by Taylor expansion. If you have no a-priori knowledge about the smoothness of your data, using a low order quadrature rule is a safer bet. For example consider this well known example: >> x = linspace (-1, 1, 10); >> f = @(x) 1./(1+25.*x.^2); >> F = f(x); >> integrator (F, -1, 1) ans = 0.47972 >> sum ((F(2:end)+F(1:end-1)).*diff(x)/2) ans = 0.54437 while the exact value of the integral is >> .4 * atan (5) ans = 0.54936 >> quad(f, -1, 1) ans = 0.54936 so in this case even the simple trapezoidal rule beats your 10th order method because it's based on approximating f by means of a highly- order and thus highly oscillating polynomial. So I believe your function would actually be more useful if the order of the quadrature rule to use was to be given as an input option rather than be set automatically depending on the size of the sample. HTH, c. ```

 Re: [OctDev] Developer Registration Request From: Carlo de Falco - 2009-06-02 20:30 ```On 2 Jun 2009, at 22:15, Carlo de Falco wrote: > > On 2 Jun 2009, at 21:12, dmelliott wrote: > >> >> Dear Søren, >> >> More thoughts: >> >> >> The idea of this routine is that it integrates existing data in >> its most >> ususal form. That is, it does not need a function to call, and, >> since, for >> better or for worse, most data comes on a domain of equally sized >> steps, >> this is what it uses. This is an attempt to make it compatable >> whith most >> experimantal data, and the outputs of other routines, e.g. sales by >> week, >> Fourie analysed amplitudes by frequency, actuarial data by age, >> etc. The >> patrial interval integrals, including cumulative, can be achieved >> by looping >> or otherwise manipulating the endpoint values. >> >> The best way to see its worth is to compare it to the available >> routine >> for existing data, by editing the "integrator_verifier" to use the >> "trapz" >> routine. The latter is only of first order, and even for as many >> as 500 >> points on [0,1] yields a 2.01e-6 relative error for the next higher >> order, >> the second. For higher orders higher than second it is even more >> useless. >> There probably should a caution appended to the instructions about >> this. > > Douglas, > > It seems to me there is one detail you are missing here: > experimental data are not always polynomials, actually most often > you don't even have a way to tell wether they are smooth, if all you > have are equispaced samples. > > Using a high order quadrature rule only makes sense if you know a- > priori your data can be > accurately approximated by a polynomial, e.g. by Taylor expansion. > If you have no a-priori knowledge about the smoothness of your data, > using a low order quadrature rule is a safer bet. For example > consider this well known example: > > >> x = linspace (-1, 1, 10); > >> f = @(x) 1./(1+25.*x.^2); > >> F = f(x); > >> integrator (F, -1, 1) > ans = 0.47972 > >> sum ((F(2:end)+F(1:end-1)).*diff(x)/2) > ans = 0.54437 > > while the exact value of the integral is > > >> .4 * atan (5) > ans = 0.54936 > >> quad(f, -1, 1) > ans = 0.54936 > > so in this case even the simple trapezoidal rule beats your 10th > order method because it's based on approximating f by means of a > highly-order and thus highly oscillating polynomial. > > So I believe your function would actually be more useful if the > order of the quadrature rule to use was to be given as an input > option rather than be set automatically depending on the size of the > sample. > > HTH, > c. Another, even simpler example : >> x = linspace (-1, 1, 15); >> f = @(x) abs(x); >> F = f(x); >> integrator (F, -1, 1) ans = 9.92164981733434e-01 >> sum ((F(2:end)+F(1:end-1)).*diff(x)/2) ans = 1.00000000000000e+00 >> quad(@(x) abs(x), -1, 1) ans = 1.00000000000000e+00 >> In this case, quadrature by the trapezoidal rule is exact as the integrand function is piece-wise linear while a higher order rule suffers because the first derivative has a jump so the 2nd derivative is unbounded. c. ```

 Re: [OctDev] Developer Registration Request From: dmelliott - 2009-06-04 04:13 ```Dear All, Thank you very much for giving this your consideration. Both the below and a comment by Mr. Hauberg indicate that the documentation should point out that you can not run over an integrand's singularity, x=+/-1/5 below, with a power series. The below is only one of an infinite number of functions that the proposed should not be able to handle properly. This is always the chance taken when dealing with data. This peaked my interest in just how many data points it would take to get five place accuracy for various functions for both the proposed, and the trapz, sighted below, routines. I found that for the below atan example, the proposed took 23 while the trapz took 98, for exp(-x) on [0,1] it was 5 and 41, for exp(x) on [0,1] it was 5 and ~500, and for exp(-X^2) on [0,1] it was 7 and somewhere between 100 and 200, respectively. Also, as mentioned previously, the trapz method is all but useless for simple powers of x. I don't know how quad got into the discussion, since this is about dealing with given data points, rather than functions for which the evaluation points are adjustable. I was a bit surprised at how well this did work over the singularity, but this has indeed been my experience with such things. If by higher dimensionality, you mean two or three orthogonal dimensions, that would be a very useful, but an awfully time consuming undertaking. I just do not have the time for that now. If you mean vectorized, so that several data sets could be done at the same time, this can be done. However, all the sets would have to have exactly the same number of elements. I had it this way once, but found I never took advantage of it, and the feature was just overhead. If you think this might be useful, I could try to resurrect it. With respect to a standard name, it has been way too long since I either took or taught this sort of thing, and reference to my numerical analysis texts* came up empty. This is part of why I wish to submit this; I don't see this simple but useful tool in practice. In any case, "integ1es" sounds fine to me. Yes, I would be happy to have it in the public domain. I will expand the documentation, and resubmit. O.K., so the name for the character ø is "ø". Who would have thought? Thank you for the link; I enjoyed it. From my youth in a partly Danish-American culture I knew the pronunciation, but, from the website, I was doing it wrong when it was at the end of a word, if my ears are right. Thanks again, dmelliott * Survey of Numerical Analysis, John Todd editor, McGraw-Hill Handbook of Mathematical Functions, Abramowitz and Stegun editors, National Bureau of Standards etc. ----- Original Message ----- From: Carlo de Falco To: dmelliott Cc: Søren Hauberg ; octave-dev@... Sent: Tuesday, June 02, 2009 3:15 PM Subject: Re: [OctDev] Developer Registration Request On 2 Jun 2009, at 21:12, dmelliott wrote: > > Dear Søren, > > More thoughts: > > > The idea of this routine is that it integrates existing data in > its most > ususal form. That is, it does not need a function to call, and, > since, for > better or for worse, most data comes on a domain of equally sized > steps, > this is what it uses. This is an attempt to make it compatable > whith most > experimantal data, and the outputs of other routines, e.g. sales by > week, > Fourie analysed amplitudes by frequency, actuarial data by age, > etc. The > patrial interval integrals, including cumulative, can be achieved by > looping > or otherwise manipulating the endpoint values. > > The best way to see its worth is to compare it to the available > routine > for existing data, by editing the "integrator_verifier" to use the > "trapz" > routine. The latter is only of first order, and even for as many as > 500 > points on [0,1] yields a 2.01e-6 relative error for the next higher > order, > the second. For higher orders higher than second it is even more > useless. > There probably should a caution appended to the instructions about > this. Douglas, It seems to me there is one detail you are missing here: experimental data are not always polynomials, actually most often you don't even have a way to tell wether they are smooth, if all you have are equispaced samples. Using a high order quadrature rule only makes sense if you know a- priori your data can be accurately approximated by a polynomial, e.g. by Taylor expansion. If you have no a-priori knowledge about the smoothness of your data, using a low order quadrature rule is a safer bet. For example consider this well known example: >> x = linspace (-1, 1, 10); >> f = @(x) 1./(1+25.*x.^2); >> F = f(x); >> integrator (F, -1, 1) ans = 0.47972 >> sum ((F(2:end)+F(1:end-1)).*diff(x)/2) ans = 0.54437 while the exact value of the integral is >> .4 * atan (5) ans = 0.54936 >> quad(f, -1, 1) ans = 0.54936 so in this case even the simple trapezoidal rule beats your 10th order method because it's based on approximating f by means of a highly- order and thus highly oscillating polynomial. So I believe your function would actually be more useful if the order of the quadrature rule to use was to be given as an input option rather than be set automatically depending on the size of the sample. HTH, c.= ```

 Re: [OctDev] Developer Registration Request From: Carlo de Falco - 2009-06-04 05:54 ```On 4 Jun 2009, at 06:12, dmelliott wrote: > > Dear All, > > Thank you very much for giving this your consideration. > > Both the below and a comment by Mr. Hauberg indicate that the > documentation should point out that you can not run over an > integrand's singularity, x=+/-1/5 below, > with a power series. The function 1./(1+25*x^2) does not have singularities in the interval (-1,1) the reason why this example creates trouble is more subtle. > The > below is only one of an infinite number of functions that the proposed > should not be able to handle properly. This is always the chance > taken when dealing with data. > This peaked my interest in just how many data points it would > take to get five place accuracy for various functions for both the > proposed, and the trapz, sighted below, routines. I found that for > the below atan example, the proposed took 23 while the trapz took > 98, for exp(-x) on [0,1] it was 5 and 41, for exp(x) on [0,1] it was > 5 and ~500, and for exp(-X^2) on [0,1] it was 7 and somewhere > between 100 and 200, respectively. The point I wanted to make was that, if you are dealing with experimental data, you don't always have the possibility to choose the density of your sample, you just have to do the best you can with what you have. If you have the possibility to resample, why not sample at Gauss nodes? If you only have a given set of data points and you don't know a-priori whether the function you are sampling from and its derivatives are well-behaved, then using a high order rule is not the best choice. Also, if you look at how the error for your method depends on the size of the sample you will notice that it does not always decrease by increasing the number of data points >> x = linspace (-1, 1, 5); >> f = @(x) 1./(1+25.*x.^2); >> Iex = quad(f, -1, 1) Iex = 0.54936 >> Iex - integrator (f(x), -1, 1) ans = 0.074559 >> x = linspace (-1, 1, 6); >> Iex - integrator (f(x), -1, 1) ans = 0.087822 >> x = linspace (-1, 1, 7); >> Iex - integrator (f(x), -1, 1) ans = -0.22473 It only stops increasing when the order of your quadrature formula stops increasing. > Also, as mentioned previously, > the trapz method is all but useless for simple powers of x. > I don't know how quad got into the discussion, since this is > about dealing with given data points, rather than functions for > which the evaluation points are adjustable. "quad" was only used as way to compute the "exact" integral and give an estimate of the error. > I was a bit surprised at how well this did work over the > singularity, > but this has indeed been my experience with such things. > > If by higher dimensionality, you mean two or three orthogonal > dimensions, that would be a very useful, but an awfully time consuming > undertaking. > I just do not have the time for that now. If you mean > vectorized, so that several data sets could be done at the same time, > this can be done. However, all the sets would have to have exactly > the > same number of elements. I had it this way once, but found I never > took advantage of it, and the feature was just overhead. If you think > this might be useful, I could try to resurrect it. > With respect to a standard name, it has been way too long since I > either took or taught this sort of thing, and reference to my > numerical > analysis texts* came up empty. This is part of why I wish to submit > this; I don't see this simple but useful tool in practice. > In any case, "integ1es" sounds fine to me. > Yes, I would be happy to have it in the public domain. I will > expand > the documentation, and resubmit. I think it would make sense to just describe the algorithm used in the function and provide an example application. c. > O.K., so the name for the character ø is "ø". Who would have > thought? > Thank you for the link; I enjoyed it. From my youth in a partly > Danish-American culture I knew the pronunciation, but, from the > website, > I was doing it wrong when it was at the end of a word, if my ears are > right. > > > > > Thanks again, > > dmelliott > > > > * Survey of Numerical Analysis, John Todd editor, McGraw-Hill > Handbook of Mathematical Functions, Abramowitz and Stegun editors, > National Bureau of Standards > etc. > > > > > > ----- Original Message ----- > From: Carlo de Falco > To: dmelliott > Cc: Søren Hauberg ; octave-dev@... > Sent: Tuesday, June 02, 2009 3:15 PM > Subject: Re: [OctDev] Developer Registration Request > > > > On 2 Jun 2009, at 21:12, dmelliott wrote: > >> >> Dear Søren, >> >> More thoughts: >> >> >> The idea of this routine is that it integrates existing data in >> its most >> ususal form. That is, it does not need a function to call, and, >> since, for >> better or for worse, most data comes on a domain of equally sized >> steps, >> this is what it uses. This is an attempt to make it compatable >> whith most >> experimantal data, and the outputs of other routines, e.g. sales by >> week, >> Fourie analysed amplitudes by frequency, actuarial data by age, >> etc. The >> patrial interval integrals, including cumulative, can be achieved by >> looping >> or otherwise manipulating the endpoint values. >> >> The best way to see its worth is to compare it to the available >> routine >> for existing data, by editing the "integrator_verifier" to use the >> "trapz" >> routine. The latter is only of first order, and even for as many as >> 500 >> points on [0,1] yields a 2.01e-6 relative error for the next higher >> order, >> the second. For higher orders higher than second it is even more >> useless. >> There probably should a caution appended to the instructions about >> this. > > Douglas, > > It seems to me there is one detail you are missing here: > experimental data are not always polynomials, actually most often you > don't even have a way to tell wether they are smooth, if all you have > are equispaced samples. > > Using a high order quadrature rule only makes sense if you know a- > priori your data can be > accurately approximated by a polynomial, e.g. by Taylor expansion. > If you have no a-priori knowledge about the smoothness of your data, > using a low order quadrature rule is a safer bet. For example consider > this well known example: > >>> x = linspace (-1, 1, 10); >>> f = @(x) 1./(1+25.*x.^2); >>> F = f(x); >>> integrator (F, -1, 1) > ans = 0.47972 >>> sum ((F(2:end)+F(1:end-1)).*diff(x)/2) > ans = 0.54437 > > while the exact value of the integral is > >>> .4 * atan (5) > ans = 0.54936 >>> quad(f, -1, 1) > ans = 0.54936 > > so in this case even the simple trapezoidal rule beats your 10th order > method because it's based on approximating f by means of a highly- > order and thus highly oscillating polynomial. > > So I believe your function would actually be more useful if the order > of the quadrature rule to use was to be given as an input option > rather than be set automatically depending on the size of the sample. > > HTH, > c.= > ```

 Re: [OctDev] Developer Registration Request From: dmelliott - 2009-06-04 10:58 ```Dear Søren, An example that is more often used for this kind of thing is that of fractional powers of x on (0,1). These do not have a Maclaurin series due to the infinite derivatives at x=0. Taking f=x^((2*n+1)/2), for n=0 both methods do quite poorly, needing ~10,000 points to achieve five place accuracy. For n=1, the integ1es takes 19 points while the trapz takes somewhere between 100 and 200. For n=2 through 5, it is 7 and some where between 500 and 1,000, respectively. In the atan example of last corespondence, the trapz method was said to be prefered because it gave two digit accuracy with a smaller number of points than did the integ1es. If such is the anticipated need, and it is not even this good for a number of frequently encountered distributions, then, indeed, this should be used. Possable examples are endless, but I think the point has been established. The integ1es is quite general in its aplicability. Expansions and corrections forthcoming. Cheers, dmelliott ```

 Re: [OctDev] Developer Registration Request From: dmelliott - 2009-06-05 22:48 Attachments: integ1es.zip ```Dear Søren, O.K., here is an update with a new name and docs. Cheers, dmelliott ```

 Re: [OctDev] Developer Registration Request From: dmelliott - 2009-06-05 23:15 Attachments: Message as HTML      integ1es.zip

 Re: [OctDev] Developer Registration Request From: dmelliott - 2009-06-06 22:27 ```Dear Mr. de Falco, While it does not have a singularity on the path of integration, it does at x = +/- i/5. Thus the radius of convergence, from zero, interferes with the construction of a polynomial approximation therefrom. This is also early calculus, and not subtle. In the real world data comes to you as it comes to you, usually on an equal step domain and often without tolerance (necessary for any coherent data processing). If you can convince the all manufacturers of measuring equipment to modify all their machines, I am sure we would all be better off. The Octave routines that give this type of output might be a place to start. If you have a better method for equal step integration, it would indeed be of great value. dmelliott ----- Original Message ----- From: Carlo de Falco To: dmelliott Cc: Søren Hauberg ; octave-dev@... Sent: Thursday, June 04, 2009 12:54 AM Subject: Re: [OctDev] Developer Registration Request On 4 Jun 2009, at 06:12, dmelliott wrote: > > Dear All, > > Thank you very much for giving this your consideration. > > Both the below and a comment by Mr. Hauberg indicate that the > documentation should point out that you can not run over an > integrand's singularity, x=+/-1/5 below, > with a power series. The function 1./(1+25*x^2) does not have singularities in the interval (-1,1) the reason why this example creates trouble is more subtle. > The > below is only one of an infinite number of functions that the proposed > should not be able to handle properly. This is always the chance > taken when dealing with data. > This peaked my interest in just how many data points it would > take to get five place accuracy for various functions for both the > proposed, and the trapz, sighted below, routines. I found that for > the below atan example, the proposed took 23 while the trapz took > 98, for exp(-x) on [0,1] it was 5 and 41, for exp(x) on [0,1] it was > 5 and ~500, and for exp(-X^2) on [0,1] it was 7 and somewhere > between 100 and 200, respectively. The point I wanted to make was that, if you are dealing with experimental data, you don't always have the possibility to choose the density of your sample, you just have to do the best you can with what you have. If you have the possibility to resample, why not sample at Gauss nodes? If you only have a given set of data points and you don't know a-priori whether the function you are sampling from and its derivatives are well-behaved, then using a high order rule is not the best choice. Also, if you look at how the error for your method depends on the size of the sample you will notice that it does not always decrease by increasing the number of data points >> x = linspace (-1, 1, 5); >> f = @(x) 1./(1+25.*x.^2); >> Iex = quad(f, -1, 1) Iex = 0.54936 >> Iex - integrator (f(x), -1, 1) ans = 0.074559 >> x = linspace (-1, 1, 6); >> Iex - integrator (f(x), -1, 1) ans = 0.087822 >> x = linspace (-1, 1, 7); >> Iex - integrator (f(x), -1, 1) ans = -0.22473 It only stops increasing when the order of your quadrature formula stops increasing. > Also, as mentioned previously, > the trapz method is all but useless for simple powers of x. > I don't know how quad got into the discussion, since this is > about dealing with given data points, rather than functions for > which the evaluation points are adjustable. "quad" was only used as way to compute the "exact" integral and give an estimate of the error. > I was a bit surprised at how well this did work over the > singularity, > but this has indeed been my experience with such things. > > If by higher dimensionality, you mean two or three orthogonal > dimensions, that would be a very useful, but an awfully time consuming > undertaking. > I just do not have the time for that now. If you mean > vectorized, so that several data sets could be done at the same time, > this can be done. However, all the sets would have to have exactly > the > same number of elements. I had it this way once, but found I never > took advantage of it, and the feature was just overhead. If you think > this might be useful, I could try to resurrect it. > With respect to a standard name, it has been way too long since I > either took or taught this sort of thing, and reference to my > numerical > analysis texts* came up empty. This is part of why I wish to submit > this; I don't see this simple but useful tool in practice. > In any case, "integ1es" sounds fine to me. > Yes, I would be happy to have it in the public domain. I will > expand > the documentation, and resubmit. I think it would make sense to just describe the algorithm used in the function and provide an example application. c. > O.K., so the name for the character ø is "ø". Who would have > thought? > Thank you for the link; I enjoyed it. From my youth in a partly > Danish-American culture I knew the pronunciation, but, from the > website, > I was doing it wrong when it was at the end of a word, if my ears are > right. > > > > > Thanks again, > > dmelliott > > > > * Survey of Numerical Analysis, John Todd editor, McGraw-Hill > Handbook of Mathematical Functions, Abramowitz and Stegun editors, > National Bureau of Standards > etc. > > > > > > ----- Original Message ----- > From: Carlo de Falco > To: dmelliott > Cc: Søren Hauberg ; octave-dev@... > Sent: Tuesday, June 02, 2009 3:15 PM > Subject: Re: [OctDev] Developer Registration Request > > > > On 2 Jun 2009, at 21:12, dmelliott wrote: > >> >> Dear Søren, >> >> More thoughts: >> >> >> The idea of this routine is that it integrates existing data in >> its most >> ususal form. That is, it does not need a function to call, and, >> since, for >> better or for worse, most data comes on a domain of equally sized >> steps, >> this is what it uses. This is an attempt to make it compatable >> whith most >> experimantal data, and the outputs of other routines, e.g. sales by >> week, >> Fourie analysed amplitudes by frequency, actuarial data by age, >> etc. The >> patrial interval integrals, including cumulative, can be achieved by >> looping >> or otherwise manipulating the endpoint values. >> >> The best way to see its worth is to compare it to the available >> routine >> for existing data, by editing the "integrator_verifier" to use the >> "trapz" >> routine. The latter is only of first order, and even for as many as >> 500 >> points on [0,1] yields a 2.01e-6 relative error for the next higher >> order, >> the second. For higher orders higher than second it is even more >> useless. >> There probably should a caution appended to the instructions about >> this. > > Douglas, > > It seems to me there is one detail you are missing here: > experimental data are not always polynomials, actually most often you > don't even have a way to tell wether they are smooth, if all you have > are equispaced samples. > > Using a high order quadrature rule only makes sense if you know a- > priori your data can be > accurately approximated by a polynomial, e.g. by Taylor expansion. > If you have no a-priori knowledge about the smoothness of your data, > using a low order quadrature rule is a safer bet. For example consider > this well known example: > >>> x = linspace (-1, 1, 10); >>> f = @(x) 1./(1+25.*x.^2); >>> F = f(x); >>> integrator (F, -1, 1) > ans = 0.47972 >>> sum ((F(2:end)+F(1:end-1)).*diff(x)/2) > ans = 0.54437 > > while the exact value of the integral is > >>> .4 * atan (5) > ans = 0.54936 >>> quad(f, -1, 1) > ans = 0.54936 > > so in this case even the simple trapezoidal rule beats your 10th order > method because it's based on approximating f by means of a highly- > order and thus highly oscillating polynomial. > > So I believe your function would actually be more useful if the order > of the quadrature rule to use was to be given as an input option > rather than be set automatically depending on the size of the sample. > > HTH, > c.= > ```

 Re: [OctDev] Developer Registration Request From: dmelliott - 2009-06-06 22:28 ```Dear Søren, I forgot to change the name of the demo per your instructions. Please feel free to make this and any other changes necessary to achieve standard practice conformance. dmelliott ----- Original Message ----- From: Søren Hauberg To: dmelliott Cc: octave-dev@... Sent: Tuesday, June 02, 2009 2:35 PM Subject: Re: [OctDev] Developer Registration Request tir, 02 06 2009 kl. 14:12 -0500, skrev dmelliott: > The idea of this routine is that it integrates existing data in its > most > ususal form. That is, it does not need a function to call, and, since, > for > better or for worse, most data comes on a domain of equally sized steps, > this is what it uses. This is an attempt to make it compatable whith most > experimantal data, and the outputs of other routines, e.g. sales by week, > Fourie analysed amplitudes by frequency, actuarial data by age, etc. The > patrial interval integrals, including cumulative, can be achieved by > looping > or otherwise manipulating the endpoint values. Sounds sensible. Most of the data I work with are equidistantly spaced, so I can related :-) > The best way to see its worth is to compare it to the available > routine > for existing data, by editing the "integrator_verifier" to use the "trapz" > routine. The latter is only of first order, and even for as many as 500 > points on [0,1] yields a 2.01e-6 relative error for the next higher order, > the second. For higher orders higher than second it is even more useless. > There probably should a caution appended to the instructions about this. OK. It would probably be wise to write a bit about this in the documentation of the function. Could you do this? > The problem with a copyright in the U.S. (it is different in many > other > places) is that if you do not want to spend the money to register and > fight > a challange, you may end up with a legal record of having lost a copyright > infringement suit. The government here does not proctively protect > copyright claims, even if registered. My knowledge about (and interest in) copyright law is very limited. I think it is perfectly fine if you don't want to claim copyright of some of your work. What is wrong with putting your work in the public domain, then? Then you're bypassing copyright law (as far as I understand). > With respect to the name, perhaps integratores for "integrator, even > steps", or some such thing, would be more suitable. I note that the names > in the integration package go by internal workings insted of giving a clue > as to what they are for. That is probably because several of the functions are trying to solve the exact same problem, so it is hard to come up with discriminative names for the different algorithms. Does your approach have a standard name? Can it be explained in terms commonly used in numerical integration? If so, then it might be easier to come up with a name. Also, does it work in N-dimensions? If it is only for 1D data, then it should probably end with '1' to signal this. > What is the name of the "ø" character? I have asked all my second > generation Dansk relatives, but they do not know for some reason. Well the character is named "ø" :-) The English name for the character is "o slash" (i.e. an "o" with a slash through). The sound of the character has no corresponding sound in English. Basically, that sound is not part of the English language. You can hear the different pronunciations of the letter at http://udtale.dansk.nu/ Recently, it was pointed out that we have a bug in Octave in the 'fscanf' function, that could be triggered by the letter "ø" :-) Søren ```

 Re: [OctDev] Developer Registration Request From: Søren Hauberg - 2009-06-07 09:52 ```Hi Sorry 'bout the delay in reply... 1) The package you sent contains three files: the actual function, a demo function, and some documentation. This is two files too many. The documentation should be integrated with the help text of 'integ1es'. The demo should be made part of the 'integ1es.m' file. Specifically, this file should contain something like %!demo %! ord = XXX: pick a good example value %! for pts = [2:45,100,200,500,1000,10000]; %! if (pts == 1) %! f = ((xu+xl)*0.5)^ord; %! else %! f = linspace(xl,xu,pts).^ord; %! endif %! %! I = integ1es(f,xl,xu); %! %! E = I*(ord+1)/(xu^(ord+1)-xl^(ord+1))-1; %! %! printf("Points = %5.0d I = %7.5f RelErr = %10.3g \n",pts,I,E); %! %! endfor at the end. This example will then be available when the user types 'demo integ1es'. These two changes should be made to avoid filling up the namespace. Could you make these changes? 2) Carlo, where should this function go. Is the 'integration' package a suitable place? 3) If you put these functions in the public domain then you should not include the GPL text as part of the license. You have previously said that you would like to publish this as public domain. If this still stands, then please only have the following license: ## This file is in the public domain. ## It would be appreciated if the statement of authorship is ## preserved. Please put this text _after_ the help text as otherwise it seems 'help integ1es' doesn't work. Søren lør, 06 06 2009 kl. 17:27 -0500, skrev dmelliott: > Dear Søren, > > I forgot to change the name of the demo per your instructions. Please > feel free to make this and any other changes necessary to achieve > standard practice conformance. > > dmelliott > > > > > ----- Original Message ----- > From: Søren Hauberg > To: dmelliott > Cc: octave-dev@... > Sent: Tuesday, June 02, 2009 2:35 PM > Subject: Re: [OctDev] Developer Registration Request > > > tir, 02 06 2009 kl. 14:12 -0500, skrev dmelliott: > > The idea of this routine is that it integrates existing data in its > > most > > ususal form. That is, it does not need a function to call, and, since, > > for > > better or for worse, most data comes on a domain of equally sized steps, > > this is what it uses. This is an attempt to make it compatable whith most > > experimantal data, and the outputs of other routines, e.g. sales by week, > > Fourie analysed amplitudes by frequency, actuarial data by age, etc. The > > patrial interval integrals, including cumulative, can be achieved by > > looping > > or otherwise manipulating the endpoint values. > > Sounds sensible. Most of the data I work with are equidistantly spaced, > so I can related :-) > > > The best way to see its worth is to compare it to the available > > routine > > for existing data, by editing the "integrator_verifier" to use the "trapz" > > routine. The latter is only of first order, and even for as many as 500 > > points on [0,1] yields a 2.01e-6 relative error for the next higher order, > > the second. For higher orders higher than second it is even more useless. > > There probably should a caution appended to the instructions about this. > > OK. It would probably be wise to write a bit about this in the > documentation of the function. Could you do this? > > > The problem with a copyright in the U.S. (it is different in many > > other > > places) is that if you do not want to spend the money to register and > > fight > > a challange, you may end up with a legal record of having lost a copyright > > infringement suit. The government here does not proctively protect > > copyright claims, even if registered. > > My knowledge about (and interest in) copyright law is very limited. I > think it is perfectly fine if you don't want to claim copyright of some > of your work. What is wrong with putting your work in the public domain, > then? Then you're bypassing copyright law (as far as I understand). > > > With respect to the name, perhaps integratores for "integrator, even > > steps", or some such thing, would be more suitable. I note that the names > > in the integration package go by internal workings insted of giving a clue > > as to what they are for. > > That is probably because several of the functions are trying to solve > the exact same problem, so it is hard to come up with discriminative > names for the different algorithms. Does your approach have a standard > name? Can it be explained in terms commonly used in numerical > integration? If so, then it might be easier to come up with a name. > Also, does it work in N-dimensions? If it is only for 1D data, then it > should probably end with '1' to signal this. > > > > What is the name of the "ø" character? I have asked all my second > > generation Dansk relatives, but they do not know for some reason. > > Well the character is named "ø" :-) The English name for the character > is "o slash" (i.e. an "o" with a slash through). The sound of the > character has no corresponding sound in English. Basically, that sound > is not part of the English language. You can hear the different > pronunciations of the letter at http://udtale.dansk.nu/ > Recently, it was pointed out that we have a bug in Octave in the > 'fscanf' function, that could be triggered by the letter "ø" :-) > > Søren > ```

 Re: [OctDev] Developer Registration Request From: Carlo de Falco - 2009-06-07 12:53 Attachments: integ1samp.m      Message as HTML ```On 7 Jun 2009, at 00:25, dmelliott wrote: > > Dear Mr. de Falco, > > While it does not have a singularity on the path of > integration, it does at x = +/- i/5. Thus the radius of > convergence, from zero, interferes with the construction > of a polynomial approximation therefrom. This is also > early calculus, and not subtle. > > In the real world data comes to you as it comes to you, > usually on an equal step domain and often without > tolerance (necessary for any coherent data processing). > If you can convince the all manufacturers of measuring > equipment to modify all their machines, I am sure we > would all be better off. The Octave routines that give > this type of output might be a place to start. > > If you have a better method for equal step integration, > it would indeed be of great value. > > > dmelliott On 7 Jun 2009, at 00:25, dmelliott wrote: > > Dear Mr. de Falco, > > While it does not have a singularity on the path of > integration, it does at x = +/- i/5. Thus the radius of > convergence, from zero, interferes with the construction > of a polynomial approximation therefrom. This is also > early calculus, and not subtle. The counterexample I proposed is indeed a very well-known one (usually referred to as "Runge's counterexample") you can find in any elementary text book on numerical analysis, see for example [1], page 390 example 9.3. But complex roots in the denominator do not have anything to do with the poor performance of high order Newton-Cotes formulae. The reason why Runge's function exposes the limitations of Lagrange interpolation on equispaced nodes (and therefore of quadrature rules based on this kind of interpolation) has rather to do, to put it simply, with the fact that it has large areas near the ends of the integration interval where it is nearly flat so that high order, highly oscillating polynomials are not able to approximate it correctly. You should see the same effect by substituting a gaussian curve for Runge's function in the example. > In the real world data comes to you as it comes to you, > usually on an equal step domain and often without > tolerance (necessary for any coherent data processing). > If you can convince the all manufacturers of measuring > equipment to modify all their machines, I am sure we > would all be better off. The Octave routines that give > this type of output might be a place to start. I did not object your idea to provide a function for doing quadrature on (equispaced) data samples. I just wanted to put out a warning that increasing the order of the quadrature formula does not always improve the accuracy, in the extreme case of Runge's function it's even the other way around. That being said, I have nothing to object about your approach as long as the docs explain exactly what your function is doing: it is then left to the user to apply it wisely. > If you have a better method for equal step integration, > it would indeed be of great value. My suggestion was to simply use composit formulae of a fixed order and let the users choose the order depending on whatever a-priori knowledge they might have about how the data they are analyzing were generated. An example of how to do this is in the attached function, you can see a test by typing "demo integ1samp" I'm not proposing this as a substitute for your approach, it is just a quick hack to explain my idea, do whatever you wish with it as I'm not willing to pursue this subject any further. c. > > dmelliott [1] A. Quarteroni, R. Sacco, F. Saleri, Numerical Mathematics, secon edition. Springer Verlag (2007) ```

 Re: [OctDev] Developer Registration Request From: dmelliott - 2009-06-09 09:05 ```Delay here too; new work station to set up. If MS put in any more helps, the thing wouldn't work at all. ----- Original Message ----- From: Søren Hauberg To: dmelliott Cc: octave-dev@... Sent: Sunday, June 07, 2009 4:51 AM Subject: Re: [OctDev] Developer Registration Request Hi Sorry 'bout the delay in reply... 1) The package you sent contains three files: the actual function, a demo function, and some documentation. This is two files too many. The documentation should be integrated with the help text of 'integ1es'. The demo should be made part of the 'integ1es.m' file. Specifically, this file should contain something like %!demo %! ord = XXX: pick a good example value %! for pts = [2:45,100,200,500,1000,10000]; %! if (pts == 1) %! f = ((xu+xl)*0.5)^ord; %! else %! f = linspace(xl,xu,pts).^ord; %! endif %! %! I = integ1es(f,xl,xu); %! %! E = I*(ord+1)/(xu^(ord+1)-xl^(ord+1))-1; %! %! printf("Points = %5.0d I = %7.5f RelErr = %10.3g \n",pts,I,E); %! %! endfor at the end. This example will then be available when the user types 'demo integ1es'. These two changes should be made to avoid filling up the namespace. Could you make these changes? 2) Carlo, where should this function go. Is the 'integration' package a suitable place? 3) If you put these functions in the public domain then you should not include the GPL text as part of the license. You have previously said that you would like to publish this as public domain. If this still stands, then please only have the following license: ## This file is in the public domain. ## It would be appreciated if the statement of authorship is ## preserved. Please put this text _after_ the help text as otherwise it seems 'help integ1es' doesn't work. Søren lør, 06 06 2009 kl. 17:27 -0500, skrev dmelliott: > Dear Søren, > > I forgot to change the name of the demo per your instructions. Please > feel free to make this and any other changes necessary to achieve > standard practice conformance. > > dmelliott > > > > > ----- Original Message ----- > From: Søren Hauberg > To: dmelliott > Cc: octave-dev@... > Sent: Tuesday, June 02, 2009 2:35 PM > Subject: Re: [OctDev] Developer Registration Request > > > tir, 02 06 2009 kl. 14:12 -0500, skrev dmelliott: > > The idea of this routine is that it integrates existing data in its > > most > > ususal form. That is, it does not need a function to call, and, since, > > for > > better or for worse, most data comes on a domain of equally sized steps, > > this is what it uses. This is an attempt to make it compatable whith > > most > > experimantal data, and the outputs of other routines, e.g. sales by > > week, > > Fourie analysed amplitudes by frequency, actuarial data by age, etc. > > The > > patrial interval integrals, including cumulative, can be achieved by > > looping > > or otherwise manipulating the endpoint values. > > Sounds sensible. Most of the data I work with are equidistantly spaced, > so I can related :-) > > > The best way to see its worth is to compare it to the available > > routine > > for existing data, by editing the "integrator_verifier" to use the > > "trapz" > > routine. The latter is only of first order, and even for as many as 500 > > points on [0,1] yields a 2.01e-6 relative error for the next higher > > order, > > the second. For higher orders higher than second it is even more > > useless. > > There probably should a caution appended to the instructions about this. > > OK. It would probably be wise to write a bit about this in the > documentation of the function. Could you do this? > > > The problem with a copyright in the U.S. (it is different in many > > other > > places) is that if you do not want to spend the money to register and > > fight > > a challange, you may end up with a legal record of having lost a > > copyright > > infringement suit. The government here does not proctively protect > > copyright claims, even if registered. > > My knowledge about (and interest in) copyright law is very limited. I > think it is perfectly fine if you don't want to claim copyright of some > of your work. What is wrong with putting your work in the public domain, > then? Then you're bypassing copyright law (as far as I understand). > > > With respect to the name, perhaps integratores for "integrator, even > > steps", or some such thing, would be more suitable. I note that the > > names > > in the integration package go by internal workings insted of giving a > > clue > > as to what they are for. > > That is probably because several of the functions are trying to solve > the exact same problem, so it is hard to come up with discriminative > names for the different algorithms. Does your approach have a standard > name? Can it be explained in terms commonly used in numerical > integration? If so, then it might be easier to come up with a name. > Also, does it work in N-dimensions? If it is only for 1D data, then it > should probably end with '1' to signal this. > > > > What is the name of the "ø" character? I have asked all my second > > generation Dansk relatives, but they do not know for some reason. > > Well the character is named "ø" :-) The English name for the character > is "o slash" (i.e. an "o" with a slash through). The sound of the > character has no corresponding sound in English. Basically, that sound > is not part of the English language. You can hear the different > pronunciations of the letter at http://udtale.dansk.nu/ > Recently, it was pointed out that we have a bug in Octave in the > 'fscanf' function, that could be triggered by the letter "ø" :-) > > Søren > ```

 Re: [OctDev] Developer Registration Request From: dmelliott - 2009-06-12 01:20 Attachments: Message as HTML      integ1es.zip

 Re: [OctDev] Developer Registration Request From: dmelliott - 2009-06-13 04:11 Attachments: Message as HTML      integ1es.zip

 Re: [OctDev] Developer Registration Request From: dmelliott - 2009-06-13 06:20 ```Dear All, Yes, all our texts have this example. However, the stricter criteria of the radius of convergence from any point on the real axis, x, for a power series representation of 1/(a^2+x^2), a real, being R=(x^2+a^2)^0.5 should be observed instead, since this is where it stops working. The theorem deals with where the series becomes divergent, whereas the radius of convergence indicates when the series will not be sufficiently convergent. I am having trouble understanding the statement "poor performance", since this does quite well, both on my Pentium 2 and the Core 2, although the answers are not identical. Apparently the math handling in the Core 2 is better. This does go to show that you never want to take data for an arctan process. Instead you want it to simply tell you what its functionality is, so you can better integrate it. dmelliott ________________________________________________________________ ----- Original Message ----- From: Carlo de Falco To: dmelliott Cc: Søren Hauberg ; octave-dev@... Sent: Sunday, June 07, 2009 7:47 AM Subject: Re: [OctDev] Developer Registration Request On 7 Jun 2009, at 00:25, dmelliott wrote: > > Dear Mr. de Falco, > > While it does not have a singularity on the path of > integration, it does at x = +/- i/5. Thus the radius of > convergence, from zero, interferes with the construction > of a polynomial approximation therefrom. This is also > early calculus, and not subtle. > > In the real world data comes to you as it comes to you, > usually on an equal step domain and often without > tolerance (necessary for any coherent data processing). > If you can convince the all manufacturers of measuring > equipment to modify all their machines, I am sure we > would all be better off. The Octave routines that give > this type of output might be a place to start. > > If you have a better method for equal step integration, > it would indeed be of great value. > > > dmelliott On 7 Jun 2009, at 00:25, dmelliott wrote: > > Dear Mr. de Falco, > > While it does not have a singularity on the path of > integration, it does at x = +/- i/5. Thus the radius of > convergence, from zero, interferes with the construction > of a polynomial approximation therefrom. This is also > early calculus, and not subtle. The counterexample I proposed is indeed a very well-known one (usually referred to as "Runge's counterexample") you can find in any elementary text book on numerical analysis, see for example [1], page 390 example 9.3. But complex roots in the denominator do not have anything to do with the poor performance of high order Newton-Cotes formulae. The reason why Runge's function exposes the limitations of Lagrange interpolation on equispaced nodes (and therefore of quadrature rules based on this kind of interpolation) has rather to do, to put it simply, with the fact that it has large areas near the ends of the integration interval where it is nearly flat so that high order, highly oscillating polynomials are not able to approximate it correctly. You should see the same effect by substituting a gaussian curve for Runge's function in the example. > In the real world data comes to you as it comes to you, > usually on an equal step domain and often without > tolerance (necessary for any coherent data processing). > If you can convince the all manufacturers of measuring > equipment to modify all their machines, I am sure we > would all be better off. The Octave routines that give > this type of output might be a place to start. I did not object your idea to provide a function for doing quadrature on (equispaced) data samples. I just wanted to put out a warning that increasing the order of the quadrature formula does not always improve the accuracy, in the extreme case of Runge's function it's even the other way around. That being said, I have nothing to object about your approach as long as the docs explain exactly what your function is doing: it is then left to the user to apply it wisely. > If you have a better method for equal step integration, > it would indeed be of great value. My suggestion was to simply use composit formulae of a fixed order and let the users choose the order depending on whatever a-priori knowledge they might have about how the data they are analyzing were generated. An example of how to do this is in the attached function, you can see a test by typing "demo integ1samp" I'm not proposing this as a substitute for your approach, it is just a quick hack to explain my idea, do whatever you wish with it as I'm not willing to pursue this subject any further. c. > > dmelliott [1] A. Quarteroni, R. Sacco, F. Saleri, Numerical Mathematics, secon edition. Springer Verlag (2007) ```

 Re: [OctDev] Developer Registration Request From: dmelliott - 2009-06-13 06:37 Attachments: integ1es.zip ```Dear Søren, Wait, wait! Too many versions hanging around. I picked the wrong one. This should work. Sorry, my fault. dmelliott ```

 Re: [OctDev] Developer Registration Request From: dmelliott - 2009-06-13 13:01 Attachments: integ1es.zip ```Is this guy ever going to get it right? ```

 Re: [OctDev] Developer Registration Request From: Søren Hauberg - 2009-06-13 20:50 ```lør, 13 06 2009 kl. 07:31 -0500, skrev dmelliott: > Is this guy ever going to get it right? :-) I'm sorry to keep bringing up small issues -- I truly hope this doesn't scare you from contributing. That being said I have three comments 1) In the license you write: "This file is distributed with Octave." This is not true. When we add the function to a package it will be distributed with the package, which is not "Octave". This is just a minor detail, but the line should be removed. 2) I still do not think the 'test_integ1es' function should be included. It seems like a demonstration to me, and not a function anybody would be using in their own programs. Is this true, or am I missing something? If it is true, then it would be better to add the example as a demo. We already have too many '_test' functions in various packages. These are but a remedy of old days. 3) You do not need to add semi-colons after keywords such as 'endif', 'endfunction', etc. I don't care if you add or remove these semi-colons, I just thought you should know that you do not need them :-) Other than these minor issues, I think your code looks good. Thanks for doing this :-) Søren ```

 Re: [OctDev] Developer Registration Request From: dmelliott - 2009-06-14 02:48 ```Dear Søren, Please feel more than free to bring up any issue of compliance. Learning how to do this was my goal for this submission. Having been, among many other things, a QA Manager, I am quite sensitive to document control, and understand the importance of document uniformity. Please feel totally free, especially with my terrible spelling, and poor typing. 1) Gone. Need incorrectly assumed. Does the 'help' work for you in the last submission? 3) I understand the lack of requirement. I use it just because I find it helpful to myself. Also gone. 2) Finally found the 'demo' documentation, sorry. Will get back to you on this. Question about these E-Mails. I keep changing them to 'plain text' because of a poor looking "Help" posting I once had, and trying to chop things off at 80 characters. Besides finding this something of a bother, I can't believe that people are not using one of the many, free E-Mail programs that do perfectly well with HTML (even if the forum doesn't). Can I stop doing this? Yours truly, dmelliott ----- Original Message ----- From: Søren Hauberg To: dmelliott Cc: octave-dev@... Sent: Saturday, June 13, 2009 3:50 PM Subject: Re: [OctDev] Developer Registration Request lør, 13 06 2009 kl. 07:31 -0500, skrev dmelliott: > Is this guy ever going to get it right? :-) I'm sorry to keep bringing up small issues -- I truly hope this doesn't scare you from contributing. That being said I have three comments 1) In the license you write: "This file is distributed with Octave." This is not true. When we add the function to a package it will be distributed with the package, which is not "Octave". This is just a minor detail, but the line should be removed. 2) I still do not think the 'test_integ1es' function should be included. It seems like a demonstration to me, and not a function anybody would be using in their own programs. Is this true, or am I missing something? If it is true, then it would be better to add the example as a demo. We already have too many '_test' functions in various packages. These are but a remedy of old days. 3) You do not need to add semi-colons after keywords such as 'endif', 'endfunction', etc. I don't care if you add or remove these semi-colons, I just thought you should know that you do not need them :-) Other than these minor issues, I think your code looks good. Thanks for doing this :-) Søren ```

 Re: [OctDev] Developer Registration Request From: Søren Hauberg - 2009-06-14 10:11 ```lør, 13 06 2009 kl. 21:48 -0500, skrev dmelliott: > Please feel more than free to bring up any issue of compliance. > Learning how to do this was my goal for this submission. Having been, among > many other things, a QA Manager, I am quite sensitive to document control, > and understand the importance of document uniformity. Please feel totally > free, especially with my terrible spelling, and poor typing. Usually, we only have minimal QA here at Octave-Forge, whereas things are controlled more thoroughly at Octave. I mainly reacted to the license issues (with this point, we need to show some caution), and then I thought I might as well comment on your code :-) > 1) Gone. Need incorrectly assumed. Does the 'help' work for you in the > last submission? Actually, no. You're missing a "@end deftypefn" at the end of the help text. > 3) I understand the lack of requirement. I use it just because I find it > helpful to myself. Also gone. If you find it more clear with the semi-colons in the end, then by all means keep them. The Octave coding style requires that you remove them, but we don't enforce that style here at Octave-Forge. > 2) Finally found the 'demo' documentation, sorry. Will get back to you on > this. Oh, I'm sorry, I should have posted a link or something to show you how demos are made. > Question about these E-Mails. I keep changing them to 'plain text' > because of a poor looking "Help" posting I once had, and trying to chop > things off at 80 characters. Besides finding this something of a bother, I > can't believe that people are not using one of the many, free E-Mail > programs that do perfectly well with HTML (even if the forum doesn't). Can > I stop doing this? I'm sorry, I don't understand the question. Are you receiving mail that is formated as HTML or something like that? Søren ```

 Re: [OctDev] Developer Registration Request From: dmelliott - 2009-06-16 09:52 Attachments: integ1es.zip ```Dear Søren, O.K., let's give this a try. The demo is changed. See if it is O.K., if you would (works on my Pentium II). No, it is not that I am getting things in HTML, although I wish I was. It is that Octave is the only recipient that I write to that seems to want 'plain text'. I can't believe that anybody still does E-Mail in plain text; gopher? Even my spell checker does not work with plain text. HTML is much easier to read, and has the normal facilities for written documents. So the question is: do you prefer to receive things in 'plain text'? Cheers, dmelliott __________________________________________________________ ----- Original Message ----- From: Søren Hauberg To: dmelliott Cc: octave-dev@... Sent: Sunday, June 14, 2009 5:10 AM Subject: Re: [OctDev] Developer Registration Request lør, 13 06 2009 kl. 21:48 -0500, skrev dmelliott: > Please feel more than free to bring up any issue of compliance. > Learning how to do this was my goal for this submission. Having been, > among > many other things, a QA Manager, I am quite sensitive to document control, > and understand the importance of document uniformity. Please feel totally > free, especially with my terrible spelling, and poor typing. Usually, we only have minimal QA here at Octave-Forge, whereas things are controlled more thoroughly at Octave. I mainly reacted to the license issues (with this point, we need to show some caution), and then I thought I might as well comment on your code :-) > 1) Gone. Need incorrectly assumed. Does the 'help' work for you in the > last submission? Actually, no. You're missing a "@end deftypefn" at the end of the help text. > 3) I understand the lack of requirement. I use it just because I find it > helpful to myself. Also gone. If you find it more clear with the semi-colons in the end, then by all means keep them. The Octave coding style requires that you remove them, but we don't enforce that style here at Octave-Forge. > 2) Finally found the 'demo' documentation, sorry. Will get back to you > on > this. Oh, I'm sorry, I should have posted a link or something to show you how demos are made. > Question about these E-Mails. I keep changing them to 'plain text' > because of a poor looking "Help" posting I once had, and trying to chop > things off at 80 characters. Besides finding this something of a bother, > I > can't believe that people are not using one of the many, free E-Mail > programs that do perfectly well with HTML (even if the forum doesn't). > Can > I stop doing this? I'm sorry, I don't understand the question. Are you receiving mail that is formated as HTML or something like that? Søren ```

 Re: [OctDev] Developer Registration Request From: Søren Hauberg - 2009-06-16 14:11 ```tir, 16 06 2009 kl. 04:50 -0500, skrev dmelliott: > O.K., let's give this a try. The demo is changed. See if it is O.K., > if you would (works on my Pentium II). This looks fine to me, although you should use '%!demo' rather than '%! test' -- the latter is for unit testing, whereas '%!demo' is for demonstrating function usage. I've made this change and submited the function to the 'integration' package in SVN. > No, it is not that I am getting things in HTML, although I wish I was. > It is that Octave is the only recipient that I write to that seems to want > 'plain text'. I can't believe that anybody still does E-Mail in plain text; > gopher? Even my spell checker does not work with plain text. HTML is much > easier to read, and has the normal facilities for written documents. You are the first person I have ever heard say this. To me it sounds as if you have a really bad e-mail client. > So the question is: do you prefer to receive things in 'plain text'? Yes. I think _all_ mailing lists out there prefers this. It it the common way of doing things. Søren ```