Noémie Soullier

M Ph

Ph.D Jean Bouyer

M.D Jean-Luc Pouly

M.D Juliette Guibert

Elise De

Ph.D L A Rochebrochard

Effect of the woman's age on discontinuation of IVF treatment

Keywords: Age, cumulative rates, in vitro fertilization, multiple imputation, treatment discontinuation

Treatment discontinuations are an important issue in IVF programmes. In the French context, financial constraint does not intervene in discontinuation until older ages.

This study examined treatment discontinuation in IVF programmes, according to the woman's age and when there is no financial burden for couples. Medical records were collected for 3037 women who began their IVF programme between 1998 and 2002 in two French IVF units. Up to four attempts were taken into consideration.

Cumulative success (delivery) rates were calculated, as well as discontinuation rates.

Multiple imputation was applied to estimate a theoretical cumulative success rate as if no woman discontinued treatment before the end of the IVF programme without delivering. Cumulative discontinuation rates at the end of the IVF programme increased with the woman's age (41% for age<35, 56% for age 35-39, 80% for age ≥40). The benefit in terms of delivery rates of pursuing treatment would be smaller for older women (~10% for age<35, 7% for age 35-39, 4% for age ≥40). Even when treatment is reimbursed, the discontinuation rate is high for older women, suggesting that the strong decrease in success rate with age induces older women to discontinue.

Introduction

Since the middle of the twentieth century, epidemiologists and demographers have presented numerous results showing that the increasing age of a woman causes a decline in the biological ability to give birth to a child, i.e. fecundity [START_REF] Henry | Some data on natural fertility[END_REF][START_REF] Tietze | Reproductive span and rate of reproduction among Hutterite women[END_REF]). These studies estimated that the age for the start of the fall in the probability of conception lay within the age range 31-35 years [START_REF] Schwartz | Female fecundity as a function of age: results of artificial insemination in 2193 nulliparous women with azoospermic husbands[END_REF][START_REF] Van Noord-Zaadstra | Delaying childbearing: effect of age on fecundity and outcome of pregnancy[END_REF].

A similar age effect has been shown for women undergoing in vitro fertilization (IVF). A decrease in the live birth rate per cycle started has been demonstrated in older women [START_REF] Templeton | Factors that affect outcome of in-vitro fertilisation treatment[END_REF]. In particular, the success rate was highest for women aged between 25 and 30 and declined sharply after age 35.

In the light of some recent studies, it seems interesting to consider IVF success not only in relation to each attempt, but also throughout the entire IVF program consisting of several successive attempts [START_REF] Land | Patient dropout in an assisted reproductive technology program: implications for pregnancy rates[END_REF][START_REF] Witsenburg | Cumulative live birth rates in cohorts of patients treated with in vitro fertilization or intracytoplasmic sperm injection[END_REF]. Witsenburg et al. carried out a cohort study in two centers in The Netherlands that included 1456 patients starting IVF treatment between 1996 and 2000 [START_REF] Witsenburg | Cumulative live birth rates in cohorts of patients treated with in vitro fertilization or intracytoplasmic sperm injection[END_REF]. They showed that although both centers had the same live birth rate per cycle (24%), their cumulative live birth rate differed significantly (59% vs. 49%). This was explained by the lower number of cycles undergone by the patient (due to a higher discontinuation rate) in the center with the lower cumulative success rate.

Treatment discontinuations are an important issue in IVF programs, as the proportion of women discontinuing treatment before having a child is very high. Land et al. reported a cumulative drop-out rate of 62% after the three cycles that are reimbursed by health insurance in The Netherlands [START_REF] Land | Patient dropout in an assisted reproductive technology program: implications for pregnancy rates[END_REF], while La Rochebrochard et al. reported this cumulative drop-out rate to be 46% and 58% at the end of the fourth and last reimbursed cycle in two French IVF units (La [START_REF] Rochebrochard | High in vitro fertilization discontinuation rate in France[END_REF].

Previous work suggests that the women who discontinue the IVF program may have a poorer prognosis of success than those who persevere [START_REF] Sharma | Factors influencing the cumulative conception rate and discontinuation of in vitro fertilization treatment for infertility[END_REF].

In this context, life-table analysis has been shown to overestimate success rates [START_REF] Daya | Life table (survival) analysis to generate cumulative pregnancy rates in assisted reproduction: are we overestimating our success rates?[END_REF][START_REF] Land | Patient dropout in an assisted reproductive technology program: implications for pregnancy rates[END_REF][START_REF] Witsenburg | Cumulative live birth rates in cohorts of patients treated with in vitro fertilization or intracytoplasmic sperm injection[END_REF], and so is considered as an "optimistic" estimation. Conversely, methods considering that patients who discontinue IVF have no chance of success lead to "conservative" estimations [START_REF] Malizia | Cumulative live-birth rates after in vitro fertilization[END_REF]. Various alternative methods have been developed to give a better estimate [START_REF] Olivius | Cumulative probability of live birth after three in vitro fertilization/intracytoplasmic sperm injection cycles[END_REF][START_REF] Soullier | Estimating the success of an in vitro fertilization programme using multiple imputation[END_REF][START_REF] Stolwijk | Cumulative probability of achieving an ongoing pregnancy after in-vitro fertilization and intracytoplasmic sperm injection according to a woman's age, subfertility diagnosis and primary or secondary subfertility[END_REF]. A possible solution would be to include the reason for discontinuation in the estimation of the cumulative success rate. The problem is that discontinuation of treatment is a matter of not deciding to continue, rather than deciding not to continue. It is defined a posteriori, when the women did not return to the IVF unit after a long period. Thus, the reason for discontinuation is not entered in the medical records and can be hard to determine. To study the reason for discontinuation, questionnaires must be sent to the women years after their last IVF attempt [START_REF] Olivius | Why do couples discontinue in vitro fertilization treatment? A cohort study[END_REF][START_REF] Rajkhowa | Reasons for discontinuation of IVF treatment: a questionnaire study[END_REF]). When we wish to estimate the cumulative success rate, it is important to take into account discontinuations of treatment. However, it is not the reason for discontinuation which is most important, but the chances of success that women who discontinued would have had. The two may be linked as women discontinuing for a medical reason are likely to have had poor chances of success if they had continued.

However, when the objective is to estimate the success rate, data focus on medical records and do not clarify the reason for discontinuation. Rather, they provide variables that are linked with both success and discontinuation and can be used to compare women discontinuing and women continuing, as well as to make inferences on the chances of success that women who discontinued would otherwise have had. This appears to be a promising method of providing a better estimation of the IVF success rate than that obtained with "optimistic" or "conservative" methods [START_REF] Malizia | Cumulative live-birth rates after in vitro fertilization[END_REF]).

The French social security system reimburses up to four IVF attempts to all couples until the woman is 43 years old. In this context, financial constraint does not intervene in discontinuation until older ages.

We aimed to examine treatment discontinuation in IVF programs, according to the woman's age and when there is no financial burden for couples.

Materials and methods

The Institutional Review Board (CNIL) approved the project in September 2005.

Population and methods have been detailed in a previous article [START_REF] Soullier | Estimating the success of an in vitro fertilization programme using multiple imputation[END_REF] and are briefly described below.

Materials

Data were provided by two French IVF units (Cochin in Paris and Clermont-Ferrand, a medium-sized city in the center of France). All 3037 women beginning an IVF program between 1998 and 2002 in these two units were included. Data were collected from medical records and concerned all conventional IVF procedures and intracytoplasmic sperm injections (ICSI) undergone by the woman in the IVF unit, as well as data on frozen embryo transfers (FET) up to 2005. Data were collected until the woman's fourth attempt, four being the number of attempts which is refunded by the French social security system.

Definitions

An IVF program was therefore defined as a maximum of four successive attempts undergone by the woman in the IVF unit. An attempt was defined as an aspiration, i.e. an oocyte pick-up from the patient (cycles cancelled before oocyte retrieval were not included). Success of an attempt was defined as a delivery resulting from fresh or frozen embryo transfer. Only the first delivery was considered. Discontinuation of treatment was defined as no subsequent attempt in the IVF unit for at least two years at the time of data acquisition, whatever the reason for discontinuation (decision to stop IVF treatment, relocation to another area, decision to pursue treatment in another IVF center, etc). Age was defined at the beginning of the IVF program and was considered as a categorical variable divided into 5 groups: <25, [25 -29], [30 -34], [35 -39], and ≥40 years.

Methods

The observed cumulative delivery rate corresponded to the percentage of women entering the IVF unit and delivering during the IVF program.

The cumulative discontinuation rate corresponded to the proportion of women discontinuing treatment before the end of the IVF program without delivering expressed as a percentage of the women entering the IVF unit..

To evaluate the efficiency of the IVF technique, the theoretical cumulative delivery rate was calculated. This is the delivery rate which would be achieved if no woman discontinued treatment before the end of the IVF program. It was calculated by reconstituting a whole program for women who discontinue treatment as if they had in fact continued. Outcomes of attempts posterior to discontinuation were treated as missing and were estimated with multiple imputation (MI). The MI method consists of replacing each missing value by a set of plausible values in order to take into account the uncertainty about the correct value to impute. This method has been presented in detail elsewhere [START_REF] Soullier | Estimating the success of an in vitro fertilization programme using multiple imputation[END_REF][START_REF] Soullier | Multiple imputation for estimation of an occurrence rate in cohorts with attrition and discrete follow-up time points: a simulation study[END_REF]). The MI estimation was made using the known characteristics of women and of their previous aspirations: IVF unit, woman's age, number of oocytes retrieved and total number of embryos (defined as the sum of the number of transferred embryos and the number of frozen embryos). Following Rubin's recommendations, we made 5 imputations by attempt [START_REF] Rubin | Multiple imputation after 18+ years[END_REF]. Multiple imputation was carried out using the SAS MI procedure (SAS/STAT® 9.1 User's Guide. Cary, NC: SAS Institute Inc., 2004).

Results

Of the 3037 women included, 716 (24%) were aged between 25 and 29 years at the beginning of their IVF program, 1215 (40%) were aged between 30 and 34 years and 807 (27%) were aged between 35 and 39 years. The younger and older age groups were much smaller: at the beginning of the IVF program, 80 women (3%) were aged less than 25 years and 219 (7%) were aged ≥40 years. Median age at the beginning of the program was 32 years. On average, women were aged 33 years at the first and second attempts, 34 years at the third attempt and 35 at the fourth attempt.

The decrease in observed delivery rates with the woman's age is shown in Figure 1 (solid line). The three groups of women starting an IVF program before age 35 had similar chances of delivery. In older women, the observed cumulative delivery rate decreased for age 35-39 and declined sharply for age ≥40. These observed delivery rates at ages 35-39 and ≥40 differed significantly both from each other and from those of the age groups <35 years (p-values < 0.03).

On the other hand, cumulative discontinuation rates at the end of the IVF program increased with the woman's age (Table 1). Indeed, 41% of women starting an IVF program before age 35 years discontinued treatment before completion without delivering. This proportion increased to 56% for women starting a program between age 35 and 39 and was twice as high (80%) for women aged ≥40 at the beginning of the IVF program. Concerning the time of discontinuation, half of all women discontinuing treatment did so after the first attempt, 32% after the second and 18% after the third. This distribution was similar in the five age groups.

The theoretical cumulative delivery rate estimated what the cumulative delivery rates would be if no woman discontinued before the end of the IVF program without delivering (Figure 1). This would increase the chances of delivery for women starting IVF before age 35 years by about 10%. Thus, younger women would have a more than 50% chance of delivery during the IVF program if none of them discontinued treatment. For women starting IVF when older than 35 years, the increase would be smaller: 7% for women starting between age 35 and 39, and 4%

for women starting at 40 years or later. Overall, the delivery rate would increase from 37% to 46% if no woman discontinued treatment before the end of the IVF program without delivering.

Differences were also noted in the time elapsing between successive attempts according to the woman's age. On average, the time elapsing since the beginning of the IVF program was 1.0 year at the time of the second attempt, 1.8 years at the third attempt and 2.6 years at the fourth attempt (Table 2). However, the intervals between attempts were shorter for older age groups. Women beginning an IVF program before age 35 completed the fourth attempt approximately 2.7 years later, whereas women starting a program at age ≥40 took 1 year less to complete a program of four attempts (1.7 years). Carrying out the same analysis but including only the women who did not have frozen embryo transfers between aspirations, the same significant trend was observed at each attempt (p-values < 0.002). This result was therefore not due to a greater number of frozen embryo transfers for the younger women.

Discussion

Studying the effect of the woman's age on discontinuation of IVF treatment is a new and important topic. It is particularly interesting to study this issue in the French context, where four attempts are reimbursed by the French social security system for all women aged less than 43 years. Indeed, financial burden did not intervene in the decision to discontinue. We observed that the cumulative discontinuation rate was high and that it strongly increased with the woman's age.

We also noted a strong decrease in cumulative IVF success rates with the woman's age: from 44% at 25-29 years to 14% at over 40 years old. This decrease may be even greater if not only oocyte pick-up cycles but also all cycles where women started stimulation are included. In our study, this decrease can be explained both by a decrease in delivery rates following embryo transfer and by a decrease in the number of frozen embryo transfers following an IVF attempt. Indeed, after the first IVF attempt, 40% of women aged <35 years who did not obtain a delivery after fresh embryo transfer had at least one frozen embryo transfer, but this proportion decreased to 29% among women aged 35-39 years and 18% among those aged 40 years and older. In our analysis, the effect of the center's frozen embryo policy was controlled by including a center effect in the imputation model.

Both women and physicians are well aware of this decrease. Two results suggested that IVF success rates were being taken into account by the women who discontinued. First, the difference between the theoretical and the observed cumulative delivery rates was smaller for older women than for younger women. The theoretical cumulative delivery rate -the rate as if no woman discontinued unless she delivered -was estimated using multiple imputation based on variables characterizing the main biological factors explaining IVF success and discontinuation for medical reasons [START_REF] Sharma | Factors influencing the cumulative conception rate and discontinuation of in vitro fertilization treatment for infertility[END_REF][START_REF] Soullier | Estimating the success of an in vitro fertilization programme using multiple imputation[END_REF][START_REF] Templeton | Factors that affect outcome of in-vitro fertilisation treatment[END_REF].

The small difference between the observed and the theoretical cumulative success rates for older women might then suggest that most of these discontinuations were due to poor chances of success. Second, older women completed an IVF program more quickly than younger women: women aged <35 when they started the IVF program completed the whole program in almost three years, whereas women aged between 35 and 39 completed it in two years and women aged ≥40 in a year and a half. This difference was not due to a greater number of frozen embryo transfers undergone by the younger women. This could reflect the fact that physicians and/or women are aware that IVF efficiency decreases markedly after age 35. Therefore, physicians and their patients may be more likely to conduct IVF cycles in rapid succession, to diminish the effect of further age-related decline on IVF success. The hypothesis that women beginning an IVF program after age 35 received more rapid treatment has been suggested in a study in a French unit [START_REF] Tain | The hospital, the woman and the physician: the construction of in vitro fertilization trajectories[END_REF]. Such a possibility deserves more detailed research.

In a brand-new perspective, this work suggests that when financial constraint does not intervene, another process leads older women to discontinue treatment.

Further research should be done to determine how this process originates: does the woman/couple make the decision to discontinue or do the medical staff strongly recommend it? In the latter case, the couple may consider pursuing treatment in another IVF unit. Further work should address the reasons and consequences of the decision to discontinue IVF treatment. Moreover, it will be important to develop these results by examining how cycles cancelled before oocyte pick-up affect the treatment discontinuation process. These cancelled cycles could represent 10% to 15% of all cycles [START_REF] Min | What is the most relevant standard of success in assisted reproduction? The singleton, term gestation, live birth rate per cycle initiated: the BESST endpoint for assisted reproduction[END_REF]) and center policies regarding cancellation of IVF treatment before oocyte pick-up may vary. This issue could not be dealt in the current study as data on all cycles where women started stimulation were not collected.

In a context of state reimbursement for all, the increase in discontinuation rates with the woman's age suggests that IVF care self-regulates. Even when the IVF attempts are reimbursed, the discontinuation rate is very high for older women, suggesting that the strong decrease in success rate with age induces them to discontinue treatment.

Table 1 . Cumulative discontinuation rates at the end of the IVF program according to the woman's age at the beginning of the program

 1

			Cumulative discontinuation
	Woman's age (years)	N	rate a %
	< 25	80	41
	25 -29	716	41
	30 -34	1215	41
	35 -39	807	56
	≥ 40	219	80
	Overall	3037	48

a Proportion of women discontinuing treatment before the end of the IVF program without delivering expressed as a percentage of the women entering the IVF unit

Figure 1.

Cumulative delivery rates according to the woman's age at the beginning of the IVF programme.

  Triangles with solid line = observed rates; squares with dotted line = theoretical rates.

	Data for figure 1
	Age at the first attempt (years)	N	Observed rates	Theoretical rates
	< 25	80	40.00	49.59
	25 -29	716	44.00	55.94
	30 -34	1215	41.98	51.46
	35 -39	807	27.88	35.19
	≥ 40	219	14.16	18.19
	Overall	3037	36.78	45.74


Maria Papadomanolaki
email: mar.papadomanolaki@gmail.com

Sagar Verma
email: sagar.verma@centralesupelec.fr

Maria Vakalopoulou
email: maria.vakalopoulou@centralesupelec.fr

Siddharth Gupta

Konstantinos Karantzalos

Detecting urban changes with recurrent neural networks from multitemporal Sentinel-2 data

Keywords: change detection, fully-convolutional, urban, recurrent networks, multi-temporal modeling, high resolution satellite imagery

come

INTRODUCTION

Change detection is a critical issue for the remote sensing community as it provides an effective way of monitoring the globe. A thorough understanding of the earth's land usage and land cover (LULC) in time can be made by modeling the changes that occur owing to man-made structures and natural phenomena. As far as human intervention on earth is concerned, change detection techniques offer valuable information on a variety of topics such as urban sprawl, water and air contamination levels, illegal constructions, etc. In this way, we can fully comprehend the future LULC tendencies, take Date 1 Date 3 Date 5 Change Mask Fig. 1. Learning specific types of change such as urbanisation is a challenging task. The concurrent exploitation of more than two temporal images is more robust in detecting accurately changes since the presence of clouds/shadows (top) or vegetation/agricultural alterations may be significant (bottom).

precautions and design more appropriate city infrastructures.

However, even if nowadays we can have access to a large amount of multitemporal datasets provided by satellites such as Landsat and Sentinel, the problem of change detection is very challenging. Traditional methods, summarised in surveys such as [START_REF] Radke | Image change detection algorithms: a systematic survey[END_REF], use handcrafted techniques which heavily rely on pre-processing and post-processing making them not so easily adaptive to images that cover large areas. Change detection is a non-trivial problem as the accuracy of a method is highly influenced by registration errors [START_REF] Vakalopoulou | Simultaneous registration and change detection in multitemporal, very high resolution remote sensing data[END_REF] and illumination changes that do not really correspond to semantic changes.

Recently, with the advances in deep learning-based methods in different fields, a variety of change detection techniques have been proposed. In particular, in [START_REF] Mou | Learning spectral-spatial-temporal features via a recurrent convolutional neural network for change detection in multispectral imagery[END_REF] a deep patchbased architecture is proposed where bi-temporal patches are processed in parallel by a series of dilated convolutional layers generating features which are then fed to a recurrent sub-network to learn sequential information. In the end, fullyconnected layers are used to create the change prediction map. Although patch-based techniques produce promising results, they are time-consuming since they need to process every single pixel of the image individually. Recently, Daudt et al. [START_REF] Caye Daudt | Fully convolutional siamese networks for change detection[END_REF] suggested three different fully-convolutional siamese networks based on the U-Net architecture [START_REF] Ronneberger | U-net: Convolutional networks for biomedical image segmentation[END_REF] aiming to address this problem and detect accurately the regions with changes. However, this approach is lacking the appropriate modeling of the data's temporal pattern.

In this paper, we investigate the use of recurrent networks and in particular fully convolutional Long Short-Term Memory (LSTM) [START_REF] Hochreiter | Long short-term memory[END_REF] layers for pixel-wise detection of urbanization from multi-temporal high-resolution data. The proposed deep learning model uses a simple U-Net architecture to compute spatial features from multi-date inputs while LSTM blocks learn the temporal change pattern. Our experiments were based on the recently publicly available Onera Satellite Change Detection dataset (OSCD) [START_REF] Caye Daudt | Urban change detection for multispectral earth observation using convolutional neural networks[END_REF] after enriching it with more temporal information for each of the provided cities. Our final aim is to study the behaviour and prospects of such a model when multitemporal data are available eliminating at the same time the need for any fully-connected layers.

METHODOLOGY

The employed network is based on the U-Net architecture and it is demonstrated in Figure 2. Each block involves convolutional, batch normalization and rectified linear unit (ReLU) activations. All the convolutional operations apply 3x3 filters with both stride and padding being equal to 1. As far as the encoder is concerned, the first convolutional block increases the depth to 16, while the height and width of the input volume remain unchanged. The following four blocks follow the same pattern increasing the depth to twice its size and including also a 2x2 max pooling operation. As a result, at the end of the encoder the input has been downsampled at one fourth of its original dimension containing 256 planes.

The encoding process is repeated for every different date independently while at the same time, recurrent blocks existing in each of the five encoding levels calculate the temporal relationship among the outputs. This is implemented by replacing the standard fully-connected LSTM operations with convolutional structures. In practice, the recurrent operations' weights are no longer simple matrices, but convolutional layers which constitute in this way an end-to-end trainable framework.

Next, the decoder receives the encoder's last temporal volume to upsample it back to its original dimensions. For this purpose, five convolutional blocks similar to the encoder are used, this time applying 2x2 upsampling operations instead of max-pooling ones. In addition, the resulted feature map of each upsampling operation is concatenated with the calculated temporal pattern of the symmetrical block existing in the encoder part. In this way, higher resolution information is combined with lower resolution information producing more sophisticated features and maintaining spatial and temporal knowledge. Finally, at the end of the model, a 1x1 convolution operation is applied to compute the final probability heatmap detecting areas of urbanisation.

Dataset and Implementation Details

All the experiments were conducted using the Onera Satellite Change Detection dataset (OSCD) [START_REF] Caye Daudt | Urban change detection for multispectral earth observation using convolutional neural networks[END_REF] which consists of Sentinel-2 satellite images depicting 24 different cities around the world for two distinct dates. 13 spectral channels are available for each image pair with ground truth information provided for 14 cities. Our setup follows the submission system guidelines where the 14 image pairs are used for training and the rest for testing.

As mentioned earlier, additional Sentinel-2 images depicting the provided cities in different dates were acquired to further enrich the temporal information of the OSCD dataset.

In Table 1 we present some of the additional selected images for 8 different cities. The first and last rows include the before and after dates that are already provided in the OSCD dataset. In general, we tried to obtain dates corresponding to similar seasons for every city, adapting them as much as possible to the two existing OSCD dates. 1. Acquired dates for some cities to enhance the already provided OSCD bi-temporal information.

For the training process, patches of size 32x32 were produced with a stride of either 6 in case change pixels were included, or 32 in case the patch did not include pixels for the change class. This strategy was applied as a data augmentation approach to enrich the training samples that contain change. In addition, more data augmentation techniques mainly used from the computer vision community, namely flipping in all possible angles proportional to 90 degrees, were implemented for patches whose number of change pixels exceeded the threshold of 5% for the entire patch. Lastly, each class was associated with a weight inversely proportional to the total pixel number included in it. A total of 32421 patches containing both change and non-change pixels resulted from the 14 training cities and was feedforwarded to the proposed architecture for training. To provide more robust results, our final predictions were produced by an ensemble of different trained models following a cross-validation. Giving some more details, the training patches were divided into five equal parts and the same model was trained five times using all possible combinations of the dataset partitions. Then, predictions for the testing images were produced from all five models and in the end the final predictions were formulated by averaging the five model outcomes. Regarding hyperparameter details, the chosen optimizer was Adam while batch size and learning rate values were equal to 64 and 0.0001 respectively. All experimental setups were conducted using the PyTorch deep learning library [START_REF] Paszke | Automatic differentiation in pytorch[END_REF] on a single NVIDIA GeForce GTX TI-TAN with 12 GB of GPU memory, with the training time for each model being approximately 70 minutes and the testing for an entire city approximately 1 minute.

EXPERIMENTAL RESULTS AND DISCUSSION

Different model combinations were evaluated on the testing images, the results of which are shown in Table 2. Precision, recall, F1 score and Overall Accuracy rates have resulted from the confusion matrix of the testing images for each different approach while all quantitative numbers except OA are associated to the change class. Beginning with the simple U-Net architecture, judging from the F1 rate we can observe that between 2/13 and 2/4, change has been more successfully detected in the latter case. This can be explained by the fact that RGB-NIR channels provide the highest spatial resolution in Sentinel-2 images. Hence, the integration of the remaining lower resolution channels to the training process requires the use of more sophisticated pansharpening methods than only simple resizing. Based on this fact and since 13 channel volumes require much more computational power and registration preprocessing, we based our experiments on the four higher resolution channels.

Continuing with the quantitative analysis, one can notice that for the simple U-Net architecture the addition of temporal dates reduce the performance of the model, indicating that this architecture is not capable to model properly the temporal information that exists in more than two pairs of images. On the other hand, the use of the LSTM blocks prove their significance by reporting their best performance after using all the available temporal information. In addition, recall rates remain over 50% in all Dates-Channels combinations.

In Figure 3, we can also present some qualitative results from the different models. Red and green parts in the predictions' visualization represent false positive and false negative areas that we have manually annotated, only for the qualitative analysis of our method, since no ground truth is available for the testing part of the dataset. As we can observe, the LSTM frameworks are able to distinguish clouds from change as shown in the Milano case in the third row. In addition, bi-temporal approaches tend to confuse urban changes with changes related to bare soil lands, whereas multi-date approaches seem to overcome this problem. This is obvious in the last row of Figure 3 where false positives are reduced when more dates are exploited. In the Dubai case however, bare-soil-related false positives continue to exist in the 5-dates case, whereas they are eliminated in the 3-dates case. Such false positive predictions may be a result of various factors like clouds, improper registration etc.

CONCLUSION

In this paper, we investigated the behaviour of LSTM convolutional blocks integrated into fully-convolutional deep architectures for urban change detection. Several experiments were implemented using various combinations of architectures and inputs. Results on the OSCD dataset indicate that the use of recurrent networks can boost both F1 and Overall Accuracy rates. Our future steps include the investigation of other types and combinations of recurrent fully convolutional architectures on high-resolution images. Moreover, we will also investigate the use of these models for change detection on very high-resolution satellite imagery.

Fig. 2 .

 2 Fig. 2. Graphical illustration of the employed architecture. The left and the right part demonstrate the network's encoder and decoder respectively. Blue layers represent convolutional blocks while pink boxes illustrate the recurrent processing layers.

Fig. 3 .

 3 Fig. 3. Qualitative evaluation of the employed frameworks on testing images. From top to bottom: Dubai, Brasilia, Milano, Las Vegas. From left to right: Image1, Image2, 2/4 U-Net, 2/4 U-Net+LSTM, ,3/4 U-Net+LSTM, 5/4 U-Net + LSTM. White: True Positives, Black: True Negatives, Red: False Positives, Green: False Negtatives.

Table 2 .

 2 Quantitative evaluation of the proposed framework. Precision, recall and F1 rates are associated to the change class. All the rows except the first one demonstate results using the RGB-NIR bands.

	Architecture	#Dates/ #Channels Precision Recall	OA	F1
		2/13	60.80	50.51 95.76 55.18
	U-Net	2/4 3/4	58.87 59.28	53.90 95.67 56.28 51.94 95.67 55.36
		5/4	61.21	47.57 95.73 53.53
		2/4	59.88	54.78 95.77 57.22
	U-Net + LSTM	3/4	60.66	50.91 95.76 55.36
		5/4	63.59	52.93 96.00 57.78


Julien Delplanque
email: julien.delplanque@inria.fr

Stéphane Ducasse
email: stephane.ducasse@inria.fr

Oleksandr Zaitsev
email: oleksandr.zaitsev@inria.fr

Magic Literals in Pharo

Keywords: Software analysis, Quality, Idioms, Extensibility

Literals are constant values (numbers, strings, etc.) used in the source code. Magic literals are the ones used without a clear explanation of their meaning. Presence of such literals harms source code readability, decreases its modularity, and encourages code duplication.

Identifying magic literals is not straightforward. A literal can be considered self-explanatory in one context and magic in another. We need a heuristic to help developers spot magic literals.

In this article, we study and characterize the literals in Pharo. We implemented a heuristic to detect magic literals and integrated it as a code critic rule for System Browser and Critics Browser in Pharo 7.

We run our heuristic on 112,500 Pharo methods which reported 23,292 magic literals spread across 8,986 methods. We manually validated our approach on a random subset of 100 methods and found that 62% of the reported literals in those methods are indeed magic.

Introduction

Code smells [FBB + 99, SSS14, SS18] are characteristics of source code that indicate certain coding practices lowering code quality. Those bad practices are formalized as anti-patterns [START_REF] Koenig | Patterns and antipatterns[END_REF][START_REF] Brown | AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis[END_REF]. They describe code situation providing a counterproductive response to a recurring problem [START_REF] Koenig | Patterns and antipatterns[END_REF][START_REF] Brown | AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis[END_REF][START_REF] Suryanarayana | Refactoring for Software Design Smells: Managing Technical Debt[END_REF][START_REF] Sharma | A survey on software smells[END_REF]. Multiple anti-patterns have been discovered and discussed in the literature [START_REF] Brown | AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis[END_REF][START_REF] Abbes | An Empirical Study of the Impact of Two Antipatterns, Blob and Spaghetti Code, on Program Comprehension[END_REF].

One of them is Magic literal: literal of any kind that appears in source code without a clear explanation. For example, numbers 4 and 52 in Listing 1 are magic literals. Depending on the knowledge of the developer, it can be hard to infer the meaning and purpose of those values just by reading the source code. For a developer who has no knowledge of the domain of card games, it can be complicated to guess that 4 is the number of players and 52 is the number of cards in the game. Listing 1. Literals that are not clearly explained make code harder to comprehend and reuse.

CardGame » initialize

Magic numbers are indeed an anti-pattern [Bec97, FBB + 99]. They make source code harder to understand and decrease its modularity. When code is duplicated, magic numbers increment complexity and risk of bugs due to their use in different locations [START_REF] Baker | Parameterized duplication in strings: Algorithms and an application to software maintenance[END_REF][START_REF] Ducasse | A language independent approach for detecting duplicated code[END_REF][START_REF] Golomingi | A scenario based approach for refactoring duplicated code in object oriented systems[END_REF][START_REF] Kamiya | CCFinder: A multi-linguistic token-based code clone detection system for large scale source code[END_REF].

It is recommended to replace magic literals with wellnamed constants or method calls. For example, we can improve the code in Listing 1 by replacing value 4 with argument named numberOfPeople and returning the value 52 from a method called deckSize. As can be seen in Listing 2, the code without magic numbers is much easier to comprehend. It also allows us to change both values either by passing a different number of players as argument or by overriding the "deckSize" method.

CardGame » initialize deck := (1 to: self deckSize) asOrderedCollection.

CardGame » distributeCards: numberOfPlayers ^(1 to: numberOfPlayers) collect: [ :i | cards remove: cards atRandom ]

Listing 2. Magic literals should be replaced with wellnamed constants

In literature, authors use the term "magic number" to refer to any kind of undocumented literal. Robert Martin [START_REF] Robert C Martin | Clean code: a handbook of agile software craftsmanship[END_REF] highlights:

The term "magic number" does not apply only to numbers. It applies to any token that has a value that is not self-describing. These can be strings, symbols, characters, arrays, etc. Consider the following example: label text: 'e4c0c62'.

Listing 3. Magic literal that is not a number.

The string literal 'e4c0c62' should be replaced with a descriptive variable named commitSHA. It is therefore the "magic string". To avoid confusion, we adopt the term "magic literals" and use "magic numbers" only when referring to magic literals that are numbers.

Magic literals seem to be very common in software projects [START_REF] Smit | Maintainability and source code conventions: An analysis of open source projects[END_REF]. We need to assist developers both by warning them whenever they introduce a magic literal and by helping them extract the list of all magic literals from a given project to refactor them. However, detecting magic literals is not an easy task. Some literals can be self-explanatory in certain context. For example, number 2 in Listing 4 should not be considered as magic literal. In this case, 2 is not a constant that can be named otherwise. length := 2 * pi * radius.

Listing 4. Some literals (here 2) can not be renamed.

In this article, we introduce a heuristic for identifying magic literals based on the context in which they appear. It is the algorithm that reports undocumented numbers such as those presented in Listing 1 as magic literals and try not report self-explanatory numbers like the one in Listing 4.

To introduce the heuristic for detecting magic literals, we study the usage of literals in latest Pharo 7 image. Syntax of Smalltalk programming language and the conventions adopted by Pharo developers create many exceptional cases that must be considered. For example, since indexing of Smalltalk collections starts from 1, number 1 in statement 1 to: n is not a magic literal. And because of the special nature of tests, numbers and other literals that appear in tests are not considered magic [START_REF] Van Rompaey | On the detection of test smells: A metricsbased approach for general fixture and eager test[END_REF]. We implement a heuristic for detecting magic literals in Pharo and add it as a code critic rule integrated with System Browser and Critics Browser [START_REF] Tymchuk | Renraku: The one static analysis model to rule them all[END_REF]. In Section 7.5, we propose several strategies for refactoring magic literals and benchmark those strategies to compare their performance.

The rest of the article is organized as follows: In Section 2 we provide a definition for "literal" and in Section 3 we explore the distribution of literals in Pharo. In Section 4 and 5 respectively we characterize acceptable literals and define magic literals. In Section 6 we present the heuristic developed to detect magic literals in Pharo source code and evaluate the accuracy of this approach. In Section 7 we discuss properties and limitations of our heuristic. It is followed by Section 8 where we do an overview of research related to the topic of this article. Finally, in Section 9 we conclude the article and discuss perspectives.

Literals in Smalltalk

A commonly accepted definition for the concept of "literal" in the context of a programming language is: "the notations for constant values of some types" [ada, pyt]. A corollary of this definition is that data provided by a literal involves no computation during the program execution.

In Smalltalk, literals refers to the objects that are created by the parser and not via execution of messages.

Originally, Smalltalk-80 specifications define literals as "Literals describe certain constant objects, such as numbers and character strings. [...] Five kinds of objects can be referred to by literal expressions. Since the value of a literal expression is always the same object, these expressions are also called literal constants. The five types of literal constant are: 1. numbers, 2. individual characters, 3. strings of characters, 4. symbols, and 5. arrays of other literal constants" ]. This definition is similar to definitions used by other languages while being more precise on the kind of objects that can be referred to by literal expressions.

In the context of this paper, we use the Smalltalk definition of literals cited previously and slightly extend it with true, false and nil. We consider these 3 tokens as literals since they always refer to their respective object and their value is constant. Furthermore, in Pharo abstract syntax tree true, false and nil are not special nodes. They are the same literal nodes as numbers, characters, strings, symbols and array of other literals. This strengthens our proposition to consider them as literal.

Exploring Literals in Pharo

Using the previous definition of literals in Pharo, we explore their occurrences to understand how they are used. This analysis help us identify magic literals. To achieve this task, we collect all literals from latest Pharo 7 image1 and analyze how they are distributed over data types, over tests and non-tests, and over the kinds of parent abstract syntax tree nodes.

Distribution Over Data Types

In Figure 1, we can see how the 169,133 literals found in Pharo 7 are distributed over the data types. We observe that literals referring to integer are the most common literal found in the system making more that one third of all literals. String is the second most common type of literals, their proportion being about one fourth of all literals followed by Symbol literals with slightly less than one fifth.

Boolean literals occupy the fourth place with a proportion of 8%. Array and UndefinedObject (nil) literals occur with a proportion close to 4%. The proportion of Character literals is about 2% and all other types combined take the remaining 2% of all literals.

Distribution Over Test and Non-Test methods

We analyze the distribution of literals over test and nontest. Pharo 7 image has 20,170 test methods (18%) and 92,330 non-test methods (82%).

Literals occur more often in test methods than in non-test methods. 63% of test methods have at least one literal, which holds for only for 40% of the non-test methods.

In Section 4.5, we discuss the special case of literals used in test methods and claim that they should not be considered magic.

Distribution Over the Kind of Parent Node

We identify 7 groups of literals based on the type of their parent node in the abstract syntax tree:

1. Receiver. The literal is the receiver of a message send. 2. Argument. The literal is an argument of a message send. 3. Assignment. The literal is assigned to a variable directly. 4. Return. The literal is returned by the method. 5. Sequence. The literal appears in a sequence of statements to be executed. 6. Pragma. The literal is an argument to a pragma. 7. Array. The literal appears in a curly-braces array. Note that while it seems strange to have literals in a Sequence, the explanation is in fact straightforward: this is because of block closure. For example, this case appears when a literal is used in the block closure argument of a ifTrue: message.

In Figure 2, we can observe that literals mostly appear in message node (as receiver or argument). Furthermore, they appear much more often as argument (69% of literals) than as receiver (13%).

Acceptable Literals in Source Code

The presence of literals in source code is not wrong by essence. In some contexts, it is legit or needed to insert a literal value at a specific location in the code. It is then important for the detection of magic literals to identify the legit usage of literals. We present now the categories of acceptable literal values in source code. Some literals directly refer to the data they hold. In Smalltalk, true, false, nil, #() (empty literal array), {} (empty curly braces array) and " (empty string) are part of this group. The two first refer directly to boolean values true and false, nil refers to the value held by an uninitialized variable and the last ones refer to empty array and empty string. Those literals are acceptable because their semantic is obvious and well known by developers.

We will discuss two additional types of literals: Strings and Symbols. Introducing String literals in the source code might be legit. Indeed, if its contents aims to be read by a human (i.e., it is a sentence or part of a sentence in natural language) it is self-explanatory. Thus this kind of String literals should be considered as acceptable. However, some String literals can be considered as magic if their meaning is not clear. Those should be considered as unacceptable. An heuristic to distinguish these two kinds of Strings is discussed in Section 6.4.

In Pharo, Symbols are a special kind of unique Stringthere is a single instance for each sequence of characters (Symbols are flyweight [START_REF] Alpert | The Design Patterns Smalltalk Companion[END_REF]). Symbol uniqueness is what make them one of the cornerstones of identity-based data structures: they are readable unique keys. In the core of the system, symbols are used to represent method name (i.e., its selector), the name of a class, the name of a slot, to represent the name of a pragma, etc... Symbols are also used in many projects as key in associative data structures such as dictionaries. A developer often uses a symbol as a key to get access to the value object.

Icon management is a good example. Indeed, an application does not directly refer to an icon object, instead it refer to it sending the message Object»iconNamed: with a symbol as argument being the name of the icon (see for example 82% of all literals appear in message sends: 69% as arguments and 13% as receivers Listing 5). This mechanism allows one to change the set of icons to be used in Pharo without updating all icons users.

CriticBrowser class»icon

"Answer an icon for the receiver." ^self iconNamed: #smallWarningIcon Listing 5. iconNamed: method call.

These examples drive us to the conclusion that occurrences of Symbols in the source code should be considered as acceptable because they correspond to the name of a unique object. In addition a symbol has a readable form, contrary to a simple number which is also unique but does not convey a semantic information beside its actual value.

Literals that are part of API.

Programming languages usually define some internal conventions that must be respected by developers. An example of such a convention is the manner in which collections are indexed. For example, Java uses 0 as first index of its collections. Python uses index -1 to refer to the last element of a list. Such conventions do not only concern indexing of collections, in C there is no boolean data type. Instead, the language considers that 0 is false and any other value is true by convention. In practice, macros are used to avoid putting explicitly 0 or 1 literals in the source code.

In Pharo, such coding conventions are more contextual (in the sense that they depend on the exact message send). This is due to the extremely compact syntax of Smalltalk and the fact that all control flow operations are not part of the syntax but messages like any others. In Pharo a literal can be the receiver or an argument of a message. For example, copyFrom:to: sent to an instance SequenceableCollection copies the collection from the first argument index to the last. However, when a collection needs to be copied from beginning to a certain index, the literal 1 is provided as first argument (e.g., aCollection copyFrom: 1 to: n will copy the n first elements of aCollection as shown in Listing 6).

'abcdedfgh' copyFrom: 1 to: 5 Listing 6. Literals as arguments.

As we discuss in Section 7.3, the same arguments can be considered magic in other languages, such as Java or C. Unlike in Pharo, method names in those languages can not describe multiple arguments.

Such literals are acceptable because the programming language explicitly expects developers to use them. Furthermore, since these conventions are described in the language specifications, it is highly unlikely that they get changed.

Literals directly assigned to a variable / returned

by a method. Some literals appear assigned to a variable (e.g. Listing 7) or returned by a method (e.g. Listing 8).

EventSensorConstants class » initializeEventTypeConstants "Types of events" EventTypeNone := 0. [...] Listing 7. Literals assignments.

JPEGReadWriter class » typicalFileExtensions

"Answer a collection of file extensions (lowercase) which files that I can read might commonly have" ^#('jpg' 'jpeg') Listing 8. Method returning a literal directly.

In this case, the variable name or the method name has the responsibility to hold the semantics of the stored or returned literal. Both possibilities are acceptable.

Literals located in a method annotation arguments

In Pharo, methods can be annotated using pragmas [START_REF] Ducasse | Pragmas: Literal messages as powerful method annotations[END_REF]. A pragma is a static annotation of the method. It acts as a tag and supports a declarative registration mechanism that can be used to easily retrieve and execute all methods having a specific tag.

Listing 9 shows the source code of a method that is annotated as example. This tag is used by the integrated development environment to let user run examples. Pragmas can be parameterized with arguments. However, such arguments can only be literals (in the sense of definition given previously [GR83: p18-19]) because pragmas are created at parse time.

Listing 10 shows an example of gtInspectorPresentationOrder: pragma. This pragma supports inspector extension. It adds an additional view on the object being inspected. The argument provided to this pragma is a number that orders the inspector views (the smaller, the first to appear). Thus, any literal that is the argument of a pragma is legit because, by design, it could not be another way.

Form

Unacceptable Literals: The Magic Ones

Objective reasons can be found to reject the usage of literals in some contexts. Those literals are said to be magic because their role and meaning in the computation is obscure.

In the context of this article, we define magic literal as source code literal that does not fall into any of the acceptable literals categories described previously in Section 4.

We identify three main reasons why magic literals are bad from a code quality perspective: readability, logic duplication and modularity.

Readability

The usage of magic literals heavily reduces the code readability and as such the program logic understanding. A case where it is especially true is when a magic literal is used to apply bit operation on some input.

Let's take for example Listing 11. This method has a good comment about what it returns: an integer which encodes the format describing the kind of object an instance is. However, this method is not easy to understand with the two literals it holds. Line 8 is shifting the bits of the integer returned by the call to format method 16 times to the right. This step is used to discard the 16 least significant bit. Line 9 is applying the bit-wise "and" operation to the shifted integer and 16r1F literal. On the first look, it is not explicit what the bit-wise "and" aims to compute if one is not familiar with base-16. If one look at the representation of this literal in base-2 (2r11111), the purpose of this operation becomes clearer: it extracts the 5 least significant bits from the receiver of bitAnd:.

In the present case, using the base-2 representation of -16 is a constant time improvement. Another possible solution, to enhance the readability of this method is to extract 16 and 16r1F into two methods having named respectively instSpecOffset and instSpecMask.

The method names describe the purpose of these numbers. Applying this solution leads to Listing 12 source code. We discuss performances implications of such change in Section 7.5.

Behavior » instSpecOffset ^16

Behavior » instSpecMask ^2r11111

Behavior » instSpec [...] ^(self format bitShift: self instSpecOffset negated) bitAnd: self instSpecMask Listing 12. Solution to remove magic literals used for bit operations.

Note that 16 literal was extracted in instSpecOffset instead of -16. The reason is that this number is negated only because of the call to bitShift: which expects positive numbers to shift bits right and negative numbers to shift bits left. Thus the negation of the offset is only there as a side effect of bitShift: usage. If, » method is used instead (see Listing 13), the argument does not need to be negated as this method shift the receiver bits to the right for positive numbers provided as argument.

Behavior » instSpec [...] ^(self format » self instSpecOffset) bitAnd: self instSpecMask
Listing 13. Alternative solution to remove magic literals used for bit operations.

Logic Duplication

When the same magic literal is repeated over and over again, it participates to create complex to understand source code subject to duplication. This duplication of the magic literal can be quite harmful to the evolution of software. For example, if the literal is complex, a typo can be introduced in some literals that should refer to the same value creating potential bugs and confusion for people reading the code. Furthermore, if a duplicated magic literal needs to be changed in the future, changing the source code will be difficult and error-prone.

For example, the magic literal 1024 appears 7 times in 3 methods of the class EncoderForV3 responsible of encoding a certain version of the byte-code. After reading these 3 methods, it appears that 1024 is the maximal length of a jump in the byte-code. It is not possible to be 100% sure that all 1024 literals refer to the maximal length of a jump in the byte-code because it requires the knowledge of Smalltalk byte-code experts. However, some of these literals probably refer to the same concept and should be extracted in a method providing it a name.

EncoderForV3

Modularity

Magic literals reduce the modularity of methods in which they occur. Indeed, since the occurrence of a magic literal freezes its value in the source code preventing sub-classes or client to change its value.

We identify five strategies to address this problem. 1. Extract the literal in a class-variable and set it in its initialize method. This strategy is relevant if the literal refer to a constant that should never be changed such as a physical constant.

initialize MEANING_OF_LIFE := 42 2. Extract the literal in a method that directly returns it. This strategy allows sub-classes to change the value by redefining the method. However, it can not be customized per instance.

meaningOfLife ^42

3. Extract the literal in a method that returns the value of an instance variable initialized previously with the literal by default. Strategies 3 and 4 allows users of instances to customize the value of meaningOfLife to fit their needs.

We do not argue that one strategy is better than another, it depends on what kind of value the developer deals with. In Section 7, we evaluate differences between these strategies in terms of performance.

Detecting Magic Literals in Pharo

We have implemented the heuristic for detecting magic literals in Pharo2 . We realized that it becomes unusable if too many false positives are generated. Thus, we took the decision to favor the usability of the heuristic over finding all magic literals. For this reason, some decisions taken in the implementation to identify magic literals can have counterexamples creating false negatives. These counter examples are discussed in Section 7.

In the following subsections, we explain how the implementation proceeds to detect magic literals in practice. Then, an evaluation of the implementation is performed on 100 methods considered as containing magic literals in Pharo.

Literals Considered as Not Magic

From the definition provided in Section 4, true, false, nil, #(), {} and empty string ('') are never reported as magic by the heuristic.

Additionally, we decided to extend this set of literals with a white list of literals to consider as non-magic. This white list has been created empirically while exploring literals of the system and is configurable by users of the heuristic. This white list includes: 0, 1 and -1. The rational behind this choice is that from our exploration we observed that most of the time these literals were understandable when looking at the whole code of a method. Thus, while it happens that the white list make the heuristic miss some magic literals, it makes it more usable.

Literals that are part of API

We provide a mechanism to ignore literals that are either receiver of or provided as argument of certain methods because they are part of the API. This mechanism is based on a list of rules to ignore occurrences of literals in certain context.

Table 1 lists literals ignored in the context of certain message sends. "Selector" column is the selector of the message setting the context in which the literal is ignored. "Role" column describes whether the literal is receiver or argument of the message send. "Literal" column describes which literal (or group of literals via the class of these literals) is ignored. "Arg. index" contains a value only if the role value is "Argument" and describes the position of the literal in the message arguments (index starting at 1).

Baselines and Configurations

Our implementation ignores magic literals for all methods of certain classes because their usage is just part of the API. We identified two kinds of classes: subclasses of BaselineOf and ConfigurationOf. Baselines and configurations allows one to define which packages belong to a project, the dependencies between these packages and the dependencies to external projects. Because these classes are descriptions of projects structures, they make a huge usage of String literals to refer to package names, project versions, etc... Thus, a lot of false positives are generated by these methods of these classes.

An heuristic to detect magic Strings

As discussed previously, some String literals contain natural language sentences which are understandable when read by a human. From that observation, these String literals as legit. However, detecting if a String contains a sentence in natural language or not is a complicated task.

In the context of this article, we used a simple but yet effective heuristic to deal with this problem. We build a trie data structure from a list of 479,000 English words [Eng]. This data structure allows one to check if a string is included in a list of string or not efficiently. This trie is used to determine if a String literal contains natural language sentences or not by:

1. Splitting the string on space characters and removing non alphabetic characters. 2. Counting the number of sub-strings obtained that are included in the trie. 3. Computing the ratio sub-strings included over the total number of substrings. 4. If the ratio is greater than a certain threshold, the string literal is considered to contains natural language.

The ratio of English words required a string literal as nonmagic has been fixed to 0.5. The idea behind this threshold is that if more than 50% of words in a string literal are English words, the content held by this literal should be understandable by a developer.

Evaluation of the Approach

To evaluate our approach for detecting magic literals in the source code, we run the heuristic on the 112,500 methods of Pharo 7 and gathered 8,986 methods containing 23,292 magic literals. From these 8,986 methods, we randomly selected 100 methods and reviewed them manually. For each magic literal detected by the heuristic, we assigned one of the 3 following labels:

• True Positive. The literal is recognized as a magic literal which means the heuristic is right. • False Positive. The literal is not a magic literal, it is a false positive generated by the heuristic. • Unclassified. It is not clear whether the literal should be considered as magic or not.

The results are the following. In these 100 methods, the heuristic detected 243 magic literals. From these 243 literals, we find out that 151 are true positives split across 68 methods (where 60 contain only true positives), 74 are false positives split across 28 methods (where 20 contain only false positives) and 18 could not be classified split across 14 methods (where 11 contain only unclassified literals).

These results suggest that the heuristic works quite well since it is able to reveal magic literals while being right about 62% of the time on this sample of 100 methods.

Discussion

In this section we discuss some aspects and limitation of the heuristic implementation.

Constant Values v.s. Missed Parameterization

Some magic literals represent constant values: they can never change. Examples of such constant are π , G (gravity constant), Euler number, etc. For these literals we do not want to enforce modularity, quite the contrary in fact. It would be error-prone to let developers override those constants. The objective when removing these magic literals is to make the code more readable and to avoid inserting typo in some occurrences of the constant in the source code. In Pharo, extracting these constants as class-variable in a SharedPool is the way to go.

On the other hand, there are magic literals that should be instance variables or method parameters. The developer missed the opportunity to make the code parameterizable. Those literals can be extracted into a method that return directly the literal or as a call to an accessor method for which the instance variable is set to the literal value by default (these two possibilities have been addressed in Section 5).

The difference between constant values and missed parameter literals can not be extracted from structural properties of the software. Thus, our code critic rule is not able to propose the correct extraction strategy to the developer.

Magic Strings

We developed a heuristic which aims to remove string literals that are not self-explanatory. This is acceptable if one considers that only readability of the source code is important. From the modularity point of view, the heuristic is wrong to not consider strings recognized as understandable. Indeed, these strings might still cause problem for future evolution of the software.

It is not clear how to solve this problem. Extracting all string literals to make them parameterizable would be the best from a modularity point of view. However, it will make the number of methods (and eventually instance variables) increase which is an overkill because most of these strings will probably never be changed and are not repeated multiple time. Further research is required to tackle this problem correctly.

Method Selector Explaining Argument Literal

We observed that, for literals appearing as method argument, it happens that the part of the method selector appearing just before the argument allows developer to understand it. A good example of such method selector is Date class»year:month:day:. Consider the code snippet in Listing 16, it is obvious that 2019 refer to the year 2019, 6 refer to June and 1 refer to the first day of the month. Still, from a modularity point of view the occurrence of these literals is not optimal. date := Date year: 2019 month: 6 day: 1.

Listing 15. Example of literals as method argument that are explained by the method seector.

Method names in most other programming languages do not describe multiple arguments as well as the names in Pharo. Consider, the same initialization written in Java. In this case, all three arguments can be considered magic literals:

Date date = new Date(2019, 6, 1); Listing 16. Arguments of the same initialization are nonmagic in Pharo, but magic in Java.

Scripting vs. Extensible Code

While scripting (i.e., writing specialized code that is usually not reusable) developers tend to introduce magic literals. Indeed, since a script should be one-shot, developers will not put effort in making it parameterisable.

The problem arise when a developer find out that the script he wrote can actually be reused. It is likely that developer copy-pastes the script code into a method and starts working on it from the script version. This behavior increases the occurrence of magic literals in the source code.

Performance Impact of Magic Literals

Extraction Depending on the extraction strategy chosen by a developer, the time for the execution of a method can increase. We identified 5 possible strategies:

1. Extract the literal into a class-variable (Listing 17). 2. Extract the literal into a method that directly returns it (Listing 18). 3. Extract the literal into a method that returns the value of an instance variable initialized previously with the literal (Listing 19). 4. Extract the literal into a method that returns the value of an instance variable that is initialized lazily if it is nil when read (Listing 20). 5. Extract the literal into an instance-variable initialized previously with the literal (Listing 21).

To compare these strategies, we implemented each of them and performed a simple benchmark. Details of the setup for this benchmark can be found in Appendix A.

Figure 3 shows the results of the benchmark for each strategy. Strategies 1 and 5 are impacting the least time to run a method. Indeed, retrieving the value held by an instance / a class variable is fast since it only requires to read the variable's value.

Strategies 2 and 3 are slower than Strategy 1. This can be explained by the fact that each time the value needs to be retrieved, a method lookup is triggered. The mechanism involved creates an overhead which impact method performances. However, it seem that there is no significant difference between benchmarks of strategies 2 and 3. This is interesting because it suggests that reading the value of an instance variable costs virtually nothing.

Strategy 4 is the slowest which can be explained by the need to check whether the instance variable is nil or not each time the method is called. This create an overhead that is added to the time consumed by method lookup.

Related Works

To our knowledge, no similar study about magic literals in Pharo nor in Smalltalk exists in the literature. This article is thus probably the first to address this problem in the context of Smalltalk.

The concept of a magic number is discussed by Martin Fowler [FBB + 99] and Robert C. Martin [START_REF] Robert C Martin | Clean code: a handbook of agile software craftsmanship[END_REF] describing it as a bad practice that should be avoided. Both authors claim that magic numbers should be replaced with symbolic constant to ease understanding of software. However, the modularity problem caused by magic literals that should be parameterizable is not discussed. As we discuss in Section 1, in this article we choose to use the term "magic literal" instead of magic number.

Smit et. al. [START_REF] Smit | Code convention adherence in evolving software[END_REF][START_REF] Smit | Maintainability and source code conventions: An analysis of open source projects[END_REF] identified the relative importance of 71 coding conventions to maintainability based on a survey of 7 software engineers. The authors analyzed the revisions of four different open-source projects and observed that when developers are conscious of conventions (via explicit coding conventions policy and checks made by continuous integration servers), they put effort to respect those convention. When developers are not conscious of conventions, violations are prevalent. One of these coding conventions is the usage of magic numbers. The definition of magic number used by the authors is only about number literals (which contradicts with the definition of Robert C. Martin [Mar09] cited previously). Furthermore, their definition considers -1, 0, 1 and 2 as non-magic. The results of the survey suggest that avoiding magic numbers occurrences in source code is considered as important by software engineers. However, in the analysis of the 4 open source projects, "avoiding magic numbers" coding convention appears three times as the third and once as the fourth most violated convention.

Nundhapana and Senivongse [NS18] discuss the approach taken by an IT organization in Thailand to enforce naming conventions in Objective C software. The authors developed a library to check for naming conventions automatically. In particular, magic numbers are considered as a violation of naming convention since they are unnamed literal constants. A regex-based checker is used to detect magic numbers in Objective C source code.

Both Smit et. al. [START_REF] Smit | Code convention adherence in evolving software[END_REF][START_REF] Smit | Maintainability and source code conventions: An analysis of open source projects[END_REF] and Nundhapana et. al. [START_REF] Nundhapana | Enhancing understandability of objective c programs using naming convention checking framework[END_REF] distinguish "magic numbers" from "literal strings" but "literal strings" are not the "string" equivalent of magic numbers. The coding violation is different since literal strings concern multiple occurrence of the same string literal inside a Java / Objective C file that should be extracted into a constant. The concept of "literal strings" does not deal with the selfexplanatory property of the source code but rather with its modularity. Indeed, the occurrence of a string can be misleading for a developer reading the code (think of commit hash example in the introduction of this article).

The WikiWikiWeb [wik] has a very interesting page related to magic numbers. The content of this page is similar to the explanations we provide in this article while providing a less precise characterization of magic numbers. In particular, the authors provide three rules to determinate if a literal is a magic number:

1. Strict Magic Number rule: Literals should only appear on the right hand side of a constant declaration statement. 2. Practical Magic Number rule: A literal is a not a magic number if the most meaningful variable name for it is the same as the spoken name of the literal. 3. ZeroOneInfinityRule: The only constants that should appear without a name in a program are 0 and 1, and then only if they are used in integer arithmetic or comparisons.

We agree with these 3 rules and the work presented in this paper basically extend them. However, rule 2 is for developer and can probably not be handled by an automatic analysis.

Conclusion

In this paper, we explored the concept of magic literal generally and more specifically, in the context of Pharo. We did an exploration of the distribution of literals in the system leading us to a characterization of acceptable literals and a definition of magic literals. We used the definition to implement a heuristic to identify magic literals as code critics rule. We manually evaluated a subset of the results produced by our heuristic and found that it identified correctly magic literals 62% of the time. To our knowledge, this contribution is the first heuristic to detect magic literal.

10 Future Work

The research we conduct in this article opens multiple perspectives. We want to dig deeper in the analysis of magic literals by studying how and why they occur project per project. We have the hypothesis that some domain are probably more subject to the usage of magic literals than others. We would like to test this hypothesis on a large set of Pharo projects addressing various problems of different domains.

In the same direction, some domains are probably using more magic literals of certain types than others (for example a mathematical library is likely to use more Number magic literals than String magic literals).

Finally, an study of the evolution of magic literals across multiple versions of these Pharo projects will help us to understand why magic literals appear. Such study consists in doing a post-mortem analysis of commits that occur during the development of the project. We will compute the difference between each pair of consecutive versions of each project and watch for magic literal apparition.

  IWST'19, August 27-29th, 2019, Cologne, Germany 2019.

  deck := (1 to: 52) asOrderedCollection. CardGame » distributeCards ^(1 to: 4) collect: [ :i | cards remove: cards atRandom ]

Figure 1 .

 1 Figure 1. Distribution of literals over data types

Figure 2 .

 2 Figure2. Distribution of literals over the kind of parent node. 82% of all literals appear in message sends: 69% as arguments and 13% as receivers

FileDialogWindow

  class » example <example> (self onFileSystem: FileSystem disk) open Listing 9. An example of <example> pragma usage.

1

  Behavior » instSpec 2 "Answer the instance specification part of the format that defines what kind of object 3 an instance of the receiver is. The formats are 4 0 = 0 sized objects (UndefinedObject True False et al ) 5 1 = non--indexable objects with inst vars (Point et al) 31 = compiled methods (CompiledMethod)" 8 ^(self format bitShift: --16) 9 bitAnd: 16r1F Listing 11. Example of magic literals used for bit operations.

  the literal in a method that returns the value of an instance variable initialized with the literal lazily. meaningOfLife ^meaningOfLife ifNil: [ meaningOfLife := 42 ] 5. Extract the literal in an instance variable initialized previously with the literal and reference it directly. initialize meaningOfLife := 42

Figure 3 .

 3 Figure 3. Average execution time of each strategy. Measured by benchmarking each strategy for 10 seconds

  Literals located in test and example methods. As we observed in Section 3.2, a part of literals in the system appear in test code. While exploring non-tests literals, we also saw that some of them are part of example code[START_REF] Van Deursen | Refactoring test code[END_REF][START_REF] Van Rompaey | On the detection of test smells: A metricsbased approach for general fixture and eager test[END_REF]. Literals in test / example methods are acceptable for the following reasons:1. Developers tend to keep tests and example source code as simple as possible. In this context, calling methods to get some values or using a class variable would make the code more complex. 2. Literals in test or example code are used to build instances of fake objects that are used locally in the method. 3. Example and test source code are usually not reused by other parts of the system. 4. Literals arrays offer a compact way to create collections of different kinds using conversion methods e.g., #( 2 3 5 2) asSet. They are widely used and acceptable in tests and examples.

	» gtInspectorFormIn: composite
	<gtInspectorPresentationOrder: 90>
	^composite morph
	title: 'Morph';

display: [ self asMorph ] Listing 10. An example of <gtInspectorFormIn:> pragma usage with an argument.

4.5

Table 1 .

 1 Literals ignored in the context of certain message sends because they are part of the API.

	Selector	Role	Literal	Arg.
				index
	nextPut:	Argument Character 1
	«	Argument Character 1
	nextPutAll:	Argument String	1
	name:	Argument String	1
	«	Argument String	1
	ffiCall:	Argument Array	1
	ffiCall:module:option: Argument Array	1
	ffiCall:option:	Argument Array	1
	to:	Receiver	Integer	/
	to:by:	Receiver	Integer	/
	to:do:	Receiver	Integer	/
	timesRepeat:	Receiver	Integer	/

Pharo-7.0.3+build.159.sha.87d28366ab24e00f43dbd5d91f1c0b01ec519e6f (64 Bit)

https://github.com/juliendelplanque/MagicLiteralsInPharoExperiment

Acknowledgements. The authors thank Arolla (http://www. arolla.fr) for the funding of Oleksandr Zaitsev.

A Setup to Benchmark Magic Literal Extraction Strategies

This appendix contains the experimental setup for the performance measurement discussed in Section 7.5.

Object


A Merlen
email: merlen@univ-tln.fr

M Chaigneau

S Coussan

Vibrational modes of aminothiophenol : a TERS and DFT study

We report Tip Enhanced Raman Spectroscopy (TERS) mapping and Density Functional (DFT) calculations of aminothiophenol (ATP) grafted on a gold surface. The TERS mapping has demonstrated Raman modes of (ATP) and its dimerised derivative Dimercaptoazobenzene (DMAB). This feature confirms that the plasmon activated chemical reaction of ATP has occurred during TERS measurements. In some specific part of the samples some unidentified Raman modes are observed. We suggest that they could come from intermediate species formed during the conversion of ATP into DMAB. These modes are compared with calculated Raman spectra of some possible intermediate species. These results confirm the high potentiality of TERS measurements for nanochemistry.

Introduction

Metallic nanoparticles have already demonstrated their huge potentiality both in chemistry and physics. Based on collective electronic oscillation, their plasmonic properties can be used for highly sensitive optical spectroscopy 1,2 , photo thermal therapy 3 , photovoltaics 4 …Recently a new field has emerged: Plasmon driven surface catalyzed reactions 5 . For some specific molecules linked to metallic nanoparticles (mainly gold or silver, these two metals exhibit strong plasmonic properties in the visible range), it has been shown by Surface Enhanced Raman Spectroscopy (SERS [START_REF] Etchegoin | Principles of surface-enhanced Raman spectroscopy and related plasmonic effects[END_REF] ) measurements that a chemical reaction could occur when the plasmonic resonance of the nanoparticle is excited by an incoming light. In this case the localized plasmon act as a catalyst to activate the reaction. Such mechanism has been reported for Aminothiophenol (ATP, also known as Aminobenzenethiol or Paramercaptoaniline) and Nitrothiophenol (NTP). During laser illumination, new vibrational modes are observed in the Raman spectra of these molecules. These modes have been first associated to a charge transfer mechanism [START_REF] Osawa | [END_REF] (associated to the chemical effect in the enhancement mechanism of SERS) or discussed in terms of change in the molecular orientation 8 . Nevertheless some recent studies have demonstrated that they are in fact vibrational modes of Dimercaptoazobenzene (DMAB) 9 : two ATP (or NTP) molecules react on the metallic surface to form this new molecule. Many SERS studies have since confirmed this hypothesis. A mechanism to explain this transformation has even been proposed. Nevertheless there is still a debate in the SERS community and new techniques are necessary to confirm this hypothesis. A promising tool is Tip Enhanced Raman Spectroscopy (TERS 10 ). This technique, similar to SERS, is based on the giant electromagnetic enhancement present at the apex of a metallic nanoantenna 11 . This electromagnetic enhancement is used to amplify the Raman signal. SERS requires a network of nanoantennas and the molecules are usually deposited on this network. As a consequence SERS must be performed with specific substrates, which is a major limitation of this technique. In opposition, TERS can be performed with any kind of sample: the unique nanoantenna (usually a metallic tip) is simply approached to the sample thanks to a scanning probe microscope. The recorded Raman signal comes from the molecules localized a few nanometers around the apex of the tip. It is thus possible to have a high sensitivity associated to a nanometric resolution, similar to what can be obtained with optical near field devices 12 . TERS appears thus as a perfect tool to study the chemical transformation of ATP or NTP into DMAB and several studies have reported such measurements. They have confirmed the high reactivity of ATP or NTP. Lantman et al. have observed temporal fluctuations in the TERS signal of NTP 13 . Performing high vacuum TERS measurements Sun et al. have observed some unidentified vibrational modes 14 . Nevertheless none of these studies has tried to take advantage of the high spatial resolution of TERS to perform mapping. In this article, we report such mapping performed on ATP deposited on a gold annealed sample. On some specific part of the sample new Raman modes are observed. These modes are compared to DFT calculations. We suggest that they could come from intermediate species formed during the transformation of ATP into DMAB.

Method

A SAM layer of ATP was prepared following the usual protocol 15 . The atomically flat Au(111) substrates were purchased from Arrandee. A 1 mM solution of ATP molecules in ethanol was used for the SAM absorption on the freshly flame annealed substrate during an absorption time of 12 h. A Flat flame annealed surface was used to avoid any strong SERS background signal that could arise from gold nanostructures.

Our TERS set-up consists of a confocal Raman microscope (Labram HR800, HORIBA Jobin Yvon) with a 633 nm HeNe laser source optically coupled in an oblique backscattering geometry to a scanning probe microscope (XE-100, Park Systems). The 633 nm excitation is far from the absorption bands of ATP 16 and resonant mechanism are excluded in our measurements. The long-working-distance objective (50×, NA = 0.45) is oriented at 65° with respect to the sample normal (figure 1). The polarization state of the incident beam is p-polarized (electric field parallel to the scattering plane). Further details about the experimental setup can be found in other references [17][18][19] . The SPM is operated in scanning tunnelling microscopy (STM) mode; the tips used were prepared from Au wire pieces of a 250 µm diameter and 99.99% purity (from Goodfellow) by electrochemical etching in a concentrated HCl / ethanol 1:1 solution. It must be said that a recent study has shown that the STM voltage has not much influence in the TERS measurements of ATP molecules 14 . The TERS mapping was performed over a 0.8 × 0.8 m 2 area (number of pixels 20 × 20) by recording a Raman spectrum at every 40 nm with a 1s acquisition time. These experimental parameters offers a good compromise between total acquisition time, spatial resolution, high quality Raman spectra and total scan size.

The calculations of Raman modes were performed within Density Functional Theory (DFT) using the GAUSSIAN 09 suite [START_REF] Frisch | Gaussian[END_REF] . We used the PW91PW91 functional [START_REF] Perdew | [END_REF] , a 6-311+G(2d,p) basis set for C,N,S and H and a LANDL2DZ basis set for Au 22 . Those parameters are known to be efficient for the calculations of ATP and DMAB on gold 23 . FDTD simulations were performed using Lumerical software 24 with parameters that have already been used for others simulations 25,26 .

Results and Discussion

A typical STM image of the gold surface can be seen in figure 1c. It presents smooth and flat areas separated by a grain boundary. Such a surface is typical of what can be obtained with annealed gold. The average intensity of the TERS signal for the same surface is shown in figure 1d. A good correlation between the TERS signal and the topography is observed. We can estimate the optical resolution to be lower than 100 nm, a much better resolution than what can be obtained with classical optical Raman microscopy. This confirms that the Raman signal really comes from the limited area below the tip as can be seen in figure1b. In addition no far-field Raman signal is observed when the tip is removed from the surface. A higher resolution could be obtained using a smaller mapping step size at the cost of a much longer total time acquisition. The TERS signal intensity is too low (ranging from 100 to 1000 cts/sec) to ensure a reasonable total time acquisition of the mapping compatible with a limited drift of the piezo-table. Some typical TERS spectra are reported (and the corresponding location are pointed by arrows on the TERS mapping) in figure 2. Most of the Raman spectra exhibit 2 peaks located at 1080 and 1580 cm -1 . These two modes are associated to ATP molecules, this is clearly confirmed by DFT simulations of the ATP Raman modes (figure 2c). In some particular places of the sample, other modes are observed: 1140, 1390 and 1440 cm -1 (see fig. 2 (b), TERS spectrum in the middle). These modes have already been reported in many SERS studies of ATP and have led to many debates. As mentioned in the introduction, those Raman peaks has been first attributed to a charge transfer mechanism 27,28 . Nevertheless, some recent studies have demonstrated that their presence strongly depends on several experimental parameters: density of the ATP layer, laser power, etc... 15 These features are hardly compatible with a charge transfer mechanism and based on DFT calculations several authors have proposed to attribute them to a new molecule: DMAB 9,[29][30][31] . This molecule should be formed via dimerization of ATP molecules activated by an electromagnetic and plasmonic process occurring under the tip. Such a reaction can also be observed with nitrothiophenol molecules 5 .

Figure 2: a) TERS mapping b) Raman spectra for different positions of the mapping. c) DFT calculations of the Raman modes for ATP (above) and DMAB (below). Both molecules are in interaction with a 5 atoms gold cluster.

Many experimental studies have been performed and it appears in the Raman community that this hypothesis is now privileged to explain the presence of these new modes (1120, 1380 and cm - 1 ).

Based on these TERS mapping on ATP molecules grafted on a Au substrate, we can conclude that most of the layer on the gold surface is still ATP, and in random locations on the sample the Raman modes of DMAB are observed suggesting that the dimerization has occurred. Nevertheless, it appears that our illumination condition is not powerful enough to induce an immediate and total transformation of ATP into DMAB. It must be said that no clear correlation between the places where DMAB molecules have been formed and the corresponding topography of the sample has been observed. The proposed mechanism for the transformation of ATP into DMAB is based on the giant electromagnetic enhancement present in the vicinity of plasmonic nanostructures. This enhancement is highly localized, as can be seen in the figure 1b showing this distribution between the tip and the gold surface thanks to FDTD calculations. For gold nanostructures the electromagnetic enhancement is usually much higher at their edge. The relation between electromagnetic enhancement and the plasmon driven chemical reaction has been evidenced and discussed recently 32 . The gold annealed surface used in our study presents atomic flat grains but some edges and kinks are anyway present (see STM image in figure 1c). DMAB molecules should preferentially be formed at these edges but the spatial resolution of the TERS mapping is not enough to confirm this hypothesis. To study the correlation between electromagnetic enhancement and DMAB synthesis we suggest to perform similar TERS measurements on a sample with well-defined metallic nanostructures (such as nanodots 26 or nanotriangles 33 ). Nevertheless performing TERS mapping with such plasmonic nanostructures would lead to a strong SERS background signal which will decrease the final spatial resolution. Performing such TERS measurements remains an experimental challenge. In figure 3 are reported some Raman spectra that can neither be attributed to ATP or DMAB. These spectra are observed on a very limited number of places on the gold surface. This is the experimental reason why we have performed a rather large TERS scan at the cost of a lower spatial resolution: we wanted to observe a significant number of places where new Raman spectra are observed. Recently a high vacuum TERS measurements of ATP have reported the observation of new modes in the Raman spectrum of ATP 14 . The authors observed a considerably higher number of peaks compared to what we observed here. Some unidentified peaks were attributed to IR modes activated by the strong gradient-field effect 34 at the tip apex. Even without performing any TERS mapping, the results shown in this article present a remarkably reproducible Raman signal. The fact that we have not observed such a high number of vibrational modes and that the other modes (corresponding to the DMAB) are observed only in some specific parts of the sample suggest that the unidentified modes presented in figure 3 should not be explained by a similar mechanism. Performing time resolved TERS measurements with nitrothiophenol, Lantman et al. 13 have observed intensity fluctuations and have associated them to a photoreaction, giving few suggestions about its exact nature. Recently, Zhao et al. 35 have performed a DFT study about the chemical photoinduced reaction of azobenzene on nanostructured silver. For the conversion of ATP into DMAB, the authors have proposed the mechanism described in figure 4a. Even proposed for silver, one can reasonably assume that it would be the same on a gold surface: these two metals exhibit similar plasmonic properties in the visible range, except the fact that the silver resonance occurs at shorter wavelengths compared to gold. The proposed mechanism reaction for the conversion of ATP into DMAB is based on the formation of several intermediate species. Some are surely extremely reactive (the charged radical species) and can probably not be observed, but some others might be more stable. As already mentioned, our illumination condition is not powerful enough to induce an immediate and total transformation of ATP into DMAB. This suggests that some intermediate species could be observed in our TERS measurements and the induced vibrations associated to the unidentified Raman modes. To confirm this hypothesis, we have performed DFT calculations on some intermediate species (named DMHAB and DATP in figure 4a). It must be said that it is necessary to be cautious about the results given by these simulations: the mechanism of conversion is still under discussion 36,37,29,38,39 . A recent study of Xu et al. 40 has evidenced the role of oxygen and water in the conversion but the proposed intermediate species remain the same. We have also performed similar calculations with the free ATP molecule. Calculated Raman activities are reported in figure 4b andc. For DATP, two main modes are observed: at 1050 and 1540 cm -1 . Two main modes are also observed for DMHAB with slightly different positions: 1060 and 1600 cm -1 . Our spectral resolution in TERS measurements is not enough to clearly distinguish two broad peaks separated by only 10 cm -1 . As a consequence the observed mode at 1080 cm -1 cannot be used to distinguish some intermediate species. This is not the case for the higher frequency modes: in Raman spectra of figure 3 we can clearly distinguish a doublet at around 1600 cm -1 , not observed in figure 2. The lowest frequency mode of this doublet could be associated to DATP. In figure 3 there is also a broad mode observed in one spectrum at 1250 cm -1 and at 1320 cm -1 in the other. These peaks could be associated to the 1280 cm -1 mode reported for free ATP (see figure 4c), not observed when ATP is in interaction with gold. This hypothesis suggests that during the photochemical reaction some ATP molecules are desorbed from the gold surface. We also note that the relative intensity between all the calculated modes strongly depends on the considered specie. This could explain the intensity temporal fluctuations reported by Lantman et al 13 . As a conclusion, we suggest that these new modes could be the experimental fingerprint of intermediate species formed during the transformation of ATP into DMAB.

Conclusion

We have performed a TERS mapping on ATP molecules deposited on a flat gold surface. We have observed Raman modes of ATP and DMAB confirming that the plasmon driven dimerization can occur in such a configuration. We have also observed some unidentified vibrational modes. Our DFT calculations suggest that they could be the experimental fingerprints of intermediate species formed during the plasmon-driven dimerization. Our study confirms the huge potentiality of TERS for a better understanding of nanochemistry mechanisms.

Figure 1 :

 1 Figure 1: a) Experimental setup configuration b) Distribution of the enhanced electromagnetic field between the tip and the gold surface (FDTD calculations) c) STM image of the gold surface (800 x 800 nm 2 ) d) Corresponding TERS mapping of the same surface (average intensity integrated between 1500 and 1620 cm -1 ).

Figure 3 :

 3 Figure 3: a) TERS mapping b) Others Raman spectra for different positions of the mapping indicated by the arrows.

Figure 4 :

 4 Figure 4: a) The chemical mechanism of synthesis of DMAB from ATP proposed by Zhao et al. 35 b) DFT calculations of the Raman modes for different chemical intermediates DMAHB (for Dimercaptohydrazobenzene) and DATP (for deprotonated ATP) c) DFT calculations of a free ATP molecule.

Acknowledgements:

The authors acknowledge Dr Nicolas Ferré, Dr Cédric Pardanaud and Pr Razvigor Ossikovski for fruitful discussions.