At Fri, 21 Dec 2007 14:17:01 +0100, Alfonso MHC wrote: > Page 86 section 8.4.1 Matrix allocation, third line, first word is > "vector", but I think it should be "matrix". Thanks for the correction. I'll fix that for the next release. -- -- Brian Gough
At Thu, 20 Dec 2007 23:27:21 -0500, Jason Coy wrote: > > Enclosed is a patch file for the wavlelet/dwt.c file that speeds up the > operation of the dwt_step function a bit by eliminating the need for the > program to calculate the buffer offset repeatedly. The dwt.c file contains > the updated code. > It increases speed at the cost of slightly more complicated code. Thanks for the patch. What sort of speedup do you get with that? -- -- Brian Gough
Approximately 5% improvement depending on the size of the buffers. Jason -----Original Message----- From: Brian Gough [mailto:bjg <at> gnu.org] Sent: Wednesday, January 02, 2008 7:32 AM To: Jason Coy Cc: bug-gsl <at> gnu.org Subject: Re: [Bug-gsl] Wavelet DWT speedup At Thu, 20 Dec 2007 23:27:21 -0500, Jason Coy wrote: > > Enclosed is a patch file for the wavlelet/dwt.c file that speeds up the > operation of the dwt_step function a bit by eliminating the need for the > program to calculate the buffer offset repeatedly. The dwt.c file contains > the updated code. > It increases speed at the cost of slightly more complicated code. Thanks for the patch. What sort of speedup do you get with that? -- -- Brian Gough
At Wed, 2 Jan 2008 20:46:08 -0500, Jason Coy wrote: > > Approximately 5% improvement depending on the size of the buffers. Thanks, I've moved the pointer dereference out of the inner loop. -- -- Brian Gough GNU Scientific Library - http://www.gnu.org/software/gsl/
Thank you for reporting this. I have fixed it in the latest CVS. On Tue, Nov 27, 2007 at 10:30:24PM +0100, Christophe Cloquet wrote: > Dear Patrick, > > Thanks for your e-mail. I apologize for this extremely late answer. I > enclosed a sample code in this mail. I don't actually know if this is a > bug, or a bad implementation from my side. > > The code defines a cubic spline basis bw3, then a linear spline basis bw2 > based on bw3. The problem arise when evaluating the splines in bw2 at the > last breakpoint. It is only a minor problem, and I could fix it for my > application. The final aim is to compute the second derivative of the bw3 > basis, based on De Boor, Practical Guide to splines, 1978, p. 138. > > If something is unclear, please ask me. I'll try to answer as soon as > possible. > > > > Best regards, > > > > Christophe > > Here is the code : > ==================================================================================== > > #include <stdlib.h>(Continue reading)
There is a bug in error estimation for gsl_sf_exp_mult_e10_e: gsl_sf_exp_e10_e(10000) gives error estimate 3.911404048e-11 but gsl_sf_exp_mult_e10_e(10000, 1) gives 3.911012947e-15 so it looks like just multiplying by 1 gives us 4 more digits of precision. True error is about 1.6884e-11 (using MPFR http://ex-cs.sist.ac.jp/~tkouya/try_mpfr.html), so the error is clearly underestimated. Changing line: const double arg_err = 2.0 * GSL_DBL_EPSILON * fabs(ly); to const double arg_err = 2.0 * GSL_DBL_EPSILON * fabs(x); seems to fix the problem, but I'm not sure this is correct. Also, there is a discrepancy in result format between exp_e10 and exp_mult_e10 for x = 100 and y = 1. The former returns 2.688 with e10=43, the latter 2.688e43 with e10=0. It would be nicer to return the first result in both cases, but since both are correct it might not be worth fixing. Attached is a file reproducing both cases. Szymon Jaroszewicz(Continue reading)
At Mon, 14 Jan 2008 12:16:10 +0100, Szymon Jaroszewicz wrote: > > There is a bug in error estimation for gsl_sf_exp_mult_e10_e: > > gsl_sf_exp_e10_e(10000) gives error estimate 3.911404048e-11 > > but > > gsl_sf_exp_mult_e10_e(10000, 1) gives 3.911012947e-15 > Thanks for the bug report and example program. I've confirmed it and logged it in the bug tracker. It does look like the error from gsl_sf_exp_mult_e10_e is wrong. -- -- Brian Gough
Hi all, Thanks very much for your efforts. I downloaded the gsl-1.10. When I am trying to use configure file to compile gsl I found the following message Report bugs to <bug-coreutils <at> gnu.org>. aeo3 <at> aeo3-pc /cygdrive/x/home/cc1/gsl $ ./configure --disable-shared ./configure: line 12: $'\r': command not found ./configure: line 23: syntax error near unexpected token `$'in\r'' '/configure: line 23: ` case `(set -o) 2>/dev/null` in aeo3 <at> aeo3-pc /cygdrive/x/home/cc1/gsl $ make make: *** No targets specified and no makefile found. Stop. aeo3 <at> aeo3-pc /cygdrive/x/home/cc1/gsl $ make clean make: *** No rule to make target `clean'. Stop. aeo3 <at> aeo3-pc /cygdrive/x/home/cc1/gsl $ ./configure ./configure: line 12: $'\r': command not found ./configure: line 23: syntax error near unexpected token `$'in\r'' '/configure: line 23: ` case `(set -o) 2>/dev/null` in aeo3 <at> aeo3-pc /cygdrive/x/home/cc1/gsl $ vi configure(Continue reading)
At Tue, 29 Jan 2008 04:03:03 -0800 (PST),
ahmed okasha wrote:
> aeo3 <at> aeo3-pc /cygdrive/x/home/cc1/gsl
> $ ./configure
> ./configure: line 23: syntax error near unexpected token `('
> '/configure: line 23: ` case (set -o) 2>/dev/null` in
>
Sorry, there's a problem with your cygwin installation - we can't help
with that.
--
--
Brian Gough
RSS Feed2 | |
|---|---|
11 | |
13 | |
16 | |
13 | |
12 | |
12 | |
34 | |
46 | |
17 | |
23 | |
27 | |
11 | |
10 | |
6 | |
15 | |
11 | |
13 | |
22 | |
18 | |
29 | |
13 | |
12 | |
13 | |
8 | |
51 | |
17 | |
7 | |
29 | |
15 | |
16 | |
30 | |
38 | |
25 | |
27 | |
14 | |
28 | |
34 | |
34 | |
46 | |
35 | |
8 | |
30 | |
3 | |
17 | |
42 | |
34 | |
21 | |
17 | |
29 | |
17 | |
22 | |
35 | |
21 | |
38 | |
30 | |
34 | |
13 | |
9 | |
14 | |
39 | |
39 | |
14 | |
16 | |
9 | |
10 | |
13 | |
20 | |
29 | |
24 | |
18 | |
6 | |
12 | |
34 | |
11 | |
9 | |
16 | |
12 | |
10 | |
10 | |
20 | |
8 | |
4 | |
15 | |
4 | |
24 | |
24 | |
19 | |
17 | |
7 | |
5 | |
15 | |
19 | |
15 | |
13 | |
12 | |
18 | |
12 |
