climate change time planning infrastructure uncertainty flexible model dam future water temperature Bayesian virtual \Delta Water approach observations projections precipitation scenario large using {border-style adaptive alternative approaches cost models px;} #ffffff;} MCM \ast historical previous range \ldots reliability GCM SDP V_{t estimates Climate World analysis flexibility learning mean period regional state static use used (\Delta -year Fig. develop potential transition Clim. capacity changes new risk Change Resour. \documentclass[pt]{minimal} \setlength{\oddsidemargin}{-pt} \usepackage{amsbsy} \usepackage{amsfonts} \usepackage{amsmath} \usepackage{amssymb} \usepackage{mathrsfs} \usepackage{upgreek} \usepackage{wasysym} available chosen current monthly possible probabilities probability small value Bank Supplementary assume based developed information observed reservoir shortages supply t−, (). Mwache T_{} adaptation costs desalination different estimate estimated framework learn method observation optimal projected px; regret robust substantially upfront {font-family mm month However, assess corresponding demand dynamic economies font-size function high management meet performance policy provide sample scenarios set targets {\mathrm{P}}(\Delta {}, CIs CLIRUN Planning Report ability action adjacent alternative, assessment assuming best data decisions democratic design double; dry ensembles evaluate expansion future. investments joint modest operations opportunities period. reflecting runoff series shown strategies target total unique updated values variability yield {}} = ./WR . °C Groves Lempert Science Tebaldi \forall \right) _{} absolute adding annual apply border-color border-width capital development distribution enables ensemble expanded expected expensive including multiple needed observations. period, periods. planners probabilistic requires samples scale shows simulations simulations, solid; statistical stochastic streamflow tradeoffs uncertain wet y_{{}i},T_{} years {\mathrm{P}}(\upsilon {font-style {font-weight })\\ Adaptive CMIP Cambridge, Capex Commons Creative Engineering Eq. First, GCMs LINK MAR Massachusetts Mombasa Nature New Panel Press, Res. Research Resources S.F. Table Therefore, Virtual \in additional allows alternative. alternatives analogous application applied approaches. assumed averaged better bold comparison courier; critical damages dams decision demonstrate demonstrates density described discount distributions drier em; enabling end given global impact increases independent initial later learned likely low methods modeling observation. observations, optimization periods pt;} reduces reflect relative reliable shortage study thresholds traditional trends t = , uses {\mathrm{N}}(\mu {},i}) υ(Δ


Overview
The variants
section of your tailwind.config.js
file is where you control which core utility plugins should have responsive variants and pseudo-class variants generated.
// tailwind.config.js
module.exports = {
variants: {
appearance: ['responsive'],
// ...
borderColor: ['responsive', 'hover', 'focus'],
// ...
outline: ['responsive', 'focus'],
// ...
zIndex: ['responsive'],
},
}
Each property is a core plugin name pointing to an array of variants to generate for that plugin.
It's important to note that these values are not merged with the defaults, so if you'd like to enable another variant for a utility, you need to repeat the default variants for that utility as well.
Don't list only the extra variants you want to enable
// tailwind.config.js
module.exports = {
variants: {
backgroundColor: ['active'],
},
}
Always provide the complete list of variants you want to enable
// tailwind.config.js
module.exports = {
variants: {
backgroundColor: ['responsive', 'hover', 'focus', 'active'],
},
}
Ordering variants
It's important to note that variants are generated in the order you specify them, so variants at the end of the list will take precedence over variants at the beginning of the list.
In this example, focus
variants have the highest precedence for backgroundColor
utilities, but hover
variants have the highest precedence for borderColor
utilities:
// tailwind.config.js
module.exports = {
variants: {
backgroundColor: ['hover', 'focus'],
borderColor: ['focus', 'hover'],
},
}
/* Generated CSS */
.bg-black { background-color: #000 }
.bg-white { background-color: #fff }
/* ... */
.hover\:bg-black:hover { background-color: #000 }
.hover\:bg-white:hover { background-color: #fff }
/* ... */
.focus\:bg-black:focus { background-color: #000 }
.focus\:bg-white:focus { background-color: #fff }
/* ... */
.border-black { border-color: #000 }
.border-white { border-color: #fff }
/* ... */
.focus\:border-black:focus { border-color: #000 }
.focus\:border-white:focus { border-color: #fff }
/* ... */
.hover\:border-black:hover { border-color: #000 }
.hover\:border-white:hover { border-color: #fff }
/* ... */
This means that given the following HTML:
<input class="focus:bg-white hover:bg-black focus:border-white hover:border-black">
...if the input was hovered and focused at the same time, the background would be white but the border would be black.
Generally, we recommend the following order for the built-in variants, although you are free to use whatever order makes the most sense for your own project:
['responsive', 'group-hover', 'focus-within', 'hover', 'focus', 'active']
The responsive variant
The responsive
variant is the only variant that is not impacted by the order you list in your variants configuration.
This is because the responsive
variant automatically stacks with pseudo-class variants, meaning that if you specify both responsive
and hover
variants for a utility, Tailwind will generate responsive hover variants as well:
// tailwind.config.js
module.exports = {
variants: {
backgroundColor: ['responsive', 'hover'],
borderColor: ['responsive', 'focus'],
},
}
/* Generated CSS */
.bg-black { background-color: #000 }
/* ... */
.hover\:bg-black:hover { background-color: #000 }
/* ... */
.border-black { border-color: #000 }
/* ... */
.focus\:border-black:focus { border-color: #000 }
/* ... */
@media (min-width: 640px) {
.sm\:bg-black { background-color: #000 }
/* ... */
.sm\:hover\:bg-black:hover { background-color: #000 }
/* ... */
.sm\:border-black { border-color: #000 }
/* ... */
.sm\:focus\:border-black:focus { border-color: #000 }
/* ... */
}
@media (min-width: 768px) {
.md\:bg-black { background-color: #000 }
/* ... */
.md\:hover\:bg-black:hover { background-color: #000 }
/* ... */
.md\:border-black { border-color: #000 }
/* ... */
.md\:focus\:border-black:focus { border-color: #000 }
/* ... */
}
@media (min-width: 1024px) {
.lg\:bg-black { background-color: #000 }
/* ... */
.lg\:hover\:bg-black:hover { background-color: #000 }
/* ... */
.lg\:border-black { border-color: #000 }
/* ... */
.lg\:focus\:border-black:focus { border-color: #000 }
/* ... */
}
@media (min-width: 1280px) {
.xl\:bg-black { background-color: #000 }
/* ... */
.xl\:hover\:bg-black:hover { background-color: #000 }
/* ... */
.xl\:border-black { border-color: #000 }
/* ... */
.xl\:focus\:border-black:focus { border-color: #000 }
/* ... */
}
Responsive variants are grouped together and inserted at the end of your stylesheet by default to avoid specificity issues. If you'd like to customize this behavior for whatever reason, you can use the @tailwind screens directive to specify where responsive variants should be inserted.
The default variant
You can use the special default
variant to control where the normal, non-prefixed versions of a utility are generated relative to the other variants.
// tailwind.config.js
module.exports = {
variants: {
backgroundColor: ['hover', 'default', 'focus'],
},
}
/* Generated CSS */
.hover\:bg-black:hover { background-color: #000 }
.hover\:bg-white:hover { background-color: #fff }
/* ... */
.bg-black { background-color: #000 }
.bg-white { background-color: #fff }
/* ... */
.focus\:bg-black:focus { background-color: #000 }
.focus\:bg-white:focus { background-color: #fff }
/* ... */
This is an advanced feature and only really useful if you have a custom variant (like children
in the example below) that should have a lower precedence than the normal version of a utility.
// tailwind.config.js
module.exports = {
variants: {
backgroundColor: ['children', 'default', 'hover', 'focus'],
},
}
/* Generated CSS */
.children\:bg-black > * { background-color: #000; }
.children\:bg-black > * { background-color: #000; }
.bg-black { background-color: #000 }
.bg-white { background-color: #fff }
/* ... */
.hover\:bg-black:hover { background-color: #000 }
.hover\:bg-white:hover { background-color: #fff }
/* ... */
.focus\:bg-black:focus { background-color: #000 }
.focus\:bg-white:focus { background-color: #fff }
/* ... */
Learn more about creating custom variants in the variant plugin documentation.
Using custom variants
If you've written or installed a plugin that adds a new variant, you can enable that variant by including it in your variants configuration just like if it were a built-in variant.
For example, the tailwindcss-interaction-variants plugin adds a visited
variant (among others):
// tailwind.config.js
{
variants: {
backgroundColor: ['responsive', 'hover', 'focus', 'visited'],
},
plugins: [
require('tailwindcss-interaction-variants')(),
],
}
Learn more about creating custom variants in the variant plugin documentation.
Default variants reference
Here is a complete reference of Tailwind's default variants configuration, which can be useful when you'd like to add a new variant while preserving the defaults.
// Default configuration
module.exports = {
// ...
variants: {
alignContent: ['responsive'],
alignItems: ['responsive'],
alignSelf: ['responsive'],
appearance: ['responsive'],
backgroundAttachment: ['responsive'],
backgroundColor: ['responsive', 'hover', 'focus'],
backgroundPosition: ['responsive'],
backgroundRepeat: ['responsive'],
backgroundSize: ['responsive'],
borderCollapse: ['responsive'],
borderColor: ['responsive', 'hover', 'focus'],
borderRadius: ['responsive'],
borderStyle: ['responsive'],
borderWidth: ['responsive'],
boxShadow: ['responsive', 'hover', 'focus'],
cursor: ['responsive'],
display: ['responsive'],
fill: ['responsive'],
flex: ['responsive'],
flexDirection: ['responsive'],
flexGrow: ['responsive'],
flexShrink: ['responsive'],
flexWrap: ['responsive'],
float: ['responsive'],
fontFamily: ['responsive'],
fontSize: ['responsive'],
fontSmoothing: ['responsive'],
fontStyle: ['responsive'],
fontWeight: ['responsive', 'hover', 'focus'],
height: ['responsive'],
inset: ['responsive'],
justifyContent: ['responsive'],
letterSpacing: ['responsive'],
lineHeight: ['responsive'],
listStylePosition: ['responsive'],
listStyleType: ['responsive'],
margin: ['responsive'],
maxHeight: ['responsive'],
maxWidth: ['responsive'],
minHeight: ['responsive'],
minWidth: ['responsive'],
objectFit: ['responsive'],
objectPosition: ['responsive'],
opacity: ['responsive'],
order: ['responsive'],
outline: ['responsive', 'focus'],
overflow: ['responsive'],
padding: ['responsive'],
pointerEvents: ['responsive'],
position: ['responsive'],
resize: ['responsive'],
stroke: ['responsive'],
tableLayout: ['responsive'],
textAlign: ['responsive'],
textColor: ['responsive', 'hover', 'focus'],
textDecoration: ['responsive', 'hover', 'focus'],
textTransform: ['responsive'],
userSelect: ['responsive'],
verticalAlign: ['responsive'],
visibility: ['responsive'],
whitespace: ['responsive'],
width: ['responsive'],
wordBreak: ['responsive'],
zIndex: ['responsive'],
}
}


Mfg. Journal Register
No entries found within given criteria.
Do search with some other dates
0">
| Date |
Vch. No. |
Final Product |
Raw Products |
Product Inwards |
Quantity Outwards |
| {{item.date}} |
{{item.voucherNumber}} |
{{item.stockName}} |
| |
{{item.manufacturingQuantity}} {{item.manufacturingUnit}} |
|
| {{row.stockName}} |
|
{{row.manufacturingQuantity}} {{row.manufacturingUnit}} |
|


VS Code Plugin
The VSCode plugin directly integrates with Travetto framework, exposing some of the Command Line Interface functionality.
The currently supported features are:
- Real-time test evaluation and debugging
- Cli command launching with parameters
- Terminal integration for framework links
- Miscellaneous utilities
Testing
The test related functionality relies upon the Testing module being installed, and used to define tests (@Suite and @Test).
Real-time Test Evaluation
The real-time test functionality will re-evaluate your test code on save. This means as you type and save, the test will run. The test will provide feedback inline, using green to indicate success, red to indicate failure, and gray to indicate unknown.
Debugging Tests
While working on a test, if you want to debug it, you can press running command-shift-t
on OSX or ctrl-shift-t
on Windows/Linux. This will start a debug session with the current line activated as a breakpoint. This allows you to seamlessly jump into a debug session while writing tests.In addition to manual invocation at a line, each test has a CodeLens, that allows for trigger the test as well.
Commands
Travetto: Debug Tests
to force a running all the tests in debug mode. Will not establish a breakpoint, but will use any existing breakpoints.
Travetto: Re-run Tests
to force a full re-run of all the tests in a given document
CLI Running
While using the Command Line Interface, a common pattern is to use @CliCommand annotations to define entry points into the application. These entry points can take parameters, and if using the cli, you can invoke them with parameters, type checked and validated.
The plugin exposes this functionality as a command, to allow you to debug these commands directly from the editor.
Running
Launching relies upon the command Travetto: Run New Command
. This will show you a list of the available entry points in the project, with the parameters they support. Selecting a command will take you through the parameter flow to select inputs, and once all parameters are selected, your command will launch. After running and selecting a configuration for a command, you can now access those configurations via Travetto: Run Recent Command
. This allows you to execute a recent run that you can invoke immediately without prompting for inputs. If you find yourself running the same application multiple times, you can also invoke Travetto: Run Most Recent Command
to bypass application selection overall.
Exporting and Customizing
If at any point in time, you wish to modify the launch configuration of any command, you can execute Travetto: Export Command
, and it will provide the same options as launch. The only difference is that instead of running the command, you will have a new debug launch config. This option is now completely independent from the plugin and can be modified without issue.
Commands
Travetto: Run New Command
to launch a new command config
Travetto: Run Recent Command
to launch a previously configured command
Travetto: Run Most Recent Command
to launch the most recently run configured command
Travetto: Export Command
to export an command config
Running from Command Line
When invoking commands from the terminal (within VSCode), the CLI will delegate the relevant commands to the VSCode plugin. This allows for more customization of entry points, as well as ability to leverage aliases/scripts (e.g. npm start
) as a way of unifying the tooling.
Email Template Development
While developing emails, the desire to visual inspect output, as well as quickly test changes is paramount. To that end, the plugin supports the ability to compile, view, and send email templates all from within the plugin.
The plugin exposes this functionality as a command, to allow you to debug these applications directly from the editor.Any file that ends with .email.tsx
is assumed to be an email template, and will trigger background compilation upon editing the file. All of the following commands require the user to be actively editing the .email.tsx
file to be available.
Additional, for rendering the email, a context may be needed to exercise the various logic paths. The plugin picks up resources/email/dev.yml
by default, and if its not found, then an empty object is provided.
Commands
Travetto: Preview Email HTML
to view the html
version of the rendered template
Travetto: Preview Email Text
to view the text
version of the rendered template
Travetto: Send Email Template
to trigger sending an email (requires SMTP configuration)
Travetto: Email Template Context
to view/edit the context file used to render the template
Misc Utilities
Currently the supported commands are:
Travetto: Clean
to run the cli operation travetto clean
. This will purge the project's cache, which is generally after workspace changes, like npm installs.
Release Info
Requirements
- You should have the Travetto framework installed, version 1.1.0 and higher.
- Tests require the Testing module to be installed.
- CLI command running requires the Command Line Interface module to be installed.
Known Issues
Release Notes
1.1.x
- Introduced the email template functionality
1.0.x
- Complete rewrite of plugin
- Test framework integration completely inverted, and majority of logic offloaded to framework
0.5.x
- Introduced application launching
- Resolved test stability issues
- Introduced clean functionality


Create Brawndough
Mint Brawndough ERC721 NFT Coin
Description as URI:
Enter inital Ether amount: (In Wei)
Mint Brawndough
Transfer Brawndough ERC721 NFT Coin by selecting Token ID and Address to Send to:
Enter the Token ID as a positive integer:
Enter the address to send to:
Transfer Brawndough Coin
Buy Brawndough ERC721 NFT Coin by selecting Token ID
Buy Brawndough ERC721 NFT Coin by selecting Token ID
Confirm receipt of a Purchased Brawndough ERC721 NFT Coin by selecting Token ID
Confirm receipt of a Brawndough ERC721 NFT Coin by selecting Token ID
Donate to Brawndough ERC721 NFT Coin Owner
Enter Ether donation amount: (In Wei)
Donate to Brawndough
Destroy your Brawndough ERC721 NFT by selecting Token ID
Destroy Brawndough Coin
Brawndough Electrolight Token Board
Address
Token ID
Description
Ether Value


Theme Ambiance Blackboard Cobalt Eclipse Elegant Elegant Code Elegant Type Erlang-dark Lesser-dark Monokai Neat Night New Plus Rubyblue Solarized (dark) Solarized (light) Twilight Vibrant-ink Xq-dark Xq-light Lines on | Lines off
# Welcome to Wreditor (v0.8.3) Wreditor is the browser-based text editor that powers [Write.app](https://writeapp.me). It's built on top of the wonderful [Codemirror project](http://codemirror.net) and you can drop it into most projects and expect it to work with minimal effort. *Wreditor currently implements the following features:* * Automatically closes brackets * Live syntax highlighting (Markdown by default with other languages available) * Live theme switching * Toggle line numbers * Save locally * Distraction-free mode * Note options * Bundled web server for running it locally * The readme has more information * See the [blog post](http://billpatrianakos.me/blog/2013/04/22/introducing-wreditor-the-in-browser-text-editor/) *Features coming soon* * General improvements to all current features * Write.app users can save to their accounts from any Wreditor instance * Easily plug into any custom database * Live-preview mode ## Get the source! [On GitHub](https://github.com/WrtApp/wreditor) # Frequently asked questions ## What can it do? Wreditor is set up to be a... * Drop-in solution for any project requiring a powerful, customizeable, browser-based text editor along the lines of Codemirror. * Standalone, simplistic text editor. What does just about every computer have installed? A web browser. You can run Wreditor locally using the bundled simple HTTP server script (requires Python) or using XAMPP, MAMP. * Private or public hosted tool. Drop the contents of the `wreditor` folder onto a web server and have an easily accessible, customizeable text editor at your disposal everywhere you have a web connection. (Or you can just use this demo if that's sufficient for you). ## How is it different than CodeMirror? You may wonder, "Why not just use CodeMirror instead?" and you'd have a great point. Wreditor relies heavily on CodeMirror for it's functionality. On the surface it's basically a CodeMirror instance that's been set up for a specific use-case. Even so, Wreditor comes pre-made and bundled with customizations and tools that would take quite a bit of time for some people (but not all) to implement.  Write.app's editor has gone through three major revisions since the first version was built in 2011. Wreditor is the third major release of the [Write.app editor](https://writeapp.me/write) and the first to be open sourced. All of its features have been refined after three years of work and research into how people use Markdown text editors. ## Differences between Write.app's Wreditor implementation and the open source version The version of Wreditor in use in Write.app has been slightly modified for use specifically with the app. In particular there are a few extra note options, API access for note saving and secondary backups, and live previews in Write.app's Wreditor implementation as well as cosmetic differences to match the theme of the site. Wreditor Open (this version) will catch up with all of those missing features in future releases. They are not included in the open source version because of differences in the way the general public would need to use Wreditor and Write.app's specific use cases. It takes time to take a Write.app feature and add it to Wreditor in a way that's generally useful to everyone regardless of whether they have a Write.app account or not.


There will be notes in italics throughout the introductory material discussing similarities and differences between growthcleanr-adults and growthcleanr-pediatrics for those who are familiar with growthcleanr-pediatrics and are interested. The nonitalicized text of the narrative does not assume any prior knowledge of growthcleanr-pediatrics.
The overall goal of growthcleanr-adults is to prepare datasets of height (HT) and weight (WT) data for adults (18y to 65y) for analysis by identifying and excluding HT and WT values that are implausible for an individual in the dataset. For many researchers and analysts who are focused on people with atypical anthropometrics, including severe obesity or anorexia nervosa, excluding values that are implausible for an individual rather than values that are atypical for a population is particularly important.
Growthcleanr-adults is designed to be as flexible as possible. In addition to data on HT and/or WT and a subject identifier, growthcleanr-adults requires only a variable for age to run, making it feasible to run on datasets from many sources. To date, it has been designed and tested in outpatient data. It is designed to work in people with many conditions that can affect anthropometrics, and modifications can likely be made to accommodate additional conditions that users identify. It can work on datasets of almost any size, from a dataset with one subject with one observation to datasets with hundreds of millions of observations. Subjects are evaluated completely independently from each other. HT and WT measurements for each subject are also evaluated separately from each other except for two small exceptions that will be detailed in the detailed description of steps.
Growthcleanr-adult does not require sex, which is required for growthcleanr-pediatrics to determine standard deviation scores. There is no recentering step as there is in growthcleanr-pediatrics. Also, except for the swap step and the 1 distinct value step (similar to ‘singles’) in which BMI is generated, both of which can be bypassed, there is no use of the other parameter as there is in some steps of growthcleanr-pediatrics.
It is not too difficult to evaluate a subjects HT or WT values and determine that at least one of them is likely implausible. It is much harder to confirm that there is an implausible measurement and especially to determine which measurement is the problem. Also, once there is one implausible measurement for a subject, there is an increased risk of finding an implausible measurement among the remaining values. Once there are two or more implausible measurements for a subject for HT or WT, it takes a lot of work to identify correctly which measurements are the problem.
To deal with the above challenges, growthcleanr-adults has multiple steps. In general, the steps exclude more extreme errors earlier and less extreme errors later, and rarely are multiple errors for a subject excluded in one step. Additionally, much of each step is devoted to checks to confirm that any value should be excluded and determine which value that should be.
These general principles are the same as for growthcleanr-pediatrics.
Overall, it was expected that WT in adults could remain stable or could have multiple gain/loss cycles within a subject. Expected changes included shorter term changes (fluid shifts, WT loss after pregnancy, short term WT loss/gain such as during/after illness) as well as longer term changes (intentional WT loss with or without surgery, WT gain with or without prior WT loss, slower gain during pregnancy). Although we do not have data on pregnancy or other diagnoses, it is reassuring that the proportion of excluded WTs is very similar for males and females, making it less likely that WT changes common in pregnancy are being excluded by growthcleanr.
For HT, three overall patterns were allowed in adults of this age, with an expectation of one inch of measurement error in either direction. The first pattern was stable HT. The second pattern was up to two episodes of HT loss without evidence of subsequent HTs inconsistent with the proposed HT loss pattern. The third pattern was HT gain for people whose first measurement occurred before age 25 years (although most gain in HT was allowed during the first years after 18) and who demonstrated one or more periods of HT gain without evidence of subsequent HTs inconsistent with the proposed HT gain pattern.
The expected patterns of WT and HT are two of the biggest differences with growthcleanr-pediatrics. Although growthcleanr-pediatrics accounted for weight loss, it was not written into the code the way it is for growthcleanr-adults, and growthcleanr-pediatrics would likely exclude some WTs in people with gains and losses that growthcleanr-adults can handle. Also, growthcleanr-pediatrics could not handle a HT loss of >3 cm (and that 3 cm was meant to cover measurement error, not actual HT loss).
In the primary dataset used to derive growthcleanr-adults, many values are repeated for both HT and WT. To a certain extent, this is expected because HT especially is generally fairly stable in adults among this age, and for some adults especially over periods of a couple of years WT is fairly stable. However, other values show fairly clear evidence of being pulled forward from a prior visit (e.g., subject Z with a WT pattern of 61, 63, 67, 72, 61, 72, 74, 61, 81, 61, 92). These have to be addressed specifically because otherwise they can distort the findings for other measurements; for example, you can imagine that for subject Z the WT=81 might be identified as implausible, even though on inspection it is far more likely that the surrounding 61 kg WTs did not represent new measurements. Additionally, when a subject has 20 identical HTs or WTs, it is extremely unlikely that they provide the same strength of information that 20 similar but not all identical HTs or WTs provides. Therefore, for both WT and HT, in later parts of the code there is a distinction made between how many distinct values a subject has; 2 distinct WTs each repeated 5 times are treated more similarly to how 2 total WTs would be treated than to how 10 completely distinct WTs would be treated. In many, but not all steps, if one member of a repeated value group is excluded, all members of that group are excluded. A lot of attention was paid to avoid inappropriately excluding repeated values.
Repeated values are different in very important ways from carried forwards in growthcleanr-pediatrics. The biggest differences are: 1) In growthcleanr-adults, most repeated values are retained (in growthcleanr-pediatrics essentially all carried forwards are excluded). 2) In growthcleanr-adults, repeated values are identified as part of the repeated value group regardless of whether they are consecutive (in growthcleanr -pediatrics carried forwards are only consecutive). 3) In growthcleanr-adults, groups of repeated values often (not always) get excluded in the same step (this is not a possibility in growthcleanr-pediatrics because later carried forward values are excluded early, and nonconsecutive values are not identified).
Changes in recorded HT that are commonly seen in EHR data can have a substantial impact on BMI that are likely not reflective of differences in adiposity in most patients. For this reason, in addition to cleaning HT data we can optionally output a mean HT. For patients in whom we see evidence of HT gain or loss the mean HT changes as the HT changes, otherwise the mean HT is averaged over all of the subject’s included HTs. People using the dataset can decide to use the original HT or the mean HT. Note that in all cases, based on the way the algorithm works, the mean HT will be within 2 inches of the original HT.
While the adult algorithm is considered complete, several areas for potential improvement remain. These are noted as next steps for future work.
Growthcleanr-adults works better with:
Precise HT and WT measurements – Growthcleanr-adults uses metric data. When extracting and converting data, it is useful to conserve as much precision as possible.
Difference between measurements in days, or as precisely as possible – Growthcleanr-adults is not especially dependent on a precise starting age, and if an exact starting age in days is not known it is reasonable to estimate it. Relatively small differences in ages could affect whether certain values are excluded in the HT gain and loss steps, but this would likely affect a very small number of subjects. Growthcleanr-adults is more dependent on precise age intervals. The allowable differences between WTs change with the interval between the WTs, and the rate of this change is high over short intervals. If age intervals are not known to the day and must be estimated, the algorithm will likely be considerably less reliable for short intervals between WTs.
As many (actually measured) measurements as possible per subject – In general, the more measurements the better. For example, if a researcher is interested in data from 2015-2018 but has data from 2012-2020, growthcleanr-adults will clean the 2015-2018 data better if all the data is put into the algorithm, even if data from some years will later be excluded. An exception to the “more is better” rule is that measurements known to be carried forward from prior measurements should be excluded before running growthcleanr-adults. For example, if a HT is recorded during a telephone visit and is identical to a prior WT, it was likely not measured on that day. Excluding these measurements before running growthcleanr-adults will result in better data cleaning.
Many steps in the algorithm rely on an exponentially weighted moving average (EWMA – we pronounce it “yooma”). This is an average of all of a subject’s WT or HT values, weighted by how far a measurement is in days of age from the measurement of interest. Measurements closer in age are weighted much more heavily, and the influence of measurements farther away drops off fairly quickly. The EWMA is in some ways a predicted value for the WT or HT at a given age, given the other values for a subject. A WT or HT does not contribute to its own EWMA. There is also the EWMA-BEF, which is the EWMA excluding the value just before the value of interest, and the EWMA-AFT, the EWMA excluding the value just after the value of interest. For the first measurement for a subject EWMA-BEF is the same as the EWMA. Then there are the D-EWMA, D-EWMA-BEF, and D-EWMA-AFT, the differences between a WT or HT and the EWMAs for the same day. Often the sign of the D-EWMA doesn’t matter, so we focus on its absolute value, the absD-EWMA. In many steps, especially for WT, the D-EWMA is one of the criteria to determine if a value gets excluded. Often D-EWMA-BEF and D-EWMA-AFT are required as well, serving as extra checks to exclude only the correct measurements.
There are important differences in EWMA between growthcleanr-adults and growthcleanr -pediatrics. First, the parameters are different so that closer WTs/HTs are counted much more heavily in growthcleanr -adults. This is because of WT gain and loss, but the new parameters worked well for HT as well. Also, instead of making a EWMA of standard deviation scores, in adults we just make the EWMA of the raw WT or HT itself. So, the EWMAs and D-EWMAs are in kgs and cms, and the cutoffs are very different than for pediatrics.
One issue that came up repeatedly for WT is that with WT gain/loss, there would be values, including local mins/maxes, that looked plausible on inspection but would come up as implausible by EWMA criteria. One check in a late step that helped to avoid excluding these plausible values was extrapolating a WT using the two prior values (P1 and P2 are used to make P-Extrap-WT) or the two next values (N1 and N2 are used to make N-Extrap-WT). Then, the algorithm checks if the WT of interest (WTi) is between the further prior/next value and the extrapolated value (so if WTi is between P2 and P-Extrap-WT or if WTi is between N2 and N-Extrap-WT) with some allowable error on either side. Generally, if a WTi is between these values for either the prior or the next extrapolation it will not get excluded in this step through standard criteria (there may be alternate criteria it can meet).
An example of the extrapolation calculations is provided below:
| Agedays | WT | |
|---|---|---|
| P2 | 10000 | 61 |
| P1 | 10014 | 65 |
| WTi | 10028 | 72 |
| N1 | 10056 | 68 |
| N2 | 10112 | 58 |
Subject gained 4 kg in 14 days from P1 to P2
There are 14 days from P2 to WTi, so extrapolating would give 4 more kg on top of P2
P-Extrap-WT = 65+4 = 69
Allowable range for WTi is P2 to P-Extrap-WT (61-69) with 5 kg error on either side (56-74)
WTi (72) is within the allowable range, therefore, this WTi would not get excluded through standard criteria.
Subject “gained” 10 kg in 56 days from N2 to N1 (helps to think about this going back in time)
There are 28 days from N1 to WTi, and 28=56*0.5, so extrapolating would give 10*0.5 more kg on top of N1
N-Extrap-WT = 68+5 = 73
Allowable range for WTi is P2 to P-Extrap-WT (58-73) with 5 kg error on either side (53-78)
WTi (72) is within the allowable range; nothing changes because it was already ineligible to get excluded through standard criteria.
Note that not all steps are done for both HT and WT; this is indicated for each step in the left of the step title box.
Please note that although HT is evaluated in growthcleanr-adults in cm, it is often measured in inches. Many allowable HT errors are based on multiples of inches for this reason.
Each step is listed with its step number, its name, and exclusion output. If a new output variable is created, it will be listed in the text in bold.
Biologically implausible values. Excludes WT<20, WT>500, HT<50, HT>244. These are extremely broad limits on purpose. Keeping out of scale measurements in (WT=3000) can cause problems, but otherwise excluding very extreme measurements that are not in line with a person’s other measurements does not interfere with data cleaning. Very little is gained by making these numbers more conservative, and there is potential for removing plausible measurements.
In this step, WTs that are identical to another WT and are not the first WT of that identical group have EXC-WTR set to “RV”; the EXC-WT is still “INC”. Note this will sometimes be redone in future steps and will just be designated as “RV redone” in the body of the description. For WT we will discuss using firstRV, in which case we will only use the first of an RV group (excluding all with EXC-WT==”RV”). If we do this, and we exclude the first of an RV group, we generally exclude all subsequent members of the RV group. This ultimately results in a very small number of exclusions. For other steps we will use allRV. Either way, we need to update both EXC-WT and EXC-WTR at the end of each WT step.
We identify where there is more than one WT or HT for the same subject, parameter, and day of age (designated same days). For each day with same days, we select the value closest to the median WT or HT for that subject (not including any same days) and set all other same days to “temp extraneous”. Then RVs are redone for WT. This will often be redone in future steps and will be designated as “temp extraneous is redone” – this includes redoing WT RVs.
Some hospitals, vendors, or other data providers may place caps on elements of the data. It seems that a cap on the upper limit of weight is most likely to affect this algorithm. If the user enters a parameter indicating that there is a weight cap in the provided dataset, this step will do three things. If no weight cap is entered, the algorithm will skip to step 5. A) If a subject has all WTs equal to the cap, it will exclude all WTs and all HTs for that subject with code weight-cap-identical. B) If a subject has at least 1 WT equal to the cap, and that WT (or WTs) is not in line with the subject’s other WTs, it will exclude the WT(s) equal to the cap with code weight-cap. C) If a subject has at least 1 WT equal to the cap that IS in line with the subject’s other WT, then there is the concern that the capped WT is inaccurate, and the subject’s true WT is higher. In this case the WT(s) equal to the cap is/are retained. Temp extraneous is redone.
In this section, we will exclude WTs and HTs that meet criteria for certain special cases, such as unit errors. This helps us exclude some errors early that are relatively extreme but may be less extreme than we could exclude without the additional evidence provided by the special case data. These steps are most useful for WT but also can help for HT. In general, the special case steps involve comparing the recorded value with the same value transformed in a manner based on which special case is being tested. The recorded and transformed values are then compared with the values surrounding them using EWMA and by calculating the difference between the recorded/transformed values and the prior and next values. Criteria are developed for each type of special case. If the recorded value deviates from the surrounding values in a specific way AND the transformed value fits the surrounding values using fairly strict criteria, the special case is considered met and the recorded value is excluded. The method does not correct special cases, it just excludes them. FirstRV is used for all WT special case steps except for swaps. At the end of all special case steps (except swaps), if the first RV of a group is excluded, all other members of that RV group are excluded with an RV appended to their error code (e.g., EXC-WTR=”RV Hundreds”). At the end of each special case step, temp extraneous is redone.
This step evaluates whether there is evidence that the WT is off by 100 or 200 kg from the expected value (or off by 100, 200, or 300 lbs.), or if the HT is off by 100 cm below the expected value. For example, imagine subject A had WTs of 76kg, 78kg, 177kg, 76kg. Each of those 4 values would be tested for each type of hundred special case. When the 177 kg WT was tested, one transformed value would involve subtracting 100 kg, for a transformed value of 77kg which is in line with the other measurements. This WT of 177kg will therefore meet criteria to be excluded in the Hundreds step.
This step evaluates whether there is evidence that the WT is recorded in pounds when the dataset indicates it was recorded in kilograms, and or that HT is recorded in inches when the dataset indicates it was recorded in centimeters. For example, if subject B had HTs 170.2, 170.5, 67, 170.5, 170, the HT=67 (67*2.54=170.18) would be recognized as a unit error and excluded in this step. Again, firstRV is used for WT and allRV for HT.
This step evaluates whether there is evidence that 10s and 1s digit of HT or WT are transposed. For example, if subject C had WTs of 95, 94, 59, 96, 95.5, the recorded value would be 59 and the transformed value would be 95. The WT=59 would be excluded as a transposed WT in this step. One of the checks in the transpositions step is that the tens and ones digits have to be at least 3 apart to consider something a potential transposition. So, if subject D had WTs of 75 74 57 76 75.5, the WT=57 would not be excluded as a transposition.
This step evaluates whether there is evidence that the WT and HT are swapped with each other. This step only evaluates metric values; in other words, it does not evaluate the case in which there is a combination of unit errors and a swap. For example, if subject E had HTs of 164, 165, 72, 164, 164 and WTs on the same days of 73.1, 71, 165, 72.2, 73.2, the HT=72 and the WT=165 would be recognized and excluded as swaps. In order to compare as many HTs and WTs as possible, allRVs are used for WT. Other members of an RV group are not excluded at the end of a swaps step. Temp extraneous is redone for WT but not for HT, because the final extraneous step is the next step for HT.
This is the final step in which same day extraneous HTs (multiple HT measurements for the same subject on the same day) are evaluated. The criteria to keep a same day extraneous value are fairly strict. First, if all HTs on the same day are identical, one is set to be included and the rest are included. Then, it is determined if all HTs on the same day for a subject vary by a trivial amount (<1 inch). If so, the recorded values are replaced with the mean of the same day extraneous values for that day. The original values are stored in orig_wt_sde. Then, if more than 25% of days for a subject have same day extraneous values OR if there are adjacent days that have same day extraneous values, all remaining same day extraneous values for that subject are excluded. For remaining subjects with same day extraneous values, if there is 1 (and only
In this step, subjects for whom there are only 2 remaining distinct HTs are evaluated. So subject F with 2 different HTs (170, 171) and subject G with 8 HTs but only 2 distinct HTs (162, 162, 162, 163, 162, 162, 163, 162) are both evaluated in this step. In this step either all HTs or no HTs are excluded, because if it is determined that the pair of HTs is implausible it is generally too difficult to tell which of the pair should remain included. If both HTs are within 2 inches (5.08 cm) of each other, both HTs remain included. If the HTs are not within 2 inches of each other, they may stay if they meet loss or gain criteria. Loss criteria is primarily designed to identify people with a vertebral fracture and include a loss of HT that is below a limit based on whether the subject is under or over 50 years old AND whether the HT remains stable after the initial loss (for example 170, 170, 163, 163, 163 meets loss criteria but 170, 170, 163, 163, 170 does not). Gain criteria only apply to people with an initial age <25 years and allow HT gain that is dependent on the starting age and the age interval; gain criteria also require that the HT remains stable after the initial gain. The variables pairhtloss and pairhtgain indicate that values met the loss or gain criteria; these variables also facilitate calculation of meanht at the end of the algorithm.
In this step, subjects for whom there are 3 or more remaining distinct HTs. If all HTs are within a 2-inch range, they all remain included. Otherwise, the algorithm attempts to identify a band of HTs within 2 inches of each other that has at least 1.5x as many HTs as the # of HTs outside the band. If there are multiple bands of HTs that meet these criteria, the algorithm selects the band with the highest HT number score (score = total HTs within band + 0.5 * distinct HTs within band) with ties broken by a measure of the distance between the mean of the HTs within the band and the HTs within the band, with the goal of identifying the band that is most distinct from the HTs outside the band. If no band is identified, all HTs are excluded. If a band is identified, HTs outside the band are excluded. Then, in loss and gain steps, subjects with HTs excluded in this step may be reincluded if they meet specific criteria. The loss and gain criteria are similar to step 10H except that two separate episodes of HT loss are allowed, and up to 5 separate episodes of HT gain are allowed (all starting before age 25y). The variables htlossgroup and htgaingroup indicate that HTs were reallowed because of loss/gain criteria in this step and also indicate which HTs are grouped with which HTs. These variables also facilitate calculation of meanht at the end of the algorithm.
In this step a mean HT for each subject is calculated that can provide a more stable HT, particularly useful for BMI calculations. The mean was purposely chosen over the median in order to ensure to ensure weight is provided for more common measurements. All HTs that will be averaged will be within 2 inches of each other, so the difference between the mean and median, and between the mean and the recorded HT, will generally be small. For most subjects, meanht will simply be the mean of all HTs for that subject. Exceptions are described below. If HTs were kept in step 10H because of allowed loss or gain (pairhtloss is 1 or pairhtgain is 1), then there are only 2 distinct HTs, but they are identified as representing two separate states and should not be averaged, so each distinct HT serves as its own mean for these subjects. Similarly, if HTs were kept in step 11H because of allowed loss or gain (htlossgroup is 1-3 or htgaingroup is 1-6), then only HT values within each loss group or gain group should be averaged together.
In this step, EWMA is used to remove remaining extreme implausible measurements before choosing final same day extraneous values and excluding more moderate errors. Extreme EWMA is done first with firstRV and then with allRV because doing it with either alone missed important errors in some datasets. The cutoffs for absD-EWMA are >60 kg (so a value must be at least 60 kg from its EWMA or `predicted’ value) for WTs that are within one year of at least one other WT, and 100 kg from WTs that are not within one year of a WT. There are sometimes multiple extreme EWMA values within one subject, so the extreme EWMA steps are run multiple times excluding the most extreme value for each subject with each round until no values are excluded. The firstRV extreme EWMA step is run multiple times first, then the allRV extreme EWMA step is run multiple times. RVs are then redone.
This is the final step in which same day extraneous WTs (multiple WT measurements for the same subject on the same day) are evaluated. AllRV are used. The criteria to keep a same day extraneous value are fairly strict. First, if all WTs on the same day are identical, one is set to be included and the rest are included. Then, it is determined if all WTs on the same day for a subject vary by a trivial amount (<1 kg). If so, the recorded values are replaced with the mean of the same day extraneous values for that day. The original values are stored in orig_wt_sde. Then, if more than 25% of days for a subject have same day extraneous values OR if there are adjacent days that have same day extraneous values, all remaining same day extraneous values for that subject are excluded. For remaining subjects with same day extraneous values, the algorithm determines if there is 1 WT with an absD-EWMA<2 and that there is only 1 WT with an absD-EWMA<5. The goal here is to find one WT that `fits’ and confirm that the rest of the WTs do not `fit.’ If those criteria are met, the WT with an absD-EWMA<2 is included and the rest for that day are excluded as same day extraneous. If either of those criteria are not met, all same day extraneous values for that day are excluded. RVs are redone.
In this step the algorithm evaluates subjects with 2 remaining
distinct WTs that are in order so that all of one WT come before all of
another WT. As examples, 45, 45, 48, 48, 48 would be an ordered pair.
And 102, 107 would also be an ordered pair. But 81, 81, 74, 81, 74 would
not be an ordered pair. The amount that the WTs in an ordered pair are
allowed to differ is determined the by the difference in ages between
the last day of the distinct WT 1 and the first day of distinct WT 2.
The formula is
wtallow = 4 + 18 * ln(1 + ageinterval [in months])
. If the
absolute difference between WT1 and WT2 is below wtallow, all WTs stay
included. If the absolute difference is above wtallow, all WTs are
excluded. Very low WTs that are not consistent with a subject’s other WT
do not necessarily trigger the wtallow criteria; for this reason, a
limit on the percent change in WT for subjects with low WTs is also
added to this step.
In this step the algorithm evaluates subjects with 3 or more remaining distinct WTs or 2 remaining distinct WTs that are unordered (see distinct ordered pairs above for definition). AllRV are used. In this step, multiple additional checks are made to EWMA to avoid excluding WTs that are likely consistent with a subject who is gaining or losing WT. The primary additional checks that help to evaluate whether a WT is in line with a subject’s surrounding WTs are a) the extrapolation calculation described near the beginning of this document that evaluates whether a WT is within limits set by the surrounding values and an extrapolated value and b) a check called “interpolation” which simply checks if the WT of interest is between the WTs before and after it with some allowed error. If a WT is within the bounds of the extrapolation and/or interpolation checks, it cannot get excluded by meeting standard criteria and must meet special criteria. As in the distinct ordered pairs step, a limit on the percent change in weight for low WT values is added to this step. As in extreme EWMA, the moderate EWMA step is run multiple times, removing the most extreme implausible value in each run until no implausible values are removed.
In this step, which only runs if a weight cap was entered, if there are any WTs equal to the weight cap that are still included, all remaining included WTs for the subject will be set to “Exclude – Possibly Impacted by Weight Cap.” This is because a WT equal to the weight cap could mean the WT is the weight cap, or that it is substantially higher. (Please note the following examples only are in pounds.) For example, in a dataset with a weight cap of 400 lbs, in which WTs above 400 are reset to 400, subject M has WTs of 370, 395, 400, 400, 400, 390, 365, 340. If the WTs=400 are included as is, they would give the possibly false impression that M’s WT was stable at 400 during those three middle WTs, when M’s actual WT could have been 370, 395, 405, 420, 435, 390, 365, 340. But if the WTs equal to 400 were just excluded, M’s WT would appear to be 370, 395, 390, 365, 340, which is clearly inaccurate. Therefore, all of subject M’s WTs should be excluded. On the other hand, there are subjects with WTs equal to the WT cap that are out of line with a subject’s other WTs and were excluded earlier, such as if subject N’s WTs were 140, 145, 400, 148, 150, and the 400 were excluded in an earlier step. Therefore, it is okay to exclude the 400 and keep subject N’s other WTs. In order to identify subjects whose WTs were all excluded due to weight cap issues in step 4W, or whose remaining included WTs were all excluded in this step (12W), a variable all-exc-weight-cap is created that is TRUE or FALSE. Subjects with all WTs excluded due to the weight cap likely have severe obesity, or did at one point. The all-exc-weight-cap variable helps analysts identify these subjects in a dataset, even if their WT values cannot be determined precisely due to the weight cap. If desired, analysts can reinclude WTs for these subjects excluded because of weight caps to be reincluded.
In this step subjects with only one remaining distinct value for WT or HT, or both, are evaluated. BMI is calculated where possible to assist in providing evidence about whether a WT or HT is plausible or not. If a subject has at least one day on which a BMI can be calculated, and at least one BMI is between 16 and 60 (inclusive), then the following limits apply to parameters with only one distinct value: exclude HT<88, HT>231, WT<30, WT>273. If there is at least one BMI and no BMIs are between 16 and 60, then any HT or WT for which there is only one distinct value is excluded. For example, if the only BMIs are ~117, and the HTs are 68, 68, 68 and the WTs are 54, 53, 52, then the HTs would be excluded, and the WTs remain included. But if the only BMIs are ~117 and the HTs are 68, 68, 68 and the WTs are 54, 54, 54, then all HTs and all WTs are excluded. After these two steps, BMIs are recalculated and subjects with one distinct value are reidentified because the initial steps may have changed these results. Then, for subjects with no remaining BMI the following limits apply to parameters with only one distinct value: exclude HT<139, HT>206, WT<40, WT>225. It is very reasonable to consider adjusting these limits for specific projects, depending on your population(s) of interest.
In this step, subjects with a large proportion of HT or WT values for a parameter excluded are identified, and all HT or WT values for that subject are excluded, because a very high number of errors makes it difficult to make reliable decisions for all values for that subject. The error ratio is calculated as Errors/Total. Errors are everything that is not included, missing, or a same day extraneous or an included value. The total is everything that is not missing or a same day extraneous. If the error ratio is >0.4 all values for that parameter for that subject are excluded.


Sir Patrick Stewart
Rank: Admiral
Assignment: U.S.S. Enterprise NCC-1701-E
Full Name: Jean-Luc Picard
Date of birth: July 13, 2305
Place of birth: Labarre, France, Earth
Marital status: Single
Children: None
Quarters: Formerly, Enterprise: Deck 9, Room 3601
Office: Enterprise: Deck 1 Ready Room, adjoining Main Bridge
Kate Mulgrew
Rank: Admiral
Assignment: U.S.S. Voyager
Full Name: Kathryn Janeway
Home region: Indiana, North America, Earth
Birthday: May 20
Parents: Admiral Edward Janeway (d. 2358) and Gretchen Janeway
Siblings: One sister
Marital status: Single (once engaged)
Office: (2371-2378) U.S.S. Voyager, Deck 1 Ready Room adjoining Bridge
Avery Brooks
Full Name: Benjamin Lafayette Sisko
Year of birth: 2332
Place of birth: New Orleans, Earth
Parents: Mr. and Mrs. Joseph Sisko (update: it has been learned that Sisko was born to Sarah,
Joseph's first wife [d. 2336], but only knew his stepmother)
Marital status: (at time of disappearance) married to Kasidy Yates 2375; previously married to Jennifer Sisko (d. 2367)
Children: One son, Jake, born 2355; wife pregnant with second child as of 2375
Current status: MISSING IN ACTION, 2375 (last known whereabouts: Bajor)
Assignment: Deep Space Nine, U.S.S. Defiant


Thief threatens shopkeeper with knife before making off with crates of beer
The staff member at McColl's store on Calder Road refused to hand over cash.
by Lynn LoveA thief threatened a Bellshill shopkeeper with a knife and screwdriver before making off with two crates of beer.
The staff member at McColl's store on Calder Road refused to hand over the cash after the brazen robber threatened them at around 3.30pm on Sunday, November 3.
The suspect then left with two crates of beer and headed off in the direction of Rosevale Crescent .
He is described as male, of heavy build, wearing a dark hooded bubble style jacket with his hood up, denim jeans and brown boots.
Detective constable Gerry Hattie, of Wishaw CID , said: “The victim was uninjured as a result of this incident but has been left shaken.
“We are keen to speak to anyone who may have been in the area at the time of the robbery or may have seen a man matching this description.
“Anyone who has any information can contact Police Scotland on 101 quoting incident number 2572 of 3 November 2019."


Back Translation for Text Augmentation with Google Sheets
When working on Natural Language Processing applications such as Text Classification, collecting enough labeled examples for each category manually can be difficult. In this article, I will go over an interesting technique to augment your existing text data automatically called back translation.
Introduction to Back Translation
The key idea of back translation is very simple. We create augmented version of a sentence using the following steps:
- You take the original text written in English
- You convert it into another language (say French) using Google Translate
- You convert the translated text back into English using Google Translate
- Keep the augmented text if the original text and the back-translated text are different.
Figure: Back Translation
Using Back Translation in Google Sheets
We need a machine translation service to perform the translation to a different language and back to English. Google Translate is the most popular service for this purpose, but you need to get an API key to use it and it is a paid service.
Luckily, Google provides a handy feature in their Google Sheets web app, which we can leverage for our purpose.
Step 1: Load your data
Let’s assume we are building a sentiment analysis model and our dataset has sentences and their associated labels. We can load it into Google Sheets by importing the Excel/CSV file directly.
Step 2: Add a column to hold augmented data
Add a new column and use the GOOGLETRANSLATE()
function to translate from English to French and back to English.
The command to place in the column is
=GOOGLETRANSLATE(GOOGLETRANSLATE(A2, "en", "fr"), "fr", "en")
Once the command is placed, press Enter and you will see the translation.
Now, select the first cell of “Backtranslated” column and drag the small square at the bottom right side below to apply this formula over the whole column
This should apply to all your training texts and you will get back the augmented version.
Step 3: Filter out duplicated data
For texts where the original text and what get back from back translation
are the same, we can filter them out programmatically by comparing the original text column and the augmented column. Then, only keep responses that have True
value in the Changed
column.
Step 4: Export your data
You can download your data as a CSV file and augment your existing training data.
Example Sheet
Here is a Google Sheet demonstrating all the four steps above. You can refer to that and make a copy of it to test things out.
Conclusion
Back translation offers an interesting approach when you’ve small training data but want to improve the performance of your model.


Step 1:
Make sure that you have ledger running locally. This app will support ledger networks later on.
Step 2:
Go to Test Connection link and click on Test button. If you see a "successful" pop-up, you may proceed.
Step 3:
Go to Deploy Contract link. Click on Choose File and select adoption.etch from etch-demos Github.
The source code will automatically populate in textarea. Click Deploy, wait a few second, and you will see
a "deployed" page. Once there, put http://<IP_ADDRESS>:5000/ as link to go back to home page.
Step 4:
Go to Deploy Contract link. Repeat Step 3 but this time deploy hello.etch from etch-demos.
Step 5:
Go to Interact with Contract link. You should see the latest block info in the Ledger section. This will update
everytime you refresh the "/interact" page. You will also see the all the contract names you deployed in the dropdown
to the right of "Select Contract:". Each contract has an owner (type Entity), which you can find the dropdown to the
to the right of "Select entity to execute function:". They will automatically update with each new deployed contract.
Step 6:
To add a new non-owner Entity, type in the Entity name in the textbox in the Entity section and click the Add button.
Once you go back to the "/interact" page, the new Entity name will appear in the dropdown.
Step 7:
By default, in the Contract Section, the selected contract is "hello", selected action is "@query", and selected
function is "persistentGreeting". If that is the case, feel free the press the Execute button without touching the
[tx fee] or [arg1] textboxes. You should see a new page with "Hello World!" as that is the current result of the
persistentGreeting function from the hello.etch contract you have deployed onto the ledger.
Note:
This app is still WIP. For example, it does not support @action function. The next step is for the "/interact" page to
to dynamically update whenever the user changes a dropdown value in the Contract Section.
Back to Home


Scientists engineer 'Venus flytrap' bio-sensors to snare pollutants
| Source: | Trinity College Dublin |
| Summary: | The biological sensors change color once they have successfully snared a target molecule, and will soon have a host of important environmental, medical and security applications. |
Scientists from Trinity College Dublin have created a suite of new biological sensors by chemically re-engineering pigments to act like tiny Venus flytraps. The sensors are able to detect and grab specific molecules, such as pollutants, and will soon have a host of important environmental, medical and security applications.
Porphyrins, a unique class of intensely coloured pigments — also known as the "pigments of life" — provide the key to this ground-breaking innovation.
The word porphyrin is derived from the Greek word porphura, meaning purple, and the first chapter detailing the medical-chemical history of porphyrins goes back to the days of Herodotus (circa 484 to 425 BC). This tale has been progressing ever since and is at the heart of Professor Mathias O. Senge's work at Trinity.
In living organisms, porphyrins play an important role in metabolism, with the most prominent examples being heme (the red blood cell pigment responsible for transporting oxygen) and chlorophyll (the green plant pigment responsible for harvesting light and driving photosynthesis).
In nature, the active versions of these molecules contain a variety of metals in their core, which gives rise to a set of unique properties.
The researchers at Trinity, under the supervision of Professor Mathias O. Senge, Chair of Organic Chemistry, chose a disruptive approach of exploring the metal-free version of porphyrins. Their work has created an entirely new range of molecular receptors.
By forcing porphyrin molecules to turn inside out, into the shape of a saddle, they were able to exploit the formerly inaccessible core of the system. Then, by introducing functional groups near the active centre they were able to catch small molecules — such as pharmaceutical or agricultural pollutants, for example pyrophosphates and sulphates — and then hold them in the receptor-like cavity.
Porphyrins are colour-intense compounds so when a target molecule is captured this results in the colour changing drastically. This underlines the value of porphyrins as bio-sensors because it is clear when they have successfully captured their targets.
Karolis Norvaiša, an Irish Research Council-funded PhD Researcher at Trinity, and first author of the study, said:
"These sensors are like Venus flytraps. If you bend the molecules out of shape, they resemble the opening leaves of a Venus flytrap and, if you look inside, there are short stiff hairs that act as triggers. When anything interacts with these hairs, the two lobes of the leaves snap shut."
"The peripheral groups of the porphyrin then selectively hold suitable target molecules in place within its core, creating a functional and selective binding pocket, in exactly the same way as the finger-like projections of Venus flytraps keep unfortunate target insects inside."
The discovery was recently published in the print version of the leading international journal Angewandte Chemie International Edition and is featured as a hot paper. It has also been selected as the journal's cover illustration.
The work highlights the beginning of an EU-wide H2020 FET-OPEN project called INITIO, which aims to detect and remove pollutants. The work was made possible by initial funding from Science Foundation Ireland and an August-Wilhelm Scheer guest professorship award for Professor Senge at the Technical University of Munich.
Professor Senge added:
"Gaining an understanding of the porphyrin core's interactions is an important milestone for artificial porphyrin-based enzyme-like catalysts. We will slowly but surely get to the point where we can realise and utilise the full potential of porphyrin-substrate interfaces to remove pollutants, monitor the state of the environment, process security threats, and deliver medical diagnostics."
make a difference: sponsored opportunity
Story Source:
Materials provided by Trinity College Dublin.
Note: Content may be edited for style and length.
Journal Reference:
- Karolis Norvaiša, Keith J. Flanagan, Dáire Gibbons, Mathias O. Senge. Conformational Re-engineering of Porphyrins as Receptors with Switchable N−H⋅⋅⋅X-Type Binding Modes. Angewandte Chemie International Edition, 2019; 58 (46): 16553 DOI: 10.1002/anie.201907929
Cite This Page:
| MLA | Trinity College Dublin. "Scientists engineer 'Venus flytrap' bio-sensors to snare pollutants." ScienceDaily. ScienceDaily, 19 November 2019. <www.sciencedaily.com/releases/2019/11/191119105444.htm>. |
| APA | Trinity College Dublin. (2019, November 19). Scientists engineer 'Venus flytrap' bio-sensors to snare pollutants. ScienceDaily. Retrieved November 19, 2019 from www.sciencedaily.com/releases/2019/11/191119105444.htm |
| Chicago | Trinity College Dublin. "Scientists engineer 'Venus flytrap' bio-sensors to snare pollutants." ScienceDaily. www.sciencedaily.com/releases/2019/11/191119105444.htm (accessed November 19, 2019). |


React Native¶
The React Native environment has a lot of little quirks, so this documentation is aimed at helping smooth those over.
Please feel free to create issues on GitHub for recommendations and additions to this document.
Shims¶
There are several pieces of functionality missing from the current version
of React-Native. Here is a list of functionality the ethers/dist/shims
will
provide if unavailable:
ArrayBuffer.isView
atob
andbtoa
nextTick
Promise
String.prototype.normalize
// Import the required shims
import 'ethers/dist/shims.js';
// Import the ethers library
import { ethers } from 'ethers';
- Note
- This file must be minified, since the React-Native
require
seems to hijack the variable namerequire
, even when encapsulated inside a closure. The minification process replaces therequire
with a mangled name, so that there is no collision. This is hacky and in the future a better method would be preferred. Suggestions? - Note
- As we find additional features not generally available, they will be added to this shim file. It is targetted toward platforms where build-size is not critical, so functionality is favored over keeping the size small.
Wordlists¶
React-Native will pull in the browser version of ethers, which does not have all the additional word lists, by default. Each desired wordlist must be separately imported.
import {
es, // Spanish
fr, // French
it, // Italian
ja, // Japanese
ko, // Korean
zh_ch, // Chinese (simplified)
zh_tw // Chinese (tranditional)
} from 'ethers/wordlists';
Other Notes¶
- console.log
- The use of
console.log
in React Native can substantially impact performance. For this reason, you may wish to reduce the log level to not show info and warnings.
// The default is "info"; other options
// "debug", "info", "warn", "error", "off"
ethers.errors.setLogLevel("error");
TODO: Include instructions on installing crypto performance
- scrypt (it is VERY slow in React Native; too slow to be functional)


Tale of a Tesla and a wife - It's All About . . .
by Mark Jennings-BatesIf you want to test your marriage and your Tesla, this may be the way to do it.
A husband recently tested his Tesla by driving at speed toward his wife in autonomous mode to see if it would stop in time as she crossed the road.
At 30 km-h, the car stopped just before killing his wife. She perhaps was drawing up the divorce papers a the same time.
Mind you that could have been the next time when they tried again but at 20 km-h and this time the Tesla did not even attempt to brake. Thankfully, the dutiful husband covered the brakes and missed his wife.
Later, the husband claimed the reason for the supposed error on the Tesla on the slower test was because his wife was walking too slowly.
I’m sure the divorce papers are now filed.
All the posted videos of the event have been blocked since articles started to share the video of a husband almost killing his wife.
Of course, it goes without saying (or maybe none in this day and age) that you should not try this — stupid idea.
It goes to show how early we are on the curve of suggesting that autonomous vehicles are right around the corner, which will likely appear about as quickly as eVTOLS (electric vertical take-off and landing).
Interestingly, the Malaysian Civil Aviation Authority took steps today to cancel a planned attempt to demonstrate Malaysia’s eVTOL product because the company had no authority to do so, not even attempting to obtain the correct permits.
It is the first of many push backs from global aviation regulators as disruptive entrepreneurs misunderstand the requirement to follow aviation regulations in development of their products.
How do you know what is real and what is not in our fast cycled news media? Do the research and think critically.


Restaurant Passport
Restaurant
Passport
Keep track of the local spots you've been to by stamping each restaurant on your Restaurant Passport.
Get the scoop on local hidden gems.
Be the first friends to try new foodie bliss.
Save your favorite restaurants and dishes.
Thai Palace
Dirty Dog
New France
Great Greens
Flame Kabob


QuipEngineerNovember 2012 to Present |
Did (and doing) many things. The Quip category of my blog has some details. |
|
August 2004 to November 2012 |
Google Chrome (2010-2012)
Google Reader (2005-2010)
AdWords Frontend (2004-2005)
|
VMware.Performance Group - InternJune to August 2003 |
|
MicrosoftPicture It!/MSN Photos - InternJune to September 2002 |
|
OIT - WebMediaWeb SpecialistFebruary 2001 to June 2004 |
|
The Daily PrincetonianWeb Department - Online EditorSeptember 2000 to January 2004 |
|
Mscape SoftwareSeptember 1998 to June 2004 |
|


This is a redesign of UCSD's study abroad website. The website redesign was done with design processes learned in Cogs 187a class at UCSD.


Popup dialog boxes for Bootstrap.
Available via npm
Available via bower
AMD support: require.js
BootPopup is a JavaScript library intended to simplify the task of creating Bootstrap modals.
Check out the examples to see how easy it is!
You can download and extract the archive into your project folder, or
Install BootPopup through npm (or bower if you are using it) with:
npm install --save bootpopup
Then, include BootPopup in your HTML document. BootPopup requires jQuery and Bootstrap:

<link rel="stylesheet" type="text/css" href="node_modules/bootstrap/dist/css/bootstrap.min.css" />

See the full documentation about how to use BootPopup in the API section on GitHub
A simple alert:
bootpopup.alert("You are now alerted by this message!");
An alert with custom title:
bootpopup.alert("You are now alerted by this message with a custom title!", "You are alerted");
A simple confirm:
bootpopup.confirm("Do you confirm this message?");
A confirm with a custom title:
bootpopup.confirm("Do you confirm this message with a custom title?", "Confirm this message");
A confirm with a callback and response:
bootpopup.confirm("Do you confirm this message?", "Confirm this message", function(ans) { alert(ans); });
Or if you want a callback without a custom title:
bootpopup.confirm("Do you confirm this message with a callback?", function(ans) { alert(ans); });
A simple prompt:
bootpopup.prompt("Name");
A prompt with a custom type of data. This corresponds to HTML input types:
bootpopup.prompt("Age", "number");
A prompt with a custom message:
bootpopup.prompt("Text", null, "Insert a random text:");
Or if you want a callback without a custom title and message:
bootpopup.prompt("Text", function(data) { alert(data); });
You can also request multiple values at same time, providing a list of values to input:
bootpopup.prompt([
{ label: "A text"},
{ label: "A number", type: "number"},
{ label: "A boolean", type: "checkbox", name: "boolean"}
],
function(data) { alert(JSON.stringify(data)); }
);
BootPopup is also highly customizable, you can create a list of items to display very quickly. Then, you can pick up the entered data from the callback very easily:
bootpopup({
title: "Add image",
size: "large",
size_labels: "col-sm-2",
size_inputs: "col-sm-10",
content: [
{ p: {text: "Insert image info here:"}},
{ input: {type: "text", label: "Title", name: "title", id: "title", placeholder: "Description for image", value: "Woman picking flowers"}},
{ url: {label: "Link", name: "link", id: "link", placeholder: "Hyperlink for image", value: "http://hmp.me/3lv"}},
{ checkbox: {label: "Add border to the image", name: "border", id: "border"}},
{ button: {name: "button", value: "Open image", class: "btn btn-info", onclick: function() {
bootpopup({
title: $('#title').val(),
content: [ { img: {src: $('#link').val()}} ],
before: function(window) {
if($("#border").prop("checked"))
$("#image").attr("style", "border: 10px solid red");
}
});
}
}}],
before: function(window) { alert("Before"); },
dismiss: function(event) { alert("Dismiss"); },
cancel: function(data, array, event) { alert("Cancel"); },
ok: function(data, array, event) { alert("OK\n" + JSON.stringify(data)); },
complete: function() { alert("Complete"); },
});
If the provided functionality is not enough for your case, you can simply mix your HTML:
bootpopup({
title: "Custom HTML",
content: [
'
BootPopup
',
'
Popup dialog boxes for Bootstrap.
',
'BootPopup is a JavaScript library intended to simplify the task of creating Bootstrap modals',
'
Check out the examples to see how easy it is!
',
'Give us a rate 1-10:',
{ input: {type: "number", label: "Rate", name: "rate", value: "11"}}],
cancel: function(data, array, event) { alert("Cancel"); },
ok: function(data, array, event) { alert("OK\n" + JSON.stringify(data)); },
complete: function() { alert("Complete"); },
});


As a native Calgarian, I was always exposed to the Oil and Gas industry. As such, I attended the University of Alberta, completing a Bachelor of Science in Geology in 2013. The end of my degree coincided with the economic downturn and after struggling in the oil and gas industry for a few years, I decided to pursue my interest in architecture.
In fall of 2016 I began the Architectural Technologies program at SAIT. I greatly enjoyed the classes, and was lucky enough to gain summer employment at Stantec in 2017. This experience was invaluable as I gained industry skills and knowledge, contacts and a clearer view of my career goals.
In my spare time I enjoy spending time in the mountains with my dog, traveling with my husband, and experimenting with my cooking skills. You can often find me stuck in a good book, enjoying board games, or playing volleyball and slo-pitch with friends.


Roukia Salahi
'm Roukia, Syrian currently living in Jordan. I have a bachelor degree in civil engineering and
now
I am taking courses in software development by ASAC.
Yahya AbuKhaleel
Lorem, ipsum dolor sit amet consectetur adipisicing elit. Ipsam provident consectetur ullam
praesentium dolor doloribus architecto harum? Tempore quas,
Daoud Nazek
Lorem, ipsum dolor sit amet consectetur adipisicing elit. Ipsam provident consectetur ullam
praesentium dolor doloribus architecto harum? Tempore quas,
Rania Qatawneh
Rania from Jordan-20 years old, bachelor in physics, currently a student at ASAC to learn
programming.
Ahmad Alhrthani
My name is Ahmad Alherthani. I am doing my master's degree in in Computer Science. During my
masters
study, I won a mobility scholarship to TUWIEN. I worked as a freelance IT specialist for 10
years. I
have a good experience in web development using HTML,CSS and JavaScript
Interactive Learning Experience
play & learn is an edtech proof of concept to capture student attention and study their curriculum along
the journey.
play & learn encompass many random aspects of what "learning" might mean in the webspace, ranging from
simple quizzes to gamified learning experiences such as flashcards and hangman.


Test
Scoring method:
REGULAR
SQUARE
Dictionary:
Generate new game
Start
Start multiplayer
Load
Page header
Side bar


Scope
{{ latest_landing.scope | markdownify }}
{{ latest_landing.background | markdownify }}
This year, we bring you the BioHackathon in a virtual fashion. This 9-13 November, we will put online platforms to the test to bring you a fun and productive event — we will be using Remo & SLACK!
We believe the new format will allow everyone to participate in the BioHackathon and deliver tangible outcomes from the selected projects.
While the BioHackathon is going virtual, seats are limited and registration is based on a first-come, first-served basis. Don’t miss your chance to attend this year and register before 18 September 2020.
{{ latest_landing.scope | markdownify }}


Have I Been Pwned: Check if your email has been compromised in a data breach Have I Been Pwned allows you to search across multiple data breaches to see if your email address has been compromised.
Dutch Reach Project – A site to promote the Dutch far-hand habit to avoid dooring cyclists, or drivers or passengers from stepping into on-coming traffic. A site to promote the safer far-hand Dutch Reach habit to get out of your car. It prevents dooring 'accidents' / crashes that injure & kill bicyclists. You too are safer because you naturally turn & see on-coming traffic before and as you exit.
Open source is only ajar without inclusion – Internet Citizen If open source accelerates innovation and if “open” is fundamentally about access, empowerment and participation, then it's clear that we’re failing.
The Functional Scala Concurrency Challenge A fun little challenge to improve your skills using FP for concurrency.


More Information and some other websites of mine, many also primitive.
FergBlocked, old project of mine.
Dumb nonfuctional cookie clicker.


We guarantee to meet deadlines for transcript delivery and to achieve 98% accuracy on clear recordings.
Your audio file is encrypted using SSL/TLS protocol making secure intenet communication and your files will be deleted automatically within 48hrs upon receiving.
In addition to converting your audio to a text file, we offer free text analysis tools to help you quickly capture more value of your data.


File formats recognized by the ORR include: RDF/XML, JSON-LD, Notation3, N-Triples, Turtle, OWL/XML, RDF/JSON.
{{vm | json}}


Current view:
top level
- src
Date:
2021-01-15 00:23:12
Hit
Total
Coverage
Lines
14
15
93.3 %
Functions
2
3
66.7 %
Branches
0
0
0.0 %
Filename
Line Coverage
Functions
Branches
main.rs
93.3%
14 / 15
66.7%
2 / 3
0.0%
0 / 0


|
e-puck
1.0
|
Manage LSM330 (accelerometer + gyro) registers. More...
#include "../I2C/e_I2C_protocol.h"
#include "e_lsm330.h"
#include "../uart/e_uart_char.h"
#include "string.h"
#include "stdio.h"
Macros | |
| #define | ACC_ADDR 0x3C |
| #define | GYRO_ADDR 0xD4 |
Functions | |
| void | writeReg (unsigned char addr, unsigned char reg, unsigned char value) |
| Set the register reg to value. More... | |
| unsigned char | readReg (unsigned char addr, unsigned char reg) |
| Read the register reg. More... | |
| char | readRegMulti (char device_add, unsigned char *read_buffer, char start_address, unsigned char numBytes) |
| Continuous read (multiple register reading). More... | |
| void | initAccAndGyro (void) |
| Configure and turn on the device. More... | |
| void | getAllAxesAccRaw (unsigned char *arr) |
| void | getAllAxesAcc (signed int *x, signed int *y, signed int *z) |
| int | getXAxisAcc () |
| int | getYAxisAcc () |
| int | getZAxisAcc () |
| void | getAllAxesGyroRaw (unsigned char *arr) |
| void | getAllAxesGyro (signed int *x, signed int *y, signed int *z) |
| int | getXAxisGyro () |
| int | getYAxisGyro () |
| int | getZAxisGyro () |
| signed char | getTemperature (void) |
| void | calibrateGyroscope (int numSamples) |
| float | rawToDps (int value) |
| Raw value to degrees per second. Take as input the 2's complement value received by the device for a certain axis and return the degrees per second (knowing the gyroscope is configured with sensitivity of +- 250 dps). More... | |
| float | rawToDpms (int value) |
| Raw value to degrees per millisecond. Take as input the 2's complement value received by the device for a certain axis and return the degrees per millisecond (knowing the gyroscope is configured with sensitivity of +- 250 dps). More... | |
Variables | |
| signed int | gyroOffsetX = 0 |
| signed int | gyroOffsetY = 0 |
| signed int | gyroOffsetZ = 0 |
Manage LSM330 (accelerometer + gyro) registers.
x, y axes representation on HWRev < 1.3 (analog accelerometer MMA7260): FORWARD ^ | (-y)
y, y axes representation on HWRev 1.3 (i2c device LSM330): FORWARD ^ | (+x)
Thus the x and y axes are exchanged to maintain compatibility.
| #define ACC_ADDR 0x3C |
| #define GYRO_ADDR 0xD4 |
| void calibrateGyroscope | ( | int | numSamples | ) |
| void getAllAxesAcc | ( | signed int * | x, |
| signed int * | y, | ||
| signed int * | z | ||
| ) |
| void getAllAxesAccRaw | ( | unsigned char * | arr | ) |
| void getAllAxesGyro | ( | signed int * | x, |
| signed int * | y, | ||
| signed int * | z | ||
| ) |
| void getAllAxesGyroRaw | ( | unsigned char * | arr | ) |
| signed char getTemperature | ( | void | ) |
| int getXAxisAcc | ( | ) |
| int getXAxisGyro | ( | ) |
| int getYAxisAcc | ( | ) |
| int getYAxisGyro | ( | ) |
| int getZAxisAcc | ( | ) |
| int getZAxisGyro | ( | ) |
| void initAccAndGyro | ( | void | ) |
Configure and turn on the device.
| float rawToDpms | ( | int | value | ) |
Raw value to degrees per millisecond. Take as input the 2's complement value received by the device for a certain axis and return the degrees per millisecond (knowing the gyroscope is configured with sensitivity of +- 250 dps).
| float rawToDps | ( | int | value | ) |
Raw value to degrees per second. Take as input the 2's complement value received by the device for a certain axis and return the degrees per second (knowing the gyroscope is configured with sensitivity of +- 250 dps).
| unsigned char readReg | ( | unsigned char | addr, |
| unsigned char | reg | ||
| ) |
Read the register reg.
| addr | The device address |
| reg | The register address |
| char readRegMulti | ( | char | device_add, |
| unsigned char * | read_buffer, | ||
| char | start_address, | ||
| unsigned char | numBytes | ||
| ) |
Continuous read (multiple register reading).
| device_add | The device address |
| read_buffer | the buffer that will contain the values read from the registers |
| reg | The register start address |
| void writeReg | ( | unsigned char | addr, |
| unsigned char | reg, | ||
| unsigned char | value | ||
| ) |
Set the register reg to value.
| addr | The device address |
| reg | The register address |
| value | The value to write |
| signed int gyroOffsetX = 0 |
| signed int gyroOffsetY = 0 |
| signed int gyroOffsetZ = 0 |


请参阅: 说明
| 接口 | 说明 |
|---|---|
| Advisor |
Base interface holding AOP advice (action to take at a joinpoint)
and a filter determining the applicability of the advice (such as
a pointcut).
|
| AfterAdvice |
Common marker interface for after advice,
such as
AfterReturningAdvice and ThrowsAdvice . |
| AfterReturningAdvice |
After returning advice is invoked only on normal method return, not if an
exception is thrown.
|
| BeforeAdvice |
Common marker interface for before advice, such as
MethodBeforeAdvice . |
| ClassFilter |
Filter that restricts matching of a pointcut or introduction to
a given set of target classes.
|
| DynamicIntroductionAdvice |
Subinterface of AOP Alliance Advice that allows additional interfaces
to be implemented by an Advice, and available via a proxy using that
interceptor.
|
| IntroductionAdvisor |
Superinterface for advisors that perform one or more AOP introductions.
|
| IntroductionAwareMethodMatcher |
A specialized type of
MethodMatcher that takes into account introductions
when matching methods. |
| IntroductionInfo |
Interface supplying the information necessary to describe an introduction.
|
| IntroductionInterceptor |
Subinterface of AOP Alliance MethodInterceptor that allows additional interfaces
to be implemented by the interceptor, and available via a proxy using that
interceptor.
|
| MethodBeforeAdvice |
Advice invoked before a method is invoked.
|
| MethodMatcher |
Part of a
Pointcut : Checks whether the target method is eligible for advice. |
| Pointcut |
Core Spring pointcut abstraction.
|
| PointcutAdvisor |
Superinterface for all Advisors that are driven by a pointcut.
|
| ProxyMethodInvocation |
Extension of the AOP Alliance
MethodInvocation
interface, allowing access to the proxy that the method invocation was made through. |
| RawTargetAccess |
Marker for AOP proxy interfaces (in particular: introduction interfaces)
that explicitly intend to return the raw target object (which would normally
get replaced with the proxy object when returned from a method invocation).
|
| SpringProxy |
Marker interface implemented by all AOP proxies.
|
| TargetClassAware |
Minimal interface for exposing the target class behind a proxy.
|
| TargetSource |
A
TargetSource is used to obtain the current "target" of
an AOP invocation, which will be invoked via reflection if no around
advice chooses to end the interceptor chain itself. |
| ThrowsAdvice |
Tag interface for throws advice.
|
| 异常错误 | 说明 |
|---|---|
| AopInvocationException |
Exception that gets thrown when an AOP invocation failed
because of misconfiguration or unexpected runtime issues.
|
Any AOP Alliance MethodInterceptor is usable in Spring.
Spring AOP also offers:
Spring AOP can be used programmatically or (preferably) integrated with the Spring IoC container.


JSON Save Game Example
Many games provide save functionality, so that the player's progress through the game can be saved and loaded at a later time. The process of saving a game generally involves serializing each game object's member variables to a file. Many formats can be used for this purpose, one of which is JSON. With QJsonDocument, you also have the ability to serialize a document in a binary format, which is great if you don't want the save file to be readable, or if you need to keep the file size down.
In this example, we'll demonstrate how to save and load a simple game to and from JSON and binary formats.
The Character Class
The Character class represents a non-player character (NPC) in our game, and stores the player's name, level, and class type.
It provides read() and write() functions to serialise its member variables.
class Character { public: enum ClassType { Warrior, Mage, Archer }; Character(); Character(const QString &name, int level, ClassType classType); QString name() const; void setName(const QString &name); int level() const; void setLevel(int level); ClassType classType() const; void setClassType(ClassType classType); void read(const QJsonObject &json); void write(QJsonObject &json) const; private: QString mName; int mLevel; ClassType mClassType; };
Of particular interest to us are the read and write function implementations:
void Character::read(const QJsonObject &json) { mName = json["name"].toString(); mLevel = json["level"].toDouble(); mClassType = ClassType(qRound(json["classType"].toDouble())); }
In the read() function, we assign Character's members values from the QJsonObject argument. You can use either QJsonObject::operator[]() or QJsonObject::value() to access values within the JSON object; both are const functions and return QJsonValue::Undefined if the key is invalid. We could check if the keys are valid before attempting to read them with QJsonObject::contains(), but we assume that they are.
void Character::write(QJsonObject &json) const { json["name"] = mName; json["level"] = mLevel; json["classType"] = mClassType; }
In the write() function, we do the reverse of the read() function; assign values from the Character object to the JSON object. As with accessing values, there are two ways to set values on a QJsonObject: QJsonObject::operator[]() and QJsonObject::insert(). Both will override any existing value at the given key.
Next up is the Level class:
class Level { public: Level(); const QList<Character> &npcs() const; void setNpcs(const QList<Character> &npcs); void read(const QJsonObject &json); void write(QJsonObject &json) const; private: QList<Character> mNpcs; };
We want to have several levels in our game, each with several NPCs, so we keep a QList of Character objects. We also provide the familiar read() and write() functions.
void Level::read(const QJsonObject &json) { mNpcs.clear(); QJsonArray npcArray = json["npcs"].toArray(); for (int npcIndex = 0; npcIndex < npcArray.size(); ++npcIndex) { QJsonObject npcObject = npcArray[npcIndex].toObject(); Character npc; npc.read(npcObject); mNpcs.append(npc); } }
Containers can be written and read to and from JSON using QJsonArray. In our case, we construct a QJsonArray from the value associated with the key "npcs"
. Then, for each QJsonValue element in the array, we call toObject() to get the Character's JSON object. The Character object can then read their JSON and be appended to our NPC list.
Note: Associate containers can be written by storing the key in each value object (if it's not already). With this approach, the container is stored as a regular array of objects, but the index of each element is used as the key to construct the container when reading it back in.
void Level::write(QJsonObject &json) const { QJsonArray npcArray; foreach (const Character npc, mNpcs) { QJsonObject npcObject; npc.write(npcObject); npcArray.append(npcObject); } json["npcs"] = npcArray; }
Again, the write() function is similar to the read() function, except reversed.
Having established the Character and Level classes, we can move on to the Game class:
class Game { public: Game(); enum SaveFormat { Json, Binary }; const Character &player() const; const QList<Level> &levels() const; void newGame(); bool loadGame(SaveFormat saveFormat); bool saveGame(SaveFormat saveFormat) const; void read(const QJsonObject &json); void write(QJsonObject &json) const; private: Character mPlayer; QList<Level> mLevels; };
First of all, we define the SaveFormat
enum. This will allow us to specify the format in which the game should be saved: Json
or Binary
.
Next, we provide accessors for the player and levels. We then expose three functions: newGame(), saveGame() and loadGame().
The read() and write() functions are used by saveGame() and loadGame().
void Game::newGame() { mPlayer = Character(); mPlayer.setName(QStringLiteral("Hero")); mPlayer.setClassType(Character::Archer); mPlayer.setLevel(15); mLevels.clear(); Level village; QList<Character> villageNpcs; villageNpcs.append(Character(QStringLiteral("Barry the Blacksmith"), 10, Character::Warrior)); villageNpcs.append(Character(QStringLiteral("Terry the Trader"), 10, Character::Warrior)); village.setNpcs(villageNpcs); mLevels.append(village); Level dungeon; QList<Character> dungeonNpcs; dungeonNpcs.append(Character(QStringLiteral("Eric the Evil"), 20, Character::Mage)); dungeonNpcs.append(Character(QStringLiteral("Eric's Sidekick #1"), 5, Character::Warrior)); dungeonNpcs.append(Character(QStringLiteral("Eric's Sidekick #2"), 5, Character::Warrior)); dungeon.setNpcs(dungeonNpcs); mLevels.append(dungeon); }
To setup a new game, we create the player and populate the levels and their NPCs.
void Game::read(const QJsonObject &json) { mPlayer.read(json["player"].toObject()); mLevels.clear(); QJsonArray levelArray = json["levels"].toArray(); for (int levelIndex = 0; levelIndex < levelArray.size(); ++levelIndex) { QJsonObject levelObject = levelArray[levelIndex].toObject(); Level level; level.read(levelObject); mLevels.append(level); } }
The first thing we do in the read() function is tell the player to read itself. We then clear the levels list so that calling loadGame() on the same Game object twice doesn't result in old levels hanging around.
We then populate the level list by reading each Level from a QJsonArray.
void Game::write(QJsonObject &json) const { QJsonObject playerObject; mPlayer.write(playerObject); json["player"] = playerObject; QJsonArray levelArray; foreach (const Level level, mLevels) { QJsonObject levelObject; level.write(levelObject); levelArray.append(levelObject); } json["levels"] = levelArray; }
We write the game to JSON similarly to how we write Level.
bool Game::loadGame(Game::SaveFormat saveFormat) { QFile loadFile(saveFormat == Json ? QStringLiteral("save.json") : QStringLiteral("save.dat")); if (!loadFile.open(QIODevice::ReadOnly)) { qWarning("Couldn't open save file."); return false; } QByteArray saveData = loadFile.readAll(); QJsonDocument loadDoc(saveFormat == Json ? QJsonDocument::fromJson(saveData) : QJsonDocument::fromBinaryData(saveData)); read(loadDoc.object()); return true; }
When loading a saved game in loadGame(), the first thing we do is open the save file based on which format it was saved to; "save.json"
for JSON, and "save.dat"
for binary. We print a warning and return false
if the file couldn't be opened.
Since QJsonDocument's fromJson() and fromBinaryData() functions both take a QByteArray, we can read the entire contents of the save file into one, regardless of the save format.
After constructing the QJsonDocument, we instruct the Game object to read itself and then return true
to indicate success.
bool Game::saveGame(Game::SaveFormat saveFormat) const { QFile saveFile(saveFormat == Json ? QStringLiteral("save.json") : QStringLiteral("save.dat")); if (!saveFile.open(QIODevice::WriteOnly)) { qWarning("Couldn't open save file."); return false; } QJsonObject gameObject; write(gameObject); QJsonDocument saveDoc(gameObject); saveFile.write(saveFormat == Json ? saveDoc.toJson() : saveDoc.toBinaryData()); return true; }
Not surprisingly, saveGame() looks very much like loadGame(). We determine the file extension based on the format, print a warning and return false
if the opening of the file fails. We then write the Game object to a QJsonDocument, and call either QJsonDocument::toJson() or to QJsonDocument::toBinaryData() to save the game, depending on which format was specified.
We are now ready to enter main():
int main(int argc, char *argv[]) { QCoreApplication app(argc, argv); Game game; game.newGame(); // Game is played; changes are made...
Since we're only interested in demonstrating serialization of a game with JSON, our game is not actually playable. Therefore, we only need QCoreApplication and have no event loop. We create our game and assume that the player had a great time and made lots of progress, altering the internal state of our Character, Level and Game objects.
if (!game.saveGame(Game::Json)) return 1; if (!game.saveGame(Game::Binary)) return 1; Game fromJsonGame; if (!fromJsonGame.loadGame(Game::Json)) return 1; Game fromBinaryGame; if (!fromBinaryGame.loadGame(Game::Binary)) return 1; return 0; }
When the player has finished, we save their game. For demonstration purposes, we serialize to both JSON and binary. You can examine the contents of the files in the same directory as the executable, although the binary save file will contain some garbage characters (which is normal).
To show that the saved files can be loaded again, we call loadGame() for each format, returning 1
on failure. Assuming everything went well, we return 0
to indicate success.
That concludes our example. As you can see, serialization with Qt's JSON classes is very simple and convenient. The advantages of using QJsonDocument and friends over QDataStream, for example, is that you not only get human-readable JSON files, but you also have the option to use a binary format if it's required, without rewriting any code.
Files:
See also JSON Support in Qt and Data Storage.


Up
Prev - Draw
DICOM/Image File Viewer
click to add a seed for the currently selected label
click and drag to move a seed point
double click to remove an existing seed
Add
Clear
Delete


I enjoy creating simple and awesome things that people love, using the power of programming and the beauty of technology.


--- layout: default title: Contents available while offline ---
Even if you're not connected, you can read some pages, including the ones about me and about the website.


Before Change
from dipy.data.fetcher import fetch_scil_b0
from dipy.io.image import load_nifti, save_nifti
files, folder = fetch_scil_b0()
data, affine = load_nifti(pjoin(folder, "datasets_multi-site_all_companies",
"1.5T", "Siemens", "b0.nii.gz"))
data = np.squeeze(data)
After Change
from dipy.data import get_fnames
from dipy.io.image import load_nifti, save_nifti
data_fnames = get_fnames("scil_b0")
data, affine = load_nifti(data_fnames[1])
data = np.squeeze(data)


This white chiffon shift dress with slip sleeves crafted in 100%Polyester, non-stretchable material, please hand wash cold, featuring deep v-neck design, slip sleeves, shift dress, layered detail, mini dress. casual style textured fabric, perfect cut, full details of the sense of design, personalized and fashion. - See more at: https://www.choies.com/product/white-chiffon-shift-dress-with-slip-sleeves_p29413#sthash.ToqHzuuv.dpuf


This sample shows how you can use templates from various sources. Since templates in knockbone can return promises, you can load external files and the render method will wait until the file is loaded before applying knockout bindings.
This view was loaded from .