dataesr/scientific-paragraphs-categorization huggingface dataset:
The emergence of superresolution fluorescence microscopy techniques has also promoted the development of toolboxes tailored for their specific inverse problems. For instance, FairSIM  [26]  and Simtoolbox  [18]  are dedicated to the reconstruction of structured-illumination microscopy data. For single-molecule localization microscopy, one can find dedicated localization plugins such as SMAP  [21]  and Thun-derSTORM  [27]. Although dedicated to specific physical models, the aforementioned toolboxes generally rely on similar reconstruction methods, ranging from Wiener filtering to advanced regularized iterative algorithms. Conversely, libraries that are generic have recently also been designed to handle multiple imaging modalities. The LazyAlgebra toolbox  [35]  provides an operator-algebra mechanism in Julia that can be combined with optimization packages for solving inverse problems.
More complete libraries such as AIR Tools (MATLAB ® )  [17] , IR Tools (MATLAB ® )  [15] , or TiPi (Java ™ )  [36]  provide elements for the implementation of forward models, as well as iterative solvers to tackle the associated inverse problems. The disadvantage of these toolboxes is that the optimization algorithms they provide are generally implemented to minimize a specific functional, thus limiting their modularity. In contrast, GlobalBioIm provides a fully modular environment where one can not only easily combine functionals and operators to define the loss to be minimized in  (2) , but also benefit from a variety of solvers. This philosophy is shared by a few other toolboxes with different programming languages, such as the Operator Discretization Library (in Python)  [1]  and the Rice Vector Library (in C++)  [28].
The organization of the library is illustrated in Figure  1. It is guided by five general principles. • Modularity. All objects are defined as individual modules that can be combined to generate a particular reconstruction workflow. Each building block can thus be easily changed to define new reconstruction pipelines. • Flexibility. The constraints to fulfill during implementation are few. New objects can easily be plugged into the framework of GlobalBioIm. • Abstraction. The four abstract classes (LinOp, Cost, Opti, Map) define a limited set of attributes and methods that are shared by their derived classes (i. e. , subclasses). This constitutes a common guideline for the implementation of subclasses. Moreover, generic concepts-basically, interactions between classesare implemented at the level of the abstract classes and benefit directly to all subclasses.
, H M ] T. Similarly, for invertible maps, the method applyInverse allows one to compute f = H -1 {g} for g ∈ R M. In addition to the "apply"-type methods, the Map class provides prototype methods prefixed by "make". These can be implemented in derived classes to create new instances of Map objects that are related to H. For instance, the method makeInversion returns a Map object that corresponds to H -1. The prototype methods are also used to overload the MATLAB ® operators " * " (mtimes), "+" (plus), and "-" (minus). Hence, the composition between two Map objects can be specified easily as H = H1 * H2. This will execute the method makeComposition of H1 with H2 as its argument. By default, the resulting H will be a MapComposition object that benefits from the generic implementations (e. g.
3] and, thus, that I + αSHH T S T can easily be inverted in the Fourier domain. In order to apply  (7) , the specification of αSHH T S T as a convolution is implemented in GlobalBioIm. This is done in the makeComposition method of LinOpDownsample, which returns a LinOpConv object when appropriate. As a result, I + αSHH T S T is identified as being an invertible operator, and (  7 ) can be directly implemented as follows. H=LinOpConv(fftn(psf)); S=LinOpDownsample(H. sizein,  [2, 2] ); fwd=S * H; % Forward model In=LinOpIdentity(S. sizein); Im=LinOpIdentity(S. sizeout); % Identity operators prox=(In -alpha * fwd' * (Im + alpha * (fwd * fwd'))ˆ(-1) * fwd) * (alpha * fwd' * g+u); A complete script (TestProxL2DownSampledConv) in which this example is implemented can be found in the folder Cost/Tests/ of the GlobalBioIm library.
GPU Computing GlobalBioIm provides two functions that allow the user to easily run any reconstruction pipeline on the GPU for faster computation. The function useGPU, which is typically called at the beginning of the script, allows selection of the computation mode: CPU computation (default), GPU computation with the MATLAB ® Parallel Computing Toolbox ™ , or GPU computation with CudaMat (https://github. com/RainerHeintzmann/CudaMat). Next, the function gpuCpuConverter converts the input variable to the appropriate data type as specified by useGPU. A typical use of these functions is presented below.
However, for both these regularizers, the proximity operator of R( • ) can be efficiently computed (see  [11]  for • 2,1 and  [10, 19]  for • S1,1 ). Hence, the optimization problem can be tackled using proximal-splitting algorithms such as the alternating direction method of multipliers (ADMM)  [2, 7, 14, 32]  or the primal-dual method proposed in  [12]. These algorithms are designed to minimize cost functions of the form J = P p=1 J p (T p • ), where {T p } P p=1 are linear operators and the {J p } P p=1 are "simple" functions in the sense that their proximity operator can be evaluated efficiently. The scripts provided in Figure  3  illustrate how these two algorithms can be implemented within the framework of GlobalBioIm to solve Problem  (11)  with TV or HS regularization. The modified lines of code between each setting have been Total-variation  [8, 9, 30]  ADMM  [2, 7, 14, 32]  Hessian-Schatten  [19, 20]  Primal-dual  [12]  Figure  3 : GlobalBioIm scripts for minimizing  (11)  with non-differentiable regularizers R(L • ).
Differences with respect to the script corresponding to ADMM with TV are highlighted. highlighted-observe that very few modifications are needed. This underlines the simplicity of changing the regularizer and/or the algorithm within the GlobalBioIm framework. For both algorithms, the splitting strategy is specified by the two cell arrays Fn and Hn. Note that, since S is a semi-orthogonal linear operator, the composition L2*S results in a Cost object that has an implementation of the proximity operator (see Example 4. 1). Moreover, the two scripts that use the primal-dual method illustrate the relevance of the automatic simplification features described in Section 4. 2. In order to ensure the convergence of the algorithm, the two parameters σ > 0 and τ > 0 have to be chosen so that τ σ P p=1 T T p T p ≤ 1 holds true  [12].
The norm which is involved in this inequality is easily obtained with GlobalBioIm by building the operator T=H'*H + L'*L + LinOpIdentity(szin) explicitly and computing its norm T. norm. The key is that the composition used to build T is automatically simplified to a convolution operator with the proper kernel. Finally, observe that, as for the convolution operator, the gradient and Hessian operators are defined using the argument [1 2], which implies that these operators are applied independently to each channel. Smoothed Total Variation  [4, 8]  VMLMB  [34]  Good's Roughness  [40]  FISTA  [5]  Figure  4 : GlobalBioIm scripts for minimizing  (11)  with differentiable regularizers R(L • ). Differences with respect to the script corresponding to VMLMB with S-TV are highlighted. As opposed to TV and HS, the S-TV and the GR regularizers are differentiable.
Numerical Comparisons The modularity of GlobalBioIm, which was demonstrated in the scripts presented in Section 5. 2, offers a simple way to compare the effect of regularizers as well as the efficiency of optimization algorithms. We first present the quality of the deconvolution obtained with the four regularizers TV, HS, S-TV, and GR. Here, we used ADMM to minimize  (11)  with non-differentiable regularizers (i. e. , TV and HS), and FISTA to minimize  (11)  with differentiable regularizers (i. e. , S-TV and GR). The SNR of the deconvolved image  as a function of the regularization parameter λ is depicted in Figure  5 , while the deconvolved images that maximize the SNR are presented in Figure  6. As expected, HS and GR lead to better results by avoiding the well-known staircasing effect of TV and S-TV.
Discussion Open-source software is an essential component of modern research. Not only does it shape theoretical developments, but it also turns out to be a critical tool to bridge the gap that separates researchers specialized in computer science/mathematics from scientists versed in biophysical sciences/medicine. Moreover, open-source software can act as a catalyst for engaging in new collaborations by promoting external contributions. Motivated by the observation that the image-formation models of most of the commonly used biomedical imaging systems can be expressed as a composition of a limited number of elementary operators, we developed the open-source MATLAB.
Ground Truth Data Total Variation Hessian-Schatten Smoothed-TV Good's Roughness   library GlobalBioIm. This library provides a unified and user-friendly framework for the resolution of inverse problems. It is designed around three entities, namely, forward models, cost functions, and optimization algorithms, which constitute the building blocks of any inverse problem. This organization gives GlobalBioIm a modularity that greatly facilitates the comparison between regularizers and or solvers, as illustrated in Section 5. Moreover, GlobalBioIm enjoys an operator-algebra mechanism able to perform automatic simplification of composed operators. Finally, new modalities, cost functions, or solvers are easily added to the framework of GlobalBioIm. Reference papers that use GlobalBioIm is provided in the Section "Related Papers" of the online documentation http://bigwww.
Acknowledgements The authors would like to thank warmly  Rainer Heintzmann  for fruitful discussions related to this project as well as  Philippe Thévenaz  for his useful feedback on the paper. This research was supported by the  European Research Council (ERC)  under the European Unions  Horizon 2020 research and innovation programme , Grant Agreement No. 692726  GlobalBioIm: Global integrative framework for computational bio-imaging.
Numerical Parameters This section provides first all the numerical values of the model parameters to simulate the underwater behavior of the AUV for different scenarios. In Table  1  are given the main parameters values of the AUV. The linear damping parameters are estimated using SolidWorks Flow Simulation (Dassault Systèmes SolidWorks Corporation -Waltham, Massachusetts -USA) for various water flow speeds on the micro-AUV prototype model (see Figure  1 ). Added masses and inertia, as rotational damping parameters are estimated using several data from other references about AUVs approximately of the same size and shape. To simulate uncertainties in the model dynamics, all the parameters in Table  1  have been increased or decreased arbitrarily by 15% while the nominal parameters have been kept to compute the control signal u(t) from Equation (43).
Due to its NP-hardness, most previous MVC algorithms adopted stochastic local search (SLS) heuristics (e. g. ,  [5-7, 29, 31, 36] ) to seek high-quality sub-optimal solutions in reasonable time. Several exact algorithms based on the general Branch and Bound method were also proposed for the equivalent MC problem (e. g. ,  [20, 23, 34, 38] ). These previous algorithms were demonstrated to be effective in solving traditional graphs from the DIMACS and BHOSLIB benchmark sets which are of small or medium size. Meanwhile, the fast growth of the Internet and the recent advances in information technology have generated a large amount of data whose underlying graphs are much larger than the traditional benchmarks. These real-world graphs (like social networks) are typically massive, with tens of millions of vertices, and sparse with low edge densities where the degrees of vertices often follow a power-law distribution  [22].
Experimental Settings and Computational Results The proposed DTS MVC algorithm was coded in C++ and compiled by GNU g++ 4. 1. 2 with the '-O3' flag. The experiments were conducted on a computer with an AMD Opteron 4184 processor (2. 8GHz and 2GB RAM) running Ubuntu 12. 04. Solving the DIMACS machine benchmark graphs r300. 5, r400. 5 and r500. 5 1  on our computer (without any compilation optimization flag) requires 0. 40, 2. 50 and 9. 55 seconds respectively. The proposed algorithm DTS MVC as well as the two reference algorithms were run 100 times for each instance with the time limit of 1000 seconds per run (a commonly used stopping condition in the literature  [4, 13] ). We ran the C++ source codes of FastVC 2  on our machine for the sake of fair comparison. The results of LinCom were extracted directly from the original paper since its source code is not available to us.
Acknowledgment We are grateful to our anonymous reviewers for their insightful comments that have helped us to significantly improve this work. This work was supported by the  National Natural Science Foundation of China  (Grant No:  71690233 ), the  Region of Pays de la Loire (France ,  LigeRO  project  2009-13 ) and the  Jacques Hadamard Mathematical Foundation  ( PGMO  project  2014-0024H ).
A. STUDY TOOLS The study used the following tools: • JINS MEME smart glasses • Android smartphone (Nexus 7) with a phishing game • Smartphone for recording JINS MEME readings JINS MEME is an eyewear that can detect head and eye movements  [9]. The prototype looks just like normal eye glasses and it is made of 3 electrodes (electrooculography) and motion sensors (accelerometer and gyroscope) around the nose to detect eye and head movements respectively, as well as a Bluetooth LE module to stream the data to a computer, smartphone or tablet. JINS MEME smart glasses measure EOG signals of roughly over 100 Hz generated by human brain non-invasively and over 50 Hz of the motion sensor. Additionally, JINS MEME provides raw data that could easily be visualized and retrieved in CSV. The smart glasses battery can operate up to 8 hours  [13].
UnPhishMe consists of two engines, one is for an authentication automation and the other one is for server response interpretation and alert generation to a mobile device user as shown in Fig. 7. The login automation module sends login credentials to a resource server and computes a current URL hashcode. Later the resource server response about the authentication is given and again the new URL hashcode h(URL') is computed for comparison with the original one. Thereafter, the server response and the URL string status are intercepted by the application to generate a proper warning message for the user. Algorithm 1 IsClientValidate(userID, password, Flag) Result: true or false initialization if F lag == 0 then if serverConnection==0 userID. contain(@) then return true else return false end else if serverConnection==0 then return true else return false end end In brief, we developed algorithms 1 and 2 (reference to pseudocode).
Algorithm 1 handles client-side validation issues on webpages e. g. , checking whether the username is an email or has the minimum length of characters, while Algorithm 2 monitors the authentication response of the destination server. In our experiments with Alexa websites, we found that most websites, 198/200 (98%), did not have hard rules for usernames e. g. , types of characters used. They only specified the minimum length. We therefore created a database of usernames that satisfy the different lengths specified and email addresses using these usernames. When a webpage loads, Algorithm 2 invokes Algorithm 1. Initially, Flag is set to 1 in Algorithm 2. This means the algorithm enters a username, not an email address. The algorithm then enters and attempts to send a username from our database and a password.
If the destination server requires an email address, the client-side validation script on the webpage will not allow these details to be sent. In this case, Algorithm 1 return true where there is a zero connection to the destination server (serverConnection=0) and sets the Flag to 0 in Algorithm 2 to denote an email address is needed. Setting the Flag to 0 allows the algorithm to enter and send an email address from our database along with a password. In both cases, if Algorithm 1 returns false (serverConnec-tion=1), the entered login details have successfully been sent for authentication checking and therefore Algorithm 2 takes over to monitor the appropriate response. The type of operations for the algorithms is elementary, because all the operations are checking and affectation. Thus the time complexity is linear i.
1) IMPLEMENTATION ON A BROWSER Without changing the logic of UnPhishMe prototype, we initiate and customize an Android browser by modifying a Web View (WV) through the Android WebKit and invoke the input data in the background process. For setting up the custom Web View browser, the WV object has to be created whereas, the WebViewClient handles onPageFinished(), shouldOver-rideUrlLoading() methods, etc. , which are responsible for controlling the web format and structure when loaded while the WebChromeClient handles Javascript's alert() and other functions. When a webpage is opened by a user, the shouldOver-rideUrlLoading() method is called and the browser checks for the existence of the HTML login form fields by scanning the HTML tags. If there are no login form fields available, the process is killed by setting the Boolean onDestroy() function to TRUE.
To detect if the page contains a login form, our approach looks for the HTML form action attribute, action = " " method = " " >. If the login form fields exist, the browser invokes the retrieval of dummy credentials from an SQLite database which is automatically installed when the browser is installed. The getElementById() method is then used to inject the credentials to the appropriate login fields and the onClick() method submit the form. Meanwhile the boolean onDestroy() function is set to FALSE so as the process could be finalized and an alert generated to the user. We have summarized this procedure with a diagram in Fig. 11.
2) LOGIN CREDENTIALS GENERATION AND MANAGEMENT The fake passwords used by UnPhishMe were generated using a simple script (Listing 1). In our experiment with Alexa sites, we found that apart from one website, the top 200 sites follow the same password requirements. The exceptional website did not accept '@' or '-' as special characters. Listing 1 generated a random list of characters that satisfy the password requirements of the top 200 websites. We used this approach to ensure that if a Phisher implements a clientside validation for a password, the fake password would be viewed as legitimate since it meets the required criteria. However, in our testing of phishing sites, we only found rare cases of input validation on userID (either an email or a username is acceptable) but not on entered passwords.
1) ARCHITECTURAL ISSUES The authentication automation in mobile devices is more challenging than in desktop computers. The necessary automation drivers that are available on desktops are normally not found on mobile devices. In this work, we automated the user authentication procedure through Selendroid with JavaScript Object Notation (JSON). However, Selendroid is only compatible with Android devices and may not work on other types of devices. Another significant challenge for implementing our solution is the requirement of specific websites that implement or follow industrial standards for authentication such as RFC 2616. Following such standards makes it difficult for an attacker to simulate fake legitimate responses. However, there is a possibility for an attacker to try to authenticate the UnPhishMe request traffic to an associated legitimate website on the fly in order to fool a user into providing true credentials.
However, webpages are made of the HTML technology, often in conjunction with other technologies such as CSS, Javascript, JSON etc. , thus non-HTML sites would render so poorly on smartphones to the point that they can easily be recognized effortlessly even without the techniques such as UnPhishMe. On the other hand, another significant issue worth mentioning is the performance of our approach on legitimate webpages. We tested the approach with additional top 200 webpages from Alexa. com and achieved a 91% detection accuracy. The 9% were due to the webpages that require different authentication techniques such as QR code scanners, One Time Password (OTP) sent to a user mobile phone through SMS, and graphical passwords which work by having a user selects a matching image, in a specific order, presented in a graphical user interface (GUI).
address pointed by rbp. In this paper we focus on the x86_64 architecture, but similar conventions hold for other architectures. If instead, as suggested by the x86_64 ABI, the code has been compiled without a frame pointer register, then the only information available to the the debugger is stack pointer register rsp, but this is useless if the current stack frame size is not known as well. DWARF debug information  [DWARF 2017 ] comes to the rescue. In general, DWARF debug information attempts to communicate an accurate picture of the source program to debuggers and program analysis tools. Separate tables cover different debugger capabilities; among them, the. debug_line table maps object code addresses to source code locations, the. debug_info table maps source variables to the registers or stack locations where they are stored, while the.
The first few lines of the table above are for instance computed by the following bytecode: The bytecode defines the rows of the table by expressing the delta with the previous line. The advance_loc command provides the new location, and the new row is defined as a clone of the previous one, which can then be altered, for instance by setting CFA to rsp+48. This process of defining every line with respect to the previous one is compact, but implies that to get the row for a given address, all the bytecode from the beginning of the function to that address must be evaluated, potentially a very slow process. In the example expressions are simply computing offsets from rsp, but DWARF was designed to be as flexible as possible, and expressions can be arbitrarily complex. For instance, the. eh_frame table associated with the PLT sections routinely uses this entry: DW_CFA_def_cfa_expression (DW_OP_breg7 (rsp): 8; DW_OP_breg16 (rip): 0; DW_OP_lit15; DW_OP_and; DW_OP_lit11; DW_OP_ge; DW_OP_lit3; DW_OP_shl; DW_OP_plus) Each instruction is executed by a stack-based interpreter, and without dwelling on the details, this code is computing the expression: rsp + 8 +  ((((rip & 15) >= 11)? 1 : 0)<< 3) a clever hack that relies on the rip register and the regular structure of PLT tables to concisely encode the unwind information for all the PLT entries with only one unwind expression.
It is an essential component of our computational infrastructure. However DWARF based unwinding has three major drawbacks: it is unreliable, slow, and not always available. Unreliable Generating the DWARF tables tends to be a burden for compiler authors, as each optimisation pass potentially invalidates them; keeping tables and code synchronised pass after pass requires a tedious and error prone logic to be added to the already convoluted optimiser passes. In practice, there are bugs in the generated tables and these are hard to detect because DWARF information generation lacks rigorous and complete test suites. Unavailable Many important compilers do not generate DWARF tables at all; this is a major issue for JIT compilers as HotSpot (OpenJDK) and prototype implementations of new languages, but also concerns C and C++ compilers for complex optimisation passes (e.