http://permalink.gmane.org/gmane.comp.lib.gsl.bugs hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.lib.gsl.bugs/1913 <pre>URL: &lt;http://savannah.gnu.org/bugs/?39057&gt; Summary: gsl_cdf_chisq_Pinv fails for some values Project: GNU Scientific Library Submitted by: psa Submitted on: Thu 23 May 2013 08:32:36 PM GMT Category: Runtime error Severity: 3 - Normal Operating System: all Status: None Assigned to: None Open/Closed: Open Release: Discussion Lock: Any _______________________________________________________ Details: The following parameters cause gsl_cdf_chisq_Pinv to fail - this has been commented out of cdf/test.c to enable 'make check' to succeed. /* Test case reported by Yan Zhou &lt;zhouyan&lt; at &gt;me.com&gt; */ TEST (gsl_cdf_chisq_Pinv, (0.5, 0.01), 0.99477710813146, TEST_TOL6); _______________________________________________________ Reply to this item at: &lt;http://savannah.gnu.org/bugs/?39057&gt; _______________________________________________ </pre> Patrick Alken 2013-05-23T20:32:37 http://permalink.gmane.org/gmane.comp.lib.gsl.bugs/1912 <pre>URL: &lt;http://savannah.gnu.org/bugs/?39056&gt; Summary: gsl_sf_hyperg_2F1_e fails for some test cases Project: GNU Scientific Library Submitted by: psa Submitted on: Thu 23 May 2013 08:26:48 PM GMT Category: Runtime error Severity: 4 - Important Operating System: all Status: Confirmed Assigned to: None Open/Closed: Open Release: Discussion Lock: Any _______________________________________________________ Details: The following test cases are confirmed to fail for the gsl_sf_hyperg_2F1_e function. They have been commented out of specfunc/test.c to enable 'make check' to succeed. /* Test case from Hatef Monajemi &lt;monajemi&lt; at &gt;stanford.edu&gt; */ TEST_SF(s, gsl_sf_hyperg_2F1_e, (3.5, -0.5, 5.0, 0.9, &amp;r), 0.5923981284370653465208973272, TEST_TOL2, GSL_SUCCESS); /* Test case from Robert L Wolpert &lt;Wolpert&lt; at &gt;stat.duke.edu&gt; */ TEST_SF(s, g</pre> Patrick Alken 2013-05-23T20:26:49 http://permalink.gmane.org/gmane.comp.lib.gsl.bugs/1911 <pre>URL: &lt;http://savannah.gnu.org/bugs/?39055&gt; Summary: gsl_poly_complex_solve fails on a 15th degree polynomial Project: GNU Scientific Library Submitted by: psa Submitted on: Thu 23 May 2013 08:14:21 PM GMT Category: Runtime error Severity: 3 - Normal Operating System: all Status: Confirmed Assigned to: None Open/Closed: Open Release: Discussion Lock: Any _______________________________________________________ Details: The following code demonstrates a failure of gsl_poly_complex_solve(). I have commented this out from poly/test.c since it will cause that test to fail until the problem is fixed. The QR reduction of the polynomial companion matrix does not converge. The eigenvalues of the companion matrix can be successfully computed with gsl_eigen_nonsymm(), but this is not a good long-term solution - the qr algorithm should be fixed</pre> Patrick Alken 2013-05-23T20:14:22 http://permalink.gmane.org/gmane.comp.lib.gsl.bugs/1910 <pre>Hi, I found what I think is a bug in miser.c. In the function estimate_corrmc, line 689 in the file sigma_l[i] = sqrt (fsum2_l[i] - fsum_l[i] * fsum_l[i] / hits_l[i]); is supposed to be the variance in the left hand region with the division in the i-axis , Shouldn't this be: sqrt( ( fsum2_l[i] / hits_l[i] - fsum_l[i] * fsum_l[i] ) / (hits_l[i] - 1) ) and correspondingly for the right hand variance? Or is there some subtlety I am missing? Rudy. </pre> Rudy Arthur 2013-05-19T20:49:19 http://permalink.gmane.org/gmane.comp.lib.gsl.bugs/1909 <pre> Does this happen atop version 1.15, the latest release? Version 1.9 is quite old. - Rhys </pre> Rhys Ulerich 2013-05-01T11:22:12 http://permalink.gmane.org/gmane.comp.lib.gsl.bugs/1908 <pre>Yes I believe the first line needs to be changed to: struct powell_params * params = (struct powell_params *)p; Thanks for finding this Patrick On 04/30/2013 06:03 AM, David Faustner wrote: </pre> Patrick Alken 2013-04-30T15:20:40 http://permalink.gmane.org/gmane.comp.lib.gsl.bugs/1907 <pre>Hello, please check http://validator.w3.org/feed/check.cgi?url=http%3A%2F%2Fsavannah.gnu.org%2Fnews%2Fatom.php%3Fgroup%3Dgsl as it says: Sorry This feed does not validate. line 228, column 100: XML parsing error: &lt;unknown&gt;:228:100: undefined entity [help] ... UINT_MAX [&lt;em&gt;&lt;a href="/bugs/?24897"&gt;bug&amp;nbsp;#24897&lt;/a&gt;&lt;/em&gt;] -&gt; HTML entities are not allowed in plain XML... Best regards, Michael Bunk </pre> Michael Bunk 2013-04-30T12:13:54 http://permalink.gmane.org/gmane.comp.lib.gsl.bugs/1906 <pre>Dear GNU Scientific Library Team, I've been studying section 35.3: "Providing the function to solve" in the GNU Scientific Library Reference Manual and I deal with a command sequence, where I'm not sure if it is stated correctly. My question relates to the powell function according to struct powell_params { double A; }; int powell (gsl_vector * x, void * p, gsl_vector * f) { struct powell_params * params = *(struct powell_params *)p; const double A = (params-&gt;A); const double x0 = gsl_vector_get(x,0); const double x1 = gsl_vector_get(x,1); gsl_vector_set (f, 0, A * x0 * x1 - 1); gsl_vector_set (f, 1, (exp(-x0) + exp(-x1) - (1.0 + 1.0/A))); return GSL_SUCCESS } The powell function gets a pointer p to a structure of unknown type (void) as an argument. So, the content of p is an address of a structure. With the command (struct powell_params *)p the pointer</pre> David Faustner 2013-04-30T12:03:20 http://permalink.gmane.org/gmane.comp.lib.gsl.bugs/1905 <pre>Hi there! I got the following failure after running 'make check &gt; log 2&gt;&amp;1'. My Operating System is Debian 6.0 amd64. Making check in sort make[1]: Entering directory `/home/eric/Downloads/gsl-1.9/sort' make test make[2]: Entering directory `/home/eric/Downloads/gsl-1.9/sort' gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I.. -g -O2 -c test.c /bin/bash ../libtool --tag=CC --mode=link gcc -g -O2 -o test test.o libgslsort.la ../permutation/libgslpermutation.la ../vector/libgslvector.la ../block/libgslblock.la ../ieee-utils/libgslieeeutils.la ../err/libgslerr.la ../test/libgsltest.la ../sys/libgslsys.la -lm gcc -g -O2 -o test test.o ./.libs/libgslsort.a ../permutation/.libs/libgslpermutation.a ../vector/.libs/libgslvector.a ../block/.libs/libgslblock.a ../ieee-utils/.libs/libgslieeeutils.a ../err/.libs/libgslerr.a ../test/.libs/libgsltest.a ../sys/.libs/libgslsys.a -lm make[2]: Leaving directory `/home/eric/Downloads/gsl-1.9/sort' make check-TESTS make[2]: Entering directory `/home/eric/Downloads/gsl-1.9/so</pre> eric 2013-04-30T11:02:47 http://permalink.gmane.org/gmane.comp.lib.gsl.bugs/1904 <pre>FWIW, I disagree. With only one data point you have no idea what the variance is, and nan is the natural return value. </pre> Peter Johansson 2013-04-25T23:53:01 http://permalink.gmane.org/gmane.comp.lib.gsl.bugs/1903 <pre> Do you want gsl_stats_sd_with_fixed_mean instead of gsl_stats_sd? http://www.gnu.org/software/gsl/manual/html_node/Mean-and-standard-deviation-and-variance.html - Rhys </pre> Rhys Ulerich 2013-04-24T21:15:55 http://permalink.gmane.org/gmane.comp.lib.gsl.bugs/1902 <pre>Hi, The output of the following test code is nan. I don't think this is the desired behavior for users. When number of input data is 1, I think it is more reasonable to say standard deviation is 0 instead of nan. thanks, Ming #include &lt;iostream&gt; #include &lt;gsl/gsl_statistics.h&gt; itn main() { double data[1] = {1.0}; double sd = gsl_stats_sd(data, 1, 1); std::cout &lt;&lt; sd &lt;&lt; std::endl; return 0; } </pre> Ming Ji 2013-04-24T16:23:15 http://permalink.gmane.org/gmane.comp.lib.gsl.bugs/1901 <pre>make check-TESTS make[2]: Entering directory `/clars/gsl-1.15/histogram' FAIL: gsl_histogram_fprintf and fscanf [36] FAIL: test.exe ================== 1 of 1 test failed ================== Makefile:453: recipe for target `check-TESTS' failed make[2]: *** [check-TESTS] Error 1 make[2]: Leaving directory `/clars/gsl-1.15/histogram' Makefile:575: recipe for target `check-am' failed make[1]: *** [check-am] Error 2 make[1]: Target `check' not remade because of errors. make[1]: Leaving directory `/clars/gsl-1.15/histogram' </pre> Pongetti, Thomas J (3286 2013-04-23T19:40:09 http://permalink.gmane.org/gmane.comp.lib.gsl.bugs/1900 <pre>I've had some trouble with non-converging minimizations using the gsl_multimin_fdfminimizer_vector_bfgs minimizer, which finally led me to look into the code. The comments in 'vector_bfgs.c' and 'vector_bfgs2.c' read /* This is the BFGS update: */ /* p' = g1 - A dx - B dg */ /* A = - (1+ dg.dg/dx.dg) B + dg.g/dx.dg */ /* B = dx.g/dx.dg */ where, as far as I can see, p' is the new search direction, g1 and g both denote the new gradient, dx is the position change and dg the change in the gradient after the line search. All the literature I've found on the BFGS method defines the new search direction as p' = B^(-1) g, where B^(-1) is the BFGS estimate of the inverse Hessian, defined trough outer and inner products of dx and dg and the inverse Hessian B_prev^(-1) of the _previous_ iteration. (See, e.g. http://en.wikipedia.org/wiki/BFGS_method). Using these expressions, I can only reproduce the formula from the comments for the special case where B_prev^(-1) is the identity matrix. I've also compared, during a</pre> Martin Wiebusch 2013-04-19T00:43:50 http://permalink.gmane.org/gmane.comp.lib.gsl.bugs/1899 <pre>I checked the akima memory allocation and found some potential optimizations: * It is sufficient to allocate (size - 1) doubles for the spline coefficients b, c and d of akima_state_t. * It is sufficient to allocate (size + 3) doubles for the divided differences _m of akima_state_t. * The divided differences _m of akima_state_t are only accessed in akima_calc and akima_init / akima_init_periodic, hence could be freed earlier at the end of the calculation of the spline coefficients b, c and d in akima_calc. Best regards, Thomas Beutlich -- http://tbeu.de </pre> Thomas Beutlich 2013-04-18T14:59:57 http://permalink.gmane.org/gmane.comp.lib.gsl.bugs/1898 <pre>LinkedIn ------------ I'd like to add you to my professional network on LinkedIn. - JongKwan JongKwan Kim Research Assistant at Utah State University Greater Salt Lake City Area Confirm that you know JongKwan Kim: https://www.linkedin.com/e/amzjnv-hfe9ifvf-2p/isd/12394142958/NhQfousI/?hs=false&amp;tok=3wvdIqzsYmklI1 -- You are receiving Invitation to Connect emails. Click to unsubscribe: http://www.linkedin.com/e/amzjnv-hfe9ifvf-2p/qG1nLK-EHylaV3JK4GMM3u2qVg/goo/bug-gsl%40gnu%2Eorg/20061/I4106544415_1/?hs=false&amp;tok=2_mhhT3FYmklI1 (c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA. </pre> JongKwan Kim 2013-04-11T18:30:28 http://permalink.gmane.org/gmane.comp.lib.gsl.bugs/1897 <pre>Additional Item Attachment, bug #36197 (project gsl): File name: 36197a.diff Size:118 KB File name: 36197b.diff Size:179 KB _______________________________________________________ Reply to this item at: &lt;http://savannah.gnu.org/bugs/?36197&gt; _______________________________________________ Nachricht gesendet von/durch Savannah http://savannah.gnu.org/ </pre> Markus Elfring 2013-03-30T21:35:37 http://permalink.gmane.org/gmane.comp.lib.gsl.bugs/1896 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Almost a feature :). This issue has something to do with gcc optimizations. Possible workarounds: 1. Use CFLAGS="-Os" instead of the default -O2 2. Use clang instead of gcc See archive of the mailing-list for details. Richard Outerbridge wrote: - -- С уважением, Алексей Александрович Илларионов. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQEcBAEBAgAGBQJRUTI3AAoJEEBWYSFzoNKeir8IAOpAVrUqPNp7Dww2apCEKQra e8NQ3f56Y4/PuCQhhJEYNsay6c/wiL3AW+tr2Bln3C92+7KkpCbZtSpmRgrxwLrg /veJZG/ON+TOyvIuYs2cobMkQDIiNbdZfwohJFPc+6HtgVEPDH1ugTdRbxVLhSNr 4cMPOfqViyf3qoiHQzuua3tXw1fHm88Ww43dHkW9+VcJZyQLRvyzSGlqZTW1VuM7 Ch7ekpc/+OkrZXCtf5yn3NhkmU3JUFjZTUgGc4NtOv8lUiFkSoKizYalXZheqK9N lDRc5FAC9eTgkH8MDdb6vX50wGUxmUIeNIB1pF56aV+SroGfilRAO4L2fxwScwQ= =TqxM -----END PGP SIGNATURE----- </pre> Alexey A. Illarionov 2013-03-26T05:29:27 http://permalink.gmane.org/gmane.comp.lib.gsl.bugs/1895 <pre>Mountain Lion OS X 10.8.3 (12D78) 12.3.0 Darwin Kernel Version 12.3.0; root:xnu-2050.22.13~1/RELEASE_X86_64 x86_64 gcc i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) ./configure make make check many (but not all) checks in linalg fail. first FAIL is: FAIL: SV_decomp (3x3) A=[ 0, 0, 0; 0, 0, 1; 1, 1, 0] [852] (several hundred later) last FAIL is: FAIL: SV_decomp_mod (4x4) A=[ 1, 1, 1, 1; 1, 1, 1, 1; 0, 1, 0, 1; 0, 0, 1, 1] [233613] if the linalg tests are bypassed, all other checks pass. __outer </pre> Richard Outerbridge 2013-03-25T14:14:11 http://permalink.gmane.org/gmane.comp.lib.gsl.bugs/1894 <pre>Sorry for the late reply. I had a chance to look into this, and you are correct that your matrix causes GSL nonsymmv to fail. In fact, if you check the return value of gsl_eigen_nonsymmv() it will be 11, or GSL_EMAXITER, meaning the solver failed to find all eigenvalues within the allotted number of iterations. In this case, according to the documentation, the eigenvectors are not even computed, so the eigenvectors you printed out are just garbage. The eigenvalue solver failed to converge, most likely because your matrix is ill-conditioned and the entries vary wildly in magnitude, and the double-shift algorithm was unable to find appropriate shifts to break off a new eigenvalue block. The LAPACK library uses a more sophisticated algorithm than the GSL which is able to handle your matrix, so I'd recommend using that for these types of matrices. In the mean time, I'll try tinkering with the shift calculation to see if GSL can be improved to work with this type of matrix. Thanks for the report an</pre> Patrick Alken 2013-03-23T20:15:19 http://permalink.gmane.org/gmane.comp.lib.gsl.bugs/1893 <pre>Hi, The problem is that 'gsl/Makefile.am' defines some targets ('all' and 'clean') that normally is created by Automake and thereby mess up the dependencies crafted by Automake, so there is no dependency that clean and install should depend on all. The solution is to use *-local targets as documented by Automake. Please find a patch attached. Cheers, Peter --- Makefile.am2013-03-22 09:48:59.358824603 +1000 +++ Makefile.am.new2013-03-22 09:48:43.471826950 +1000 &lt; at &gt;&lt; at &gt; -10,8 +10,6 &lt; at &gt;&lt; at &gt; rm -f gsl*.h -all: all-am header-links +all-local: header-links -clean: clean-am remove-links -distclean: distclean-am remove-links --rm -f Makefile +clean-local: remove-links </pre> Peter Johansson 2013-03-21T23:54:53 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lib.gsl.bugs