text:
## 23 October, 2015

### From Stabilization to Interval Estimation

In this post, I'm going to show how to use league means and stabilization points to construct mean interval and prediction interval estimates for some basic counting statistics. I'll focus on two specific models: the normal-normal and the beta-binomial model.

At a few points during this post I'm going to mention some empirical results. You can find the data I used and the code I ran on my github.

## Distributional Assumptions

I'm assuming the statistic in question is a binomial outcome - this covers many basic counting statistics (batting average, on-base percentage, batting average on balls in play etc.) but not rate statistics, or more complicated statistics such as wOBA.

Assume that in $n_i$ trials, a player accrues $x_i$ events (hits, on-base events, etc.). I'm going to assume that trials are independent and identical with parameter of success $\theta_i$.

For the distribution of the $x_i$, I'm going to work out the math for two specific distributions - the normal and the binomial. I'm also going to assume that the distribution of the $\theta_i$ follows the respective conjugate distribution - the normal for the normal model, and the beta for the binomial model. This prior has mean talent level $\mu$ and stabilization point $M$.

$x_i \sim p(x_i | \theta_i, n_i)$
$\theta_i \sim G(\theta_i | \mu, M)$

For the stabilization point $M$, I'm going assume this is the number of events at which $r = 0.5$. If you choose the point at which $r = 0.7$, then these formulas won't work

For several of the mathematical results here, I'm going to refer back to my article shrinkage estimators for counting statistics - particularly, the examples section at the end - without offering proofs or algebraic derivations.

The posterior distribution for $\theta_i$ is given by

$\displaystyle p(\theta_i | x_i, n_i, \mu, M) = \dfrac{p(x_i | \theta_i, n_i)G(\theta_i | \mu, M)}{\int p(x_i | \theta_i, n_i)G(\theta_i | \mu, M) d_{\theta_i}}$

Intervals will be constructed by taking quantiles from this distribution.

(For rate statistics instead of count statistics, the gamma-Poisson model can be used - though that will take more math to figure out the correct forms of the intervals. I got about three-quarters of the way there in my article WHIP stabilization by the gamma-Poisson model if somebody else wants to work through the rest. For more complicated statistics such as wOBA, I'm going to have to work through some hard math.)

## Mean Intervals

### Normal-Normal Model

For the normal-normal model, suppose that both the counts and the distribution of talent levels follow a normal distribution. Then the observed proportion $x_i / n_i$ also follows a normal distribution.

$\dfrac{x_i}{n_i} \sim N\left(\theta_i, \dfrac{\sigma^2}{n_i}\right)$

$\theta_i \sim N(\mu, \tau^2)$

Furthermore, a normal approximation to the binomial is used to estimate $\sigma^2$ as $\sigma^2 = \mu (1-\mu)$. The usual normal approximation to the binomial takes $\theta_i (1-\theta_i)$ as the variance; however, the normal-normal model assumes that variance $\sigma^2$ is constant around every single $\theta_i$ - so an estimate for that is the average amount of variance over all of them, $\mu(1-\mu)$.

As a side note, the relationship between $M$ and $\tau^2$ is given by

$M = \dfrac{\sigma^2}{\tau^2} \approx \dfrac{\mu(1-\mu)}{\tau^2}$

As I showed in my article shrinkage estimators for counting statistics, for the normal-normal model the shrinkage coefficient is given as

$B = \dfrac{\sigma^2/\tau^2}{\sigma^2/\tau^2 + n_i} = \dfrac{ M }{ M + n_i }$

The resulting posterior is then

$\theta_i | x_i, n_i, \mu, M \sim N\left( (1-B) \left(\dfrac{x_i}{n_i}\right) + B \mu, (1-B) \left(\dfrac{\sigma^2}{n_i}\right)\right)$

And substituting in the values of $B$, the variance of the posterior is given as

$\left(1 - \dfrac{M}{M + n_i}\right)\left(\dfrac{\mu(1-\mu)}{n_i}\right) = \left(\dfrac{n_i}{M + n_i}\right)\left(\dfrac{\mu(1-\mu)}{n_i}\right) = \dfrac{\mu(1-\mu)}{M+n_i}$

And a 95% interval estimate for $\theta_i$ is

$\left[ \left(\dfrac{n_i}{n_i + M}\right) \dfrac{x_i}{n_i}+ \left(\dfrac{M}{n_i+M}\right) \mu \right] \pm 1.96 \sqrt{ \dfrac{\mu(1-\mu)}{M+n_i}}$

### Beta-Binomial Model

For the beta-binomial model, suppose that the counts of events $x_i$ in $n_i$ events follows a binomial distribution and the distribution of the $\theta_i$ themselves is beta.

$x_i \sim Binomial(n_i, \theta_i )$

$\theta_i \sim Beta(\alpha, \beta)$

For the beta distribution of talent levels, the parameters can be constructed from the league mean and stabilization point as

$\alpha = \mu M$

$\beta = (1-\mu) M$

Using the beta as a prior distribution, the posterior for $\theta_i$ is then

$\theta_i | x_i, n_i, \mu, M \sim Beta(x_i + \mu M, n_i - x_i + (1-\mu) M)$

A 95% credible interval can then be taken as quantiles from this distribution - I show how to do this in in R in my article on Bayesian credible intervals. Most statistical software should be able to take quantiles from the beta distribution easily.

Alternatively, a normal approximation may be used - the posterior should be approximately normal with mean and variance

$\theta_i | x_i, n_i, \mu, M \sim N\left( \dfrac{x_i + \mu M}{n_i + M}, \dfrac{(x_i + \mu M)(n_i - x_i + (1-\mu) M)}{(n_i + M)^2 (1 + n_i + M)}\right)$

So a 95% credible interval based on the normal approximation to the beta posterior is given by

$\left(\dfrac{x_i + \mu M}{n_i + M}\right) \pm 1.96 \sqrt{\dfrac{(x_i + \mu M)(n_i - x_i + (1-\mu) M)}{(n_i + M)^2 (1 + n_i + M)}}$

This should be very close to the interval given by taking quantiles directly from the beta distribution.

### Practical Application

I downloaded first and second half data hitting data from all qualified non-pitchers from 2010 to 2015 from fangraphs.com. I used the above formulas on the first half of on-base percentage data to create intervals, and then calculated the proportion of those intervals that contained the on-base percentage for the second half. For the league mean and stabilization point, I used values of $M$ and $\mu$ (even though I didn't show $\mu$) from my article "More Offensive Stabilization Points."

But wait...isn't there uncertainty in those estimates of $M$ and $\mu$? Yes, but it actually doesn't play a huge role unless the uncertainty is large, such as for the BABIP. You can try it out yourself by running the code and changing the values slightly, or just trust me.

I rounded off to the nearest whole number for $M$ and to three nonzero digits  for $\mu$. The intervals compared were the normal-normal as NN, beta-binomial as BB, and the normal approximation to the beta-binomial as BB (N). The resulting coverages were

\begin{array}{| l | l | c | c | c | c |} \hline
\textrm{Stat}& \mu & M & \textrm{NN Coverage} & \textrm{BB Coverage} & \textrm{BB (N) Coverage} \\ \hline
OBP & 0.33 & 296 & 0.66 & 0.659 & 0.659 \\
BA & 0.268 & 466 & 0.604 & 0.601 & 0.603 \\
1B & 0.158 & 222 & 0.685 & 0.675 & 0.679 \\
2B & 0.0475 & 1025 & 0.532 & 0.532 & 0.531 \\
3B & 0.00492 & 373 & 0.762 & 0.436 & 0.76 \\
XBH & 0.0524 & 1006 & 0.545 & 0.542 & 0.551 \\
HR & 0.0274 & 125 & 0.754 & 0.707 & 0.738 \\
BB & 0.085 & 106 & 0.688 & 0.661 & 0.673 \\
SO & 0.181 & 50 & 0.74 & 0.728 & 0.729 \\
HBP & 0.00866 & 297 & 0.725 & 0.591 & 0.721 \\  \hline\end{array}

So what happened? Shouldn't the 95% intervals have 95% coverage? Well, they should. The problem is, I used the wrong type of interval - the intervals calculated here are for the mean $\theta_i$. But we don't have $\theta_i$. What we have is the second half on-base percentage, which is $\theta_i$ plus the random noise that naturally surrounds $\theta_i$ in however many additional plate appearances. What's appropriate here is a prediction-type interval that attempts to cover not the mean, but a new observation - this interval will have to account for both the uncertainty of estimation and the natural randomness in a new set of observations.

## Prediction Intervals

The interval needed is predictive - since the previous intervals were constructed as Bayesian credible intervals, a posterior predictive interval can be used.

Suppose that $\tilde{x_i}$ is the new count of events for player $i$ in $\tilde{n_i}$ new trials. I'm going to assume that $\tilde{n_i}$ is known. I'll also assume that $\tilde{x_i}$ is generated from the same process that generated $x_i$.

$\tilde{x_i} \sim p(\tilde{x_i} | \theta_i, \tilde{n_i})$

The posterior predictive is then

$p(\tilde{x_i}| \tilde{n_i}, x_i, n_i, \mu, M) = \displaystyle \int p(\tilde{x_i} | \theta_i, \tilde{n_i})p(\theta_i | x_i, n_i, \mu, M) d\theta_i$

For a bit more explanation, check out my article on posterior predictive distributions.

### Normal-Normal Model

As stated above, the posterior distribution for $\theta_i$ is normal

$\theta_i | x_i, n_i, \mu, M \sim N\left( B \left(\dfrac{x_i}{n_i}\right) + (1-B) \mu, \dfrac{\mu (1-\mu)}{n_i + M}\right)$

$B = \dfrac{M}{n_i + M}$

Using a normal approximation to the binomial, the distribution of the new on-base percentage in the second half (call this $\tilde{x_i}/\tilde{n_i}$) is also normal

$\dfrac{\tilde{x_i}}{\tilde{n_i}} | \theta_i, \mu \sim N\left(\theta_i, \dfrac{\mu(1-\mu)}{\tilde{n_i}}\right)$

The posterior predictive is the marginal distribution, integrating out over $\theta_i$ - it is given as

$\dfrac{\tilde{x_i}}{\tilde{n_i}} | \tilde{n_i}, x_i, n_i, \mu, M \sim N\left(B \left(\dfrac{x_i}{n_i}\right) + (1-B) \mu, \dfrac{\mu (1-\mu)}{n_i + M} + \dfrac{\mu(1-\mu)}{\tilde{n_i}}\right)$

And so a 95% posterior predictive interval for the on-base percentage in the second half is given by

$\left[ \left(\dfrac{M}{n_i + M}\right) \dfrac{x_i}{n_i}+ \left(\dfrac{n_i}{n_i+M}\right) \mu \right] \pm 1.96 \sqrt{ \dfrac{\mu(1-\mu)}{n_i + M} + \dfrac{\mu(1-\mu)}{\tilde{n_i}}}$

### Beta-Binomial Model

The posterior distribution for $\theta_i$ is beta

$\theta_i | x_i, n_i, \mu, M \sim Beta(x_i + \mu M, n_i - x_i + (1-\mu) M)$

The distribution for the number of on-base events $\tilde{x_i}$ in $\tilde{n_i}$ follows a binomial distribution

$\tilde{x_i} \sim Binomial(\theta_i, \tilde{n_i})$

The posterior predictive for the number of on-base events in the new number of trials is the marginal distribution, which has density

$p(\tilde{x_i}| x_i, n_i, \mu, M, \tilde{n_i}) = \displaystyle {\tilde{n_i} \choose \tilde{x_i}} \dfrac{\beta(\tilde{x_i} + x_i + \mu M, \tilde{n_i} - \tilde{x_i} + n_i - x_i + (1-\mu) M)}{\beta(x_i + \mu M,n_i - x_i + (1-\mu) M)}$

This is the beta-binomial distribution. It's is a discrete distribution that gives the probability of the number of on-base events in $\tilde{n_i}$ new PA, not the actual on-base percentage.

Since it is discrete, it's easy to solve for quantiles

$Q(\alpha) = \displaystyle \min_{k} \{ k : F(k) \le \alpha \}$
Where

$F(k) = \displaystyle \sum_{\tilde{x_i} \le k} p(\tilde{x_i} | x_i, n_i, \mu, M, \tilde{n_i}) = \displaystyle \sum_{\tilde{x_i} \le k} \displaystyle {\tilde{n_i} \choose \tilde{x_i}} \dfrac{\beta(\tilde{x_i} + x_i + \mu M, \tilde{n_i} - \tilde{x_i} + n_i - x_i + (1-\mu) M)}{\beta(x_i + \mu M,n_i - x_i + (1-\mu) M)}$

Since $Q(\alpha)$ is the quantile for the count of events, a 95% interval for the actual on-base proportion is given by

$\left(\dfrac{Q(.025)}{\tilde{n_i}} ,\dfrac{Q(.975)}{\tilde{n_i}}\right)$.

Alternatively, since the distribution is likely to be unimodal and bell-shaped, a normal approximation to the 95% posterior predictive interval is given by

$\left(\dfrac{x_i + \mu M}{n_i + M}\right) \pm 1.96 \sqrt{\dfrac{(x_i + \mu M)(n_i - x_i + (1-\mu)M)(n_i + M + \tilde{n_i})}{\tilde{n_i} (n_i + M)(n_i + M + 1)}}$

This isn't as good of an approximation as the normal approximation to the beta-binomial interval for the mean, but the difference between intervals is still only around 1% of the length and should work well.

### Practical Application

I repeated the analysis using the predictive formulas given above, using the first half on-base percentage to try to capture the second half on-base percentage, using the same $\mu$ and $M$ values as before.

\begin{array}{| l | l | c | c | c | c |} \hline
\textrm{Stat}& \mu & M & \textrm{NN Coverage} & \textrm{BB Coverage} & \textrm{BB (N) Coverage} \\ \hline
OBP & 0.33 & 296 & 0.944 & 0.944 & 0.94 \\
BA & 0.268 & 466 & 0.943 & 0.943 & 0.944 \\
1B & 0.158 & 222 & 0.941 & 0.941 & 0.942 \\
2B & 0.0475 & 1025 & 0.956 & 0.956 & 0.955 \\
3B & 0.00492 & 373 & 0.955 & 0.955 & 0.956 \\
XBH & 0.0524 & 1006 & 0.957 & 0.957 & 0.959 \\
HR & 0.0274 & 125 & 0.951 & 0.951 & 0.952 \\
BB & 0.085 & 106 & 0.925 & 0.925 & 0.921 \\
SO & 0.181 & 50 & 0.918 & 0.918 & 0.92 \\
HBP & 0.00866 & 297 & 0.95 & 0.95 & 0.947 \\ \hline\end{array}

## Cautions and Conclusion

Despite the positive results, I think that 95% actual coverage from these intervals is overoptimistic. For one, I selected a very "nice" group of individuals to test it on - nonpitchers with more than 300 PA. Being in this category implies a high talent level and a lack of anything that could drastically change that talent level over the course of the season, such as injury. I also treated the second half sample size $\tilde{n_i}$ as known - obviously, that must be estimated as well, and should add additional uncertainty.

Furthermore, there are clearly other factors at work than just random variation - players can get traded to different environments (a player being traded to or from Coors park, for example), talent levels may very well change over the course of the season, and events are clearly not independent and identical.

Applying these formulas to the population of players at large should see the empirical coverage drop - my guess (though I haven't tested it) is that 95% intervals should empirically get around 85%-90% actual coverage. Also keep in mind that $M$ and $\mu$ need to be kept updated - using means and stabilization points from too far in the past will lead to shrinkage towards the wrong point.

You can and should be able to do better than these intervals, in terms of length - these are incredibly simplistic, using only information about the player and information about the population. Adding covariates to the model to account for other sources of variation should allow you to decrease the length without sacrificing accuracy.

Alternatively, you could use these formulas with projections, with $\mu$ as the preseason projection and $M$ representing how many events that projection is "worth." This is more in keeping with the traditional Bayesian sense of the interval, and won't guarantee any sort of coverage.

However, I still think these intervals are useful in that they represent a sort of baseline - any more advanced model that generates predictive intervals should be able to do better than these.

Edit 16 Mar. 2017: I found that the data file I used for this analysis with the split first and second half  statistics was not what I thought it was - it repeated the same player multiple times, giving an inaccurate estimate of the confidence level. I have corrected the data file and re-run the analysis and presented the corrected confidence levels.


text:
Allometric law

Redirected from Isometry

34,191pages on
this wiki

Allometric law (or power-law) describes the relationship between the body parts or processes within or among living organisms, usually expressed in power-law form:

$y \sim x^{a} \,\!$ or in a logarithmic form: $\log y \sim a.\log x \,\!$

Such Allometric functions ( are mathematical equations derived from the the study of allometry,

For example in Body size scaling relationships between a physiological quantity (such as the respiration rate, or the maximum reproduction rate) of organisms and their body size (frequently taken to be body weight)can be expressed mathematically in terms of a curve on a graph.

Many characteristics, ranging from brain size and heart rate to life span and population density, change consistently with body size. These relationships normally fit a simple power function. The use of logarithms makes the equation easier to visualize. The exponent becomes the slope of a straight line when the logarithm of the variable (say respiration rate) is plotted against the logarithm of body mass.

The terms isometry, positive allometry, and negative allometry are used in relation to the slope of the line. For example if heart rate, varies proportionally to body mass this is isometry; positive allometry is where the larger animals have proportionatly higher heart rates; while negative allometry is where larger animals have proportionately lower heart rate..

ExamplesEdit

Some examples of allometric laws:
• Kleiber's law, the proportionality between metabolic rate $q_{0}$ and body mass $M$ raised to the power $3/4$:
$q_{0} \sim M^{\frac 3 4}$
• the proportionality between breathing and heart beating times $t$ and body mass $M$ raised to the power $1/4$:
$t \sim M^{\frac 1 4}$
• mass transfer contact area $A$ and body mass $M$:
$A \sim M^{\frac 7 8}$
• the proportionality between the optimal cruising speed $V_{opt}$ of flying bodies (insects, birds, airplanes) and body mass $M$ in kg raised to the power $1/6$:
$V_{opt} \sim 30.M^{\frac 1 6} m.s^{-1}$

format: plain


text:
The open source CFD toolbox
eddyIO.C
Go to the documentation of this file.
1/*---------------------------------------------------------------------------*\
2 ========= |
3 \\ / F ield | OpenFOAM: The Open Source CFD Toolbox
4 \\ / O peration |
5 \\ / A nd | www.openfoam.com
6 \\/ M anipulation |
7-------------------------------------------------------------------------------
8 Copyright (C) 2015 OpenFOAM Foundation
9 Copyright (C) 2016 OpenCFD Ltd.
10-------------------------------------------------------------------------------
12 This file is part of OpenFOAM.
13
14 OpenFOAM is free software: you can redistribute it and/or modify it
16 the Free Software Foundation, either version 3 of the License, or
17 (at your option) any later version.
18
19 OpenFOAM is distributed in the hope that it will be useful, but WITHOUT
20 ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
21 FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
22 for more details.
23
24 You should have received a copy of the GNU General Public License
25 along with OpenFOAM. If not, see <http://www.gnu.org/licenses/>.
26
27\*---------------------------------------------------------------------------*/
28
29#include "eddy.H"
30#include "IOstreams.H"
31
32// * * * * * * * * * * * * * * * * Constructors * * * * * * * * * * * * * * //
33
35:
37 position0_(is),
39 sigma_(is),
40 alpha_(is),
41 Rpg_(is),
44{
46}
47
48
49// * * * * * * * * * * * * * * * * * Operators * * * * * * * * * * * * * * * //
50
52{
53 patchFaceI_ = e.patchFaceI_;
54 position0_ = e.position0_;
55 x_ = e.x_;
56 sigma_ = e.sigma_;
57 alpha_ = e.alpha_;
58 Rpg_ = e.Rpg_;
59 c1_ = e.c1_;
60 dir1_ = e.dir1_;
61}
62
63
64// * * * * * * * * * * * * * * * IOstream Operators * * * * * * * * * * * * //
65
67{
69
70 is >> e.patchFaceI_
71 >> e.position0_
72 >> e.x_
73 >> e.sigma_
74 >> e.alpha_
75 >> e.Rpg_
76 >> e.c1_
77 >> e.dir1_;
78
80 return is;
81}
82
83
85{
87
88 os << e.patchFaceI_ << token::SPACE
89 << e.position0_ << token::SPACE
90 << e.x_ << token::SPACE
91 << e.sigma_ << token::SPACE
92 << e.alpha_ << token::SPACE
93 << e.Rpg_ << token::SPACE
94 << e.c1_ << token::SPACE
95 << e.dir1_;
96
98 return os;
99}
100
101
102// ************************************************************************* //
Useful combination of include files which define Sin, Sout and Serr and the use of IO streams general...
virtual bool check(const char *operation) const
Check IOstream status for given operation.
Definition: IOstream.C:58
An Istream is an abstract base class for all input systems (streams, files, token lists etc)....
Definition: Istream.H:64
An Ostream is an abstract base class for all output systems (streams, files, token lists,...
Definition: Ostream.H:62
Class to describe eddies for the turbulentDFSEMInletFvPatchVectorField boundary condition.
Definition: eddy.H:70
eddy()
Construct null.
Definition: eddy.C:117
void operator=(const eddy &e)
Definition: eddyIO.C:51
@ SPACE
Space [isspace].
Definition: token.H:125
OBJstream os(runTime.globalPath()/outputName)
#define FUNCTION_NAME


text:
A journal of IEEE and CAA , publishes high-quality papers in English on original theoretical/experimental research and development in all areas of automation
Volume 7 Issue 2
Mar.  2020

IEEE/CAA Journal of Automatica Sinica

• JCR Impact Factor: 7.847, Top 10% (SCI Q1)
CiteScore: 13.0, Top 5% (Q1)
Google Scholar h5-index: 64， TOP 7
Turn off MathJax
Article Contents
<NAME> and <NAME>, "Tracking Control of Uncertain Nonlinear Systems With Unknown Constant Input Delay," IEEE/CAA J. Autom. Sinica, vol. 7, no. 2, pp. 420-425, Mar. 2020. doi: 10.1109/JAS.2019.1911807
 Citation: <NAME> and <NAME>, "Tracking Control of Uncertain Nonlinear Systems With Unknown Constant Input Delay," IEEE/CAA J. Autom. Sinica, vol. 7, no. 2, pp. 420-425, Mar. 2020.

# Tracking Control of Uncertain Nonlinear Systems With Unknown Constant Input Delay

##### doi: 10.1109/JAS.2019.1911807
• A robust delay compensator has been developed for a class of uncertain nonlinear systems with an unknown constant input delay. The control law consists of feedback terms based on the integral of past control values and a novel filtered tracking error, capable of compensating for input delays. Suitable Lyapunov-Krasovskii functionals are used to prove global uniformly ultimately bounded (GUUB) tracking, provided certain sufficient gain conditions, dependent on the bound of the delay, are satisfied. Simulation results illustrate the performance and robustness of the controller for different values of input delay.

• 1 For simplicity of presentation, a second order system is considered in the paper, however, the development can be trivially extended to higher order system of the same form as (1).
2 $\mathbb{R}^{+}$ denotes a positive real value.
3 The notation $\mathcal{L}_{\infty}$ denotes the space of bounded Lebesgue measurable functions on $[0, \infty)$.

### Catalog

###### 通讯作者: 陈斌, <EMAIL>
• 1.

沈阳化工大学材料科学与工程学院 沈阳 110142

Figures(2)


text:
## Question Authors' Forum

### Initilization VM problems when running Javacode with Python

by <NAME> -
Number of replies: 2

Dear all,

setup:
I do not have admin right. I am just a teaching assistant trying to create nice exercises
I have build a prototype based on python3 which compiles and runs C/Java files.
Normally everything works fine.
However, sometimes - I think especially after the prototype has change - the Javafiles are not compile in one tests, however in all other similar tests they are. Changing basically nothing and rechecking it, it starts working.
Students however will loose a try.

The compiler output is:

Error occurred during initialization of VMjava.lang.OutOfMemoryError: unable to create native thread: possibly out of memory or process/resource limits reached
As a quickfix I just try to compile the file 10 times (hoping that at some point it is initialized):

for _ in range(10):
compiler = subprocess.Popen(compile_command, stdout=subprocess.PIPE, stderr=subprocess.PIPE, universal_newlines=True)
STD[COUT], STD[CERR] = [s for s in compiler.communicate()]
if "Error occurred during initialization of VM" not in STD[COUT]:
break
However this somehow seems not right (although it worked so far) :D.
Also, I one tried to run the compile step for every test 10 times and 2 out of 10 tries (randomly distributed) failed.

Is there any way to prevent this error in coderunner?

Thanks a lot
Thomas
In reply to Thomas Goerttler

### Re: Initilization VM problems when running Javacode with Python

by <NAME> -

You've almost certainly hit either the default memory limit or process limit for the task on Jobe. Java is a resource hog, and running it from within Python doubly so. If you're getting intermittent failures you must be right on the borderline of one of those limits.

If you customise your question, then open the Advanced Customisation panel, you'll find a MemLimit (MB) field and a Parameters field for the sandbox. You can turn off Memory Limit checking by setting MemLimit to 0. This is pretty safe because the JVM itself enforces memory limits. If that doesn't solve the problem, raise the process limit for the task by setting the Parameters field to something of the form {"numprocs": 200}.

In reply to <NAME>

### Re: Initilization VM problems when running Javacode with Python

by <NAME> -

Thanks a lot.
The MemLimit had already been set to 0 (as you gave the hint https://coderunner.org.nz/mod/forum/discuss.php?d=386).
I will try to increase the numsprocs to 200.
I hope that solves the problem.

PS: As I want to use the same thing also for C (I probably will copy the protype at the end to have a fix unique ace-language) setting the MemLimit to 0 is probably more dangerous for C, is not it?


text:
# A geometry problem by <NAME>

Geometry Level 2

A railway train is travelling on a circular curve of perimeter $$3000\times \dfrac{22}7$$ meters at the rate of $$66 \text{ km/hr}$$. Through what angle has it turned in 10 seconds?

×


text:
/ hep-ex CMS-HIN-12-016

Study of the production of charged pions, kaons, and protons in pPb collisions at sqrt(sNN) = 5.02 TeV

Pages: 37

Abstract: Spectra of identified charged hadrons are measured in pPb collisions with the CMS detector at the LHC at sqrt(sNN) =5.02 TeV. Charged pions, kaons, and protons in the transverse-momentum range pt approximately 0.1-1.7 GeV and laboratory rapidity abs(y) < 1 are identified via their energy loss in the silicon tracker. The average pt increases with particle mass and the charged multiplicity of the event. The increase of the average pt with charged multiplicity is greater for heavier hadrons. Comparisons to Monte Carlo event generators reveal that EPOS LHC, which incorporates additional hydrodynamic evolution of the created system, is able to reproduce most of the data features, unlike HIJING and AMPT. The pt spectra and integrated yields are also compared to those measured in pp and PbPb collisions at various energies. The average transverse momentum and particle ratio measurements indicate that particle production at LHC energies is strongly correlated with event particle multiplicity.

Note: Submitted to EPJC; *Temporary entry*

Total numbers of views: 6302
Numbers of unique views: 1038


text:
# Tropical Pacific Sea Level Diagnostic Documentation¶

Last update: 11/16/2020

Sea level rise is closely related to climate variability and change. It has important socio-economic impacts on many coastal cities and island nations. The largest sea level variability occurs in the tropical Pacific, with a magnitude of ~200mm on interannual timescales during El Niño. This sea level variability is superimposed on long-term sea level trends and closely related to global temperature evolution and other climate indices. A detailed understanding of climate model’s ability in simulating sea level variability and change in the tropical Pacific is crucial for future projections of climate and sea level.

## Version & Contact info¶

• Version/revision information: version 1 (11/16/2020)

• PI (<NAME>, University of Arizona, <EMAIL>)

• Developer/point of contact (<NAME>, University of Arizona, <EMAIL>)

## Functionality¶

The main script generates the tropical Pacific dynamic sea level and wind stress curl scatter plots at different time scales due to their strong dependency from Ekman pumping/suction and barotropic response over the ocean.

### Python function used¶

• spherical_area.cal_area : generate area array based on the lon lat of data

• dynamical_balance2.curl_var_3d : calculate wind stress curl in obs (for Dataset with time dim)

• dynamical_balance2.curl_var : calculate wind stress curl in obs (for Dataset without time dim)

• dynamical_balance2.curl_tau_3d : calculate wind stress curl in model (for Dataset with time dim)

• dynamical_balance2.curl_tau : calculate wind stress curl in model (for Dataset without time dim)

• xr_ufunc.da_linregress : linregress for Dataset with time dim

## Required programming language and libraries¶

The programming language is python version 3 or up. The third-party libraries include “matplotlib”, “xarray”, “cartopy”,”cftime”,”numpy”. The conda environment can be set to _MDTF_python3_base.

## Required model output variables¶

With monthly frequency from the model output. This diagnostic needs

### input model variables¶

• tauuo (surface wind stress in the x direction from native model output resolution/grid)

• tauvo (surface wind stress in the y direction from native model output resolution/grid)

• zos (dynamic sea level height in the model from native model output resolution/grid)

The script is written based on the CESM2-OMIP1 download provided by CMIP6-OMIP hosted by WCRP.

The dimension of all variable is 3-D with (time,nlat,nlon) in dimension and 2-D array for lat and lon as coordinate.

## Required observational data¶

This diagnostic needs

### input observational variables¶

• adt (absolute dynamic topography from CMEMS)

preprocessing from daily to monthly mean is needed (use ‘io_cmems_adt.py’)

• tx (surface wind stress in the x direction from WASwind)

no preprocessing needed

• ty (surface wind stress in the y direction from WASwind)

no preprocessing needed

#### data access :¶

The dimension of all variable is 3-D with 2-D in space and time

## References¶

1. <NAME> et al. (2020): A Mechanistic Analysis of Tropical Pacific Dynamic Sea Level in GFDL-OM4 under OMIP-I and OMIP-II Forcings. GMD, under review.

2. <NAME> et al. (2016): OMIP contribution to CMIP6: experimental and diagnostic protocol for the physical component of the Ocean Model Intercomparison Project. GMD, https://doi.org/10.5194/gmd-9-3231-2016

3. <NAME> et al., (2015): The JRA-55 Reanalysis: General Specifications and Basic Characteristics. Journal of the Meteorological Society of Japan. Ser. II, https://doi.org/10.2151/jmsj.2015-001<https://doi.org/10.2151/jmsj.2015-001>_

4. <NAME> and <NAME>, (2009): The global climatology of an interannually varying air–sea flux data set. Climate Dynamics,https://doi.org/10.1007/s00382-008-0441-3<https://doi.org/10.1007/s00382-008-0441-3>_

## More about this diagnostic¶

The sea level over the tropical Pacific is a key indicator reflecting vertically integrated heat distribution over the ocean. We find persisting mean state dynamic sea level (DSL) bias along 9◦N even with updated wind forcing in JRA55-do relative to CORE. The mean state bias is related to biases in wind stress forcing and geostrophic currents in the 4◦N to 9◦N latitudinal band. The simulation forced by JRA55-do significantly reduces the bias in DSL trend over the northern tropical Pacific relative to CORE. In the CORE forcing, the anomalous westerly wind trend in the eastern tropical Pacific causes an underestimated DSL trend across the entire Pacific basin along 10◦N. The simulation forced by JRA55-do significantly reduces the bias in DSL trend over the northern tropical Pacific relative to CORE. We also identify a bias in the 10 easterly wind trend along 20◦N in both JRA55-do and CORE, thus motivating future improvement. In JRA55-do, an accurate Rossby wave initiated in the eastern tropical Pacific at seasonal time scale corrects a biased seasonal variability of the northern equatorial counter-current in the CORE simulation. Both CORE and JRA55-do generate realistic DSL variation during El Niño. We find an asymmetry in the DSL pattern on two sides of the equator is strongly related to wind stress curl that follows the sea level pressure evolution during El Niño.


text:
How to set compensation using commonsense principles

Compensation has always been one of the most confusing parts of management to me. Getting it right is obviously extremely important. Compensation is what drives our entire economy, and you could look at the market for labor as one gigantic resource-allocating machine in the same way as people look at the stock market as a gigantic resource-allocating machine for investments.

Yet, almost everything I learned about compensation comes from practical experience, so what follows is a blog post I wish I could have read ten years ago! I wrote it from the perspective of a manager at a tech startup, but hope there's some parts that generalize.

I'll start by stating what I think are goals and anti-goals:

• A good system doesn't waste money hiring new people when you can pay to keep existing people.
• A bad system keeps people below the salary that you would give them to keep them.
• A good system pre-empts people interviewing elsewhere.
• A bad system gives raises mostly when people interview elsewhere and get offers.
• A good system phases out underperformers or makes it clear they will never get a raise until they step it up.
• A bad system give raises to people who are already paid more than you would pay to hire them today.
• A good system pays people on an absolute scale, where salary history is not a factor.
• A bad system thinks of salary increases in relative terms (eg top performers get +5%).
• A good system doesn't pay more just because someone interviews with many companies.
• A bad system determines offers to new hires mostly based on their other offers.
• A good system pays only for the value someone is creating, not for irrelevant things.
• A bad system pays based on years of experience or pedigree.
• A good system gives the biggest raises to humble people who never asked for it, but deserve it.
• A bad system gives raises to people when they ask for it, and gives more when people complain more.
• A good system understands how to use equity to motivate people.
• A bad system penalizes people for trading off salary for equity.
• A good system incentivizes people to do whatever adds the most value to the company.
• A bad system incentivizes people to go into management in order to get a raise.
• A good system has a clear link between performance and salary that people understand.
• A bad system makes people frustrated because they don't understand why some people make more than other.

Phew, that was a lot! Most of is should be sort of self-evident, or at least it feels so to me. But I've seen a lot of companies mess it up! What are some principles we can use that prevent us from all of these traps? Hold my beer as I go through:

Principle 1: align with market

Ignoring for a second that productivity is basically impossible to quantify, let's say we made a scatter plot of employees at the company CrazyBananaCo, where the x-axis is how much value they create and the y-axis is their cost.

Just to make it a bit simpler, let's say the chart only includes people who spent at least 1 year at the company, so that we can roughly ignore the “ramp time”. There's about 99 other simplifications here, some of which I addressed at the end of this post, but they key point here is this a toy model that still lets us say a lot about compensation management!

Two quantities are important benchmarks for someone's salary:

• Market rate: if this person started here today, what would we have to pay to get them?
• Replacement cost: how much are we willing to pay in order to get this person to stay?

The market range is not a perfect “price” so I picture it more like a range. The replacement cost will be a bit higher than the market rate because of the extra cost of hiring/training the person. It's rational that we would rather pay a bit more to get someone to stay versus hiring an identical person coming in from scratch.

With productivity, I also mean value, so the diagonal line represents the curve where the net benefit of an employee is exactly 0. In general, market rate ≤ replacement cost ≤ value. Once we calibrate this against market/replacement, hopefully we'll end up with something like this: If your compensations are aligned with market, then no one should be below market range (give them a raise before they quit), and no one should be above replacement cost (then they should be replaced). Ideally pretty few should be above market range but below replacement cost (the purple zone), although I consider that zone a bit of a special “insurance card” you can buy, like if someone on your team has some deep domain knowledge that's absolutely crucial right now so you don't have time to hire a replacement and train them. But how do you know the market rate and the replacement cost? You really don't ever know it, but the best way to get a good pulse on it is through recruiting. A good offer acceptance rate is in the 70-80% range—too low, and you might be underpaying, too high, and you might be overpaying. If you make a lot of offers, you should develop a pretty good understanding of the market from making offers and learning about what other companies are offering. There are also datasets such as Radford, which you have to pay for, and levels.fyi, which is a free database of self-reported salaries. Principle 2: create consistency Let's consider the company SuperFairCo, which has a super nice consistent pay distribution. Let's say SuperFairCo is considering hiring Meg—an engineer highly desired in the market. Other companies are offering a lot as well. But we still have an opportunity to hire her at a cost lower than their value. Should we do it? Meg would generate surplus value, so from that perspective it might seem like a good trade. But there's a subtle catch. Consider these situations: 1. Joe in the HR team is accidentally shares a spreadsheet with everyone's salaries. Mike notices someone with less experience than him is making more money. 2. Anna goes to her manager and asks for more money. She's currently making150,000 and the company values her contributions as $200,000. She's asking for$190,000 or else she will quit.

The last one is especially tricky. If you comply, you're still benefitting from having Anna on the team, but you just created a culture where people who complain to their manager get more money and people who don't complain get no raise. That seems like bad incentives!

The only solution to all of this, is to make sure salaries are consistent. A useful Litmus test is: if all salaries were made fully transparent, would people be upset? If so, you might have an inconsistency problem.

Our hypothetical offer to Meg comes with two big hidden costs:

1. The heartburn of creating a very inconsistent pay scale (with all the bad feelings if people find out)
2. The hypothetical dollar costs of raising salaries for many other people if you ever want to get the pay scale back to consistency:

On the other hand, a consistency-based model implies the salary range for Meg's offer is much tighter, and that the SuperFairCo is willing to lose her even at a salary that generates surplus value to the company. And this is why the company is probably better off declining Anna's request for a raise.

I kind of glossed over what “consistency” exactly means here, but just to clarify: if person A is more productive than person B, then A should have a higher salary than B. I think that's reasonable!

Corollaries of a consistency-based framework

I think the consistency aspect largely explains why companies have a tighter “cap” on salary than you would otherwise expect. They might not be willing to pay above market salary for someone, even though their salary is below replacement cost, and even though they generate a lot of surplus value.

The theory also implies that companies will be really risk-averse about offers. There's an asymmetry in the “total inconsistency”, where overpaying often creates a lot more inconsistencies than underpaying. Rationally a company may thus lowball such an offer.

Putting it to practice: the salary calibration process

Let's discuss how to actually calibrate salaries. We'll consider another startup MegaHyperCo with a somewhat inconsistent salary distribution:

Let's first aim for consistency. One way to do it is to simply give the smallest raise to everyone in order to bring the total inconsistency to zero:

The method I used in the chart above isn't meant to be taken extremely literally. And note that this example started with a somewhat extreme distribution—ideally, you never deviate very far from consistency, and so the inconsistency-driven raises should be small. But hopefully you get the point of what I'm doing here!

A major benefit of the consistency-based calibration is that it doesn't require modeling out a person's value. All we need is to be able to rank people. It's almost impossible to argue that Abdul who's an associate engineer making $120,000 is exactly 69% as productive as Pierre the senior engineer making$175,000. But we can often rank Pierre vs Abdul.

We should also calibrate against market salary. Usually, markets don't move much, so the calibrations will be minor, but occasionally when markets move quickly, this could mean changing a larger set of salaries (say 50%+ of the team). You definitely shouldn't just give everyone a blanket x% raise! Instead, do it in a way that targets the underpaid employees:

Note that the two models (figure 8 and 9) recommend raises to roughly the same set of employees:

What do you do with people who are overpaid? I've never lowered anyone's salary, and if they are vastly overpaid (above their replacement cost) then they should probably be let go instead. But it occasionally happens that someone is slightly overpaid, but still generating surplus value. If you're not letting them go then you don't have much of a choice here: keep their salary the same for multiple years in a row, potentially indefinitely. If that person makes a fuss and ends up quitting, that's OK!

This system is greatly simplified by introducing levels. By bucketing everyone into say 5-10 buckets, with clearly defined expectations, you can build salary ranges for each bucket and use that for calibration as well. There are many other benefits of levels (and some drawbacks) but I'll save that for another time!

I have done something similar to this every six months for the past four years and it works reasonably well. A year ago I started bringing in my reports (who each manage 20-30 people), and we spend a few hours calibrating until we feel like the final compensation data is reasonably consistent. I try to target about 30% of the team getting a raise each year, so 15% each six months.

Other considerations

What happens when someone asks for a raise? In almost all cases, the answer should be no. You should do the salary calibration process in a way that people get salaries they deserve, but not more. The only exception to this rule is if their performance is way out of range and there's a real retention risks—essentially you're just doing an early off-cycle calibration.

I also strongly recommend against paying more to new managers than individual contributors. This incentivizes people to go into management for the wrong reasons, and make it very hard for people to step back if they decide management isn't what they wanted to do. In my experience, something like half of all managers realize they were happier not managing, and you don't want to lock people in.

Other types of compensation

So far, I simplified the problem a bit and talked about salary as if the base salary is the only consideration. There's of course many other things that constitute the total compensation, so let's consider what I think are the most common ones:

1. Base salary
2. Bonus
3. Equity
4. Sign-on bonus

Bonus

An odd thing about bonuses is how different it is for different jobs. Most salespeople are heavily commission-based. Most software engineers are compensated in stock and salary, with little/no bonus. Why? Is this just some dumb artifact of how the markets for those roles have evolved?

Of course not. You can easily quantify a salesperson's contribution to the company, and paying them commission aligns their contribution to the company with their compensation. It's extremely hard to quantify the contribution of software engineers. This is sort of an obvious point, but people forget about it! Why do traders and salespeople have bonuses? Why don't many other jobs? An excellent short read on this is Measuring and Managing Performance in Organizations.

I don't have as much experience with bonuses, but my observation is that bonuses tend to work only in these three circumstances:

1. The work result is quantifiable and aligned with the business. This is true for salespeople, but also quant developers and some other jobs.
2. The bonus is paid ad-hoc for hard hustle, maybe lots of overtime to hit a deadline. Management can dangle a bonus in front of employees to get something done quicker. This should probably only be a rare thing.
3. The bonus is roughly guaranteed (maybe even on the offer letter), and set to a fixed amount in advance. It's revoked only if the employee is severely underperforming. This seems to be the culture of Google and a few big companies, but I could be wrong and I'm hesitant to say much more since I don't know.

My feeling is that for many professions, bonus tied to performance reviews or ratings is blunt and arbitrary, and should be avoided. For jobs where performance takes a long time to observe, sustained good performance should be reflected in higher salary+equity instead. I've always been skeptical about paying performance bonuses to software engineers other than in truly exceptional cases.

Equity compensation

Equity is a key part of the compensation at startups. Some of the arguable benefits:

1. Financially, it preserves cash for cash-strapped startups, and offers another currency so they can compensate top talent.
2. Economically, it aligns incentives between employees and the company, although I'm skeptical this matters past the first 5-15 people.
3. Psychologically, employees will rationalize their holdings and root for the company. I think this one might be underestimated, but it's hard to tell? There could also be some kind of “survivor bias”—people who deeply believe in your biz idea will be more likely to join.
4. Practically, employees will be tied to the employment because they don't have the money to exercise options. IMO this is kind of a dumb point because (a) if the company is doing well then you can usually arrange financing (b) it's probably not in the company's best interest to keep disgruntled employees who are only staying because of the equity.

My highly speculative perception is that employees will view $1 of equity as having something like the following value: What's going on here? • In the early days, people will take a huge salary discount to get something like$100,000 in equity in a promising super-early startup. Everyone in the tech industry has a friend (or a friend of a friend) who made a bajillion dollars in some acquisition. At this point, you can probably get away paying substantially lower than the market rate in terms of base salary.
• Once the company matures, you're not going to get these early crazy people, and people will view equity as some weird paper money that may or may not be worth money in many years. At this point, you're going to have to raise the base salary substantially.
• As you approach the IPO, people are excited to get into something that will have an “pop” once it goes public, and that they can sell relatively soon.
• Once the company goes public, equity compensation is pretty liquid much just like cash, with some annoying constraints (trading windows, lockup periods etc).

There's also difference in risk aversity and other things to be attuned to—some which depends on the personality, some on the life situation of the person.

What's my point of all of this? When you look at compensation, you should be smart about the breakdown between salary and equity. Optimizing for what people value increases your bargaining power.

In my opinion, the biggest thing companies mess up with equity compensation, is to not explain it very well. This causes people to discount its value, which means companies have to pay more salary to compensate for it. Companies should think more about this!

Sign-on bonus

I'm not going to write too much about this one. I used to think sign-on bonus was the world's dumbest thing. Why pay more in the first year when an employee is the least productive? But from a company's point of view, it offers a critical advantage: you can retain salary consistency, while still being market competitive.

This applies especially in cases where there's significant uncertainty about a candidate. A $150,000 salary with a$20,000 sign-on bonus is essentially like a salary that drops from $170,000 to$150,000 the second year. If the person is awesome, you can always raise the salary back. If they aren't, then you keep them at their new “lower” salary, and keep your team's compensation consistent.

Total compensation

When you try to get salary consistency, you should really look at the total compensation number, not just base salary. Here's my opinionated view on how to do this:

• Base salary is obviously part of it.
• Equity is a part of it, and divided by the vesting time, and using the original value of the grant, not the present value. And for options, subtract the strike price. I often also think it's worth putting a small discount (10-30%) on the value to compensate employees for the risk.
• Bonus should only be a part of it if it's the “roughly guaranteed” type of bonus.

Let's look at some examples. Let's say the value per share is $4, the strike price is$1, so that the value per option is $3. We'll discount it to$2.5 for the purpose of compensating employees. The shares are vesting over four years.

Let's consider two offers that are roughly equivalent from the company's point of view:

1. $100,000 in base salary, with 50,000 shares: total value is$100,000 + 50,000 · $2.5 / 4 =$131,250
2. $110,000 in base salary, with 34,000 shares: total value is$110,000 + 34,000 · $2.5 / 4 =$131,250

Two years later, the new value per option isn't $2.5 but$10. What happens to the total compensation. Using the value at grant, the compensation is still the same. Using the present value, the total compensation is now:

1. $100,000 in base salary, with 50,000 shares: total value is$100,000 + 50,000 · $10 / 4 =$225,000
2. $110,000 in base salary, with 34,000 shares: total value is$110,000 + 34,000 · $10 / 4 =$195,000

Let's say we had hired two employees, one who picked each option. Is either of them underpaid compared to the other? One has a lower base salary, but the other one has a lower total compensation. To me it's clear that these two should be considered to have the same compensation. So the logical way to think about total compensation is to use the value at the grant date.

This is an underemphasized point. HR people generally like to use the present value (because it makes the numbers look more impressive), or exclude equity compensation completely. This applies to resources like levels.fyi and Radford as well (both use present value, afaik). So when you do cross-company calibrations, be careful looking at total compensation.

Of course, use your own best judgement. If someone came in early and is vesting trillions of dollars of shares each month, they proabably aren't a retention risk, and you might be fine looking at the present value of the shares. Just be judicious!

Conclusion

I started writing this post thinking it would be a quick one, but it ballooned into 4,000 words and that's after heavy editing where entire sections were removed. There's a lot more to be said, for sure. But hopefully you'll find some of this useful!

Notes

• Throughout this post, I assumed people's productivity is a known exact quantity. Of course, that's a gross simplification, but it's a toy model, OK :)
• Likewise, I assumed the market rate is a pretty tight band. There's always going to be weird outliers: people having deep expertise in things you don't care about, etc.
• Where does the market rate come from? In theory, the market cost should converge to the second highest value that any company would get out of a candidate. I think this convergence is extremely slow, but definitely happens in the long run.
• Of course, total compensation isn't the only thing that matters to people. The ability to learn and grow, perks, lifestyle, titles, office and much other things matter as well! But none of this affects the mechanics of the models.
• I was tempted to write about remote work, but I really don't have much experience with it. The question I'm fascinated by: what's the equilibrium?
• Note that a consistency-based model doesn't necessarily imply that a company pays the same salary across different locations! They could legitimately pay 2x salary to employees in NYC vs Boise, ID. People may grumble a bit, but the company could say something half-hearted about adjusting anyone's salary if they move to NYC.
• You could even state inconsistency in mathematical terms. One way would be to define the inconsistency loss $$I = \sum_{i} \max_j (s_j - s_i)H(p_i - p_j)$$, where $$s_i$$ are salaries, $$p_i$$ are productivities, and $$H$$ is just a function that is 1 for positive numbers and 0 for negative ones (aka the Heaviside step function). The loss is zero if you have no inconsistency whatsoever, but positive when as soon as the productivity-salary curve is no longer monotonic.
• A fun theory! Consistency implies that roles with more people will have less upside flexibility. If Amazon gives a 5% raise to one of the warehouse workers, then they kind of have to give a raise to another 100,000 warehouse workers! But if they give a huge raise to a SVP of Mega-Technology, then that doesn't really violate any inconsistencies.
• If someone is slightly overpaid, of course shouldn't just keep their salary without having a blunt conversation with them about their performance and the expectations you have on them, maybe also putting them on a performance improvement plan.
• I modeled the function of salary vs productivity as a sublinear relation. The astute reader might point that in that case we should only hire people as far out on the x-axis as possible! That's maybe true, but there's more complexity to it, and I've written about some of it in the past.
• I didn't talk about equity types, but there's a whole rabbit hole of RSUs vs ISOs vs NSOs and their legal/tax implications which would take a whole book to cover!
Tagged with: management, math, hiring


text:
# What is the correct Marlin firmware setting for Tevo Tarantula with MKS Base V1.2 board

I am trying to correct the x&y offsets in the Tevo Tarantula that I got from a friend in order that my printer is not printing over the end. What I got so far is that I need to measure and then enter the offsets into my configuration.h file, build the firmware and flash it to the board.

Because I do not have and can not find the original firmware I found the repository from <NAME> for the Tarantula.

Looking into the top section of the config file provided by the repo, the board configured is

#define MOTHERBOARD BOARD_MKS_GEN_13        // Original controller board with built in stepper drivers. Works with MKS BASE 1.3, 1.4

However since the board in my Tarantula has 1.2 on it I checked the boards.h file for MKS but could not find the v1.2 :

#define BOARD_MKS_BASE          40    // MKS BASE v1.0
#define BOARD_MKS_BASE_15       405   // MKS v1.5 with Allegro A4982 stepper drivers
#define BOARD_MKS_BASE_HEROIC   41    // MKS BASE 1.0 with Heroic HR4982 stepper drivers
#define BOARD_MKS_GEN_13        47    // MKS GEN v1.3 or 1.4
#define BOARD_MKS_GEN_L         53    // MKS GEN L
#define BOARD_MKS_GEN_L_V2      54    // MKS GEN L V2
#define BOARD_ZRIB_V20          504   // zrib V2.0 control b

Any idea, what board configuration would be compatible for 1.2? Or is there any other way to correct the x&y offsets other then compiling them into the firmware?

The MKS Base v1.2 is basically an Arduino MEGA2560 and a RAMPS1.4 on a single board.

You can use the RAMPS pin designation.

Note that the endstop to origin distances is explained in question How to center my prints on the build platform? (Re-calibrate homing offset).

In Jims Marlin fork you can find this at:

#define X_MIN_POS 0 - XTRA_BED_LEFT

and

#define Y_MIN_POS 0 - XTRA_BED_BACK

Unfortunately, XTRA_BED_LEFT and XTRA_BED_BACK are defined as zero; this implies that the endstops define the origin (not likely) or it is left as an excercise for you to find out. This answer explains how you figure that out.

• Thank you for the answer. For the RAMPS 1.4 the boards.c file also has multiple configurations. The board itself has 3 blue power outputs E0, E1, Fan followed by a green power output for the bed. #define BOARD_RAMPS_14_EFB 43 // RAMPS 1.4 (Power outputs: Hotend, Fan, Bed) #define BOARD_RAMPS_14_EEB 44 // RAMPS 1.4 (Power outputs: Hotend0, Hotend1, Bed) #define BOARD_RAMPS_14_EFF 45 // RAMPS 1.4 (Power outputs: Hotend, Fan0, Fan1) #define BOARD_RAMPS_14_EEF 46 // RAMPS 1.4 (Power outputs: Hotend0, Hotend1, Fan) #define BOARD_RAMPS_14_SF 48 // RAMPS 1.4 (Power outputs: Spindle, Fan
– Eike
Dec 29 '20 at 16:45
• @Eike Looks like you have the EFBE option.
– 0scar
Dec 30 '20 at 2:13
• Just greped through the source files for the Easyconfig 1.1 and 2.0 and found only references in some pins_RAMPS files to the EFBE option: ./Marlin/pins_RAMPS.h: #else // Non-specific are "EFB" (i.e., "EFBF" or "EFBE") sorry for being blind but I am stil not sure what board I should put into the config?
– Eike
Dec 30 '20 at 10:07
• @Eike EFB is a standard option, the EFBE is an added extra extruder (I understood you had 2 from your comment, but if you are only using 1, you can go for EFB).
– 0scar
Dec 30 '20 at 13:02


text:
# Geometric process

In probability, statistics and related fields, the geometric process is a counting process, introduced by Lam in 1988.[1] It is defined as

The geometric process. Given a sequence of non-negative random variables :${\displaystyle \{X_{k},k=1,2,\dots \}}$, if they are independent and the cdf of ${\displaystyle X_{k}}$ is given by ${\displaystyle F(a^{k-1}x)}$ for ${\displaystyle k=1,2,\dots }$, where ${\displaystyle a}$ is a positive constant, then ${\displaystyle \{X_{k},k=1,2,\ldots \}}$ is called a geometric process (GP).

The GP has been widely applied in reliability engineering [2]

Below are some of its extensions.

• The α- series process.[3] Given a sequence of non-negative random variables :${\displaystyle \{X_{k},k=1,2,\dots \}}$, if they are independent and the cdf of ${\displaystyle {\frac {X_{k}}{k^{a}}}}$ is given by ${\displaystyle F(x)}$ for ${\displaystyle k=1,2,\dots }$, where ${\displaystyle a}$ is a positive constant, then ${\displaystyle \{X_{k},k=1,2,\ldots \}}$ is called an α- series process.
• The threshold geometric process.[4] A stochastic process ${\displaystyle \{Z_{n},n=1,2,\ldots \}}$ is said to be a threshold geometric process (threshold GP), if there exists real numbers ${\displaystyle a_{i}>0,i=1,2,\ldots ,k}$ and integers ${\displaystyle \{1=M_{1} such that for each ${\displaystyle i=1,\ldots ,k}$, ${\displaystyle \{a_{i}^{n-M_{i}}Z_{n},M_{i}\leq n forms a renewal process.
• The doubly geometric process.[5] Given a sequence of non-negative random variables :${\displaystyle \{X_{k},k=1,2,\dots \}}$, if they are independent and the cdf of ${\displaystyle X_{k}}$ is given by ${\displaystyle F(a^{k-1}x^{h(k)})}$ for ${\displaystyle k=1,2,\dots }$, where ${\displaystyle a}$ is a positive constant and ${\displaystyle h(k)}$ is a function of ${\displaystyle k}$ and the parameters in ${\displaystyle h(k)}$ are estimable, and ${\displaystyle h(k)>0}$ for natural number ${\displaystyle k}$, then ${\displaystyle \{X_{k},k=1,2,\ldots \}}$ is called a doubly geometric process (DGP).
• The semi-geometric process.[6] Given a sequence of non-negative random variables ${\displaystyle \{X_{k},k=1,2,\dots \}}$, if ${\displaystyle P\{X_{k} and the marginal distribution of ${\displaystyle X_{k}}$ is given by ${\displaystyle P\{X_{k}, where ${\displaystyle a}$ is a positive constant, then ${\displaystyle \{X_{k},k=1,2,\dots \}}$ is called a semi-geometric process

## References

1. ^ <NAME>. (1988). Geometric processes and replacement problem. Acta Mathematicae Applicatae Sinica. 4, 366–377
2. ^ <NAME>. (2007). Geometric process and its applications. World Scientific, Singapore MATH. ISBN 978-981-270-003-2.
3. ^ <NAME>., <NAME>., & <NAME>. (2005). Properties of the geometric and related processes. Naval Research Logistics (NRL), 52(7), 607–616.
4. ^ <NAME>., <NAME>., <NAME>. & <NAME>. (2006). Modelling SARS data using threshold geometric process. Statistics in Medicine. 25 (11): 1826–1839.
5. ^ <NAME>. (2017). Doubly geometric processes and applications. Journal of the Operational Research Society, 1–13. doi:10.1057/s41274-017-0217-4.
6. ^ <NAME>., <NAME>. (2017). The semi-geometric process and some properties. IMA J Management Mathematics, 1–13.


text:
I am producing a PHP code and I want to implement it in my server to do its function. My question is, are there any vulnerabilities that I should correct?

I tried to establish the session first then I will initiate a SQL connection and I will ask the user to enter his email. Also I added the reset function of his email.

<?php
if ($_SESSION['admin'] !== true) { header('Location: /login.php?'); }$conn = new mysqli("localhost","admin","password","db");

if ($conn->connect_error) { die("Connection failed: " .$conn->connect_error);
}

$msg = ''; if (isset($_POST['submit'])) {
$email =$_POST['email'];
$sql = "SELECT * FROM users WHERE email =$email;";
$result = @$conn->query($sql); if ($result->num_rows == 0) {
die("This email: $email is incorrect"); }$row = $result->fetch_assoc();$id = $row["id"];$surename = $row["surename"];$sql = "SELECT * from users JOIN password_resets ON (password_resets.user_id=users.id)  WHERE id=$id;";$result = @$conn->query($query);
if ($result->num_rows == 0) {$insert_sql = "INSERT INTO password_resets (user_id, reset_timestamp) VALUES ($id, unix_timestamp());"; if ($conn->query($insert_sql) !== TRUE) { die("Error: " .$insert_sql . "
" . $conn->error); } }$result = $conn->query($query);
$row =$result->fetch_assoc();

$link = "https://".$_SERVER['SERVER_NAME']."/reset.php?id=".$row['id'] ."&timestamp=".$row['reset_timestamp'];
$message = "Hi,$surename,

Here's your password reset link: $link";$headers = "From: ".$_SESSION['first_name']." ".$_SESSION['last_name']." <".$_SESSION['email'].">"; mail($email,"Your password reset link",$message,$headers);
$msg = "Password reset for$email sent!";
?>

<form>

<?=$msg ?>
 <input type="text" width=80 name="email"> <input type="submit" name="submit" value="Send"> </form>   <?php }  • Suppressing errors when you do queries is not a good idea. Establish proper error handling so you are aware of and can fix problems. Don't use something like $result = @$conn->query($sql);. – Dave Feb 16 '19 at 13:32

Your code is wide open to SQL Injection which is the most dangerous web vulnerability. This occurs when you execute SQL queries with unsanitized user data. By placing the raw $_POST variable directly in your query you are allowing an attacker to inject their own SQL into your query and execute it. They can do anything from stealing data to deleting your database. To combat this you must use parameterized queries. Stack Overflow covers this very well but here's what your code would like if you use mysqli with prepared statements: $stmt = $dbConnection->prepare('SELECT * FROM users WHERE email = ?');$stmt->bind_param('s', $email); // 's' specifies the variable type => 'string'$stmt->execute();

$result =$stmt->get_result();
$row =$result->fetch_assoc();

You also are wide open to Cross-site scripting (XSS) attacks which is the #7 web vulnerability. This occurs because you take raw $_POST data and output it directly into your HTML. An attacker can place malicious code in this value and attack your users and site once it is rendered by the browser. When outputting user data, always escape that data. Stack Overflow covers this as well. In PHP you can do this by using htmlspecialchars(). <?= htmlspecialchars($msg, ENT_QUOTES, 'UTF-8'); ?>

You will notice that the one $_POST variable, $_POST['email'], has left your site wide open to attack. Before you even attempt to use it you should validate it indeed is a valid email address. If it is not, you should report an error and not attempt to use it as it obviously is invalid and useless anyway.

PHP offers an easy way to validate an email addresses. filter_var() with the FILTER_VALIDATE_EMAIL flag will validate if an email address is valid.

$email =$_POST['email'];
if (!filter_var($email, FILTER_VALIDATE_EMAIL)) { // email is invalid. report error and abort. }  On a different note, you start your script off by checking to see if a user is an admin. If they are not you use header() to do a redirect away from that page. That's usually okay but you should follow it with a call to exit() to ensure the script stops executing. If not, the code below may still execute and, combined with other vulnerabilities in the page, leave you open to attack. if ($_SESSION['admin'] !== true) {
exit;
}

To be honest, this code could be used as a teaching aid to demonstrate every possible mistake that could be made in a PHP script.

### A database connection.

It is not your fault, you are following just a terrible outdated example still shown in the PHP manual. Yet, even such a familiar task must be done properly:

• the proper error reporting mode for mysqli must be set
• the proper charset must be set
• the improper error reporting must be wiped from the code. You don't want to show the system error message to every site user.

I even wrote a distinct article, how to use mysqli_connect properly, because, to be honest, there is not a single good example on the whole Internet.

Not to mention that you shouldn't write the same database connection script on the every PHP page. Instead, put it in a file, and then only include this file.

### A non-working query

A query like this $sql = "SELECT * FROM users WHERE email =$email;"; will never return any result, simply because its syntax is wrong. This is another reason to use prepared statements.

### A flawed error reporting.

To let you know, @ symbols is a pure evil that will make your life a nightmare on the long run. Errors must be fixed, not swept under the rug! And in order to fix the error you must be aware of its existence. While @ operator will leave you totally ignorant.

### Superfluous queries

In this code you are running three SELECT queries to the same table. Which is just illogical. Why do you need a $sql = "SELECT * FROM users WHERE email =$email;"; if on the second line you will run almost identical query?

All you need is to use LEFT JOIN in your second query and it will happily serve for both tasks.

And after inserting into password_resets table you are trying to run the second query again. Which is also superfluous, if you care to define the reset timestamp in the script.

### The code refactored.

To sum everything up, here is the database interaction part of your code slightly refactored:

db.php:

mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);
try {
$conn = mysqli_connect("localhost","admin","password","db"); mysqli_set_charset($mysqli, "utf8mb4");
} catch (\mysqli_sql_exception $e) { throw new \mysqli_sql_exception($e->getMessage(), $e->getCode()); }  password reset script (database interaction part) require 'db.php';$msg = '';
if (isset($_POST['submit'])) {$sql = "SELECT * from users
WHERE email=?";
$stmt =$conn->prepare($sql);$stmt->bind_param("s", $_POST['email']);$stmt->execute();
$row =$stmt->get_result()->fetch_assoc();

if (!$row) {$msg = "This email: $email is incorrect"); } else { if (!$row['reset_timestamp']) {
$sql = "INSERT INTO password_resets (user_id, reset_timestamp) VALUES (?, ?);";$stmt = $conn->prepare($sql);
$time = time();$stmt->bind_param("ii", $row['id'],$time);
$stmt->execute();$row['reset_timestamp'] = $time; }$link = ... // here goes your email sending business
}
}

### Overall inconsistency

There are also other issues, like use of $_SESSION['first_name'] and$_SESSION['last_name']. I was under the impression that a password reset code is called when a user do not remember their password and therefore cannot login. In this case I am wondering why there will be their name in the session.

The same confusion is related to the topmost condition: why access to the password reset page should be restricted for the admin use only? In my understanding it must be available to any site user, or otherwise it will be of no value at all.


text:
# SQL syntax

The syntax of the SQL programming language is defined and maintained by ISO/IEC SC 32 as part of ISO/IEC 9075. This standard is not freely available. Despite the existence of the standard, SQL code is not completely portable among different database systems without adjustments.

## Language elements

${\displaystyle \left.{\begin{array}{rl}\scriptstyle {\mathtt {UPDATE~clause}}&\{{\mathtt {UPDATE\ country}}\\\scriptstyle {\mathtt {SET~clause}}&\{{\mathtt {SET\ population=~}}\overbrace {\mathtt {population+1}} ^{\mathtt {expression}}\\\scriptstyle {\mathtt {WHERE~clause}}&\{{\mathtt {WHERE\ \underbrace {{name=}\overbrace {'USA'} ^{expression}} _{predicate};}}\end{array}}\right\}{\scriptstyle {\texttt {statement}}}}$
A chart showing several of the SQL language elements that compose a single statement

The SQL language is subdivided into several language elements, including:

• Clauses, which are constituent components of statements and queries. (In some cases, these are optional.)[1]
• Expressions, which can produce either scalar values, or tables consisting of columns and rows of data
• Predicates, which specify conditions that can be evaluated to SQL three-valued logic (3VL) (true/false/unknown) or Boolean truth values and are used to limit the effects of statements and queries, or to change program flow.
• Queries, which retrieve the data based on specific criteria. This is an important element of SQL.
• Statements, which may have a persistent effect on schemata and data, or may control transactions, program flow, connections, sessions, or diagnostics.
• SQL statements also include the semicolon (";") statement terminator. Though not required on every platform, it is defined as a standard part of the SQL grammar.
• Insignificant whitespace is generally ignored in SQL statements and queries, making it easier to format SQL code for readability.

## Operators

Operator Description Example
= Equal to Author = 'Alcott'
<> Not equal to (many DBMSs accept != in addition to <>) Dept <> 'Sales'
> Greater than Hire_Date > '2012-01-31'
< Less than Bonus < 50000.00
>= Greater than or equal Dependents >= 2
<= Less than or equal Rate <= 0.05
BETWEEN Between an inclusive range Cost BETWEEN 100.00 AND 500.00
LIKE Begins with a character pattern Full_Name LIKE 'Will%'
Contains a character pattern Full_Name LIKE '%Will%'
[NOT] IN Equal to one of multiple possible values DeptCode IN (101, 103, 209)
IS [NOT] NULL Compare to null (missing data) Address IS NOT NULL
IS [NOT] TRUE or IS [NOT] FALSE Boolean truth value test PaidVacation IS TRUE
IS NOT DISTINCT FROM Is equal to value or both are nulls (missing data) Debt IS NOT DISTINCT FROM - Receivables
AS Used to change a column name when viewing results SELECT employee AS "department1"

Other operators have at times been suggested or implemented, such as the skyline operator (for finding only those records that are not 'worse' than any others).

SQL has the case/when/then/else/end expression, which was introduced in SQL-92. In its most general form, which is called a "searched case" in the SQL standard:

CASE WHEN n > 0
THEN 'positive'
WHEN n < 0
THEN 'negative'
ELSE 'zero'
END

SQL tests WHEN conditions in the order they appear in the source. If the source does not specify an ELSE expression, SQL defaults to ELSE NULL. An abbreviated syntax—called "simple case" in the SQL standard—mirrors switch statements:

CASE n WHEN 1
THEN 'One'
WHEN 2
THEN 'Two'
ELSE 'I cannot count that high'
END

This syntax uses implicit equality comparisons, with the usual caveats for comparing with NULL.

There are two short forms for special CASE expressions: COALESCE and NULLIF.

The COALESCE expression returns the value of the first non-NULL operand, found by working from left to right, or NULL if all the operands equal NULL.

COALESCE(x1,x2)

is equivalent to:

CASE WHEN x1 IS NOT NULL THEN x1
ELSE x2
END

The NULLIF expression has two operands and returns NULL if the operands have the same value, otherwise it has the value of the first operand.

NULLIF(x1, x2)

is equivalent to

CASE WHEN x1 = x2 THEN NULL ELSE x1 END

Standard SQL allows two formats for comments: -- comment, which is ended by the first newline, and /* comment */, which can span multiple lines.

## Queries

The most common operation in SQL, the query, makes use of the declarative SELECT statement. SELECT retrieves data from one or more tables, or expressions. Standard SELECT statements have no persistent effects on the database. Some non-standard implementations of SELECT can have persistent effects, such as the SELECT INTO syntax provided in some databases.[2]

Queries allow the user to describe desired data, leaving the database management system (DBMS) to carry out planning, optimizing, and performing the physical operations necessary to produce that result as it chooses.

A query includes a list of columns to include in the final result, normally immediately following the SELECT keyword. An asterisk ("*") can be used to specify that the query should return all columns of the queried tables. SELECT is the most complex statement in SQL, with optional keywords and clauses that include:

• The FROM clause, which indicates the table(s) to retrieve data from. The FROM clause can include optional JOIN subclauses to specify the rules for joining tables.
• The WHERE clause includes a comparison predicate, which restricts the rows returned by the query. The WHERE clause eliminates all rows from the result set where the comparison predicate does not evaluate to True.
• The GROUP BY clause projects rows having common values into a smaller set of rows. GROUP BY is often used in conjunction with SQL aggregation functions or to eliminate duplicate rows from a result set. The WHERE clause is applied before the GROUP BY clause.
• The HAVING clause includes a predicate used to filter rows resulting from the GROUP BY clause. Because it acts on the results of the GROUP BY clause, aggregation functions can be used in the HAVING clause predicate.
• The ORDER BY clause identifies which column[s] to use to sort the resulting data, and in which direction to sort them (ascending or descending). Without an ORDER BY clause, the order of rows returned by an SQL query is undefined.
• The DISTINCT keyword[3] eliminates duplicate data.[4]
• The LIMIT clause specifies the number of records to return.[5] Note that this clause is not supported by all SQL databases.[6]

The clauses of a query have a particular order of execution[7], which is denoted by the number on the right hand side. It is as follows:

 SELECT  5 FROM  1 WHERE  2 GROUP BY  3 HAVING  4 ORDER BY  6

The following example of a SELECT query returns a list of expensive books. The query retrieves all rows from the Book table in which the price column contains a value greater than 100.00. The result is sorted in ascending order by title. The asterisk (*) in the select list indicates that all columns of the Book table should be included in the result set.

SELECT *
FROM  Book
WHERE price > 100.00
ORDER BY title;

The example below demonstrates a query of multiple tables, grouping, and aggregation, by returning a list of books and the number of authors associated with each book.

SELECT Book.title AS Title,
count(*) AS Authors
FROM  Book
JOIN  Book_author
ON  Book.isbn = Book_author.isbn
GROUP BY Book.title;

Example output might resemble the following:

Title                  Authors
---------------------- -------
SQL Examples and Guide 4
The Joy of SQL         1
An Introduction to SQL 2
Pitfalls of SQL        1

Under the precondition that isbn is the only common column name of the two tables and that a column named title only exists in the Book table, one could re-write the query above in the following form:

SELECT title,
count(*) AS Authors
FROM  Book
NATURAL JOIN Book_author
GROUP BY title;

However, many[quantify] vendors either do not support this approach, or require certain column-naming conventions for natural joins to work effectively.

SQL includes operators and functions for calculating values on stored values. SQL allows the use of expressions in the select list to project data, as in the following example, which returns a list of books that cost more than 100.00 with an additional sales_tax column containing a sales tax figure calculated at 6% of the price.

SELECT isbn,
title,
price,
price * 0.06 AS sales_tax
FROM  Book
WHERE price > 100.00
ORDER BY title;

### Subqueries

Queries can be nested so that the results of one query can be used in another query via a relational operator or aggregation function. A nested query is also known as a subquery. While joins and other table operations provide computationally superior (i.e. faster) alternatives in many cases, the use of subqueries introduces a hierarchy in execution that can be useful or necessary. In the following example, the aggregation function AVG receives as input the result of a subquery:

SELECT isbn,
title,
price
FROM  Book
WHERE price < (SELECT AVG(price) FROM Book)
ORDER BY title;

A subquery can use values from the outer query, in which case it is known as a correlated subquery.

Since 1999 the SQL standard allows WITH clauses for subqueries, i.e. named subqueries, usually called common table expressions (also called subquery factoring). CTEs can also be recursive by referring to themselves; the resulting mechanism allows tree or graph traversals (when represented as relations), and more generally fixpoint computations.

### Derived table

A derived table is the use of referencing an SQL subquery in a FROM clause. Essentially, the derived table is a subquery that can be selected from or joined to. The derived table functionality allows the user to reference the subquery as a table. The inline view is also referred to as an inline view or a subselect.

In the following example, the SQL statement involves a join from the initial "Book" table to the derived table "sales". This derived table captures associated book sales information using the ISBN to join to the "Book" table. As a result, the derived table provides the result set with additional columns (the number of items sold and the company that sold the books):

SELECT b.isbn, b.title, b.price, sales.items_sold, sales.company_nm
FROM Book b
JOIN (SELECT SUM(Items_Sold) Items_Sold, Company_Nm, ISBN
FROM Book_Sales
GROUP BY Company_Nm, ISBN) sales
ON sales.isbn = b.isbn

### Null or three-valued logic (3VL)

The concept of Null allows SQL to deal with missing information in the relational model. The word NULL is a reserved keyword in SQL, used to identify the Null special marker. Comparisons with Null, for instance equality (=) in WHERE clauses, results in an Unknown truth value. In SELECT statements SQL returns only results for which the WHERE clause returns a value of True; i.e., it excludes results with values of False and also excludes those whose value is Unknown.

Along with True and False, the Unknown resulting from direct comparisons with Null thus brings a fragment of three-valued logic to SQL. The truth tables SQL uses for AND, OR, and NOT correspond to a common fragment of the Kleene and Lukasiewicz three-valued logic (which differ in their definition of implication, however SQL defines no such operation).[8]

p AND q p
True False Unknown
q True True False Unknown
False False False False
Unknown Unknown False Unknown
p OR q p
True False Unknown
q True True True True
False True False Unknown
Unknown True Unknown Unknown
p = q p
True False Unknown
q True True False Unknown
False False True Unknown
Unknown Unknown Unknown Unknown
q NOT q
True False
False True
Unknown Unknown

There are however disputes about the semantic interpretation of Nulls in SQL because of its treatment outside direct comparisons. As seen in the table above, direct equality comparisons between two NULLs in SQL (e.g. NULL = NULL) return a truth value of Unknown. This is in line with the interpretation that Null does not have a value (and is not a member of any data domain) but is rather a placeholder or "mark" for missing information. However, the principle that two Nulls aren't equal to each other is effectively violated in the SQL specification for the UNION and INTERSECT operators, which do identify nulls with each other.[9] Consequently, these set operations in SQL may produce results not representing sure information, unlike operations involving explicit comparisons with NULL (e.g. those in a WHERE clause discussed above). In Codd's 1979 proposal (which was basically adopted by SQL92) this semantic inconsistency is rationalized by arguing that removal of duplicates in set operations happens "at a lower level of detail than equality testing in the evaluation of retrieval operations".[8] However, computer-science professor <NAME> concluded that "The inconsistencies in the SQL standard mean that it is not possible to ascribe any intuitive logical semantics to the treatment of nulls in SQL."[9]

Additionally, because SQL operators return Unknown when comparing anything with Null directly, SQL provides two Null-specific comparison predicates: IS NULL and IS NOT NULL test whether data is or is not Null.[10] SQL does not explicitly support universal quantification, and must work it out as a negated existential quantification.[11][12][13] There is also the "<row value expression> IS DISTINCT FROM <row value expression>" infixed comparison operator, which returns TRUE unless both operands are equal or both are NULL. Likewise, IS NOT DISTINCT FROM is defined as "NOT (<row value expression> IS DISTINCT FROM <row value expression>)". SQL:1999 also introduced BOOLEAN type variables, which according to the standard can also hold Unknown values. In practice, a number of systems (e.g. PostgreSQL) implement the BOOLEAN Unknown as a BOOLEAN NULL[clarify].

### Data manipulation

The Data Manipulation Language (DML) is the subset of SQL used to add, update and delete data:

• INSERT adds rows (formally tuples) to an existing table, e.g.:
INSERT INTO example
(column1, column2, column3)
VALUES
('test', 'N', NULL);

• UPDATE modifies a set of existing table rows, e.g.:
UPDATE example
SET column1 = 'updated value'
WHERE column2 = 'N';

• DELETE removes existing rows from a table, e.g.:
DELETE FROM example
WHERE column2 = 'N';

• MERGE is used to combine the data of multiple tables. It combines the INSERT and UPDATE elements. It is defined in the SQL:2003 standard; prior to that, some databases provided similar functionality via different syntax, sometimes called "upsert".
 MERGE INTO table_name USING table_reference ON (condition)
WHEN MATCHED THEN
UPDATE SET column1 = value1 [, column2 = value2 ...]
WHEN NOT MATCHED THEN
INSERT (column1 [, column2 ...]) VALUES (value1 [, value2 ...])

### Transaction controls

Transactions, if available, wrap DML operations:

• START TRANSACTION (or BEGIN WORK, or BEGIN TRANSACTION, depending on SQL dialect) marks the start of a database transaction, which either completes entirely or not at all.
• SAVE TRANSACTION (or SAVEPOINT) saves the state of the database at the current point in transaction
CREATE TABLE tbl_1(id int);
INSERT INTO tbl_1(id) VALUES(1);
INSERT INTO tbl_1(id) VALUES(2);
COMMIT;
UPDATE tbl_1 SET id=200 WHERE id=1;
SAVEPOINT id_1upd;
UPDATE tbl_1 SET id=1000 WHERE id=2;
ROLLBACK to id_1upd;
SELECT id from tbl_1;

• COMMIT makes all data changes in a transaction permanent.
• ROLLBACK discards all data changes since the last COMMIT or ROLLBACK, leaving the data as it was prior to those changes. Once the COMMIT statement completes, the transaction's changes cannot be rolled back.

COMMIT and ROLLBACK terminate the current transaction and release data locks. In the absence of a START TRANSACTION or similar statement, the semantics of SQL are implementation-dependent. The following example shows a classic transfer of funds transaction, where money is removed from one account and added to another. If either the removal or the addition fails, the entire transaction is rolled back.

START TRANSACTION;
UPDATE Account SET amount=amount-200 WHERE account_number=1234;
UPDATE Account SET amount=amount+200 WHERE account_number=2345;

IF ERRORS=0 COMMIT;
IF ERRORS<>0 ROLLBACK;

### Data definition

The Data Definition Language (DDL) manages table and index structure. The most basic items of DDL are the CREATE, ALTER, RENAME, DROP and TRUNCATE statements:

• CREATE creates an object (a table, for example) in the database, e.g.:
CREATE TABLE example(
column1 INTEGER,
column2 VARCHAR(50),
column3 DATE NOT NULL,
PRIMARY KEY (column1, column2)
);

• ALTER modifies the structure of an existing object in various ways, for example, adding a column to an existing table or a constraint, e.g.:
ALTER TABLE example ADD column4 INTEGER NOT NULL;

• TRUNCATE deletes all data from a table in a very fast way, deleting the data inside the table and not the table itself. It usually implies a subsequent COMMIT operation, i.e., it cannot be rolled back (data is not written to the logs for rollback later, unlike DELETE).
TRUNCATE TABLE example;

• DROP deletes an object in the database, usually irretrievably, i.e., it cannot be rolled back, e.g.:
DROP TABLE example;

### Data types

Each column in an SQL table declares the type(s) that column may contain. ANSI SQL includes the following data types.[14]

Character strings and national character strings
• CHARACTER(n) (or CHAR(n)): fixed-width n-character string, padded with spaces as needed
• CHARACTER VARYING(n) (or VARCHAR(n)): variable-width string with a maximum size of n characters
• CHARACTER LARGE OBJECT(n [ K | M | G | T ]) (or CLOB(n [ K | M | G | T ])): character large object with a maximum size of n [ K | M | G | T ] characters
• NATIONAL CHARACTER(n) (or NCHAR(n)): fixed width string supporting an international character set
• NATIONAL CHARACTER VARYING(n) (or NVARCHAR(n)): variable-width NCHAR string
• NATIONAL CHARACTER LARGE OBJECT(n [ K | M | G | T ]) (or NCLOB(n [ K | M | G | T ])): national character large object with a maximum size of n [ K | M | G | T ] characters

For the CHARACTER LARGE OBJECT and NATIONAL CHARACTER LARGE OBJECT data types, the multipliers K (1 024), M (1 048 576), G (1 073 741 824) and T (1 099 511 627 776) can be optionally used when specifying the length.

Binary
• BINARY(n): Fixed length binary string, maximum length n.
• BINARY VARYING(n) (or VARBINARY(n)): Variable length binary string, maximum length n.
• BINARY LARGE OBJECT(n [ K | M | G | T ]) (or BLOB(n [ K | M | G | T ])): binary large object with a maximum length n [ K | M | G | T ].

For the BINARY LARGE OBJECT data type, the multipliers K (1 024), M (1 048 576), G (1 073 741 824) and T (1 099 511 627 776) can be optionally used when specifying the length.

Boolean
• BOOLEAN

The BOOLEAN data type can store the values TRUE and FALSE.

Numerical
• INTEGER (or INT), SMALLINT and BIGINT
• FLOAT, REAL and DOUBLE PRECISION
• NUMERIC(precision, scale) or DECIMAL(precision, scale)
• DECFLOAT(precision)

For example, the number 123.45 has a precision of 5 and a scale of 2. The precision is a positive integer that determines the number of significant digits in a particular radix (binary or decimal). The scale is a non-negative integer. A scale of 0 indicates that the number is an integer. For a decimal number with scale S, the exact numeric value is the integer value of the significant digits divided by 10S.

SQL provides the functions CEILING and FLOOR to round numerical values. (Popular vendor specific functions are TRUNC (Informix, DB2, PostgreSQL, Oracle and MySQL) and ROUND (Informix, SQLite, Sybase, Oracle, PostgreSQL, Microsoft SQL Server and Mimer SQL.))

Temporal (datetime)
• DATE: for date values (e.g. 2011-05-03)
• TIME: for time values (e.g. 15:51:36).
• TIME WITH TIME ZONE: the same as TIME, but including details about the time zone in question.
• TIMESTAMP: This is a DATE and a TIME put together in one variable (e.g. 2011-05-03 15:51:36.123456).
• TIMESTAMP WITH TIME ZONE: the same as TIMESTAMP, but including details about the time zone in question.

The SQL function EXTRACT can be used for extracting a single field (seconds, for instance) of a datetime or interval value. The current system date / time of the database server can be called by using functions like CURRENT_DATE, CURRENT_TIMESTAMP, LOCALTIME, or LOCALTIMESTAMP. (Popular vendor specific functions are TO_DATE, TO_TIME, TO_TIMESTAMP, YEAR, MONTH, DAY, HOUR, MINUTE, SECOND, DAYOFYEAR, DAYOFMONTH and DAYOFWEEK.)

Interval (datetime)
• YEAR(precision): a number of years
• YEAR(precision) TO MONTH: a number of years and months
• MONTH(precision): a number of months
• DAY(precision): a number of days
• DAY(precision) TO HOUR: a number of days and hours
• DAY(precision) TO MINUTE: a number of days, hours and minutes
• DAY(precision) TO SECOND(scale): a number of days, hours, minutes and seconds
• HOUR(precision): a number of hours
• HOUR(precision) TO MINUTE: a number of hours and minutes
• HOUR(precision) TO SECOND(scale): a number of hours, minutes and seconds
• MINUTE(precision): a number of minutes
• MINUTE(precision) TO SECOND(scale): a number of minutes and seconds

### Data control

The Data Control Language (DCL) authorizes users to access and manipulate data. Its two main statements are:

• GRANT authorizes one or more users to perform an operation or a set of operations on an object.
• REVOKE eliminates a grant, which may be the default grant.

Example:

GRANT SELECT, UPDATE
ON example
TO some_user, another_user;

REVOKE SELECT, UPDATE
ON example
FROM some_user, another_user;

## Notes

1. ^ ANSI/ISO/IEC International Standard (IS). Database Language SQL—Part 2: Foundation (SQL/Foundation). 1999.
2. ^ "Transact-SQL Reference". SQL Server Language Reference. SQL Server 2005 Books Online. Microsoft. 2007-09-15. Retrieved 2007-06-17.
3. ^ SAS 9.4 SQL Procedure User's Guide. SAS Institute. 2013. p. 248. ISBN 9781612905686. Retrieved 2015-10-21. Although the UNIQUE argument is identical to DISTINCT, it is not an ANSI standard.
4. ^ <NAME>; <NAME> (1999). "Eliminating duplicates - SELECT using DISTINCT". SQL: A Complete Reference. New Delhi: Tata McGraw-Hill Education (published 2008). p. 143. ISBN 9780074637081. Retrieved 2015-10-21. [...] the keyword DISTINCT [...] eliminates the duplicates from the result set.
5. ^ www.techonthenet.com. "SQL: SELECT LIMIT Statement". www.techonthenet.com. Retrieved 2018-02-04.
6. ^ "SQL SELECT TOP, LIMIT, ROWNUM". www.w3schools.com. Retrieved 2018-02-04.
7. ^ "What Is The Order Of Execution Of An SQL Query? - Designcise.com". www.designcise.com. Retrieved 2018-02-04.
8. ^ a b <NAME>. (2003). "Null Values in Relational Databases and Sure Information Answers". Semantics in Databases. Second International Workshop Dagstuhl Castle, Germany, January 7–12, 2001. Revised Papers. Lecture Notes in Computer Science. 2582. pp. 119–138. doi:10.1007/3-540-36596-6_7. ISBN 978-3-540-00957-3.
9. ^ a b
10. ^ ISO/IEC. ISO/IEC 9075-2:2003, "SQL/Foundation". ISO/IEC.
11. ^ "Semantics and problems of universal quantification in SQL". Portal.acm.org. doi:10.1093/comjnl/32.1.90. Retrieved 2017-01-16.
12. ^ "Technique for universal quantification in SQL". Portal.acm.org. doi:10.1145/126482.126484. Retrieved 2017-01-16.
13. ^ <NAME> (2004) Complex quantification in Structured Query Language (SQL): a tutorial using relational calculus; Journal of Computers in Mathematics and Science Teaching ISSN 0731-9258 Volume 23, Issue 2, 2004 AACE Norfolk, Virginia. Thefreelibrary.com
14. ^


text:
# Find if nCr is divisible by the given prime in C++

C++Server Side ProgrammingProgramming

Suppose there are three variables N, R and P. The N and R are used to get the NCR and P is a prime. We have to find whether NCR is divisible by P. Suppose we have some numbers N = 7, R = 2 and P = 3, then 7C2 = 21, this is divisible by 3, so the output will be true.

We know that NCR = N! / (R! * (N – R)! ). We will use Legendre Formula to largest power of P, which divides any N!, R! and (N – R)! in order to NCR to be divisible by P, the condition is N! > R! + (N - R)!

## Example

Live Demo

#include <iostream>
using namespace std;
int getPower(int n, int p) {
int pow = 0;
while (n) {
n /= p;
pow += n;
}
return pow;
}
bool isDivisibleByP(int n, int r, int p) {
// Find the highest powers of p
// that divide n!, r! and (n - r)!
int x1 = getPower(n, p);
int x2 = getPower(r, p);
int x3 = getPower(n - r, p);
if (x1 > x2 + x3)
return true;
return false;
}
int main() {
int n = 7, r = 2, p = 7;
if (isDivisibleByP(n, r, p))
cout << "nCr is divisible by P";
else
cout << "nCr is not divisible by P";
}

## Output

nCr is divisible by P
Updated on 21-Oct-2019 07:52:50