Hi,
I noticed that you have code where fields and constructor arguments have the same name. As far as I remember that is not good practise, but I might be wrong :-)? Cheers, Mikkel. 2011/1/30 <[hidden email]>: > Author: erans > Date: Sat Jan 29 23:38:39 2011 > New Revision: 1065146 > > URL: http://svn.apache.org/viewvc?rev=1065146&view=rev > Log: > MATH-503 > Added sigmoid and generalized logistic functions. > > Added: > commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/function/Logistic.java (with props) > commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/function/Sigmoid.java (with props) > commons/proper/math/trunk/src/test/java/org/apache/commons/math/analysis/function/ > commons/proper/math/trunk/src/test/java/org/apache/commons/math/analysis/function/LogisticTest.java (with props) > commons/proper/math/trunk/src/test/java/org/apache/commons/math/analysis/function/SigmoidTest.java (with props) > > Added: commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/function/Logistic.java > URL: http://svn.apache.org/viewvc/commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/function/Logistic.java?rev=1065146&view=auto > ============================================================================== > --- commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/function/Logistic.java (added) > +++ commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/function/Logistic.java Sat Jan 29 23:38:39 2011 > @@ -0,0 +1,78 @@ > +/* > + * Licensed to the Apache Software Foundation (ASF) under one or more > + * contributor license agreements. See the NOTICE file distributed with > + * this work for additional information regarding copyright ownership. > + * The ASF licenses this file to You under the Apache License, Version 2.0 > + * (the "License"); you may not use this file except in compliance with > + * the License. You may obtain a copy of the License at > + * > + * http://www.apache.org/licenses/LICENSE-2.0 > + * > + * Unless required by applicable law or agreed to in writing, software > + * distributed under the License is distributed on an "AS IS" BASIS, > + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. > + * See the License for the specific language governing permissions and > + * limitations under the License. > + */ > + > +package org.apache.commons.math.analysis.function; > + > +import org.apache.commons.math.analysis.UnivariateRealFunction; > +import org.apache.commons.math.exception.NotStrictlyPositiveException; > +import org.apache.commons.math.util.FastMath; > + > +/** > + * <a href="http://en.wikipedia.org/wiki/Generalised_logistic_function"> > + * Generalised logistic</a> function. > + * > + * @version $Revision$ $Date$ > + * @since 3.0 > + */ > +public class Logistic implements UnivariateRealFunction { > + /** Lower asymptote. */ > + private final double a; > + /** Upper asymptote. */ > + private final double k; > + /** Growth rate. */ > + private final double b; > + /** Parameter that affects near which asymptote maximum growth occurs. */ > + private final double n; > + /** Parameter that affects the position of the curve along the ordinate axis. */ > + private final double q; > + /** Abscissa of maximum growth. */ > + private final double m; > + > + /** > + * @param k Upper asymptote. > + * @param m Abscissa of maximum growth. > + * @param b Growth rate. > + * @param q Parameter that affects the position of the curve along the > + * ordinate axis. > + * @param a Lower asymptote. > + * @param n Parameter that affects near which asymptote the maximum > + * growth occurs. > + * @throws NotStrictlyPositiveException if {@code n <= 0}. > + */ > + public Logistic(double k, > + double m, > + double b, > + double q, > + double a, > + double n) { > + if (n <= 0) { > + throw new NotStrictlyPositiveException(n); > + } > + > + this.k = k; > + this.m = m; > + this.b = b; > + this.q = q; > + this.a = a; > + this.n = n; > + } > + > + /** {@inheritDoc} */ > + public double value(double x) { > + return a + (k - a) / FastMath.pow((1 + q * FastMath.exp(b * (m - x))), 1 / n); > + } > +} > > Propchange: commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/function/Logistic.java > ------------------------------------------------------------------------------ > svn:eol-style = native > > Added: commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/function/Sigmoid.java > URL: http://svn.apache.org/viewvc/commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/function/Sigmoid.java?rev=1065146&view=auto > ============================================================================== > --- commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/function/Sigmoid.java (added) > +++ commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/function/Sigmoid.java Sat Jan 29 23:38:39 2011 > @@ -0,0 +1,38 @@ > +/* > + * Licensed to the Apache Software Foundation (ASF) under one or more > + * contributor license agreements. See the NOTICE file distributed with > + * this work for additional information regarding copyright ownership. > + * The ASF licenses this file to You under the Apache License, Version 2.0 > + * (the "License"); you may not use this file except in compliance with > + * the License. You may obtain a copy of the License at > + * > + * http://www.apache.org/licenses/LICENSE-2.0 > + * > + * Unless required by applicable law or agreed to in writing, software > + * distributed under the License is distributed on an "AS IS" BASIS, > + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. > + * See the License for the specific language governing permissions and > + * limitations under the License. > + */ > + > +package org.apache.commons.math.analysis.function; > + > +import org.apache.commons.math.analysis.UnivariateRealFunction; > +import org.apache.commons.math.exception.NotStrictlyPositiveException; > +import org.apache.commons.math.util.FastMath; > + > +/** > + * <a href="http://en.wikipedia.org/wiki/Sigmoid_function"> > + * Sigmoid</a> function. > + * A more flexible version, the generalised logistic, is implemented > + * by the {@link Logistic} class. > + * > + * @version $Revision$ $Date$ > + * @since 3.0 > + */ > +public class Sigmoid implements UnivariateRealFunction { > + /** {@inheritDoc} */ > + public double value(double x) { > + return 1 / (1 + FastMath.exp(-x)); > + } > +} > > Propchange: commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/function/Sigmoid.java > ------------------------------------------------------------------------------ > svn:eol-style = native > > Added: commons/proper/math/trunk/src/test/java/org/apache/commons/math/analysis/function/LogisticTest.java > URL: http://svn.apache.org/viewvc/commons/proper/math/trunk/src/test/java/org/apache/commons/math/analysis/function/LogisticTest.java?rev=1065146&view=auto > ============================================================================== > --- commons/proper/math/trunk/src/test/java/org/apache/commons/math/analysis/function/LogisticTest.java (added) > +++ commons/proper/math/trunk/src/test/java/org/apache/commons/math/analysis/function/LogisticTest.java Sat Jan 29 23:38:39 2011 > @@ -0,0 +1,84 @@ > +/* > + * Licensed to the Apache Software Foundation (ASF) under one or more > + * contributor license agreements. See the NOTICE file distributed with > + * this work for additional information regarding copyright ownership. > + * The ASF licenses this file to You under the Apache License, Version 2.0 > + * (the "License"); you may not use this file except in compliance with > + * the License. You may obtain a copy of the License at > + * > + * http://www.apache.org/licenses/LICENSE-2.0 > + * > + * Unless required by applicable law or agreed to in writing, software > + * distributed under the License is distributed on an "AS IS" BASIS, > + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. > + * See the License for the specific language governing permissions and > + * limitations under the License. > + */ > + > +package org.apache.commons.math.analysis.function; > + > +import org.apache.commons.math.analysis.UnivariateRealFunction; > +import org.apache.commons.math.exception.NotStrictlyPositiveException; > +import org.apache.commons.math.util.FastMath; > + > +import org.junit.Assert; > +import org.junit.Test; > + > +/** > + * Test for class {@link Logistic}. > + */ > +public class LogisticTest { > + private final double EPS = Math.ulp(1d); > + > + @Test > + public void testPreconditions() { > + try { > + final UnivariateRealFunction f = new Logistic(1, 0, 1, 1, 0, -1); > + } catch (NotStrictlyPositiveException e) { > + // Expected. > + } > + > + try { > + final UnivariateRealFunction f = new Logistic(1, 0, 1, 1, 0, 0); > + } catch (NotStrictlyPositiveException e) { > + // Expected. > + } > + } > + > + @Test > + public void testCompareSigmoid() { > + final UnivariateRealFunction sig = new Sigmoid(); > + final UnivariateRealFunction sigL = new Logistic(1, 0, 1, 1, 0, 1); > + > + final double min = -2; > + final double max = 2; > + final int n = 100; > + final double delta = (max - min) / n; > + for (int i = 0; i < n; i++) { > + final double x = min + i * delta; > + Assert.assertEquals("x=" + x, sig.value(x), sigL.value(x), EPS); > + } > + } > + > + @Test > + public void testSomeValues() { > + final double k = 4; > + final double m = 5; > + final double b = 2; > + final double q = 3; > + final double a = -1; > + final double n = 2; > + > + final UnivariateRealFunction f = new Logistic(k, m, b, q, a, n); > + > + double x; > + x = m; > + Assert.assertEquals("x=" + x, a + (k - a) / FastMath.sqrt(1 + q), f.value(x), EPS); > + > + x = Double.NEGATIVE_INFINITY; > + Assert.assertEquals("x=" + x, a, f.value(x), EPS); > + > + x = Double.POSITIVE_INFINITY; > + Assert.assertEquals("x=" + x, k, f.value(x), EPS); > + } > +} > > Propchange: commons/proper/math/trunk/src/test/java/org/apache/commons/math/analysis/function/LogisticTest.java > ------------------------------------------------------------------------------ > svn:eol-style = native > > Added: commons/proper/math/trunk/src/test/java/org/apache/commons/math/analysis/function/SigmoidTest.java > URL: http://svn.apache.org/viewvc/commons/proper/math/trunk/src/test/java/org/apache/commons/math/analysis/function/SigmoidTest.java?rev=1065146&view=auto > ============================================================================== > --- commons/proper/math/trunk/src/test/java/org/apache/commons/math/analysis/function/SigmoidTest.java (added) > +++ commons/proper/math/trunk/src/test/java/org/apache/commons/math/analysis/function/SigmoidTest.java Sat Jan 29 23:38:39 2011 > @@ -0,0 +1,47 @@ > +/* > + * Licensed to the Apache Software Foundation (ASF) under one or more > + * contributor license agreements. See the NOTICE file distributed with > + * this work for additional information regarding copyright ownership. > + * The ASF licenses this file to You under the Apache License, Version 2.0 > + * (the "License"); you may not use this file except in compliance with > + * the License. You may obtain a copy of the License at > + * > + * http://www.apache.org/licenses/LICENSE-2.0 > + * > + * Unless required by applicable law or agreed to in writing, software > + * distributed under the License is distributed on an "AS IS" BASIS, > + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. > + * See the License for the specific language governing permissions and > + * limitations under the License. > + */ > + > +package org.apache.commons.math.analysis.function; > + > +import org.apache.commons.math.analysis.UnivariateRealFunction; > +import org.apache.commons.math.exception.NotStrictlyPositiveException; > +import org.apache.commons.math.util.FastMath; > + > +import org.junit.Assert; > +import org.junit.Test; > + > +/** > + * Test for class {@link Sigmoid}. > + */ > +public class SigmoidTest { > + private final double EPS = Math.ulp(1d); > + > + @Test > + public void testSomeValues() { > + final UnivariateRealFunction f = new Sigmoid(); > + > + double x; > + x = 0; > + Assert.assertEquals("x=" + x, 0.5, f.value(x), EPS); > + > + x = Double.NEGATIVE_INFINITY; > + Assert.assertEquals("x=" + x, 0, f.value(x), EPS); > + > + x = Double.POSITIVE_INFINITY; > + Assert.assertEquals("x=" + x, 1, f.value(x), EPS); > + } > +} > > Propchange: commons/proper/math/trunk/src/test/java/org/apache/commons/math/analysis/function/SigmoidTest.java > ------------------------------------------------------------------------------ > svn:eol-style = native > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
It used to be dubious practice, but now that IDEs can provide an error
for this case, it is IMO back to being good practice (in that its easy to read and understand, and follows the Sun conventions) Stephen On 30 January 2011 13:22, Mikkel Meyer Andersen <[hidden email]> wrote: > Hi, > > I noticed that you have code where fields and constructor arguments > have the same name. As far as I remember that is not good practise, > but I might be wrong :-)? > > Cheers, Mikkel. > > 2011/1/30 <[hidden email]>: >> Author: erans >> Date: Sat Jan 29 23:38:39 2011 >> New Revision: 1065146 >> >> URL: http://svn.apache.org/viewvc?rev=1065146&view=rev >> Log: >> MATH-503 >> Added sigmoid and generalized logistic functions. >> >> Added: >> commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/function/Logistic.java (with props) >> commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/function/Sigmoid.java (with props) >> commons/proper/math/trunk/src/test/java/org/apache/commons/math/analysis/function/ >> commons/proper/math/trunk/src/test/java/org/apache/commons/math/analysis/function/LogisticTest.java (with props) >> commons/proper/math/trunk/src/test/java/org/apache/commons/math/analysis/function/SigmoidTest.java (with props) >> >> Added: commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/function/Logistic.java >> URL: http://svn.apache.org/viewvc/commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/function/Logistic.java?rev=1065146&view=auto >> ============================================================================== >> --- commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/function/Logistic.java (added) >> +++ commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/function/Logistic.java Sat Jan 29 23:38:39 2011 >> @@ -0,0 +1,78 @@ >> +/* >> + * Licensed to the Apache Software Foundation (ASF) under one or more >> + * contributor license agreements. See the NOTICE file distributed with >> + * this work for additional information regarding copyright ownership. >> + * The ASF licenses this file to You under the Apache License, Version 2.0 >> + * (the "License"); you may not use this file except in compliance with >> + * the License. You may obtain a copy of the License at >> + * >> + * http://www.apache.org/licenses/LICENSE-2.0 >> + * >> + * Unless required by applicable law or agreed to in writing, software >> + * distributed under the License is distributed on an "AS IS" BASIS, >> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. >> + * See the License for the specific language governing permissions and >> + * limitations under the License. >> + */ >> + >> +package org.apache.commons.math.analysis.function; >> + >> +import org.apache.commons.math.analysis.UnivariateRealFunction; >> +import org.apache.commons.math.exception.NotStrictlyPositiveException; >> +import org.apache.commons.math.util.FastMath; >> + >> +/** >> + * <a href="http://en.wikipedia.org/wiki/Generalised_logistic_function"> >> + * Generalised logistic</a> function. >> + * >> + * @version $Revision$ $Date$ >> + * @since 3.0 >> + */ >> +public class Logistic implements UnivariateRealFunction { >> + /** Lower asymptote. */ >> + private final double a; >> + /** Upper asymptote. */ >> + private final double k; >> + /** Growth rate. */ >> + private final double b; >> + /** Parameter that affects near which asymptote maximum growth occurs. */ >> + private final double n; >> + /** Parameter that affects the position of the curve along the ordinate axis. */ >> + private final double q; >> + /** Abscissa of maximum growth. */ >> + private final double m; >> + >> + /** >> + * @param k Upper asymptote. >> + * @param m Abscissa of maximum growth. >> + * @param b Growth rate. >> + * @param q Parameter that affects the position of the curve along the >> + * ordinate axis. >> + * @param a Lower asymptote. >> + * @param n Parameter that affects near which asymptote the maximum >> + * growth occurs. >> + * @throws NotStrictlyPositiveException if {@code n <= 0}. >> + */ >> + public Logistic(double k, >> + double m, >> + double b, >> + double q, >> + double a, >> + double n) { >> + if (n <= 0) { >> + throw new NotStrictlyPositiveException(n); >> + } >> + >> + this.k = k; >> + this.m = m; >> + this.b = b; >> + this.q = q; >> + this.a = a; >> + this.n = n; >> + } >> + >> + /** {@inheritDoc} */ >> + public double value(double x) { >> + return a + (k - a) / FastMath.pow((1 + q * FastMath.exp(b * (m - x))), 1 / n); >> + } >> +} >> >> Propchange: commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/function/Logistic.java >> ------------------------------------------------------------------------------ >> svn:eol-style = native >> >> Added: commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/function/Sigmoid.java >> URL: http://svn.apache.org/viewvc/commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/function/Sigmoid.java?rev=1065146&view=auto >> ============================================================================== >> --- commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/function/Sigmoid.java (added) >> +++ commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/function/Sigmoid.java Sat Jan 29 23:38:39 2011 >> @@ -0,0 +1,38 @@ >> +/* >> + * Licensed to the Apache Software Foundation (ASF) under one or more >> + * contributor license agreements. See the NOTICE file distributed with >> + * this work for additional information regarding copyright ownership. >> + * The ASF licenses this file to You under the Apache License, Version 2.0 >> + * (the "License"); you may not use this file except in compliance with >> + * the License. You may obtain a copy of the License at >> + * >> + * http://www.apache.org/licenses/LICENSE-2.0 >> + * >> + * Unless required by applicable law or agreed to in writing, software >> + * distributed under the License is distributed on an "AS IS" BASIS, >> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. >> + * See the License for the specific language governing permissions and >> + * limitations under the License. >> + */ >> + >> +package org.apache.commons.math.analysis.function; >> + >> +import org.apache.commons.math.analysis.UnivariateRealFunction; >> +import org.apache.commons.math.exception.NotStrictlyPositiveException; >> +import org.apache.commons.math.util.FastMath; >> + >> +/** >> + * <a href="http://en.wikipedia.org/wiki/Sigmoid_function"> >> + * Sigmoid</a> function. >> + * A more flexible version, the generalised logistic, is implemented >> + * by the {@link Logistic} class. >> + * >> + * @version $Revision$ $Date$ >> + * @since 3.0 >> + */ >> +public class Sigmoid implements UnivariateRealFunction { >> + /** {@inheritDoc} */ >> + public double value(double x) { >> + return 1 / (1 + FastMath.exp(-x)); >> + } >> +} >> >> Propchange: commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/function/Sigmoid.java >> ------------------------------------------------------------------------------ >> svn:eol-style = native >> >> Added: commons/proper/math/trunk/src/test/java/org/apache/commons/math/analysis/function/LogisticTest.java >> URL: http://svn.apache.org/viewvc/commons/proper/math/trunk/src/test/java/org/apache/commons/math/analysis/function/LogisticTest.java?rev=1065146&view=auto >> ============================================================================== >> --- commons/proper/math/trunk/src/test/java/org/apache/commons/math/analysis/function/LogisticTest.java (added) >> +++ commons/proper/math/trunk/src/test/java/org/apache/commons/math/analysis/function/LogisticTest.java Sat Jan 29 23:38:39 2011 >> @@ -0,0 +1,84 @@ >> +/* >> + * Licensed to the Apache Software Foundation (ASF) under one or more >> + * contributor license agreements. See the NOTICE file distributed with >> + * this work for additional information regarding copyright ownership. >> + * The ASF licenses this file to You under the Apache License, Version 2.0 >> + * (the "License"); you may not use this file except in compliance with >> + * the License. You may obtain a copy of the License at >> + * >> + * http://www.apache.org/licenses/LICENSE-2.0 >> + * >> + * Unless required by applicable law or agreed to in writing, software >> + * distributed under the License is distributed on an "AS IS" BASIS, >> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. >> + * See the License for the specific language governing permissions and >> + * limitations under the License. >> + */ >> + >> +package org.apache.commons.math.analysis.function; >> + >> +import org.apache.commons.math.analysis.UnivariateRealFunction; >> +import org.apache.commons.math.exception.NotStrictlyPositiveException; >> +import org.apache.commons.math.util.FastMath; >> + >> +import org.junit.Assert; >> +import org.junit.Test; >> + >> +/** >> + * Test for class {@link Logistic}. >> + */ >> +public class LogisticTest { >> + private final double EPS = Math.ulp(1d); >> + >> + @Test >> + public void testPreconditions() { >> + try { >> + final UnivariateRealFunction f = new Logistic(1, 0, 1, 1, 0, -1); >> + } catch (NotStrictlyPositiveException e) { >> + // Expected. >> + } >> + >> + try { >> + final UnivariateRealFunction f = new Logistic(1, 0, 1, 1, 0, 0); >> + } catch (NotStrictlyPositiveException e) { >> + // Expected. >> + } >> + } >> + >> + @Test >> + public void testCompareSigmoid() { >> + final UnivariateRealFunction sig = new Sigmoid(); >> + final UnivariateRealFunction sigL = new Logistic(1, 0, 1, 1, 0, 1); >> + >> + final double min = -2; >> + final double max = 2; >> + final int n = 100; >> + final double delta = (max - min) / n; >> + for (int i = 0; i < n; i++) { >> + final double x = min + i * delta; >> + Assert.assertEquals("x=" + x, sig.value(x), sigL.value(x), EPS); >> + } >> + } >> + >> + @Test >> + public void testSomeValues() { >> + final double k = 4; >> + final double m = 5; >> + final double b = 2; >> + final double q = 3; >> + final double a = -1; >> + final double n = 2; >> + >> + final UnivariateRealFunction f = new Logistic(k, m, b, q, a, n); >> + >> + double x; >> + x = m; >> + Assert.assertEquals("x=" + x, a + (k - a) / FastMath.sqrt(1 + q), f.value(x), EPS); >> + >> + x = Double.NEGATIVE_INFINITY; >> + Assert.assertEquals("x=" + x, a, f.value(x), EPS); >> + >> + x = Double.POSITIVE_INFINITY; >> + Assert.assertEquals("x=" + x, k, f.value(x), EPS); >> + } >> +} >> >> Propchange: commons/proper/math/trunk/src/test/java/org/apache/commons/math/analysis/function/LogisticTest.java >> ------------------------------------------------------------------------------ >> svn:eol-style = native >> >> Added: commons/proper/math/trunk/src/test/java/org/apache/commons/math/analysis/function/SigmoidTest.java >> URL: http://svn.apache.org/viewvc/commons/proper/math/trunk/src/test/java/org/apache/commons/math/analysis/function/SigmoidTest.java?rev=1065146&view=auto >> ============================================================================== >> --- commons/proper/math/trunk/src/test/java/org/apache/commons/math/analysis/function/SigmoidTest.java (added) >> +++ commons/proper/math/trunk/src/test/java/org/apache/commons/math/analysis/function/SigmoidTest.java Sat Jan 29 23:38:39 2011 >> @@ -0,0 +1,47 @@ >> +/* >> + * Licensed to the Apache Software Foundation (ASF) under one or more >> + * contributor license agreements. See the NOTICE file distributed with >> + * this work for additional information regarding copyright ownership. >> + * The ASF licenses this file to You under the Apache License, Version 2.0 >> + * (the "License"); you may not use this file except in compliance with >> + * the License. You may obtain a copy of the License at >> + * >> + * http://www.apache.org/licenses/LICENSE-2.0 >> + * >> + * Unless required by applicable law or agreed to in writing, software >> + * distributed under the License is distributed on an "AS IS" BASIS, >> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. >> + * See the License for the specific language governing permissions and >> + * limitations under the License. >> + */ >> + >> +package org.apache.commons.math.analysis.function; >> + >> +import org.apache.commons.math.analysis.UnivariateRealFunction; >> +import org.apache.commons.math.exception.NotStrictlyPositiveException; >> +import org.apache.commons.math.util.FastMath; >> + >> +import org.junit.Assert; >> +import org.junit.Test; >> + >> +/** >> + * Test for class {@link Sigmoid}. >> + */ >> +public class SigmoidTest { >> + private final double EPS = Math.ulp(1d); >> + >> + @Test >> + public void testSomeValues() { >> + final UnivariateRealFunction f = new Sigmoid(); >> + >> + double x; >> + x = 0; >> + Assert.assertEquals("x=" + x, 0.5, f.value(x), EPS); >> + >> + x = Double.NEGATIVE_INFINITY; >> + Assert.assertEquals("x=" + x, 0, f.value(x), EPS); >> + >> + x = Double.POSITIVE_INFINITY; >> + Assert.assertEquals("x=" + x, 1, f.value(x), EPS); >> + } >> +} >> >> Propchange: commons/proper/math/trunk/src/test/java/org/apache/commons/math/analysis/function/SigmoidTest.java >> ------------------------------------------------------------------------------ >> svn:eol-style = native >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
In reply to this post by Mikkel Meyer Andersen-2
Hello.
> I noticed that you have code where fields and constructor arguments > have the same name. As far as I remember that is not good practise, > but I might be wrong :-)? Most (all?) of CM follows this convention. [Personally I prefer that fieds use names prefixed by an underscore character so that when method or constructor arguments reflect the meaning of those fields, one does not have to use the "this" keyword (i.e. I use the convention where the '_' character means "This is an instance variable").] Regards, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
Hi,
2011/1/30 Gilles Sadowski <[hidden email]>: > Hello. > >> I noticed that you have code where fields and constructor arguments >> have the same name. As far as I remember that is not good practise, >> but I might be wrong :-)? > > Most (all?) of CM follows this convention. Just to be sure: Do you mean that in most of CM, parameter and field names coincide? Cheers, Mikkel. > > [Personally I prefer that fieds use names prefixed by an underscore > character so that when method or constructor arguments reflect the meaning > of those fields, one does not have to use the "this" keyword (i.e. I use the > convention where the '_' character means "This is an instance variable").] > > > Regards, > Gilles > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
On Sun, Jan 30, 2011 at 02:58:43PM +0100, Mikkel Meyer Andersen wrote:
> Hi, > > 2011/1/30 Gilles Sadowski <[hidden email]>: > > Hello. > > > >> I noticed that you have code where fields and constructor arguments > >> have the same name. As far as I remember that is not good practise, > >> but I might be wrong :-)? > > > > Most (all?) of CM follows this convention. > Just to be sure: Do you mean that in most of CM, parameter and field > names coincide? Yes. See, for example, src/main/java/org/apache/commons/math/ode/nonstiff/AdaptiveStepsizeIntegrator.java src/main/java/org/apache/commons/math/geometry/Rotation.java I think that the list is quite long... Best, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
Thanks for clearifying :).
Den 30/01/2011 16.01 skrev "Gilles Sadowski" <[hidden email]>: > On Sun, Jan 30, 2011 at 02:58:43PM +0100, Mikkel Meyer Andersen wrote: >> Hi, >> >> 2011/1/30 Gilles Sadowski <[hidden email]>: >> > Hello. >> > >> >> I noticed that you have code where fields and constructor arguments >> >> have the same name. As far as I remember that is not good practise, >> >> but I might be wrong :-)? >> > >> > Most (all?) of CM follows this convention. >> Just to be sure: Do you mean that in most of CM, parameter and field >> names coincide? > > Yes. > See, for example, > > src/main/java/org/apache/commons/math/geometry/Rotation.java > I think that the list is quite long... > > Best, > Gilles > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > |
On Sun, Jan 30, 2011 at 10:05 AM, Mikkel Meyer Andersen <[hidden email]> wrote:
> Thanks for clearifying :). > Den 30/01/2011 16.01 skrev "Gilles Sadowski" <[hidden email]>: >> On Sun, Jan 30, 2011 at 02:58:43PM +0100, Mikkel Meyer Andersen wrote: >>> Hi, >>> >>> 2011/1/30 Gilles Sadowski <[hidden email]>: >>> > Hello. >>> > >>> >> I noticed that you have code where fields and constructor arguments >>> >> have the same name. As far as I remember that is not good practise, >>> >> but I might be wrong :-)? >>> > >>> > Most (all?) of CM follows this convention. >>> Just to be sure: Do you mean that in most of CM, parameter and field >>> names coincide? >> >> Yes. >> See, for example, >> > src/main/java/org/apache/commons/math/ode/nonstiff/AdaptiveStepsizeIntegrator.java >> src/main/java/org/apache/commons/math/geometry/Rotation.java >> I think that the list is quite long... >> When what is being set is exactly the field value and this name makes sense in the public constructor, I see nothing wrong with it. As Stephen said, IDEs and static analyzers will ensure that we do not omit the reference to the instance. What is more important is that the field and parameter names be meaningful and well-documented. Phil --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
On Sun, Jan 30, 2011 at 11:19:23AM -0500, Phil Steitz wrote:
> On Sun, Jan 30, 2011 at 10:05 AM, Mikkel Meyer Andersen <[hidden email]> wrote: > > Thanks for clearifying :). > > Den 30/01/2011 16.01 skrev "Gilles Sadowski" <[hidden email]>: > >> On Sun, Jan 30, 2011 at 02:58:43PM +0100, Mikkel Meyer Andersen wrote: > >>> Hi, > >>> > >>> 2011/1/30 Gilles Sadowski <[hidden email]>: > >>> > Hello. > >>> > > >>> >> I noticed that you have code where fields and constructor arguments > >>> >> have the same name. As far as I remember that is not good practise, > >>> >> but I might be wrong :-)? > >>> > > >>> > Most (all?) of CM follows this convention. > >>> Just to be sure: Do you mean that in most of CM, parameter and field > >>> names coincide? > >> > >> Yes. > >> See, for example, > >> > > src/main/java/org/apache/commons/math/ode/nonstiff/AdaptiveStepsizeIntegrator.java > >> src/main/java/org/apache/commons/math/geometry/Rotation.java > >> I think that the list is quite long... > >> > > When what is being set is exactly the field value and this name makes > sense in the public constructor, I see nothing wrong with it. As > Stephen said, IDEs and static analyzers will ensure that we do not > omit the reference to the instance. What is more important is that > the field and parameter names be meaningful and well-documented. (Also answering one of your other post questions.) The rationale behind the parameter names is that they correpond to those used in the advertised link. This make it easy to compare the code with the reference. Also there are not meaningful _short_ names for those and using long names makes the formula in the "value" method quite unreadable. One parameter name would be "parameterThatAffectsNearWhichAsymptoteMaximumGrowthOccurs" The reference did not provide meaningful or standard names so I preferred to stick to those letters that appear in the formula (except for changing the Greek "nu" to "n"). A more meaningful way of documenting methematical formulae would be to introduce LaTeX formatting: /** * <pre> * <div class="latex"> * y(x) = a + \frac{k - a}{(1 + q e^{-b (x - m)})^{1 / \nu}} * </div> * </pre> */ However we should agree on the exact formatting so that processing of the documentation might possibly create a PNG file showing the formula. [Something else to be put into the "unneeded" coding and documenting guidelines which I proposed a few weeks ago...] Regards, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
On 1/30/11 12:42 PM, Gilles Sadowski wrote:
> On Sun, Jan 30, 2011 at 11:19:23AM -0500, Phil Steitz wrote: >> On Sun, Jan 30, 2011 at 10:05 AM, Mikkel Meyer Andersen <[hidden email]> wrote: >>> Thanks for clearifying :). >>> Den 30/01/2011 16.01 skrev "Gilles Sadowski" <[hidden email]>: >>>> On Sun, Jan 30, 2011 at 02:58:43PM +0100, Mikkel Meyer Andersen wrote: >>>>> Hi, >>>>> >>>>> 2011/1/30 Gilles Sadowski <[hidden email]>: >>>>>> Hello. >>>>>> >>>>>>> I noticed that you have code where fields and constructor arguments >>>>>>> have the same name. As far as I remember that is not good practise, >>>>>>> but I might be wrong :-)? >>>>>> Most (all?) of CM follows this convention. >>>>> Just to be sure: Do you mean that in most of CM, parameter and field >>>>> names coincide? >>>> Yes. >>>> See, for example, >>>> >>> src/main/java/org/apache/commons/math/ode/nonstiff/AdaptiveStepsizeIntegrator.java >>>> src/main/java/org/apache/commons/math/geometry/Rotation.java >>>> I think that the list is quite long... >>>> >> When what is being set is exactly the field value and this name makes >> sense in the public constructor, I see nothing wrong with it. As >> Stephen said, IDEs and static analyzers will ensure that we do not >> omit the reference to the instance. What is more important is that >> the field and parameter names be meaningful and well-documented. > (Also answering one of your other post questions.) > The rationale behind the parameter names is that they correpond to those > used in the advertised link. > This make it easy to compare the code with the reference. > Also there are not meaningful _short_ names for those and using long names > makes the formula in the "value" method quite unreadable. > One parameter name would be > "parameterThatAffectsNearWhichAsymptoteMaximumGrowthOccurs" full words as variable names, especially those that appear in public APIs. Certainly "upperAsymptote, "lowerAsymptote" and "growthRate" (pretty much directly from the javadoc comments describing these parameters) would be improvements over single letters for those fields. > The reference did not provide meaningful or standard names so I preferred to > stick to those letters that appear in the formula (except for changing the > Greek "nu" to "n"). > > A more meaningful way of documenting methematical formulae would be to > introduce LaTeX formatting: > /** > * <pre> > * <div class="latex"> > * y(x) = a + \frac{k - a}{(1 + q e^{-b (x - m)})^{1 / \nu}} > * </div> > * </pre> > */ > fine to use external references for formulas too complex to be easily represented in HTML. This one is a borderline case. > However we should agree on the exact formatting so that processing of the > documentation might possibly create a PNG file showing the formula. > [Something else to be put into the "unneeded" coding and documenting > guidelines which I proposed a few weeks ago...] > -1 for managing png's as essential components of the javadoc. It is also very desirable to be able to read and make sense of the javadoc in the source files. Phil > Regards, > Gilles > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
In reply to this post by Gilles Sadowski
I have to say that the underscore tradition is an esthetic issue about which
there is some strong disagreement. I find it particularly distasteful. And, for what it is worth, I think that the Sun coding conventions recommend against it. On Sun, Jan 30, 2011 at 5:42 AM, Gilles Sadowski < [hidden email]> wrote: > > I noticed that you have code where fields and constructor arguments > > have the same name. As far as I remember that is not good practise, > > but I might be wrong :-)? > > Most (all?) of CM follows this convention. > > [Personally I prefer that fieds use names prefixed by an underscore > character so that when method or constructor arguments reflect the meaning > of those fields, one does not have to use the "this" keyword (i.e. I use > the > convention where the '_' character means "This is an instance variable").] > |
In reply to this post by Phil Steitz
> >>>>
> >>> src/main/java/org/apache/commons/math/ode/nonstiff/AdaptiveStepsizeIntegrator.java > >>>> src/main/java/org/apache/commons/math/geometry/Rotation.java > >>>> I think that the list is quite long... > >>>> > >> When what is being set is exactly the field value and this name makes > >> sense in the public constructor, I see nothing wrong with it. As > >> Stephen said, IDEs and static analyzers will ensure that we do not > >> omit the reference to the instance. What is more important is that > >> the field and parameter names be meaningful and well-documented. > > (Also answering one of your other post questions.) > > The rationale behind the parameter names is that they correpond to those > > used in the advertised link. > > This make it easy to compare the code with the reference. > > Also there are not meaningful _short_ names for those and using long names > > makes the formula in the "value" method quite unreadable. > > One parameter name would be > > "parameterThatAffectsNearWhichAsymptoteMaximumGrowthOccurs" > I would suggest giving this a little thought. In Java, we favor > full words as variable names, especially those that appear in public > APIs. Certainly "upperAsymptote, "lowerAsymptote" and "growthRate" > (pretty much directly from the javadoc comments describing these > parameters) would be improvements over single letters for those fields. I don't think so, for the reasons I gave. I also already mentioned what I thought of piling up redundancy in the Javadoc. This is the same; IMHO, you loose clarity when writing /** * @param lowerAsymptote Lower asymptote. * @param upperAsymptote Upper asymptote. * @param growthRate Growth rate. */ And so on... But I'm not against you changing it if you think you have interesting alternative names and it would make you feel better! > > The reference did not provide meaningful or standard names so I preferred to > > stick to those letters that appear in the formula (except for changing the > > Greek "nu" to "n"). > > > > A more meaningful way of documenting methematical formulae would be to > > introduce LaTeX formatting: > > /** > > * <pre> > > * <div class="latex"> > > * y(x) = a + \frac{k - a}{(1 + q e^{-b (x - m)})^{1 / \nu}} > > * </div> > > * </pre> > > */ > > > -1 for introduce the monstrosity of Tex into our javadoc. It is > fine to use external references for formulas too complex to be > easily represented in HTML. This one is a borderline case. > > However we should agree on the exact formatting so that processing of the > > documentation might possibly create a PNG file showing the formula. > > [Something else to be put into the "unneeded" coding and documenting > > guidelines which I proposed a few weeks ago...] > > > -1 for managing png's as essential components of the javadoc. It is > also very desirable to be able to read and make sense of the javadoc > in the source files. Talking about monstrosity, HTML beats LaTeX by far (IMHO). The rule could be that only single formula can documented with LaTeX. My proposal is in line with using "xml" in the user guide. Instead of LaTeX it could some other markup language that can properly represents mathematical notation. I'm afraid that LaTeX is the most readable of all. A tool would able to automatically convert the <chosen_format> into an image for inclusion in the generated documention (as is done for the user manual). Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
In reply to this post by Ted Dunning
On 1/30/11 1:38 PM, Ted Dunning wrote:
> I have to say that the underscore tradition is an esthetic issue about which > there is some strong disagreement. > > I find it particularly distasteful. > > And, for what it is worth, I think that the Sun coding conventions recommend > against it. > +1 Phil > On Sun, Jan 30, 2011 at 5:42 AM, Gilles Sadowski < > [hidden email]> wrote: > >>> I noticed that you have code where fields and constructor arguments >>> have the same name. As far as I remember that is not good practise, >>> but I might be wrong :-)? >> Most (all?) of CM follows this convention. >> >> [Personally I prefer that fieds use names prefixed by an underscore >> character so that when method or constructor arguments reflect the meaning >> of those fields, one does not have to use the "this" keyword (i.e. I use >> the >> convention where the '_' character means "This is an instance variable").] >> --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
In reply to this post by Gilles Sadowski
Le 30/01/2011 19:47, Gilles Sadowski a écrit :
>>>>>> >>>>> src/main/java/org/apache/commons/math/ode/nonstiff/AdaptiveStepsizeIntegrator.java >>>>>> src/main/java/org/apache/commons/math/geometry/Rotation.java >>>>>> I think that the list is quite long... >>>>>> >>>> When what is being set is exactly the field value and this name makes >>>> sense in the public constructor, I see nothing wrong with it. As >>>> Stephen said, IDEs and static analyzers will ensure that we do not >>>> omit the reference to the instance. What is more important is that >>>> the field and parameter names be meaningful and well-documented. >>> (Also answering one of your other post questions.) >>> The rationale behind the parameter names is that they correpond to those >>> used in the advertised link. >>> This make it easy to compare the code with the reference. >>> Also there are not meaningful _short_ names for those and using long names >>> makes the formula in the "value" method quite unreadable. >>> One parameter name would be >>> "parameterThatAffectsNearWhichAsymptoteMaximumGrowthOccurs" >> I would suggest giving this a little thought. In Java, we favor >> full words as variable names, especially those that appear in public >> APIs. Certainly "upperAsymptote, "lowerAsymptote" and "growthRate" >> (pretty much directly from the javadoc comments describing these >> parameters) would be improvements over single letters for those fields. > > I don't think so, for the reasons I gave. > I also already mentioned what I thought of piling up redundancy in the > Javadoc. This is the same; IMHO, you loose clarity when writing > /** > * @param lowerAsymptote Lower asymptote. > * @param upperAsymptote Upper asymptote. > * @param growthRate Growth rate. > */ > And so on... > > But I'm not against you changing it if you think you have interesting > alternative names and it would make you feel better! > >>> The reference did not provide meaningful or standard names so I preferred to >>> stick to those letters that appear in the formula (except for changing the >>> Greek "nu" to "n"). >>> >>> A more meaningful way of documenting methematical formulae would be to >>> introduce LaTeX formatting: >>> /** >>> * <pre> >>> * <div class="latex"> >>> * y(x) = a + \frac{k - a}{(1 + q e^{-b (x - m)})^{1 / \nu}} >>> * </div> >>> * </pre> >>> */ >>> >> -1 for introduce the monstrosity of Tex into our javadoc. It is >> fine to use external references for formulas too complex to be >> easily represented in HTML. This one is a borderline case. >>> However we should agree on the exact formatting so that processing of the >>> documentation might possibly create a PNG file showing the formula. >>> [Something else to be put into the "unneeded" coding and documenting >>> guidelines which I proposed a few weeks ago...] >>> >> -1 for managing png's as essential components of the javadoc. It is >> also very desirable to be able to read and make sense of the javadoc >> in the source files. > > Talking about monstrosity, HTML beats LaTeX by far (IMHO). > The rule could be that only single formula can documented with LaTeX. > > My proposal is in line with using "xml" in the user guide. Instead of LaTeX > it could some other markup language that can properly represents > mathematical notation. I'm afraid that LaTeX is the most readable of all. > A tool would able to automatically convert the <chosen_format> into an image > for inclusion in the generated documention (as is done for the user manual). This does make sense in the user manual, but not in javadoc. We are stuck with the general javadoc tool here. For user manual, we thought about introducing mathml a while ago, but as there was no support for it in maven, we gave up. Luc > > > Gilles > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
In reply to this post by Ted Dunning
Hi.
> I have to say that the underscore tradition is an esthetic issue about which > there is some strong disagreement. > > I find it particularly distasteful. As with all matter of taste... I find it particularly useful. That said, I was not asking for a vote on this. It's possible to get accustomed to *any* convention; the crux of the matter is that everyone follow the convention. Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
In reply to this post by Luc Maisonobe
Hi Luc.
> > [...] > > > > Talking about monstrosity, HTML beats LaTeX by far (IMHO). > > The rule could be that only single formula can documented with LaTeX. > > > > My proposal is in line with using "xml" in the user guide. Instead of LaTeX > > it could some other markup language that can properly represents > > mathematical notation. I'm afraid that LaTeX is the most readable of all. > > A tool would able to automatically convert the <chosen_format> into an image > > for inclusion in the generated documention (as is done for the user manual). > > This does make sense in the user manual, but not in javadoc. We are > stuck with the general javadoc tool here. > > For user manual, we thought about introducing mathml a while ago, but as > there was no support for it in maven, we gave up. I understand that there are limitations that are maybe impossible to overcome. It was just an idea. It was meant to be balanced with the ugliness of long variable names in mathematical formulae[1] as this is the primary aim of in-code documentation. Then, if we *could* have an automated conversion tool that would insert a PNG figure inside the generated documnetation, it would be far more readable than the mix of math and pseudo-code that we have now. Best, Gilles [1] Expressed in LaTeX, such a formula is still fairly legible IMO. --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
Free forum by Nabble | Edit this page |