1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
|
The GSL Bugs Database is at http://savannah.gnu.org/bugs/?group=gsl
This file was generated from it at Thu Jul 18 10:23:38 2013
------------------------------------------------------------------------
BUG-ID: 28267
STATUS: Open/Postponed
CATEGORY: Accuracy problem
SUMMARY: poor convergence region for gsl_sf_hyperg_1F1
The magnitude of the error is greater than the value itself for
a<<0, b>0, x>>0
gsl_sf_hyperg1F1(-3.78e+01, 2, 1.035e+02) => -7.00055e+18 +/- 3.77654e+19
-----------------------------------------------
From: Weibin Li <weibinli@mpipks-dresden.mpg.de>
To: bug-gsl@gnu.org
Subject: [Bug-gsl] gsl_sf_hyperg_1F1
Date: Mon, 30 Nov 2009 15:26:11 +0100
Hi, guys
I experienced bugs with gsl_sf_hyperg_1F1. The version is gsl_1.12, but
the testing is also done with gsl_1.13, using a mac with version 10.5.8
and hp-workstation with gnome_2.24.1.
#include<stdlib.h>
#include<stdio.h>
#include<math.h>
#include "gsl/gsl_sf_hyperg.h"
int main(int argc, char **argv)
{
int ii;
double Ri;
double v0;
gsl_sf_result r;
for(ii = 10; ii< 140;ii++)
{
Ri = 2013;
v0 =38.86871 +ii*2.5e-10;
gsl_sf_hyperg_1F1_e(1.0-v0,2,2.0*Ri/v0,&r);
printf("%lg\t%14.13g\t%14.13g\n",v0,r.val,r.err);
}
return 0;
}
The output of above code shows an extremely large error. by increasing
Ri, the relative error decreases. Is there any idea to fix this?
Thank you very much.
Best
Weibin
-It's inherently difficult to compute the value in this region either way as there is massive cancellation in both the series and the Kummer transformed series.I cannot find any algorithm which handles this case.Confirmed
------------------------------------------------------------------------
BUG-ID: 21828
STATUS: Open/Confirmed
CATEGORY: Performance
SUMMARY: suboptimal performance of gsl_fdfsolver_lmsder
From: "Alexander Usov" <a.s.usov@gmail.com>
To: help-gsl@gnu.org
Subject: [Help-gsl] Strange performance of gsl_fdfsolver_lmsder
Date: Wed, 24 Oct 2007 20:45:01 +0200
Hi all,
I am currently working on the problem involving source extraction from
astronomical images, which essentially boils down to fitting a number of
2d gaussians to the image.
One of the traditionally used fitters in this field is a Levenberg-Marquardt,
which gsl_fdfsolver_lmsder is and implementation of.
At some moment I have notices that for the bigger images (about 550
pixels, 20-30 parameters) gsl's lmsder algorithm spends a large fraction
of the run-time (about 50%) doing household transform.
While looking around for are different minimization algorithms I have made
a surprising finding that original netlib/minpack/lmder is almost twice faster
that that of gsl.
Could anyone explain such a big difference in performace?
--
Best regards,
Alexander.
_______________________________________________
Help-gsl mailing list
Help-gsl@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gsl
Reply-To: help-gsl@gnu.org
From: Brian Gough <bjg@network-theory.co.uk>
To: "Alexander Usov" <a.s.usov@gmail.com>
Cc: help-gsl@gnu.org
Subject: Re: [Help-gsl] Strange performance of gsl_fdfsolver_lmsder
Date: Thu, 25 Oct 2007 21:57:08 +0100
At Wed, 24 Oct 2007 20:45:01 +0200,
Alexander Usov wrote:
> At some moment I have notices that for the bigger images (about 550
> pixels, 20-30 parameters) gsl's lmsder algorithm spends a large fraction
> of the run-time (about 50%) doing household transform.
>
> While looking around for are different minimization algorithms I have made
> a surprising finding that original netlib/minpack/lmder is almost twice faster
> that that of gsl.
>
> Could anyone explain such a big difference in performace?
I have a vague memory that there was some quantity (Jacobian?) that
MINPACK only computes fully at the end, but in GSL it is accessible to
the user at each step so I felt I had to update it on each iteration
in the absence of some alternate scheme. Sorry this is not a great
answer but I am not able to look at it in detail now.
--
Brian Gough
_______________________________________________
Help-gsl mailing list
Help-gsl@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gsl
1824
|
