BUGS

The GSL Bugs Database is at http://savannah.gnu.org/bugs/?group=gsl

This file was generated from it at Tue Aug 25 15:52:36 2009

------------------------------------------------------------------------
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

------------------------------------------------------------------------
BUG-ID:   21831   
STATUS:   Open            
CATEGORY: Accuracy problem
SUMMARY:  Levý random number generator for alpha < 1

From: rafael@fis.unb.br
To: bug-gsl@gnu.org
Subject: [Bug-gsl] Levý random number generator
Date: Mon, 26 Mar 2007 19:48:01 -0300

The Levý skew random number generator (gsl_ran_levy_skew) does not  
procuce a Levý random number when beta=0 (symmetric case), and the  
gsl_ran_levy function does not work as stated in the docs. I made some  
histograms from 10^6 samples to check the accuracy of the algorithms,  
by comparison agaisnt the numerical integration of the equation of  
Levý's PDF. For the gsl_ran_levy function there is a good precison for  
alpha [1,2], for alpha (0.3,1) you must sum a series of random numbers  
to get the same precision (tipicaly 100 or more gsl_ran_levy numbers).  
For alpha<=0.3 the algorithm does not work properly, even worse, the  
error increases as you add more random numbers. This contradicts the  
manual that says "the algoritm only works for alpha (0,2]". The  
function gsl_ran_levy_skew does not produce levy random numbers when  
beta=0, instead the pdf of the random numbers is a linear (?!?!) one.

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

_______________________________________________
Bug-gsl mailing list
Bug-gsl@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gsl

From: rafael@fis.unb.br
To: Brian Gough <bjg@network-theory.co.uk>
Cc: 
Subject: Re: [Bug-gsl] Lev? random number generator
Date: Tue, 27 Mar 2007 09:35:15 -0300

Thanks for your quick answer, and sorry about my poor english, it is  
not my natural language.

The code below generates 10^6 random numbers, and makes a normalized  
histogram wich is compared to the levy pdf. To get the levy pdf, it  
numericaly integrates the characteristic function for levy process  
(the function f in the code). The n parameter just adds a series of  
levy numbers to get better precision. The code saves 2 files:  
lhist-$alpha-$n (the normalized histogram) and lpdf-$alpha (the pdf  
for the levy process). It also prints to the stdout the absolute error  
(square of the difference) between the histogram and the pdf.

The function levy skew shows problems for alpha<1.

With this code, you can also check the problems related to the  
gsl_ran_levy function (just change gsl_ran_levy_skew by gsl_ran_levy,  
cutting the last paramenter).

I am using the pre-compiled gsl that comes with debian etch (gsl  
version 1.8.2).

If you are interested, I also encoded a routine to generate levy skew  
random numbers, it is not fully tested, but it works for beta=0 and  
alpha<1 (it suffers from the same precision problem as gsl_ran_levy  
function for small alpha)

#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#include <time.h>
#include <sys/time.h>
#include <unistd.h>
#include <string.h>
#include <gsl/gsl_rng.h>
#include <gsl/gsl_randist.h>
#include <gsl/gsl_statistics_double.h>
#include <gsl/gsl_histogram.h>
#include <gsl/gsl_integration.h>

double f (double x, void *params)
{
	double alpha = *(double *) params;
	double f = exp(-pow(x,alpha))/M_PI;
	return f;
}

double *levy_pdf(double alpha,int hist_size,double a,double b)
{
	double abserr,*lpdf,dx;
	gsl_function F;
	int i;
	gsl_integration_workspace *w=gsl_integration_workspace_alloc(1000);
	gsl_integration_workspace *cw=gsl_integration_workspace_alloc(1000);
	gsl_integration_qawo_table  
*wf=gsl_integration_qawo_table_alloc(0.0,1.0,GSL_INTEG_COSINE,200);
	lpdf=(double*)calloc(hist_size,sizeof(double));
	F.function=&f;
	F.params=&alpha;
	dx=(double)(b-a)/(double)hist_size;
	for (i=0;i<hist_size;i++)
	{
		gsl_integration_qawo_table_set(wf,i*dx+a,1.0,GSL_INTEG_COSINE);
		gsl_integration_qawf (&F,0.0,1e-10,1000,w,cw,wf,&lpdf[i],&abserr);
	}
	gsl_integration_qawo_table_free(wf);
	gsl_integration_workspace_free(w);
	gsl_integration_workspace_free(cw);
	return (lpdf);
}

int main (int argc,char *argv[])
{
	double *l,*lpdf,a=-20,b=20,alpha,dx,n,errabs=0.0;
	unsigned long int rnd_seed;
	int i,j,rand_numbers=1e6,hist_size=400;
	gsl_histogram *h;
	gsl_rng *r;
	struct timeval *tv;
	struct timezone *tz;
	char filename[50];
	FILE *f1,*f2;
	if(argc!=3)
	{
		printf("\nThe program must be called with 2 parameters: alpha and n\n \n");
		exit(1);
	}
	dx=(double)(b-a)/(double)hist_size;
	h=gsl_histogram_alloc(hist_size);
	alpha=atof(argv[1]);
	n=atof(argv[2]);
	strcpy(filename,"lhist-");
	strcat(filename,argv[1]);
	strcat(filename,"-");
	strcat(filename,argv[2]);
	f1=fopen(filename,"w+");
	strcpy(filename,"lpdf-");
	strcat(filename,argv[1]);
	f2=fopen(filename,"w+");
	l=(double*)calloc(rand_numbers,sizeof(double));
	lpdf=(double*)calloc(hist_size,sizeof(double));
	r=gsl_rng_alloc (gsl_rng_mt19937);
	gettimeofday(tv,tz);
	rnd_seed=(unsigned long int)tv->tv_usec;
	gsl_rng_set(r,rnd_seed);
	i=0;
	do
	{
		l[i]=0.0;
		for (j=1;j<n;j++) l[i]+=gsl_ran_levy_skew(r,1.0,alpha,0.0);
		l[i]=l[i]/pow(n,1.0/alpha);
		if (abs(l[i])<=20) i++;//picks only random numbers in the interval  
[a,b] to get good precision in the histogram
	}while(i<rand_numbers);
	gsl_histogram_set_ranges_uniform(h,a,b);
	for(i=0;i<rand_numbers;i++) gsl_histogram_increment(h,l[i]);
	gsl_histogram_scale(h,(double)hist_size/((b-a)*gsl_histogram_sum(h)));
	gsl_histogram_fprintf(f1,h,"%g","%g");
	lpdf=levy_pdf(alpha,hist_size,a,b);
	for (i=0;i<hist_size;i++) fprintf(f2,"%e\t%e\n",i*dx+a,lpdf[i]);
	for (i=0;i<hist_size;i++) errabs+=pow((gsl_histogram_get(h,i)-lpdf[i]),2.0);
	printf("%e\n",errabs/(double)hist_size);
	gsl_histogram_free(h);
	gsl_rng_free(r);
	fclose(f1);
	exit (0);
}

> At Mon, 26 Mar 2007 19:48:01 -0300,
> rafael@fis.unb.br wrote:
>>
>> The Lev? skew random number generator (gsl_ran_levy_skew) does not
>> procuce a Lev? random number when beta=0 (symmetric case), and the
>> gsl_ran_levy function does not work as stated in the docs. I made some
>> histograms from 10^6 samples to check the accuracy of the algorithms,
>> by comparison agaisnt the numerical integration of the equation of
>> Lev?'s PDF. For the gsl_ran_levy function there is a good precison for
>> alpha [1,2], for alpha (0.3,1) you must sum a series of random numbers
>> to get the same precision (tipicaly 100 or more gsl_ran_levy numbers).
>> For alpha<=0.3 the algorithm does not work properly, even worse, the
>> error increases as you add more random numbers. This contradicts the
>> manual that says "the algoritm only works for alpha (0,2]". The
>> function gsl_ran_levy_skew does not produce levy random numbers when
>> beta=0, instead the pdf of the random numbers is a linear (?!?!) one.
>
> Thanks for your email.  Please can you send a small example program
> which demonstrates the problem.
>
> Note that the Levy skew generator is tested in the GSL test suite for
> several cases where beta=0 -- if you have not done so, can you run
> "make check" and confirm that it works for these cases.
>
> --
> Brian Gough
> (GSL Maintainer)
>
> Network Theory Ltd,
> Publishing the GSL Manual - http://www.network-theory.co.uk/gsl/manual/
>

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

_______________________________________________
Bug-gsl mailing list
Bug-gsl@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gsl

-

------------------------------------------------------------------------
BUG-ID:   21833   
STATUS:   Open            
CATEGORY: Performance
SUMMARY:  suboptimal performance of gsl permutation?

From: "djamel anonymous" <djam8193ah@hotmail.com>
To: bjg@network-theory.co.uk
Subject: gsl permutation
Date: Wed, 24 Jan 2007 07:42:06 +0000

Hi.
i am sending you this email about a possible issue in glibc permutation 
algorithm.i think it has qudratic worst case running time.for example if we 
have the permutation
1,2,3,4,,,,,n,0
we will permute all elements in first iteration then for each iteration we 
will traverse on average half the cycle (which is of size n) before we know 
that the elements of cycle have already been permuted.there is two possible 
solutions to make the algorithm linear:
1-at each step we traverse the full cycle and permute all elements in the 
cycle.for each permuted element i  we assign p[i]=i.the disavantage of this 
is that it will destroy the original permutation.
2-use a bit array of size n bits.each time we permute an element we set the 
relevant bit.if at iteration i we find that bit i is already set we skip to 
next iteration.the disavantage of this is that it equires additional storage 
allocation.
best regards.

_________________________________________________________________
MSN Hotmail sur i-mode? : envoyez et recevez des e-mails depuis votre 
téléphone portable ! http://www.msn.fr/hotmailimode/

3 - Normal

------------------------------------------------------------------------
BUG-ID:   21835   
STATUS:   Open            
CATEGORY: Accuracy problem
SUMMARY:  gsl_sf_hyperg_2F1 problematic arguments

BUG#1 -- gsl_sf_hyperg_2F1_e fails for some arguments 

From: keith.briggs@bt.com
Subject: gsl_sf_hyperg_2F1 bug report
Date: Thu, 31 Jan 2002 12:30:04 -0000

gsl_sf_hyperg_2F1_e fails with arguments (1,13,14,0.999227196008978,&r).
It should return 53.4645... .

#include <gsl/gsl_sf.h>
#include <stdio.h>

int main (void)
{
  gsl_sf_result r;
  gsl_sf_hyperg_2F1_e (1,13,14,0.999227196008978,&r);
  printf("r = %g %g\n", r.val, r.err);
}

NOTES: The program overflows the maximum number of iterations in
gsl_sf_hyperg_2F1, due to the presence of a nearby singularity at
(c=a+b,x=1) so the sum is slowly convergent.

The exact result is 53.46451441879150950530608621 as calculated by
gp-pari using sumpos(k=0,gamma(a+k)*gamma(b+k)*gamma(c)*gamma(1)/
(gamma(c+k)*gamma(1+k)*gamma(a)*gamma(b))*x^k)

The code needs to be extended to handle the case c=a+b. This is the
main problem. The case c=a+b is special and needs to be computed
differently.  There is a special formula given for it in Abramowitz &
Stegun 15.3.10

As reported by Lee Warren <warren@atom.chem.utk.edu> another set of
arguments which fail are:

#include <gsl/gsl_sf.h>
#include <stdio.h>

int main (void)
{
  gsl_sf_result r;
  gsl_sf_hyperg_2F1_e (-1, -1, -0.5, 1.5, &r);
  printf("r = %g %g\n", r.val, r.err);
}

The correct value is -2.

See also, 

From: Olaf Wucknitz <wucknitz@jive.nl>
To: bug-gsl@gnu.org
Subject: [Bug-gsl] gsl_sf_hyperg_2F1

Hi,

I am having a problem with gsl_sf_hyperg_2F1.
With the parameters (-0.5, 0.5, 1, x) the returned values show a jump at 
x=0.5. For x<0.5 the results seem to be correct, while for x>0.5 they 
aren't.
The function gsl_sf_hyperg_2F1_e calls hyperg_2F1_series for x<0.5, but
hyperg_2F1_reflect for x>0.5. The latter function checks for c-a-b being 
an integer (which it is in my case). If I change one of the parameters 
a,b,c by a small amount, the other branch of the function is taken and the 
results are correct again.
Unfortunately I know too little about the numerics of 2F1 to suggest a 
patch at the moment.

Regards,
Olaf Wucknitz
-- 
Joint Institute for VLBI in Europe                wucknitz@jive.nl

------------------------------------------------------------------------
BUG-ID:   21836   
STATUS:   Open/Confirmed  
CATEGORY: Accuracy problem
SUMMARY:  gamma_inc_P and gamma_inc_Q only satisfy P+Q=1 within errors

BUG#44 -- gamma_inc_P and gamma_inc_Q only satisfy P+Q=1 within errors

The sum of gamma_inc_P and gamma_inc_Q doesn't always satisfy the
identity P+Q=1 exactly (although it is correct within errors), due the
slightly different branch conditions for the series and continued
fraction expansions.  These could be made identical so that P+Q=1 exactly.

#include <stdio.h>
#include <gsl/gsl_sf_gamma.h>

int
main (void)
{
  gsl_sf_result r1, r2;
  double a = 0.3, x = 1.0;
  gsl_sf_gamma_inc_P_e (a, x, &r1);
  gsl_sf_gamma_inc_Q_e (a, x, &r2);
  printf("%.18e\n", r1.val);
  printf("%.18e\n", r2.val);
  printf("%.18e\n", r1.val + r2.val);
}

$ ./a.out
9.156741562411074842e-01
8.432584375889111417e-02
9.999999999999985567e-01

3 - NormalNone

------------------------------------------------------------------------
BUG-ID:   21837   
STATUS:   Open/Confirmed  
CATEGORY: Runtime error
SUMMARY:  gsl_linalg_solve_symm_tridiag requires positive definite matrix

A zero on the diagonal will cause NaNs even though a reasonable
solution could be computed in principle. 

#include <gsl/gsl_linalg.h>

int main (void)
{
  double d[] = { 0.00, 1.21, 0.80, 1.55, 0.76 } ;
  double e[] = { 0.82, 0.39, 0.09, 0.68 } ;
  double b[] = { 0.07, 0.62, 0.81, 0.11, 0.65} ;
  double x[] = { 0.00, 0.00, 0.00, 0.00, 0.00} ;

  gsl_vector_view dv = gsl_vector_view_array(d, 5);
  gsl_vector_view ev = gsl_vector_view_array(e, 4);
  gsl_vector_view bv = gsl_vector_view_array(b, 5);
  gsl_vector_view xv = gsl_vector_view_array(x, 5);

  gsl_linalg_solve_symm_tridiag(&dv.vector, &ev.vector, &bv.vector, &xv.vector);
  gsl_vector_fprintf(stdout, &xv.vector, "% .5f");

  d[0] += 1e-5;
  gsl_linalg_solve_symm_tridiag(&dv.vector, &ev.vector, &bv.vector, &xv.vector);
  gsl_vector_fprintf(stdout, &xv.vector, "% .5f");
}

$ ./a.out
 nan
 nan
 nan
 nan
 nan
 0.13626
 0.08536
 1.03840
-0.60009
 1.39219

AUG 2007: We now return an error code for this case.  To return a solution
we would need to do a permutation, see slatec/dgtsl.f

3 - NormalNone

------------------------------------------------------------------------
BUG-ID:   24252   
STATUS:   Open/Confirmed  
CATEGORY: None
SUMMARY:  suggestion: add gamma tail distribution

From: Laedermann Jean-Pascal <Jean-Pascal.Laedermann@chuv.ch>
To: Brian Gough <bjg@gnu.org>
Subject: RE : RE : tail gamma
Date: Thu, 11 Sep 2008 08:45:41 +0200

Hello,

It's only a piece of C code I attach here.
The source is the excellent book of Devroye (chapter nine p 420), see attachments.

Hoping this will be useful.

Jean-Pascal Laedermann, PhD
ing. phys. EPFL, math. UNIL

--None

------------------------------------------------------------------------
BUG-ID:   24812   
STATUS:   Open/Confirmed  
CATEGORY: Runtime error
SUMMARY:  gsl_sf_hyperg_2F1(11, -1 ; 11/2; 0.125) fails

From: "Didier Pinchon" <pinchon.didier@orange.fr>
To: <bug-gsl@gnu.org>
Subject: [Bug-gsl] Bug in gsl_sf_hyperg_2F1 ??
Date: Sat, 8 Nov 2008 03:00:41 +0100

Hello,

I have tried to compute 2F1(11, -1 ; 11/2; 0.125) and I got an error message (below is my sample program).
However 2F1(-1, 11 ; 11/2; 0.125) provides the right result 0.75

Am I wrong somewhere ?
I did not find any indication in archives.

Thank you for your help.
All the best,
Didier

/* Compilation and execution:
$ gcc -o bug_gsl -I/usr/local/include/gsl bug_gsl.c -L/usr/local/lib -lgsl -lm

$ ./bug_gsl
gsl: hyperg_2F1.c:750: ERROR: error
Default GSL error handler invoked.
Abandon

*/

-line 732:
    if(GSL_MAX_DBL(fabs(a),1.0)*fabs(bp)*fabs(x) < 2.0*fabs(c)) {
line 740:
    if(fabs(bp*bp*x*x) < 0.001*fabs(bp) && fabs(a) < 10.0) {

I think these should have a=>ap for consistency

------------------------------------------------------------------------
BUG-ID:   24871   
STATUS:   Open/Confirmed  
CATEGORY: None
SUMMARY:  suggestion, add support for E_n

Dear GSL group,

Thank you very much for your work on GSL. I use it much in Octave.

I think it would be great if you could improve the GSL routines
for computations of exponential integrals so that they can accept complex arguments too. A good algorithm for this was published in

ACM Transactions on Mathematical Software
Donald E. Amos, Computation of Exponential Integrals of a Complex Argument, vol.16, no. 2, p.169--177, 1990,
http://doi.acm.org/10.1145/78928.78933

ACM Transactions on Mathematical Software
Donald E. Amos, Algorithm 683: A Portable FORTRAN Subroutine for Exponential Integrals of a Complex Argument, vol.16, no. 2,
p.178--182, 1990,
http://doi.acm.org/10.1145/78928.78934

The fortran code is available at
http://www.netlib.org/toms/683
http://www.netlib.no/netlib/toms/683
http://www.mirrorservice.org/sites/netlib.bell-labs.com/netlib/toms/683.gz
http://scicomp.ewha.ac.kr/netlib/toms/683

With best wishes,
Oleg

---
D.Sc. Oleg V. Motygin,
Institute of Problems in Mech Engineering
Russian Academy of Sciences
V.O., Bol'shoj pr. 61
199178 St.Petersburg
Russia
email: o.v.motygin@gmail.com, mov222@yandex.ru

_______________________________________________
Bug-gsl mailing list
Bug-gsl@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gsl

------------------------------------------------------------------------
BUG-ID:   25320   
STATUS:   Open            
CATEGORY: Accuracy problem
SUMMARY:  Import fresnel, bugs on GSL Extension Fresnel

The fresnel extension should be imported for the next release, with the following bug report checked.

From: "Toshiro Ohsaki" <t.ohsaki@ipb.co.jp>
To: <bug-gsl@gnu.org>
Subject: [Bug-gsl] Bugs on GSL Extension Fresnel
Date: Wed, 26 Nov 2008 21:07:02 +0900

Dear staff of GNU

  I found bugs on GSL Extensions/Applications Fresnel by Andrew Steiner.
 This program does not return a correct value, if x is negative.

The original function fresnel_c is coded as,

double fresnel_c(double x)
{
  double xx = x*x*pi_2;
  double ret_val;
  if(xx<=8.0)
   ret_val = fresnel_cos_0_8(xx);
  else
   ret_val = fresnel_cos_8_inf(xx);
  return (x<0.0) ? -ret_val : ret_val;
}
.

 I think it should be coded as,

double fresnel_c(double x)
{
  double xx = x*x*pi_2;
  double ret_val;
  double sign;

  if(xx < 0.0){
    xx*=-1.0;
    sign=-1.0;
  }
  else{
    sign=1.0;
  }

  if(xx<=8.0)
   ret_val = fresnel_cos_0_8(xx);
  else
   ret_val = fresnel_cos_8_inf(xx);

  ret_val*=sign;

  return(ret_val);
}
.

The same correction should be done on the function fresnel_s.

Sincerely yours,
Toshiro Ohsaki
from Tokyo Japan.
_______________________________________________
Bug-gsl mailing list
Bug-gsl@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gsl

------------------------------------------------------------------------
BUG-ID:   25383   
STATUS:   Open/Postponed  
CATEGORY: None
SUMMARY:  use GSL_ENOPROG instead of GSL_CONTINUE in lmiterate.c

[I think we should use GSL_ENOPROG in lmiterate.c although it could break existing code I guess]

From: "Mark M. Ito" <marki@jlab.org>
To: bug-gsl@gnu.org
Subject: [Bug-gsl] non-linear LS fit example in documentation: bug?
Date: Tue, 20 Jan 2009 15:16:26 -0500

Dear GSL folks,

In section 37.9 "Example programs for Nonlinear Least-Squares Fitting" 
in the gsl manual, the main loop says:

       do
         {
           iter++;
           status = gsl_multifit_fdfsolver_iterate (s);

           printf ("status = %s\n", gsl_strerror (status));

           print_state (iter, s);

           if (status)
             break;

           status = gsl_multifit_test_delta (s->dx, s->x,
                                             1e-4, 1e-4);
         }
       while (status == GSL_CONTINUE && iter < 500);

       gsl_multifit_covar (s->J, 0.0, covar);

Shouldn't the "if (status) break;" be an "if (status) continue;"? It is 
normal for the solver to return GSL_CONTINUE in which case you want to 
continue to iterate. Break exits the do loop completely, no?

  -- Mark Ito

________________________________
This has been documented in the manual. Will change in a future release (1.14)3 - NormalConfirmed

------------------------------------------------------------------------