dataesr/scientific-paragraphs-categorization huggingface dataset:
Unique to this tool, it also compares submitted code to 20 billion lines of public code. The graphical user interface is web-based and users need to submit their code online. Copy/Paste Detector is the part of PMD source code analyser project with a command line interface. The tool can do intra-corpal comparison for 25 programming languages (see the list on the website). Deckard  [85]  is another code clone detector that can be used for code plagiarism detector apart from CCFinder  [91]  and Sourcer-erCC  [156]. The tool only covers two programming languages (C and Java) but it is argued to be scalable for large data sets. It is featured with command line interface. JPlag  [142]  is a common code plagiarism detector  [129]  that can also handle general text. The tool was previously designed as a web service like MOSS  [158] , but now it is designed as a Java desktop application with a command line interface.
The tool can handle any language (both programming and human languages) as it relies on no language-specific preprocessing. The tool was maintained by the University of Sydney. However, the original link is not accessible anymore and a set of developers extracted the code from Google cache and put that on GitHub. Sherlock (Warwick)  [87]  (not related to the tool of the same name mentioned above) is a desktop plagiarism detector with graphical user interface. The tool is maintained by the University of Warwick and it is integrated to BOSS submission system  [86]. It currently covers C, C++, Java, and general text.
It provides a hinting platform, as well as autograding functionality. Scratch  [148]  is a block-based programming environment aimed at children in the 8-16 age range. It was developed by the MIT Media Lab, has been translated to 70+ languages, and is released under an open source software license. It has also been used to teach programming to younger children using the Scratch Jr project  [50]  and older children as they progress in their development using Patch  [149]. It has also spawned a collection of works to help teachers analyse Scratch projects, such as the Scratch Analysis Tool  [33] , Dr Scratch  [127]  and Hairball  [20]. SDES  [173]  or Simple and Dynamic Examination System is an automatic exam question generator. It supports plugins to allow it to automatically generate questions based on arbitrary input data or from XML-formatted files.
CrypTool(s) bundles a collection of resources and tools for learning about cryptography, with versions available as binaries on Windows (CT1 & CT2 ), a Java version (JCryptTool/JCT) and finally an web based version (CrypTool-Online/CTO). Resources are available to explain algorithms, animate them and even includes cryptography based games and contests. Development on all of the tools in this section appears to be ongoing at time of publishing. Data Structure Visualizations, provided by David Galles  [57]  is one of the earliest examples of content provision moving towards the web, it started life as a Java project in the previous decade, was subsequently rewritten in Flash for the web and finally ported to HTML5/Javascript. The site contains a large variety of visualisations for different data structures and algorithms.
Work on HDX and the datasets it utilises appears to be ongoing at time of publishing. JFLAP  [151]  is a collection of visual tools which can be used as an aid in learning concepts of formal languages and automata theory. JFLAP evolved from a collection of existing tools which were ported to Java and continuously built upon for many years. The most recent version of JFLAP (7. 1) was released in 2018, though it appears that a consistent effort has been under way since 2015 to port the functionality to HTML5 and JavaScript to enable its use within the OpenDSA interactive eTextbook (see Flap. js above). JFLAP is provides visualisations of the represented systems as well as interactive components for learning how they work. In addition, OpenFlap content within the OpenDSA interactive eTextbook can be provided in the form of gradable exercises the students must complete.
jGRASP  [39]  is a lightweight development environment created to provide visualisations to improve the comprehensibility of software. It provides control structure diagrams, UML class diagrams, and run-time visualisation for primitives and objects. It is available as standalone software as well as plugins for Eclipse and IntelliJ IDEA. Development is ongoing at the time of publication. 8 https://www. openstreetmap. org/ Jive  [84]  is an eclipse plugin that provides visualisations of the execution of Java code. This visualisations are presented in a number of different forms and adds features such as reverse stepping and the extraction of finite state machines from the execution trace of a program. Development appears to be ongoing on this project up until 2021, and may be continuing at time of publication.
JavaScript Algorithm Visualization Library (JSAV)  [93]  provides the scaffolding in JavaScript to produce algorithms visualisations for use within web pages and specifically eTextbooks like OpenDSA. Last updated in 2019, the JSAV project itself does not contain a large number of examples that can be used. However, due to its heavy use within the OpenDSA interactive eTextbook there are a large number of examples available  9. [166]  are libraries that enable the visualisation of programs on the web. This is similar in concept to JSAV, but intended instead for the visualisation of programs. JSVEE allows the creation of embeddable animations showing the execution of programs, Kelmu enables the addition of annotations to these animations to provide extra information and improve learning. The animations produced are ideal for use within on-line interactive eTextbooks.
JSVEE and Kelmu JSVEE supports Python and Scala, but animations must be generated using a transpiler to create the custom JavaScript that is required. JSVEE and Kelmu were last updated in 2020. [180]  (JAAL) is an attempt to define a language that can be used to represent algorithm animations. Typically, most implementations either have a custom representation or can only be represented in code. One novel feature of this tool is that user can interactively perform the steps of the algorithm and be scored on correctness with feedback. Development on this project is ongoing at time of publication. Marble MLFQ  [97]  is similar in design and purpose to AnimOS. Marble MLFQ is however focused on only the multilevel feedback queue rather than the different algorithms available in AnimOS. Marble MLFQ has not been developed since 2018.
cs. vt. edu/ 14 https://blog. runestone. academy 15 https://runestone. academy/ns/books/published/javajavajava/book-1. html 16 https://course. csawesome. org 17 https:/gohugo. io/ 18 https:/jekyllrb. com/ 19 https:/sphinx-doc. org/ 20 https://github. com Also, there were a number of discussions about creating crossplatform mobile applications using widely available frameworks (see Flutter  21  and Cordova  22  as examples). 6. 6. 2 Approaches and Standards. We identified a number of papers which, while they didn't identify open-textbooks directly, had what we thought were useful ideas for addressing issues around creating and using open textbooks. These includes: • Instructional design model proposals when using open texts to support online courses  [150]. • A model for creating a virtual environments that could be used as a basis for textbooks  [63].
Polling / Quizzing By nature, polling and quizzing are not specific to CS education, and indeed most papers we found describe tools used in different domains. Following this, we decided to include in our analysis tools that are not CS-centred as long as they can be used in computing education or modified to that purpose. Asking questions to students is also a facility included in many larger-scope tools or tools centred on a specific category (e. g. , virtual conference software). Thus, for the poll/quiz category we needed more restrictive queries than for other types of tools studied. Moreover, as the same query was not giving meaningful results in both investigated databases, we needed to customise those queries separately. As a result, we obtained a larger ratio of number of relevant papers over number of result papers.
The community could maintain a list of community tools seeking new contributors, contact points, and how / when volunteers can become involved. The breadth of tools that have been developed for the computing education community by the community shows the commitment that instructors and staff have to making computing accessible to anyone. This report shows that many of these tools await new adopters, but that there are also many other tools that still need to be built. We hope that this report provides some clarity for what is available, and what is needed. As mentioned previously, this working group has compiled the data we collected at https://csed-tools. github. io/. We encourage members of the CER community to submit new tools, edits, and maintenance pull requests on the source site for this repository at https://github.
Source(s) Alloy4Fun  [111]  Alloy Models http://alloy4fun. inesctec. pt/ rev AutoGrader  [108]  Code https://github. com/s3team/AutoGrader rev AutoStyle  [35, 186]  Code https://github. com/autostyle/autostyle rev ChocoPy  [131]  Code https://chocopy. org/ rev CPSGrader  [90]  Code http://cpsgrader. org/ rev EarSketch  [157, 168]  Code https://earsketch. gatech. edu/ rev GitGrade  [193]  Code https://gitgrade. cs. washington. edu/ rev Gradescope Code https://gradescope. com sur JupyterCanvasSubmit  [67]  Code https://github. com/eagubsi/JupyterCanvasSubmit rev Learn-OCaml  [31]  Code https://github. com/ocaml-sf/learn-ocaml rev Mastery Learning Quiz App  [15]  Assignment https://github. com/tiara-allidina7/ MasteryLearningQuizApp rev OpenDSA Programmed Instruction  [122]  Quiz/Practice https://opendsa-server.
cs. vt. edu/ rev Reveal  [88]  Code in Exams https://github. com/ace-lab/reveal rev SnapCheck  [184]  Code https://github. com/emmableu/SnapCheck rev SQLFE  [182]  Code https://github. com/wagnerpj42/SQL-File-Evaluation rev Submitty  [137]  Code https://submitty. org rev Submitty: Graphics Applications  [114]  Code https://submitty. org rev Submitty: Distributed Algorithms  [115]  Code https://submitty. org rev TermAdventure (2021)  [174]  Terminal https://github. com/NaiveNeuron/TermAdventure rev uAssign  [12]  Terminal https://github. com/jakebailey/ua rev Web-CAT  [45]  Code https://github. com/web-cat sur Web-CAT Jupyter Plugin  [117]  Code https://github. com/web-cat/web-cat-plugin-JupyterPlugin rev AntiCutAndPaste Code & text http://www. plagiarism-report. com/anticutandpaste/ rev BPlag [34] Code https://github.
com/hjc851/BPlag rev CCFinder [91] Code http://www. ccfinder. net/ rev CodeMatch Code https://www. safe-corp. com/products_codematch. htm rev CodeQuiry Code & text https://codequiry. com/ rev Copy/Paste Detector Code https://pmd. github. io/latest/pmd_userdocs_Copy/ PasteDetector. html rev Deckard [85] Code https://github. com/skyhover/Deckard rev JPlag [142] Code & text https://github. com/jplag/JPlag rev Lichen [136] Code & text https://submitty. org/instructor/course_management/ plagiarism rev MOSS [158] Code https://theory. stanford. edu/~aiken/moss/ rev, sur Plaggie [5] Code https://www. cs. hut. fi/Software/Plaggie/ rev plagiarismchecker. com Text http://www. plagiarismchecker. com/ rev Power and Waldron [140]'s Tool Code https://github. com/johnwaldron-tcd/codemarkverilog-cleaner-tokeniser rev Safeassign Text https://help.
blackboard. com/SafeAssign/Student/ Submit_SafeAssign rev Sherlock (Sydney) Code & text https://github. com/diogocabral/Sherlock rev Sherlock (Warwick)  [87]  Code & text https://warwick. ac. uk/fac/sci/dcs/research/ias/ software/sherlock/ rev SIM  [64]  Code & text https://dickgrune. com/Programs/similarity_tester/ rev SourcererCC  [156]  Code https://github. com/Mondego/SourcererCC rev STRANGE  [94]  Code https://github. com/oscarkarnalim/strange.
The algorithm is based on a correlation directional warping function, estimated using an energy minimization procedure. The approach was optimized via an innovative coupling of a hierarchy of image resolutions to a hierarchy of transformation, in which band misalignment is corrected at successively finer scales. The algorithm's performance was assessed in terms of the bands' standard deviation before and after straightening, using a synthetic dataset and a set of 200 lanes of CSF, tear, serum and control samples on which experts had manually delineated the bands. The number of distorted bands was divided by almost 16 for the synthetic lanes and by 7 for the test dataset of real lanes. This method can be applied effectively to different sample types. It can realign minimal contrast bands and is robust for non-uniform deformations.
Materials and Methods 2. 1. Description of the Datasets 2. 1. 1. IEF Image Acquisition and Pre-Processing IEF lanes of CSF, serum, and tear samples were acquired during the POLAR French national multicentre clinical trial. POLAR was conducted from 2012 to 2018 and was coordinated by our biologists from the biochemistry laboratory at Saint Philibert Hospital (Lille, France). The trial was designed to assess the diagnostic value of OCBs detected in IEF gels of tear samples from patients with a CIS. Tears, CSF and serum samples were collected for each patient to study the relationship between tears/CSF IEF. IEF and IgG immunoblotting were carried on a 10 cm × 8 cm gel membrane, using the Helena Biosciences IgG IEF kit intended for IgG OCB detection in CSF and serum, and using a SPIFE 2000 analyser (Helena Biosciences Europe, Gateshead, UK).
The Real IEF Dataset A database of 150 lanes (50 each for CSF, tears, and serum) was distributed equally between training and test datasets. The lanes were randomly selected from the IEF database compiled during the POLAR multicentre clinical trial. IEF profiles that could not be analysed clinically (because of insufficient protein levels and thus insufficient contrast) were excluded from the database. Moreover, IEF lanes with strong artifacts that prevented visual analysis were also excluded. Due to their right-most position in the gel membrane, control samples frequently showed strong geometric band deformations (Figure  1 ). Hence, 50 control lanes (25 in the test set and 25 in the training set) were added to the dataset. The training set was used to optimize the values of the algorithm's parameters, whereas the test set was used to assess the performance of the new algorithm.
The Synthetic Dataset One thousand digitally generated lanes were created to test our band-straightening algorithm's ability to correct random artificial deformations. The synthetic lane background was generated by randomly choosing one of five real negative grayscale profiles (i. e. , profiles without OCBs) filtered beforehand with a twodimensional (2D) Gaussian filter. Gaussian functions are commonly used in the literature to approximate band shapes  [10, 18]  hence, the bands were created using a Gaussian density function. The expected value was the band position, and the standard deviation (SD) was proportional to the band width (band width ≈ 4 SD). The band position was a uniformly distributed random number in the lane height. The band's full width at half maximum (FWHM) is set to 7 px + r, where r is a random variable with an exponential distribution and an expected value of 7 pixels (0.
The Algorithm's Settings Algorithm parameters listed herein (the rolling ellipsoid radii r x , r y , r z , the decreasing function f in E ext (∆Y; I), the E int (∆Y) weighting parameters w x , w y , the shift δ j associated with each hierarchical step j, the list of types of move M j specific for each hierarchical step j) are not disclosed here due to a technology transfer being negotiated. All the latter parameters were adjusted and set empirically through trial-and-error experiments on the training dataset of real and synthetic lanes.
Optimization of the Band-Straightening Algorithm Our approach uses powerful optimization techniques to produce a low-cost, reliable band-straightening method. The coupled hierarchy of image resolutions and hierarchy of transformations gave much the same results as the hierarchy of transformations alone (in the absence of a multiresolution framework), but led to a decrease in the computational cost by a factor of ~3. Most of our methods for the automatic analysis of IEF images and the detection of OCBs were developed in MATLAB. However, the time-consuming parts (image warping, correlation calculation) were implemented in C/C++, using the MKL routines (version 2020. 1). This latest time optimization method has reduced the computation time by 20%, relative to the MATLAB version. Hence, the computation time for a full, 10-lane membrane is approximately 10 s when each lane is processed on a different thread (Intel I7-7700HQ laptop computer, MATLAB R2020b).
Real IEF Dataset We used a rigorous method to evaluate our band-straightening algorithm. Firstly, we developed an interactive graphical user interface for expert manual band annotation. One expert analysed the training and test datasets, and a second expert reviewed the analysis. Bands were manually traced on the original lane images, i. e. , without automatic band straightening. The experts placed points on the band's midline, which were then linearly interpolated. To guide the manual annotation process, the tracing assistant tool generates instant feedback on the successive points placed by the expert. This feedback consists of showing a warped lane image by mapping the lines traced by the expert to horizontal lines. Thus, the expert can check if he/she has correctly annotated the bands by checking whether they are straight on the warped image.
(iii) SD > 4 pixels corresponds to a moderately-to-strongly deformed band. (iv) SD > 5 pixels correspond to a strongly deformed band. Strongly deformed bands included in (iv) will also be included in (i), (ii), and (iii). The algorithm's overall performance for band profiles was quantified by measuring the ratio ρ t = num be f ore t num a f ter t with the different deformation thresholds t. For profiles without bands, the degree of deformation introduced was evaluated by calculating the average SD of all image rows after application of the band-straightening algorithm. Next, the individual deformations were averaged for all the profiles without bands in the training and test datasets separately. We compared the performance of the latest OCB-straightening algorithm (OCBSA-2021) with that of a correlation-based band straightening algorithm previously developed by our group (referred to here as OCBSA-2016)  [9].
Results with the Real IEF Dataset This section presents illustrative results on lanes selected for their difficulties of straightening. Figure  5  shows the results of band straightening on a CSF lane with non-uniform band deformations: the upper seven bands are severely bent downwards (average SD: 7. 9 pixels; Figure  5a, d ) and the remaining six bands are slightly deformed (average SD: 2. 6 pixels) (Figure  5a, d ). This example demonstrated the robustness of OCBSA-2021 with regard to non-uniform band deformations: all the deformed bands were straightened to a satisfactory extent (Figure  5c, f ). In contrast, OCBSA-2016 clearly failed to straighten the 7 upper bands (Figure  5b, e ). Moreover, bands 1, 2, 3, and 6 illustrated OCBSA-2021 s ability to straighten faint bands with large angle deformations and thus confirmed its value as a technique for enhancing IEF gel images prior to OCB detection.
One can note the difference in the number of bands with SD (∆Y) >5 pixels between the training dataset (58 bands) and the test dataset (25 bands). This difference is mainly due to two control lanes with, respectively, 11 and 7 highly distorted bands randomly assigned to the training database during database decomposition. Serum lanes contain rarely bands; however, in order to study band straightening on this sample type, the experts chose to also annotate several faint bands with no real clinical value. Tear lanes have less bands than CSF lanes, and so there were twice as many CSF bands (training: 109, test: 127) than tear bands (training: 59, test: 59). OCBSA-2021's ability to decrease the number of deformed bands is obvious for largeangle, bent bands: in the training database, the number of strongly deformed band (SD > 5 pixels) was divided by ρ 5 = 19, and the number of moderately-to-strongly deformed band (SD > 4 pixels) was divided by ρ 4 = 12.
In the test dataset, those factors for OCBSA-2021 are ρ 5 = 8. 3 and ρ 4 =7. 1, respectively. These values were significantly better than those of OCBSA-2016: ρ 5 = ρ 4 = 2. 9 in the training database and ρ 5 = 1. 5 and ρ 4 = 2. 5 in the test database. The difference in performance between training and test dataset is relatively small, which indicates the absence of overfitting with the chosen settings. OCBSA-2021 s superiority over OCBSA-2016 comes from the fact that the latter was developed for small ROIs selected manually by experts inside each lane, and so the bands were unlikely to have a non-uniform deformation distribution. In our automatic approach, the analysed region is no longer a small ROI; the need for a non-uniform band deformation correction therefore arises, and OCBSA-2016 gives relatively poor results.
OCBSA-2021 is operational for all profiles (serum, tears, CSF, and control) but is more effective on control and CSF lanes. This is due to OCBSA-2021 s relatively high sensitivity to band contrast: a low-contrast band is less likely to be perfectly straightened than a high-contrast band. Figure  10  shows the results obtained for the synthetic lane database. Since the deformations created were non-uniformly distributed, the striking performance difference between OCBSA-2016 and OCBSA-2021 was expected. Relatively similar ρ t were obtained using OCBSA-2021 on the real and the digitally created lanes-especially for bands with SD > 4 pixels and bands with SD > 5 pixels. However, higher ρ t are observed for bands with SD > 3 pixels and bands with SD > 2 pixels-probably due to the perfect ground truth for this dataset.
The difference in performance between training and test dataset is relatively small, which indicates the absence of overfitting with the chosen settings. OCBSA-2021′s superiority over OCBSA-2016 comes from the fact that the latter was developed for small ROIs selected manually by experts inside each lane, and so the bands were unlikely to have a non-uniform deformation distribution. In our automatic approach, the analysed region is no longer a small ROI; the need for a non-uniform band deformation correction therefore arises, and OCBSA-2016 gives relatively poor results. OCBSA-2021 is operational for all profiles (serum, tears, CSF, and control) but is more effective on control and CSF lanes. This is due to OCBSA-2021′s relatively high sensitivity to band contrast: a low-contrast band is less likely to be perfectly straightened than a highcontrast band.
We demonstrated that our new band-straightening method OCBSA-2021 (i) is effective and reliable for correcting strongly deformed bands, (ii) surpasses OCBSA-2016 by decreasing the deformation by a factor ρ t ranging from 3. 7 to 8. 3 on the test dataset (depending on the considered degree of deformation), and (iii) successfully avoided unnecessary deformations on profiles with no bands. A post hoc examination of the remaining deformed bands showed that most were due to imprecisions during expert band annotation or to broad bands that made it hard for experts to accurately locate the band's midline. In this latter case, expert annotation-based straightening and the OCBSA-2021 solution both appeared to be acceptable, despite being significantly different. An improvement in column correlation was observed for all the profiles with at least one band from both the training and test datasets, relative to expertannotation-based straightening.