| Contents | Prev | Next | Index | Java Language Specification Second Edition |
CHAPTER 13
Development tools for the Java programming language should support automatic recompilation as necessary whenever source code is available. Particular implementations may also store the source and binary of types in a versioning database and implement a ClassLoader
that uses integrity mechanisms of the database to prevent linkage errors by providing binary-compatible versions of types to clients.
Developers of packages and classes that are to be widely distributed face a different set of problems. In the Internet, which is our favorite example of a widely distributed system, it is often impractical or impossible to automatically recompile the pre-existing binaries that directly or indirectly depend on a type that is to be changed. Instead, this specification defines a set of changes that developers are permitted to make to a package or to a class or interface type while preserving (not breaking) compatibility with existing binaries.
The paper quoted above appears in Proceedings of OOPSLA '95, published as ACM SIGPLAN Notices, Volume 30, Number 10, October 1995, pages 426-438. Within the framework of that paper, Java programming language binaries are binary compatible under all relevant transformations that the authors identify (with some caveats with respect to the addition of instance variables). Using their scheme, here is a list of some important binary compatible changes that the Java programming language supports:
private
fields, methods, or constructors of a class.
We encourage development systems to provide facilities that alert developers to the impact of changes on pre-existing binaries that cannot be recompiled.
This chapter first specifies some properties that any binary format for the Java programming language must have (§13.1). It next defines binary compatibility, explaining what it is and what it is not (§13.2). It finally enumerates a large set of possible changes to packages (§13.3), classes (§13.4) and interfaces (§13.5), specifying which of these changes are guaranteed to preserve binary compatibility and which are not.
class
file format specified by the The Java Virtual Machine Specification, Second Edition, or into a representation that can be mapped into that format by a class loader written in the Java programming language. Furthermore, the resulting class
file must have certain properties. A number of these properties are specifically chosen to support source code transformations that preserve binary compatibility.
super
.f then the superclass of C is the qualifying type of the reference.
final
and initialized with compile-time constant expressions are resolved at compile time to the constant value that is denoted. No reference to such a constant field should be present in the code in a binary file (except in the class or interface containing the constant field, which will have code to initialize it), and such constant fields must always appear to have been initialized; the default initial value for the type of such a field must never be observed. See §13.4.8 for a discussion.
Object
then the qualifying type of the expression is Object
. Otherwise:
super
.m then the superclass of C is the qualifying type of the method invocation.
void
and does not return a value. The signature of a method must include all of the following:
new
D(...) or X.new D(...), then the qualifying type of the invocation is D.
this
(...), then the qualifying type of the expression is C.
Object
, then a symbolic reference to the direct superclass of this class
class
file format support these changes. Any other valid binary format, such as a compressed or encrypted representation that is mapped back into class files by a class loader under the above requirements will necessarily support these changes as well. Binaries are compiled to rely on the accessible members and constructors of other classes and interfaces. To preserve binary compatibility, a class or interface should treat its accessible members and constructors, their existence and behavior, as a contract with its users.
The Java programming language is designed to prevent additions to contracts and accidental name collisions from breaking binary compatibility; specifically:
Changes in top-level class and interface types that are not public
and that are not a superclass or superinterface, respectively, of a public
type, affect only types within the package in which they are declared. Such types may be deleted or otherwise changed, even if incompatibilities are otherwise described here, provided that the affected binaries of that package are updated together.
abstract
Classesabstract
is changed to be declared abstract
, then pre-existing binaries that attempt to create new instances of that class will throw either an InstantiationError
at link time, or (if a reflective method is used) an InstantiationException
at run time; such a change is therefore not recommended for widely distributed classes.
Changing a class that was declared abstract
to no longer be declared abstract
does not break compatibility with pre-existing binaries.
final
Classesfinal
is changed to be declared final
, then a VerifyError
is thrown if a binary of a pre-existing subclass of this class is loaded, because final
classes can have no subclasses; such a change is not recommended for widely distributed classes.
Changing a class that was declared final
to no longer be declared final
does not break compatibility with pre-existing binaries.
public
Classespublic
to be declared public
does not break compatibility with pre-existing binaries.
If a class that was declared public
is changed to not be declared public
, then an IllegalAccessError
is thrown if a pre-existing binary is linked that needs but no longer has access to the class type; such a change is not recommended for widely distributed classes.
ClassCircularityError
is thrown at load time if a class would be a superclass of itself. Changes to the class hierarchy that could result in such a circularity when newly compiled binaries are loaded with pre-existing binaries are not recommended for widely distributed classes.Changing the direct superclass or the set of direct superinterfaces of a class type will not break compatibility with pre-existing binaries, provided that the total set of superclasses or superinterfaces, respectively, of the class type loses no members.
If a change to the direct superclass or the set of direct superinterfaces results in any class or interface no longer being a superclass or superinterface, respectively, then link-time errors may result if pre-existing binaries are loaded with the binary of the modified class. Such changes are not recommended for widely distributed classes.
For example, suppose that the following test program:
is compiled and executed, producing the output:class Hyper { char h = 'h'; } class Super extends Hyper { char s = 's'; } class Test extends Super { public static void main(String[] args) { Hyper h = new Super(); System.out.println(h.h); } }
Suppose that a new version of classh
Super
is then compiled:
This version of classclass Super { char s = 's'; }
Super
is not a subclass of Hyper
. If we then run the existing binaries of Hyper
and Test
with the new version of Super
, then a VerifyError
is thrown at link time. The verifier objects because the result of new
Super()
cannot be assigned to a variable of type Hyper
, because Super
is not a subclass of Hyper
.It is instructive to consider what might happen without the verification step: the program might run and print:
This demonstrates that without the verifier the type system could be defeated by linking inconsistent binary files, even though each was produced by a correct Java compiler.s
The lesson is that an implementation that lacks a verifier or fails to use it will not maintain type safety and is, therefore, not a valid implementation.
static
) member that has the same name, accessibility, (for fields) or same name, accessibility, signature, and return type (for methods) as an instance (respectively static
) member of a superclass or subclass. No error occurs even if the set of classes being linked would encounter a compile-time error.
Deleting a class member or constructor that is not declared private
may cause a linkage error if the member or constructor is used by a pre-existing binary.
is compiled and executed, it produces the output:class Hyper { void hello() { System.out.println("hello from Hyper"); } } class Super extends Hyper { void hello() { System.out.println("hello from Super"); } } class Test { public static void main(String[] args) { new Super().hello(); } }
Suppose that a new version of classhello from Super
Super
is produced:
then recompilingclass Super extends Hyper { }
Super
and executing this new binary with the original binaries for Test
and Hyper
produces the output:
as expected.hello from Hyper
The super
keyword can be used to access a method declared in a superclass, bypassing any methods declared in the current class. The expression:
is resolved, at compile time, to a method M in the superclass S. If the method M is an instance method, then the method MR invoked at run time is the method with the same signature as M that is a member of the direct superclass of the class containing the expression involvingsuper.Identifier
super
. Thus, if the program:
is compiled and executed, it produces the output:class Hyper { void hello() { System.out.println("hello from Hyper"); } } class Super extends Hyper { } class Test extends Super { public static void main(String[] args) { new Test().hello(); } void hello() { super.hello(); } }
Suppose that a new version of classhello from Hyper
Super
is produced:
Ifclass Super extends Hyper { void hello() { System.out.println("hello from Super"); } }
Super
and Hyper
are recompiled but not Test
, then running the new binaries with the existing binary of Test
produces the output:
as you might expect. (A flaw in some early implementations caused them to print:hello from Super
incorrectly.)hello from Hyper
private
access; from protected
access to default or private
access; or from public
access to protected
, default, or private
access. Changing a member or constructor to permit less access is therefore not recommended for widely distributed classes.Perhaps surprisingly, the binary format is defined so that changing a member or constructor to be more accessible does not cause a linkage error when a subclass (already) defines a method to have less access.
So, for example, if the package points
defines the class Point
:
used by thepackage points; public class Point { public int x, y; protected void print() { System.out.println("(" + x + "," + y + ")"); } }
Test
program:
then these classes compile andclass Test extends points.Point { protected void print() { System.out.println("Test"); } public static void main(String[] args) { Test t = new Test(); t.print(); } }
Test
executes to produce the output:
If the methodTest
print
in class Point
is changed to be public
, and then only the Point
class is recompiled, and then executed with the previously existing binary for Test
then no linkage error occurs, even though it is improper, at compile time, for a public
method to be overridden by a protected
method (as shown by the fact that the class Test
could not be recompiled using this new Point
class unless print were changed to be public
.)
Allowing superclasses to change protected
methods to be public
without breaking binaries of preexisting subclasses helps make binaries less fragile. The alternative, where such a change would cause a linkage error, would create additional binary incompatibilities.
Assume a reference to a field f with qualifying type T. Assume further that f is in fact an instance (respectively static
) field declared in a superclass of T, S, and that the type of f is X. If a new field of type X with the same name as f is added to a subclass of S that is a superclass of T or T itself, then a linkage error may occur. Such a linkage error will occur only if, in addition to the above, either one of the following conditions hold:
static
(respectively instance) field.
Thus compiling and executing the code:
produces the output:class Hyper { String h = "hyper"; } class Super extends Hyper { String s = "super"; } class Test { public static void main(String[] args) { System.out.println(new Super().h); } }
Changinghyper
Super
to be defined as:
recompilingclass Super extends Hyper { String s = "super"; int h = 0; }
Hyper
and Super
, and executing the resulting new binaries with the old binary of Test
produces the output:
The fieldhyper
h
of Hyper
is output by the original binary of main
. While this may seem surprising at first, it serves to reduce the number of incompatibilities that occur at run time. (In an ideal world, all source files that needed recompilation would be recompiled whenever any one of them changed, eliminating such surprises. But such a mass recompilation is often impractical or impossible, especially in the Internet. And, as was previously noted, such recompilation would sometimes require further changes to the source code.)As an example, if the program:
is compiled and executed, it produces the output:class Hyper { String h = "Hyper"; } class Super extends Hyper { } class Test extends Super { public static void main(String[] args) { String s = new Test().h; System.out.println(s); } }
Suppose that a new version of classHyper
Super
is then compiled:
If the resulting binary is used with the existing binaries forclass Super extends Hyper { char h = 'h'; }
Hyper
and Test
, then the output is still:
even though compiling the source for these binaries:Hyper
would result in a compile-time error, because theclass Hyper { String h = "Hyper"; } class Super extends Hyper { char h = 'h'; } class Test extends Super { public static void main(String[] args) { String s = new Test().h; System.out.println(s); } }
h
in the source code for main
would now be construed as referring to the char
field declared in Super
, and a char
value can't be assigned to a String
.
Deleting a field from a class will break compatibility with any pre-existing binaries that reference this field, and a NoSuchFieldError
will be thrown when such a reference from a pre-existing binary is linked. Only private
fields may be safely deleted from a widely distributed class.
final
Fields and Constantsfinal
is changed to be final
, then it can break compatibility with pre-existing binaries that attempt to assign new values to the field.
is compiled and executed, it produces the output:class Super { static char s; } class Test extends Super { public static void main(String[] args) { s = 'a'; System.out.println(s); } }
Suppose that a new version of classa
Super
is produced:
Ifclass Super { final static char s = 'b'; }
Super
is recompiled but not Test
, then running the new binary with the existing binary of Test
results in a IllegalAccessError
.
Deleting the keyword final
or changing the value to which a field is initialized does not break compatibility with existing binaries.
If a field is a compile-time constant, then deleting the keyword final
or changing its value will not break compatibility with pre-existing binaries by causing them not to run, but they will not see any new value for the constant unless they are recompiled.
is compiled and executed, it produces the output:class Flags { final static boolean debug = true; } class Test { public static void main(String[] args) { if (Flags.debug) System.out.println("debug is true"); } }
Suppose that a new version of classdebug is true
Flags
is produced:
Ifclass Flags { final static boolean debug = false; }
Flags
is recompiled but not Test
, then running the new binary with the existing binary of Test
produces the output:
because the value ofdebug is true
debug
was a compile-time constant, and could have been used in compiling Test
without making a reference to the class Flags
.This result is a side-effect of the decision to support conditional compilation, as discussed at the end of §14.20.
This behavior would not change if Flags
were changed to be an interface, as in the modified example:
(One reason for requiring inlining of constants is thatinterface Flags { boolean debug = true; } class Test { public static void main(String[] args) { if (Flags.debug) System.out.println("debug is true"); } }
switch
statements require constants on each case
, and no two such constant values may be the same. The compiler checks for duplicate constant values in a switch
statement at compile time; the class
file format does not do symbolic linkage of case
values.)
The best way to avoid problems with "inconstant constants" in widely-distributed code is to declare as compile time constants only values which truly are unlikely ever to change. Many compile time constants in interfaces are small integer values replacing enumerated types, which the language does not support; these small values can be chosen arbitrarily, and should not need to be changed. Other than for true mathematical constants, we recommend that source code make very sparing use of class variables that are declared static
and final
. If the read-only nature of final
is required, a better choice is to declare a private
static
variable and a suitable accessor method to get its value. Thus we recommend:
rather than:private static int N; public static int getN() { return N; }
There is no problem with:public static final int N = ...;
ifpublic static int N = ...;
N
need not be read-only. We also recommend, as a general rule, that only truly constant values be declared in interfaces. We note, but do not recommend, that if a field of primitive type of an interface may change, its value may be expressed idiomatically as in:
insuring that this value is not a constant. Similar idioms exist for the other primitive types.interface Flags { boolean debug = new Boolean(true).booleanValue(); }
One other thing to note is that static
final
fields that have constant values (whether of primitive or String
type) must never appear to have the default initial value for their type (§4.5.5). This means that all such fields appear to be initialized first during class initialization (§<IP_ADDRESS>, §9.3.1, §12.4.2).
static
Fieldsprivate
was not declared static
and is changed to be declared static
, or vice versa, then a linkage time error, specifically an IncompatibleClassChangeError
, will result if the field is used by a preexisting binary which expected a field of the other kind. Such changes are not recommended in code that has been widely distributed.transient
Fieldstransient
modifier of a field does not break compatibility with pre-existing binaries.
Assume a reference to a method m with qualifying type T. Assume further that m is in fact an instance (respectively static
) method declared in a superclass of T, S. If a new method of type X with the same signature and return type as m is added to a subclass of S that is a superclass of T or T itself, then a linkage error may occur. Such a linkage error will occur only if, in addition to the above, either one of the following conditions hold:
static
(respectively instance) method.
NoSuchMethodError
may be thrown when such a reference from a pre-existing binary is linked. Such an error will occur only if no method with a matching signature and return type is declared in a superclass. If the source code for a class contains no declared constructors, the Java compiler automatically supplies a constructor with no parameters. Adding one or more constructor declarations to the source code of such a class will prevent this default constructor from being supplied automatically, effectively deleting a constructor, unless one of the new constructors also has no parameters, thus replacing the default constructor. The automatically supplied constructor with no parameters is given the same access modifier as the class of its declaration, so any replacement should have as much or more access if compatibility with pre-existing binaries is to be preserved.
void
, or replacing void
with a result type has the combined effect of deleting the old method and adding a new method with the new result type or newly void
result (see §13.4.11).abstract
Methodsabstract
to no longer be declared abstract
does not break compatibility with pre-existing binaries.
Changing a method that is not declared abstract
to be declared abstract
will break compatibility with pre-existing binaries that previously invoked the method, causing an AbstractMethodError
.
is compiled and executed, it produces the output:class Super { void out() { System.out.println("Out"); } } class Test extends Super { public static void main(String[] args) { Test t = new Test(); System.out.println("Way "); t.out(); } }
Suppose that a new version of classWay Out
Super
is produced:
Ifabstract class Super { abstract void out(); }
Super
is recompiled but not Test
, then running the new binary with the existing binary of Test
results in a AbstractMethodError
, because class Test
has no implementation of the method out
, and is therefore is (or should be) abstract. final
Methodsfinal
to be final
may break compatibility with existing binaries that depend on the ability to override the method.
is compiled and executed, it produces the output:class Super { void out() { System.out.println("out"); } } class Test extends Super { public static void main(String[] args) { Test t = new Test(); t.out(); } void out() { super.out(); } }
Suppose that a new version of classout
Super
is produced:
Ifclass Super { final void out() { System.out.println("!"); } }
Super
is recompiled but not Test
, then running the new binary with the existing binary of Test
results in a VerifyError
because the class Test
improperly tries to override the instance method out
.
Changing a class (static
) method that is not final
to be final
does not break compatibility with existing binaries, because the method could not have been overridden.
Removing the final
modifier from a method does not break compatibility with pre-existing binaries.
native
Methodsnative
modifier of a method does not break compatibility with pre-existing binaries.
The impact of changes to types on preexisting native
methods that are not recompiled is beyond the scope of this specification and should be provided with the description of an implementation. Implementations are encouraged, but not required, to implement native
methods in a way that limits such impact.
static
Methodsprivate
was declared static
(that is, a class method) and is changed to not be declared static
(that is, to an instance method), or vice versa, then compatibility with pre-existing binaries may be broken, resulting in a linkage time error, namely an IncompatibleClassChangeError
, if these methods are used by the pre-existing binaries. Such changes are not recommended in code that has been widely distributed.synchronized
Methodssynchronized
modifier of a method does not break compatibility with existing binaries.throws
clause of methods or constructors do not break compatibility with existing binaries; these clauses are checked only at compile time.We note that a compiler cannot expand a method inline at compile time.
The keyword final
on a method does not mean that the method can be safely inlined; it means only that the method cannot be overridden. It is still possible that a new version of that method will be provided at link time. Furthermore, the structure of the original program must be preserved for purposes of reflection.
In general we suggest that implementations use late-bound (run-time) code generation and optimization.
While adding a new overloaded method or constructor may cause a compile-time error the next time a class or interface is compiled because there is no method or constructor that is most specific (§<IP_ADDRESS>), no such error occurs when a program is executed, because no overload resolution is done at execution time.
is compiled and executed, it produces the output:class Super { static void out(float f) { System.out.println("float"); } } class Test { public static void main(String[] args) { Super.out(2); } }
Suppose that a new version of classfloat
Super
is produced:
Ifclass Super { static void out(float f) { System.out.println("float"); } static void out(int i) { System.out.println("int"); } }
Super
is recompiled but not Test
, then running the new binary with the existing binary of Test
still produces the output:
However, iffloat
Test
is then recompiled, using this new Super
, the output is then:
as might have been naively expected in the previous case.int
public
Interfacespublic
to be declared public
does not break compatibility with pre-existing binaries.
If an interface that is declared public
is changed to not be declared public
, then an IllegalAccessError
is thrown if a pre-existing binary is linked that needs but no longer has access to the interface type, so such a change is not recommended for widely distributed interfaces.
VerifyError
.IncompatibleClassChangeError
will result. If the original reference was an assignment, an IllegalAccessError
will result.Deleting a member from an interface may cause linkage errors in pre-existing binaries.
is compiled and executed, it produces the output:interface I { void hello(); } class Test implements I { public static void main(String[] args) { I anI = new Test(); anI.hello(); } public void hello() { System.out.println("hello"); } }
Suppose that a new version of interfacehello
I
is compiled:
Ifinterface I { }
I
is recompiled but not Test
, then running the new binary with the existing binary for Test
will result in a NoSuchMethodError
. (In some early implementations this program still executed; the fact that the method hello
no longer exists in interface I
was not correctly detected.)static
final
fields in classes, as described in §13.4.7 and §13.4.8.abstract
methods in classes, as described in §13.4.12, §13.4.13, §13.4.19, and §13.4.21.
| Contents | Prev | Next | Index | Java Language Specification Second Edition |


Home
About Us
Products
BiteMe
BiteMe is a bakery shop that sells a selection of delicious cakes, cookies, and pastries. Made from organic and 100% gluten free.
Our Products
Cakes
Cookies
Pastries


Chapter 13 Pliable Lasso
13.1 Goals
- Demonstrate how to fit a complex model
- Show how to apply an atom along a row/column axis
13.2 Pliable Lasso Problem
Robert J. Tibshirani and Friedman (2017) propose a generalization of the lasso that allows the model coefficients to vary as a function of a general set of modifying variables, such as gender, age, and time. The pliable lasso model has the form
\[ \begin{equation} \hat{y} = \beta_0{\mathbf 1} + Z\theta_0 + \sum_{j=1}^p(X_j\beta_j + W_j\theta_j), \end{equation} \]
where \(\hat{y}\) is the predicted \(N\times1\) vector, \(\beta_0\) is a scalar, \(\theta_0\) is a \(K\)-vector, \(X\) and \(Z\) are \(N\times p\) and \(N\times K\) matrices containing values of the predictor and modifying variables, respectively, and \(W_j=X_j \circ Z\) denotes the elementwise multiplication of \(Z\) by column \(X_j\) of \(X\).
The objective function used for pliable lasso is
\[ J(\beta_0, \theta_0, \beta, \Theta) = \frac{1}{2N}\sum_{i=1}^N (y_i-\hat{y}_i)^2 + (1-\alpha)\lambda\sum_{j=1}^p\biggl(||(\beta_j,\theta_j)||_2 + ||\theta_j||_2\biggr) + \alpha\lambda\sum_{j,k}|\theta_{j,k}|_1. \]
In the above, \(\Theta\) is a \(p\times K\) matrix of parameters with \(j\)-th row \(\theta_j\) and individual entries \(\theta_{j,k}\), and \(\alpha\) and \(\lambda\) are tuning parameters. As \(\alpha \rightarrow 1\) (but \(<1\)), the solution approaches the lasso solution. The default value used in the paper is \(\alpha = 0.5.\)
An R package for the pliable lasso is forthcoming from the
authors. Nevertheless, the pliable lasso is an excellent example to
highlight the prototyping capabilities of CVXR
for research. Along
the way, we also introduce some new atoms that are needed in this example.
13.3 Example
We will use a simulated example from Section 3 of Robert J. Tibshirani and Friedman (2017) with \(n=100\), \(p=50\) and \(K=4\). The response is generated as
\[ \begin{eqnarray*} y &=& \mu(x) + 0.5\epsilon;\ \ \epsilon \sim N(0, 1)\\ \mu(x) &=& x_1\beta_1 + x_2\beta_2 + x_3(\beta_3 e + 2z_1) + x_4\beta_4(e - 2z_2);\ \ \beta = (2, -2, 2, 2, 0, 0, \ldots), \end{eqnarray*} \] where \(e=(1,1,\ldots ,1)^T\).
## Simulation data.
set.seed(123)
<- 100
N <- 4
K <- 50
p <- matrix(rnorm(n = N * p, mean = 0, sd = 1), nrow = N, ncol = p)
X <- matrix(rbinom(n = N * K, size = 1, prob = 0.5), nrow = N, ncol = K)
Z
## Response model.
<- rep(x = 0, times = p)
beta 1:4] <- c(2, -2, 2, 2)
beta[<- cbind(beta[1], beta[2], beta[3] + 2 * Z[, 1], beta[4] * (1 - 2 * Z[, 2]))
coeffs <- diag(X[, 1:4] %*% t(coeffs))
mu <- mu + 0.5 * rnorm(N, mean = 0, sd = 1) y
It seems worthwhile to write a function that will fit the model for us so that we can customize a few things such as the intercept term, verbosity, etc. The function has the following structure with comments as placeholders for code we shall construct later.
<- function(y, X, Z, lambda, alpha = 0.5, intercept = TRUE,
plasso_fit ZERO_THRESHOLD= 1e-6, verbose = FALSE) {
<- length(y)
N <- ncol(X)
p <- ncol(Z)
K
<- 0
beta0 if (intercept) {
<- Variable(1) * matrix(1, nrow = N, ncol = 1)
beta0
}## Define_Parameters
## Build_Penalty_Terms
## Compute_Fitted_Value
## Build_Objective
## Define_and_Solve_Problem
## Return_Values
}
## Fit pliable lasso using CVXR.
# pliable <- pliable_lasso(y, X, Z, alpha = 0.5, lambda = lambda)
13.3.1 Parameters
The parameters are easy: we just have \(\beta\), \(\theta_0\) and \(\Theta\).
<- Variable(p)
beta <- Variable(K)
theta0 <- Variable(p, K); theta_transpose <- t(theta) theta
Note that we also define the transpose of \(\Theta\) for use later.
13.3.2 Penalty Terms
There are three of them. The first term in the parentheses,
\(\sum_{j=1}^p\biggl(||(\beta_j,\theta_j)||_2\biggr)\), involves components of
\(\beta\) and rows of \(\Theta\). CVXR
provides two functions to express
this norm:
hstack
to bind columns of \(\beta\) and the matrix \(\Theta\), the equivalent ofrbind
in R,cvxr_norm
, which accepts a matrix variable and anaxis
denoting the axis along which the norm is to be taken. The penalty requires us to use the row axis, soaxis = 1
per the usual R convention.
The second term in the parentheses, \(\sum_{j}||\theta_j||_2\), is also a norm along rows as the \(\theta_j\) are rows of \(\Theta\). The last term is simply a \(l_1\)-norm.
<- sum(cvxr_norm(hstack(beta, theta), 2, axis = 1))
penalty_term1 <- sum(cvxr_norm(theta, 2, axis = 1))
penalty_term2 <- sum(cvxr_norm(theta, 1)) penalty_term3
13.3.3 Fitted Value
Equation 1 above for \(\hat{y}\) contains a sum:
\(\sum_{j=1}^p(X_j\beta_j + W_j\theta_j)\). This requires multiplication
of \(Z\) by the columns of \(X\) component-wise and is thus a natural candidate
for a map-reduce combination: map the column multiplication function
appropriately and reduce using +
to obtain the XZ_term
below.
<- lapply(seq_len(p),
xz_theta function(j) (matrix(X[, j], nrow = N, ncol = K) * Z) %*% theta_transpose[, j])
<- Reduce(f = '+', x = xz_theta)
XZ_term <- beta0 + X %*% beta + Z %*% theta0 + XZ_term y_hat
13.3.4 Objective Function
Building the objective is now straightforward.
<- sum_squares(y - y_hat) / (2 * N) +
objective 1 - alpha) * lambda * (penalty_term1 + penalty_term2) +
(* lambda * penalty_term3 alpha
13.3.5 Solving the Problem
<- Problem(Minimize(objective))
prob <- solve(prob, verbose = verbose)
result <- result$getValue(beta) beta_hat
13.3.6 Return Values
We create a list with values of interest to us. However, since
sparsity is desired, we set values below ZERO_THRESHOLD
to
zero.
<- result$getValue(theta0)
theta0_hat <- result$getValue(theta)
theta_hat
## Zero out stuff before returning
abs(beta_hat) < ZERO_THRESHOLD] <- 0.0
beta_hat[abs(theta0_hat) < ZERO_THRESHOLD] <- 0.0
theta0_hat[abs(theta_hat) < ZERO_THRESHOLD] <- 0.0
theta_hat[list(beta0_hat = if (intercept) result$getValue(beta0)[1] else 0.0,
beta_hat = beta_hat,
theta0_hat = theta0_hat,
theta_hat = theta_hat,
criterion = result$value)
13.4 Full Function
We now put it all together.
<- function(y, X, Z, lambda, alpha = 0.5, intercept = TRUE,
plasso_fit ZERO_THRESHOLD= 1e-6, verbose = FALSE) {
<- length(y)
N <- ncol(X)
p <- ncol(Z)
K
<- 0
beta0 if (intercept) {
<- Variable(1) * matrix(1, nrow = N, ncol = 1)
beta0
}<- Variable(p)
beta <- Variable(K)
theta0 <- Variable(p, K); theta_transpose <- t(theta)
theta <- sum(cvxr_norm(hstack(beta, theta), 2, axis = 1))
penalty_term1 <- sum(cvxr_norm(theta, 2, axis = 1))
penalty_term2 <- sum(cvxr_norm(theta, 1))
penalty_term3 <- lapply(seq_len(p),
xz_theta function(j) (matrix(X[, j], nrow = N, ncol = K) * Z) %*% theta_transpose[, j])
<- Reduce(f = '+', x = xz_theta)
XZ_term <- beta0 + X %*% beta + Z %*% theta0 + XZ_term
y_hat <- sum_squares(y - y_hat) / (2 * N) +
objective 1 - alpha) * lambda * (penalty_term1 + penalty_term2) +
(* lambda * penalty_term3
alpha <- Problem(Minimize(objective))
prob <- solve(prob, verbose = verbose)
result <- result$getValue(beta)
beta_hat <- result$getValue(theta0)
theta0_hat <- result$getValue(theta)
theta_hat
## Zero out stuff before returning
abs(beta_hat) < ZERO_THRESHOLD] <- 0.0
beta_hat[abs(theta0_hat) < ZERO_THRESHOLD] <- 0.0
theta0_hat[abs(theta_hat) < ZERO_THRESHOLD] <- 0.0
theta_hat[list(beta0_hat = if (intercept) result$getValue(beta0)[1] else 0.0,
beta_hat = beta_hat,
theta0_hat = theta0_hat,
theta_hat = theta_hat,
criterion = result$value)
}
13.5 Results
Using \(\lambda = 0.6\), we fit the pliable lasso without an intercept.
<- plasso_fit(y, X, Z, lambda = 0.6, alpha = 0.5, intercept = FALSE) result
We can print the various estimates.
cat(sprintf("Objective value: %f\n", result$criterion))
## Objective value: 4.153289
We only print the nonzero \(\beta\) values.
<- which(result$beta_hat != 0)
index <- data.frame(matrix(result$beta_hat[index], nrow = 1))
est.table names(est.table) <- paste0("$\\beta_{", index, "}$")
::kable(est.table, format = "html", digits = 3) %>%
knitrkable_styling("striped")
| \(\beta_{1}\) | \(\beta_{2}\) | \(\beta_{3}\) | \(\beta_{4}\) | \(\beta_{20}\) |
|---|---|---|---|---|
| 1.716 | -1.385 | 2.217 | 0.285 | -0.038 |
For this value of \(\lambda\), the nonzero \((\beta_1, \beta_2, \beta_3,\beta_4)\) are picked up along with a few others like \((\beta_{20}, \beta_{34},\beta_{39})\).
The values for \(\theta_0\) are given below.
<- data.frame(matrix(result$theta0_hat, nrow = 1))
est.table names(est.table) <- paste0("$\\theta_{0,", 1:K, "}$")
::kable(est.table, format = "html", digits = 3) %>%
knitrkable_styling("striped")
| \(\theta_{0,1}\) | \(\theta_{0,2}\) | \(\theta_{0,3}\) | \(\theta_{0,4}\) |
|---|---|---|---|
| -0.136 | 0.25 | -0.516 | 0.068 |
Finally, we display just the first five rows of \(\Theta\), which happen to contain all the nonzero values for this result.
<- data.frame(result$theta_hat[1:5, ])
est.table names(est.table) <- paste0("$\\theta_{,", 1:K, "}$")
::kable(est.table, format = "html", digits = 3) %>%
knitrkable_styling("striped")
| \(\theta_{,1}\) | \(\theta_{,2}\) | \(\theta_{,3}\) | \(\theta_{,4}\) |
|---|---|---|---|
| 0.000 | 0.000 | 0.000 | 0.000 |
| 0.000 | 0.000 | 0.000 | 0.000 |
| 0.528 | 0.000 | 0.085 | 0.308 |
| 0.063 | -0.592 | -0.019 | -0.185 |
| 0.000 | 0.000 | 0.000 | 0.000 |
13.6 Final Comments
Typically, one would run the fits for various values of \(\lambda\),
choose one based on cross-validation, and assess the prediction against
a test set. Here, even a single fit takes a while, but techniques
discussed previously can be used to speed up the
computations. However, the potential of CVXR
in prototyping novel
methods is clear.


This game part of the classic games, please visit that page first for general information about these games.
| Actions | Agents | Manual Control | Action Shape | Action Values | Observation Shape | Observation Values | Num States |
|---|---|---|---|---|---|---|---|
| Discrete | 2 | No | Discrete(61) | Discrete(61) | (7, 4, 15) | [0, 1] | 10^163 |
from pettingzoo.classic import uno_v0
agents= ['player_0', 'player_1']
AEC Diagram
Uno is shedding game involving 2 players. At the beginning, each player receives 7 cards and the winner is determined as the first player with no cards left. In order to get rid of a card, a player must match either the color and number of the card on top of the discard pile. If the player does not have a card to discard, then it will take a card from the Draw pile. The deck of cards include 4 colors (blue, green, yellow, and red), 10 numbers (0 to 9), and special cards (Wild Draw Four, Skip, Reverse).
Our implementation wraps RLCard and you can refer to its documentation for additional details. Please cite their work if you use this game in research.
uno.env(seed=None)
seed: seed for random values. Set to None to use machine random source. Set to fixed value for deterministic behavior
The observation space has a shape of (7, 4, 15). The first index represent the plane, the second index the color, and the last index the card number (including any special card).
| Plane | Feature |
|---|---|
| 0 | Player’s Hand with 0 cards of the same color and number |
| 1 | Player’s Hand with 1 card of the same color and number |
| 2 | Player’s Hand with 2 cards of the same color and number |
| 3 | Target card (top of the Discard pile) |
| 4 | Opponent’s Hand with 0 cards of the same color and number |
| 5 | Opponent’s Hand with 1 cards of the same color and number |
| 6 | Opponent’s Hand with 2 cards of the same color and number |
| Plane Row Index | Description |
|---|---|
| 0 | Red |
| 1 | Green |
| 2 | Blue |
| 3 | Yellow |
| Plane Column Index | Description |
|---|---|
| 0 | 0 |
| 1 | 1 |
| 2 | 2 |
| … | … |
| 9 | 9 |
| 10 | Wild |
| 11 | Wild Draw Four |
| 12 | Skip |
| 13 | Draw Two |
| 14 | Reverse |
The action space is as described by RLCards.
| Action ID | Action |
|---|---|
| 0 - 9 | Red number cards0 : 0-Red, 1 : 1-Red, …, 9 : 9-Red |
| 10 - 12 | Red action cards10 : Skip, 11 : Reverse, 12 : Draw 2 |
| 13 | Red “Wild” card |
| 14 | Red “Wild and Draw 4” card |
| 15 - 24 | Green number cards15 : 0-Green, 16 : 1-Green, …, 24 : 9-Green |
| 25 - 27 | Green action cards25 : Skip, 26 : Reverse, 27 : Draw 2 |
| 28 | Green “Wild” card |
| 29 | Green “Wild and draw 4” card |
| 30 - 39 | Blue number cards30 : 0-Blue, 31 : 1-Blue, …, 39 : 9-Blue |
| 40 - 42 | Blue action cards40 : Skip, 41 : Reverse, 42 : Draw 2 |
| 43 | Blue “Wild” card |
| 44 | Blue “Wild and Draw 4” card |
| 45 - 54 | Yellow number cards45 : 0-Yellow, 46 : 1-Yellow, …, 54 : 9-Yellow |
| 55 - 57 | Yellow action cards55 : Skip, 56 : Reverse, 57 : Draw 2 |
| 58 | Yellow “Wild” card |
| 59 | Yellow “Wild and Draw 4” card |
| 60 | Draw |
For example, you would use action 6
to put down a red “6” card or action 60
to draw a card.
| Winner | Loser |
|---|---|
| +1 | -1 |
The legal moves available for each agent, found in env.infos[agent]['legal_moves']
, are updated after each step. Taking an illegal move ends the game with a reward of -1 for the illegally moving agent and a reward of 0 for all other agents.


Lori Harvey Knows Better Than Her Mom, Marjorie Harvey, According To This Video; And Future, Diddy, And Trey Songz Are Happy About That
by Mel WalkerAn old video clip showing Lori Harvey, the daughter of Marjorie and Steve Harvey, talking to her mother, regained popularity after some events in her wild love life took place over this year.
In the clip, dating from 2015, when Lori was just an 18-year-old college student, she had a discussion with Marjorie about how to behave appropriately once she was on her own and not living with her parents anymore.
Marjorie started her motherly pieces of advice by bringing up the topic of dating.
The concerned parent asked her daughter jokingly how they were going to handle the fact that she started dating earlier and continued by stating that she was not allowed to be involved with athletes, rappers, and men with similar professions.
It seems that even at such a young age, Lori had a clear opinion of how she was handling her romances as she commented that her mother had nothing to worry about when it comes to dating because she was sure she would make the right choices.
In the footage, Marjorie also gave her daughter the advice to never try to fit in, when God has created her to stand out and urged her to always behave like a lady.
Marjorie said: “I know you just started dating this year, so how are we going to handle that? No athletes, no rappers, we gon go down the list.”
She added: “Don’t ever try to fit in when God has clearly created you to stand out. Always be a lady, and always understand you are the prize. Don’t give yourself to anybody that is not going to be your husband. If they love you, if they really care about you, they’ll wait on it.”
Lori responded by: “When it comes to dating, my mom has nothing to worry about. I got this.”
However, it appears that the rule of dating no rappers does mot hold anymore since Lori has been rumored to be involved with a couple of rap performers in the past year.
Besides allegedly dating Sean “Diddy” Combs, Lori was also said to have been seeing Trey Songz and Future.
The young social media personality is one of the most sought-after dates in the entertainment industry.


--- layout: default title: Lake Management description: "With more than 20 years in the lake management industry, Terracare Associates has the expertise to maximize the aesthetic value of your lakes and water features." parent: Commercial Services sidebar: Aquatic Maintenance class: landscape banner: lake_management.jpg banner-heading: "" banner-cta: "" relevant_links: - link: '/pests/aquatics/2014/03/20/outdoor-pests-2.html' title: 'Outdoor Pests' ---
Water Quality Maintenance - We provide expert analysis of existing water quality conditions in your lake or pond and develop specific recommendations to maintain and/or improve the water quality in your aquatic system.
Vegetation and Algae Control - We develop a lake maintenance program that integrates physical, mechanical and/or chemical control methods to balance aquatic plant and algae populations in aquatic systems. Site specific use of herbicides and algaecides are used as a management tool for the control of nuisance aquatic plant and algae species.
Mechanical Systems Maintenance - Fountain and aeration system maintenance will improve lake aesthetics, water movement and oxygen deficiency concerns.
Aquatic Harvesting - Aquatic weed control utilizing aquatic plant harvesters are used to cut and remove aquatic weed growth from lakes and other waterways.
Lake Plan Development - Consulting and drafting of LMP’s with experience in the development, construction and maintenance of lake systems.
Lake Construction - Terracare Associates-TCA can also provide lake construction services including excavation, liner installation, bulkhead wall repairs, aeration systems install and aquatic vegetation planting.
Stuart Perry has over 30 years of experience in research and specialized aquatic vegetation control programs utilized in aquatic management. Prior to joining Terracare Associates-TCA, Perry performed extensive aquatic research at the university level along with the well tested experience of owning and operating a lake management firm for 15 years. He has led the aquatic maintenance group for over five years with TCA. Stuart specializes in developing site specific lake management plans, water quality monitoring, compliance and control programs. Perry is an expert in the industry for best management practices and has a reputation for providing exemplary customer service.


Crystal Ball Factory
问题描述 :
Crystal balls are made from the highest-quality crystal, whose price fluctuates from week to week. Fortunately, the ACM is able to foresee the price of crystal for the coming weeks, thanks to its own future-predicting technology.
When the price is low, the ACM would like to buy crystal and manufacture crystal balls, storing any excess in their warehouse. On the other hand, in weeks for which the price is high, ACM would rather use the crystal balls stored in the warehouse to satisfy the demand specified in their contract. However, since there is a also a fixed weekly cost to store each crystal ball in the warehouse, and an initial cost for turning on the manufacturing machines and producing a non-zero quantity of crystal balls, the decision is not always simple.
Can you help them fulfill their contract at minimal cost?
输入:
The next line will contain the non-negative integers b, k and n, where b is the base cost for manufacturing a non-zero quantity of crystal balls on a given week, k is the cost for storing each crystal ball in the warehouse for a week, and n is the maximum capacity of the warehouse.
The following lines will describe the weeks specified in the contract in chronological order. Each week is described by a single line which will contain a pair of non-negative integers c and r, where c is the cost for manufacturing a new crystal ball using new crystal bought this week, and r is the number of crystal balls which must be delivered this week. A crystal ball can be manufactured and delivered in the same week if appropriate, in which case it won’t need to be stored in the warehouse at all.
The last line of the input will contain the integer 0 and should not be processed.
输出:
The next line will contain the non-negative integers b, k and n, where b is the base cost for manufacturing a non-zero quantity of crystal balls on a given week, k is the cost for storing each crystal ball in the warehouse for a week, and n is the maximum capacity of the warehouse.
The following lines will describe the weeks specified in the contract in chronological order. Each week is described by a single line which will contain a pair of non-negative integers c and r, where c is the cost for manufacturing a new crystal ball using new crystal bought this week, and r is the number of crystal balls which must be delivered this week. A crystal ball can be manufactured and delivered in the same week if appropriate, in which case it won’t need to be stored in the warehouse at all.
The last line of the input will contain the integer 0 and should not be processed.
样例输入:
4 1 0 1000 1 1 12 4 1 0 1000 1000 2 0 100 1 1 1000 1000 101 0
样例输出:
1007 101101
#include<iostream> using namespace std; int dp[1010][1010], price[1010],need[1010]; int main() { int week,basecost,cell,storecost,i,j,k,min,mini; while(cin>>week) { if(week==0) break; cin>>basecost>>storecost>>cell; for(i=1;i<=week;i++) cin>>price[i]>>need[i]; for(j=0;j<=cell;j++) { dp[1][j]=(j+need[1])*price[1]+basecost+j*storecost; if(need[1]==0) //第一个月不生产 dp[1][0]=0; } for(i=2;i<=week;i++) for(j=0;j<=cell;j++) { min=10000000; for(k=0;k<=cell;k++) { if(k<=j+need[i]) { if(j==k-need[i]) mini=dp[i-1][k]+j*storecost; else mini=dp[i-1][k]+basecost+(j-k+need[i])*price[i]+j*storecost; if(mini<min) min=mini; } } dp[i][j]=min; } min=dp[week][0]; for(i=1;i<=cell;i++) if(dp[week][i]<min) min=dp[week][i]; cout<<min<<endl; } return 0
}
F[I][J]表示第i个月存在仓库中j个，他的最小值取决于前一个月剩余的个数，即看要生产多少个，找最小值。
参考：http://blog.csdn.net/killer_in_silence/article/details/8630387
第一眼白学，第二眼自学
第一眼白学，第二眼自学
第一眼白学，第二眼自学
第一眼白学，第二眼自学
第一眼白学，第二眼自学
第一眼白学，第二眼自学
第一眼白学，第二眼自学
第一眼白学，第二眼自学
第一眼白学，第二眼自学
第一眼白学，第二眼自学
第一眼白学，第二眼自学
第二个方法挺不错。NewHead代表新的头节点，通过递归找到最后一个节点之后，就把这个节点赋给NewHead，然后一直返回返回，中途这个值是没有变化的，一边返回一边把相应的指针方向颠倒，最后结束时返回新的头节点到主函数。
很好！！
这代码的输出格式不对阿，else语句的low=p移动一下位置，增加可读性
图像处理那题解题报告在哪儿呢？
没错的，九度OJ也有此题
这道题目虽然简单，但是小编做的很到位，应该会给很多人启发吧！对于面试当中不给开辟额外空间的问题不是绝对的，实际上至少是允许少数变量存在的。之前遇到相似的问题也是恍然大悟，今天看到小编这篇文章相见恨晚。
嗯，是写错了，文中以更改。MAX ( L(X[0..m-2], Y[0..n-1]), L(X[0..m-1], Y[0..n-2])
很好。代码比书上的简练！
红绯鱼：
牛逼牛逼
else if也是要比较两次
DFS方法的原理还是不太清楚啊
已更新
刚开始学习，为啥会报错了，你试过了吗


'Big-data’ is similar to ‘Small-data’, but bigger. It is more than simply a matter of size. Now a day trend is of Big Data. Big data can be think of as server’s log, GB’s of file. Every day Petabytes of data processed by Big MNCS. Big Data — is a pretty common concept in IT and digital marketing. Essentially, the definition is on the surface: the term “big data” implies managing and an analysis of big volumes of data. Broadly speaking, this is information which cannot be processed by classical approaches due to its volume
“Big data is at the foundation of all the megatrends that are happening today, from social to mobile to cloud to gaming.” – Chris Lynch, Vertica Systems Big Data has certain characteristics and hence is defined using 4Vs namely: Volume:”Scale of Data”. The amount of data that businesses can collect is really enormous. We used to store data from sources like spreadsheets and databases. Now data comes in the form of emails, photos, videos, monitoring devices, PDFs, audio, etc.
- • It is estimated that 2.5 Quintillion Bytes (2.3 Trillion GB) of data are created each day.
- • By 2020, 40 ZETABYTES (43 Trillion GB) of data will be created is 300 times increases by the time of 2005.
- • World population: 7 Billion, Out of that 6 Billion Cell phones.
Velocity: It refers to “Data in Motion”. The rate at which new data is being generated due to our dependence on the internet, sensors, and machine-to-machine data is also important to parse Big Data in a timely manner.
- • Examples like By 2016, it is projected there will be 18.9 Billion Network connections- almost 2.5 connections per person on Earth.
- • Modern car have close to 100 Sensors that monitor items such as fuel level and tyre pressure.
- • New York Stock Exchange captures 100 TB of trade information during each trading sessions.
Variety:”Different Form of Data”. The data that is generated is completely heterogeneous in the sense that it could be in various formats like video, text, database, sensor data and so on and hence understanding the type of Big Data is a key factor.
- • 330 Billion Pieces of content are shared on Facebook every month.
- • 400 Millions Tweets are sent per day by about 200 milion monthly active users.
- • 4 billion hours+ hours of video are watched on YouTube every month.
Veracity: “Uncertainty of DATA”. Knowing whether the data that is available is coming from a credible source is of utmost importance before deciphering and implementing Big Data for business needs.
- • 1 in 3 Business Leaders don’t trust the information they use to make decisions.
- • Poor data quality costs the US economy around $3.1 Trillion a year.
- • 27% of Respondents in one Survey were unsure of how much of their data was inaccurate.
Question: “How to process big data with reasonable cost and time?”
Answer