Cocoapods
In all of our apps, whether they are web-apps or iOS apps, we make extensive use of different frameworks. These help us to save time by abstracting out stuff that’s needed in a lot of different projects.
We also maintain some of our own frameworks:
* Tin Makes consuming webservices in iOS a lot easier.
* Coby Adds some functionality we know and love from Ruby into several default Obj-C classes.
But these frameworks grow together with our projects, so copying these into several projects can become tedious and managing different versions would make things too complicated.
Ruby has Bundler to solve this problem. Just create a gemfile that lists every “gem” you use, Bundler will install these gems and keep track of the versions in the “Gemfile.lock”.
Now there is a similar system for Cocoa, called Cocoapods.
Installing cocoapods
Cocoapods runs on macruby, so installing it using RVM is a breeze:
Then simply setup cocoapods like this:
$ rvm use macruby
$ macgem install cocoapods
$ pod setup
And now we’re ready to start using Cocoapods.
Adding Cocoapods to a project
Using Cocoapods in a new project is quite similar to using Bundler in a rails project.
We start by adding a Podfile which could look like this:
platform :ios
dependency "AFnetworking",
:git => "git://github.com/AFNetworking/AFNetworking.git"
dependency 'Tin',
:git => "git://github.com/Reprazent/Tin.git",
:commit => "baf1c407f74dd6ca6c6c8c46bc0a3a565e79d3b6"
dependency 'coby',
:git => "git://github.com/pjaspers/coby.git"
dependency "MagicalRecord"
The platform can either be :ios
or :osx
.
Note that, just like with Bundler, you can specify a git repository, and even a commit or tag to reference your dependency. This makes it a lot easier to fix versions and avoid breaking the project when updating the dependencies.
The dependencies referencing a git repository must contain a “.podspec” file. When no repository is specified, Cocoapods looks for the podspec in it’s own spec-repository. There’s already a bunch of frameworks that are available, and more are sure to follow.
Now we can enable Cocoapods for our project by running pod install
for the first time.
$ pod install demoproject.xcodeproj
This will clone the git repositories of the pods specified in a new “Pods” directory in your project root.
Just like Bundler it will create a “Podfile.lock” which holds the references to the current version of the pods and its dependecies. Together with a new workspace we can use to open our project in XCode.
There we will see that there are actually two projects added to the workspace.
One containing your regular project, and one containing the pods, this makes it easier to view the source code of these pods while working.
When building your project your pods will be built into “libPods.a” before building the project itself.
Now you’re good to go. When adding new pods or updating existing ones in your podfile just run pod install
again to update your “Podfile.lock” and adding or updating the Pods.
When multiple build configurations are needed, we also need to add these in the “Pods.xcodeproj”.
You should also set “Skip Install” to yes in your build target in order to create archives for different build types.
thanks Verbeeckx for figuring these last two out
Creating your own Cocoapods
To be able to add our own frameworks into our own projects easily, we had to add a “.podspec” to the repos.
These podspecs look very similar to the gemspecs in Ruby.
Pod::Spec.new do |s|
s.name = 'Tin'
s.version = '0.0.1'
s.license = 'MIT'
s.summary = 'Tin makes the internet easier in Cocoa.'
s.homepage = 'https://github.com/pjaspers/Tin'
s.author = { 'pjaspers' =><EMAIL_ADDRESS>}
s.description = 'An optional longer description of Tin.'
s.source = { :git => 'https://github.com/pjaspers/Tin.git' }
s.source_files = 'Classes',
'Classes/**/*.{h,m}',
"Tin",
"*.{h,m}"
s.dependency 'JSONKit'
s.dependency "AFNetworking", "~> 0.8.0"
end
In this podspec we set the source, where Cocoapods can find the repository to clone.
We specify where the required classes can be found within the repository.
We can also set several dependencies, specifying the tags that should be used.
Note that adding a dependency like this, it needs to be present in the spec repository of Cocoapods.
When the correct tag or framework isn’t present in the repo yet, we can add it ourselves in the Podfile of the project we are using the framework in.
In the case of Tin, we had to add “AFNetworking” separately in the Podfile because the highest available version from Cocoapods was 0.7.0.
I suspect Cocoapods will gain a lot in popularity in the future, because it makes adding dependencies to projects much easier. As it gains in popularity, more frameworks will become available.
I suggest you get over to the Cocoapods github and give it a try.
...Read Full


Migration Guide: MLlib (Machine Learning)
- Upgrading from MLlib 2.4 to 3.0
- Upgrading from MLlib 2.2 to 2.3
- Upgrading from MLlib 2.1 to 2.2
- Upgrading from MLlib 2.0 to 2.1
- Upgrading from MLlib 1.6 to 2.0
- Upgrading from MLlib 1.5 to 1.6
- Upgrading from MLlib 1.4 to 1.5
- Upgrading from MLlib 1.3 to 1.4
- Upgrading from MLlib 1.2 to 1.3
- Upgrading from MLlib 1.1 to 1.2
- Upgrading from MLlib 1.0 to 1.1
- Upgrading from MLlib 0.9 to 1.0
Note that this migration guide describes the items specific to MLlib. Many items of SQL migration can be applied when migrating MLlib to higher versions for DataFrame-based APIs. Please refer Migration Guide: SQL, Datasets and DataFrame.
Upgrading from MLlib 2.4 to 3.0
Breaking changes
OneHotEncoder
which is deprecated in 2.3, is removed in 3.0 andOneHotEncoderEstimator
is now renamed toOneHotEncoder
.org.apache.spark.ml.image.ImageSchema.readImages
which is deprecated in 2.3, is removed in 3.0, usespark.read.format('image')
instead.org.apache.spark.mllib.clustering.KMeans.train
with param Intruns
which is deprecated in 2.1, is removed in 3.0. Usetrain
method withoutruns
instead.org.apache.spark.mllib.classification.LogisticRegressionWithSGD
which is deprecated in 2.0, is removed in 3.0, useorg.apache.spark.ml.classification.LogisticRegression
orspark.mllib.classification.LogisticRegressionWithLBFGS
instead.org.apache.spark.mllib.feature.ChiSqSelectorModel.isSorted
which is deprecated in 2.1, is removed in 3.0, is not intended for subclasses to use.org.apache.spark.mllib.regression.RidgeRegressionWithSGD
which is deprecated in 2.0, is removed in 3.0, useorg.apache.spark.ml.regression.LinearRegression
withelasticNetParam
= 0.0. Note the defaultregParam
is 0.01 forRidgeRegressionWithSGD
, but is 0.0 forLinearRegression
.org.apache.spark.mllib.regression.LassoWithSGD
which is deprecated in 2.0, is removed in 3.0, useorg.apache.spark.ml.regression.LinearRegression
withelasticNetParam
= 1.0. Note the defaultregParam
is 0.01 forLassoWithSGD
, but is 0.0 forLinearRegression
.org.apache.spark.mllib.regression.LinearRegressionWithSGD
which is deprecated in 2.0, is removed in 3.0, useorg.apache.spark.ml.regression.LinearRegression
orLBFGS
instead.org.apache.spark.mllib.clustering.KMeans.getRuns
andsetRuns
which are deprecated in 2.1, are removed in 3.0, have no effect since Spark 2.0.0.org.apache.spark.ml.LinearSVCModel.setWeightCol
which is deprecated in 2.4, is removed in 3.0, is not intended for users.- From 3.0,
org.apache.spark.ml.classification.MultilayerPerceptronClassificationModel
extendsMultilayerPerceptronParams
to expose the training params. As a result,layers
inMultilayerPerceptronClassificationModel
has been changed fromArray[Int]
toIntArrayParam
. Users should useMultilayerPerceptronClassificationModel.getLayers
instead ofMultilayerPerceptronClassificationModel.layers
to retrieve the size of layers. org.apache.spark.ml.classification.GBTClassifier.numTrees
which is deprecated in 2.4.5, is removed in 3.0, usegetNumTrees
instead.org.apache.spark.ml.clustering.KMeansModel.computeCost
which is deprecated in 2.4, is removed in 3.0, useClusteringEvaluator
instead.- The member variable
precision
inorg.apache.spark.mllib.evaluation.MulticlassMetrics
which is deprecated in 2.0, is removed in 3.0. Useaccuracy
instead. - The member variable
recall
inorg.apache.spark.mllib.evaluation.MulticlassMetrics
which is deprecated in 2.0, is removed in 3.0. Useaccuracy
instead. - The member variable
fMeasure
inorg.apache.spark.mllib.evaluation.MulticlassMetrics
which is deprecated in 2.0, is removed in 3.0. Useaccuracy
instead. org.apache.spark.ml.util.GeneralMLWriter.context
which is deprecated in 2.0, is removed in 3.0, usesession
instead.org.apache.spark.ml.util.MLWriter.context
which is deprecated in 2.0, is removed in 3.0, usesession
instead.org.apache.spark.ml.util.MLReader.context
which is deprecated in 2.0, is removed in 3.0, usesession
instead.abstract class UnaryTransformer[IN, OUT, T <: UnaryTransformer[IN, OUT, T]]
is changed toabstract class UnaryTransformer[IN: TypeTag, OUT: TypeTag, T <: UnaryTransformer[IN, OUT, T]]
in 3.0.
Deprecations and changes of behavior
Deprecations
- SPARK-11215:
labels
inStringIndexerModel
is deprecated and will be removed in 3.1.0. UselabelsArray
instead. - SPARK-25758:
computeCost
inBisectingKMeansModel
is deprecated and will be removed in future versions. UseClusteringEvaluator
instead.
Changes of behavior
- SPARK-11215:
In Spark 2.4 and previous versions, when specifying
frequencyDesc
orfrequencyAsc
asstringOrderType
param inStringIndexer
, in case of equal frequency, the order of strings is undefined. Since Spark 3.0, the strings with equal frequency are further sorted by alphabet. And since Spark 3.0,StringIndexer
supports encoding multiple columns. - SPARK-20604:
In prior to 3.0 releases,
Imputer
requires input column to be Double or Float. In 3.0, this restriction is lifted soImputer
can handle all numeric types. - SPARK-23469:
In Spark 3.0, the
HashingTF
Transformer uses a corrected implementation of the murmur3 hash function to hash elements to vectors.HashingTF
in Spark 3.0 will map elements to different positions in vectors than in Spark 2. However,HashingTF
created with Spark 2.x and loaded with Spark 3.0 will still use the previous hash function and will not change behavior. - SPARK-28969:
The
setClassifier
method in PySpark’sOneVsRestModel
has been removed in 3.0 for parity with the Scala implementation. Callers should not need to set the classifier in the model after creation. - SPARK-25790: PCA adds the support for more than 65535 column matrix in Spark 3.0.
- SPARK-28927: When fitting ALS model on nondeterministic input data, previously if rerun happens, users would see ArrayIndexOutOfBoundsException caused by mismatch between In/Out user/item blocks. From 3.0, a SparkException with more clear message will be thrown, and original ArrayIndexOutOfBoundsException is wrapped.
- SPARK-29232:
In prior to 3.0 releases,
RandomForestRegressionModel
doesn’t update the parameter maps of the DecisionTreeRegressionModels underneath. This is fixed in 3.0.
Upgrading from MLlib 2.2 to 2.3
Breaking changes
- The class and trait hierarchy for logistic regression model summaries was changed to be cleaner
and better accommodate the addition of the multi-class summary. This is a breaking change for user
code that casts a
LogisticRegressionTrainingSummary
to aBinaryLogisticRegressionTrainingSummary
. Users should instead use themodel.binarySummary
method. See SPARK-17139 for more detail (note this is anExperimental
API). This does not affect the Pythonsummary
method, which will still work correctly for both multinomial and binary cases.
Deprecations and changes of behavior
Deprecations
OneHotEncoder
has been deprecated and will be removed in3.0
. It has been replaced by the newOneHotEncoderEstimator
(see SPARK-13030). Note thatOneHotEncoderEstimator
will be renamed toOneHotEncoder
in3.0
(butOneHotEncoderEstimator
will be kept as an alias).
Changes of behavior
- SPARK-21027:
The default parallelism used in
OneVsRest
is now set to 1 (i.e. serial). In2.2
and earlier versions, the level of parallelism was set to the default threadpool size in Scala. - SPARK-22156:
The learning rate update for
Word2Vec
was incorrect whennumIterations
was set greater than1
. This will cause training results to be different between2.3
and earlier versions. - SPARK-21681: Fixed an edge case bug in multinomial logistic regression that resulted in incorrect coefficients when some features had zero variance.
- SPARK-16957: Tree algorithms now use mid-points for split values. This may change results from model training.
- SPARK-14657:
Fixed an issue where the features generated by
RFormula
without an intercept were inconsistent with the output in R. This may change results from model training in this scenario.
Upgrading from MLlib 2.1 to 2.2
Breaking changes
There are no breaking changes.
Deprecations and changes of behavior
Deprecations
There are no deprecations.
Changes of behavior
- SPARK-19787:
Default value of
regParam
changed from1.0
to0.1
forALS.train
method (markedDeveloperApi
). Note this does not affect theALS
Estimator or Model, nor MLlib’sALS
class. - SPARK-14772:
Fixed inconsistency between Python and Scala APIs for
Param.copy
method. - SPARK-11569:
StringIndexer
now handlesNULL
values in the same way as unseen values. Previously an exception would always be thrown regardless of the setting of thehandleInvalid
parameter.
Upgrading from MLlib 2.0 to 2.1
Breaking changes
Deprecated methods removed
setLabelCol
infeature.ChiSqSelectorModel
numTrees
inclassification.RandomForestClassificationModel
(This now refers to the Param callednumTrees
)numTrees
inregression.RandomForestRegressionModel
(This now refers to the Param callednumTrees
)model
inregression.LinearRegressionSummary
validateParams
inPipelineStage
validateParams
inEvaluator
Deprecations and changes of behavior
Deprecations
- SPARK-18592:
Deprecate all Param setter methods except for input/output column Params for
DecisionTreeClassificationModel
,GBTClassificationModel
,RandomForestClassificationModel
,DecisionTreeRegressionModel
,GBTRegressionModel
andRandomForestRegressionModel
Changes of behavior
- SPARK-17870:
Fix a bug of
ChiSqSelector
which will likely change its result. NowChiSquareSelector
use pValue rather than raw statistic to select a fixed number of top features. - SPARK-3261:
KMeans
returns potentially fewer than k cluster centers in cases where k distinct centroids aren’t available or aren’t selected. - SPARK-17389:
KMeans
reduces the default number of steps from 5 to 2 for the k-means|| initialization mode.
Upgrading from MLlib 1.6 to 2.0
Breaking changes
There were several breaking changes in Spark 2.0, which are outlined below.
Linear algebra classes for DataFrame-based APIs
Spark’s linear algebra dependencies were moved to a new project, mllib-local
(see SPARK-13944).
As part of this change, the linear algebra classes were copied to a new package, spark.ml.linalg
.
The DataFrame-based APIs in spark.ml
now depend on the spark.ml.linalg
classes,
leading to a few breaking changes, predominantly in various model classes
(see SPARK-14810 for a full list).
Note: the RDD-based APIs in spark.mllib
continue to depend on the previous package spark.mllib.linalg
.
Converting vectors and matrices
While most pipeline components support backward compatibility for loading,
some existing DataFrames
and pipelines in Spark versions prior to 2.0, that contain vector or matrix
columns, may need to be migrated to the new spark.ml
vector and matrix types.
Utilities for converting DataFrame
columns from spark.mllib.linalg
to spark.ml.linalg
types
(and vice versa) can be found in spark.mllib.util.MLUtils
.
There are also utility methods available for converting single instances of
vectors and matrices. Use the asML
method on a mllib.linalg.Vector
/ mllib.linalg.Matrix
for converting to ml.linalg
types, and
mllib.linalg.Vectors.fromML
/ mllib.linalg.Matrices.fromML
for converting to mllib.linalg
types.
Refer to the MLUtils
Scala docs for further detail.
Refer to the MLUtils
Java docs for further detail.
Refer to the MLUtils
Python docs for further detail.
Deprecated methods removed
Several deprecated methods were removed in the spark.mllib
and spark.ml
packages:
setScoreCol
inml.evaluation.BinaryClassificationEvaluator
weights
inLinearRegression
andLogisticRegression
inspark.ml
setMaxNumIterations
inmllib.optimization.LBFGS
(marked asDeveloperApi
)treeReduce
andtreeAggregate
inmllib.rdd.RDDFunctions
(these functions are available onRDD
s directly, and were marked asDeveloperApi
)defaultStrategy
inmllib.tree.configuration.Strategy
build
inmllib.tree.Node
- libsvm loaders for multiclass and load/save labeledData methods in
mllib.util.MLUtils
A full list of breaking changes can be found at SPARK-14810.
Deprecations and changes of behavior
Deprecations
Deprecations in the spark.mllib
and spark.ml
packages include:
- SPARK-14984:
In
spark.ml.regression.LinearRegressionSummary
, themodel
field has been deprecated. - SPARK-13784:
In
spark.ml.regression.RandomForestRegressionModel
andspark.ml.classification.RandomForestClassificationModel
, thenumTrees
parameter has been deprecated in favor ofgetNumTrees
method. - SPARK-13761:
In
spark.ml.param.Params
, thevalidateParams
method has been deprecated. We move all functionality in overridden methods to the correspondingtransformSchema
. - SPARK-14829:
In
spark.mllib
package,LinearRegressionWithSGD
,LassoWithSGD
,RidgeRegressionWithSGD
andLogisticRegressionWithSGD
have been deprecated. We encourage users to usespark.ml.regression.LinearRegression
andspark.ml.classification.LogisticRegression
. - SPARK-14900:
In
spark.mllib.evaluation.MulticlassMetrics
, the parametersprecision
,recall
andfMeasure
have been deprecated in favor ofaccuracy
. - SPARK-15644:
In
spark.ml.util.MLReader
andspark.ml.util.MLWriter
, thecontext
method has been deprecated in favor ofsession
. - In
spark.ml.feature.ChiSqSelectorModel
, thesetLabelCol
method has been deprecated since it was not used byChiSqSelectorModel
.
Changes of behavior
Changes of behavior in the spark.mllib
and spark.ml
packages include:
- SPARK-7780:
spark.mllib.classification.LogisticRegressionWithLBFGS
directly callsspark.ml.classification.LogisticRegression
for binary classification now. This will introduce the following behavior changes forspark.mllib.classification.LogisticRegressionWithLBFGS
:- The intercept will not be regularized when training binary classification model with L1/L2 Updater.
- If users set without regularization, training with or without feature scaling will return the same solution by the same convergence rate.
- SPARK-13429:
In order to provide better and consistent result with
spark.ml.classification.LogisticRegression
, the default value ofspark.mllib.classification.LogisticRegressionWithLBFGS
:convergenceTol
has been changed from 1E-4 to 1E-6. - SPARK-12363:
Fix a bug of
PowerIterationClustering
which will likely change its result. - SPARK-13048:
LDA
using theEM
optimizer will keep the last checkpoint by default, if checkpointing is being used. - SPARK-12153:
Word2Vec
now respects sentence boundaries. Previously, it did not handle them correctly. - SPARK-10574:
HashingTF
usesMurmurHash3
as default hash algorithm in bothspark.ml
andspark.mllib
. - SPARK-14768:
The
expectedType
argument for PySparkParam
was removed. - SPARK-14931:
Some default
Param
values, which were mismatched between pipelines in Scala and Python, have been changed. - SPARK-13600:
QuantileDiscretizer
now usesspark.sql.DataFrameStatFunctions.approxQuantile
to find splits (previously used custom sampling logic). The output buckets will differ for same input data and params.
Upgrading from MLlib 1.5 to 1.6
There are no breaking API changes in the spark.mllib
or spark.ml
packages, but there are
deprecations and changes of behavior.
Deprecations:
- SPARK-11358:
In
spark.mllib.clustering.KMeans
, theruns
parameter has been deprecated. - SPARK-10592:
In
spark.ml.classification.LogisticRegressionModel
andspark.ml.regression.LinearRegressionModel
, theweights
field has been deprecated in favor of the new namecoefficients
. This helps disambiguate from instance (row) “weights” given to algorithms.
Changes of behavior:
- SPARK-7770:
spark.mllib.tree.GradientBoostedTrees
:validationTol
has changed semantics in 1.6. Previously, it was a threshold for absolute change in error. Now, it resembles the behavior ofGradientDescent
’sconvergenceTol
: For large errors, it uses relative error (relative to the previous error); for small errors (< 0.01
), it uses absolute error. - SPARK-11069:
spark.ml.feature.RegexTokenizer
: Previously, it did not convert strings to lowercase before tokenizing. Now, it converts to lowercase by default, with an option not to. This matches the behavior of the simplerTokenizer
transformer.
Upgrading from MLlib 1.4 to 1.5
In the spark.mllib
package, there are no breaking API changes but several behavior changes:
- SPARK-9005:
RegressionMetrics.explainedVariance
returns the average regression sum of squares. - SPARK-8600:
NaiveBayesModel.labels
become sorted. - SPARK-3382:
GradientDescent
has a default convergence tolerance1e-3
, and hence iterations might end earlier than 1.4.
In the spark.ml
package, there exists one breaking API change and one behavior change:
- SPARK-9268: Java’s varargs support is removed
from
Params.setDefault
due to a Scala compiler bug. - SPARK-10097:
Evaluator.isLargerBetter
is added to indicate metric ordering. Metrics like RMSE no longer flip signs as in 1.4.
Upgrading from MLlib 1.3 to 1.4
In the spark.mllib
package, there were several breaking changes, but all in DeveloperApi
or Experimental
APIs:
- Gradient-Boosted Trees
- (Breaking change) The signature of the
Loss.gradient
method was changed. This is only an issues for users who wrote their own losses for GBTs. - (Breaking change) The
apply
andcopy
methods for the case classBoostingStrategy
have been changed because of a modification to the case class fields. This could be an issue for users who useBoostingStrategy
to set GBT parameters.
- (Breaking change) The signature of the
- (Breaking change) The return value of
LDA.run
has changed. It now returns an abstract classLDAModel
instead of the concrete classDistributedLDAModel
. The object of typeLDAModel
can still be cast to the appropriate concrete type, which depends on the optimization algorithm.
In the spark.ml
package, several major API changes occurred, including:
Param
and other APIs for specifying parametersuid
unique IDs for Pipeline components- Reorganization of certain classes
Since the spark.ml
API was an alpha component in Spark 1.3, we do not list all changes here.
However, since 1.4 spark.ml
is no longer an alpha component, we will provide details on any API
changes for future releases.
Upgrading from MLlib 1.2 to 1.3
In the spark.mllib
package, there were several breaking changes. The first change (in ALS
) is the only one in a component not marked as Alpha or Experimental.
- (Breaking change) In
ALS
, the extraneous methodsolveLeastSquares
has been removed. TheDeveloperApi
methodanalyzeBlocks
was also removed. - (Breaking change)
StandardScalerModel
remains an Alpha component. In it, thevariance
method has been replaced with thestd
method. To compute the column variance values returned by the originalvariance
method, simply square the standard deviation values returned bystd
. - (Breaking change)
StreamingLinearRegressionWithSGD
remains an Experimental component. In it, there were two changes:- The constructor taking arguments was removed in favor of a builder pattern using the default constructor plus parameter setter methods.
- Variable
model
is no longer public.
- (Breaking change)
DecisionTree
remains an Experimental component. In it and its associated classes, there were several changes:- In
DecisionTree
, the deprecated class methodtrain
has been removed. (The object/statictrain
methods remain.) - In
Strategy
, thecheckpointDir
parameter has been removed. Checkpointing is still supported, but the checkpoint directory must be set before calling tree and tree ensemble training.
- In
PythonMLlibAPI
(the interface between Scala/Java and Python for MLlib) was a public API but is now private, declaredprivate[python]
. This was never meant for external use.- In linear regression (including Lasso and ridge regression), the squared loss is now divided by 2. So in order to produce the same result as in 1.2, the regularization parameter needs to be divided by 2 and the step size needs to be multiplied by 2.
In the spark.ml
package, the main API changes are from Spark SQL. We list the most important changes here:
- The old SchemaRDD has been replaced with DataFrame with a somewhat modified API. All algorithms in
spark.ml
which used to use SchemaRDD now use DataFrame. - In Spark 1.2, we used implicit conversions from
RDD
s ofLabeledPoint
intoSchemaRDD
s by callingimport sqlContext._
wheresqlContext
was an instance ofSQLContext
. These implicits have been moved, so we now callimport sqlContext.implicits._
. - Java APIs for SQL have also changed accordingly. Please see the examples above and the Spark SQL Programming Guide for details.
Other changes were in LogisticRegression
:
- The
scoreCol
output column (with default value “score”) was renamed to beprobabilityCol
(with default value “probability”). The type was originallyDouble
(for the probability of class 1.0), but it is nowVector
(for the probability of each class, to support multiclass classification in the future). - In Spark 1.2,
LogisticRegressionModel
did not include an intercept. In Spark 1.3, it includes an intercept; however, it will always be 0.0 since it uses the default settings for spark.mllib.LogisticRegressionWithLBFGS. The option to use an intercept will be added in the future.
Upgrading from MLlib 1.1 to 1.2
The only API changes in MLlib v1.2 are in
DecisionTree
,
which continues to be an experimental API in MLlib 1.2:
-
(Breaking change) The Scala API for classification takes a named argument specifying the number of classes. In MLlib v1.1, this argument was called
numClasses
in Python andnumClassesForClassification
in Scala. In MLlib v1.2, the names are both set tonumClasses
. ThisnumClasses
parameter is specified either viaStrategy
or viaDecisionTree
statictrainClassifier
andtrainRegressor
methods. -
(Breaking change) The API for
Node
has changed. This should generally not affect user code, unless the user manually constructs decision trees (instead of using thetrainClassifier
ortrainRegressor
methods). The treeNode
now includes more information, including the probability of the predicted label (for classification). -
Printing methods’ output has changed. The
toString
(Scala/Java) and__repr__
(Python) methods used to print the full model; they now print a summary. For the full model, usetoDebugString
.
Examples in the Spark distribution and examples in the Decision Trees Guide have been updated accordingly.
Upgrading from MLlib 1.0 to 1.1
The only API changes in MLlib v1.1 are in
DecisionTree
,
which continues to be an experimental API in MLlib 1.1:
-
(Breaking change) The meaning of tree depth has been changed by 1 in order to match the implementations of trees in scikit-learn and in rpart. In MLlib v1.0, a depth-1 tree had 1 leaf node, and a depth-2 tree had 1 root node and 2 leaf nodes. In MLlib v1.1, a depth-0 tree has 1 leaf node, and a depth-1 tree has 1 root node and 2 leaf nodes. This depth is specified by the
maxDepth
parameter inStrategy
or viaDecisionTree
statictrainClassifier
andtrainRegressor
methods. -
(Non-breaking change) We recommend using the newly added
trainClassifier
andtrainRegressor
methods to build aDecisionTree
, rather than using the old parameter classStrategy
. These new training methods explicitly separate classification and regression, and they replace specialized parameter types with simpleString
types.
Examples of the new recommended trainClassifier
and trainRegressor
are given in the
Decision Trees Guide.
Upgrading from MLlib 0.9 to 1.0
In MLlib v1.0, we support both dense and sparse input in a unified way, which introduces a few breaking changes. If your data is sparse, please store it in a sparse format instead of dense to take advantage of sparsity in both storage and computation. Details are described below.


put image here column size:5
put text here column size:3
put image here column size:4
put text here column size:3
put image here column size:5
put text here column size:4
put image here column size:5
put text here column size:3
put image here column size:4


---
layout: page-fullwidth
permalink: /TechnicalDiscussion/
title: Technical Discussion Techniques That Work
---
The vast majority of technical information exchange and decision-making
occurs within and as a result of group discussion.
Good discussion skills and awareness of group dynamics are critical for effective communication.
Your success within an organization will be greatly influenced by your group discussion skills.
Fact:
Good discussion skills, especially technical discussion skills will lead to more effective work environments,
reduce wasted time and much better team spirit within your work environment.
Some basic discussion rules:
-
Come prepared:
If you are supposed to prepare for a meeting, do so. You waste everyone’s time if you are unprepared.
-
Show respect for others at all times:
The single most important attitude for group discussion (and in any human interaction) is respect for others:
- All participants should be encouraged to speak, even if only to say, “I have no opinion.”
- All contention in discussion should be thoroughly clarified.
Often contention is a result of misunderstanding not fundamental disagreement.
- Critique should always be focused on ideas not a person.
-
Arrange participants well:
When possible, each participant should be able to see every other participant.
-
Important technical ideas should be thoroughly discussed:
Much misunderstanding in technical discussions is due to an incomplete or incompatible understanding of ideas.
Make sure that key terms are well understood and consistently defined.
For really important ideas, you should be able to reach a point
where you can clearly describe ideas in the words of other participants.
-
Reach consensus when possible:
If a discussion is intended to reach conclusions, try to reach a consensus decision if possible.
-
Record decisions:
One of the participants should record any decisions made.
Resources:
Here is one resource for developing good discussion skills:
Discussion Tutorial Website by Exforsys, Inc
Class Preparation:
Answer the following question
- What is the definition of the term open source software?
- What is the definition of closed source (proprietary) software?
- What is the definition of the term copy-lefting?
- Who owns the development strategy for an open source software product?
- How are open source software developers paid?
- How is open source software maintenance paid for?
Requirements:
- Provide paragraph per question.
- Use compact writing strategies.
- Use LaTeX to write your document.
- Cite any sources you use.
- Submit your answers to me by email as a PDF attachment.
Exercises: Discussion of Open Source vs. Free Software vs. Proprietary Software Projects.
Discuss the relative merits of Open Source vs. Proprietary software projects. Address the following questions:
- Should software be Open Source?
- Should software be free?
- How should software developers be paid?
- How should software support be funded?


RT @1337807: "Everything is open source if you try hard enough." - @emilyst hacking Super Mario Bros. at #osb15
6/24/2015, 11:24:20 AM
Favs: 0
Retweets: 0
link--- layout: tweet ---
RT @1337807: "Everything is open source if you try hard enough." - @emilyst hacking Super Mario Bros. at #osb15
6/24/2015, 11:24:20 AM
Favs: 0
Retweets: 0
link


Methods
maxBy(selector)
Parameters:
| Name |
Type |
Description |
selector |
function
|
function by which to order values |
- Source:
Returns:
reducer to find the maximum
Example
[1, 2, 3].reduce(minBy(() => 1 / x)) // 1
minBy(selector)
Parameters:
| Name |
Type |
Description |
selector |
function
|
function by which to order values |
- Source:
Returns:
reducer to find the minimum
Example
[1, 2, 3].reduce(minBy(() => 1 / x)) // 3
nextMove(entity, target) → {Vector}
Parameters:
| Name |
Type |
Description |
entity |
Entity
|
entity for which to simulate the movement |
target |
Entity
|
entity that the entity is moving towards |
- Source:
Returns:
-
Type
-
Vector
nextMoveVelocity(entity, target) → {Vector}
Parameters:
| Name |
Type |
Description |
entity |
Entity
|
entity for which to simulate the movement |
target |
Entity
|
entity that the entity is moving towards |
- Source:
Returns:
-
Type
-
Vector
nextPosition(entity, target) → {Vector}
Parameters:
| Name |
Type |
Description |
entity |
Entity
|
entity for which to simulate the movement |
target |
Entity
|
entity that the entity is moving towards |
- Source:
Returns:
-
Type
-
Vector
nextVelocity(entity, target) → {Vector}
Parameters:
| Name |
Type |
Description |
entity |
Entity
|
entity for which to simulate the movement |
target |
Entity
|
entity that the entity is moving towards |
- Source:
Returns:
-
Type
-
Vector
prop()
- Source:
Example
[{a: 1}, {a: 2}].map(prop('a')) // [1, 2]
step(entity, target) → {Entity}
Parameters:
| Name |
Type |
Description |
entity |
Entity
|
entity for which to simulate the movement |
target |
Entity
|
entity that the entity is moving towards |
- Source:
Returns:
entity with position and velocity forwarded in time by one turn
-
Type
-
Entity
Type Definitions
Entity
Type:
Properties:
| Name |
Type |
Description |
position |
Vector
|
|
velocity |
Vector
|
|
thrust |
number
|
|
mass |
number
|
|
- Source:
Vector
Type:
Properties:
| Name |
Type |
Description |
x |
number
|
|
y |
number
|
|
- Source:


Build System Packaging Module
Overview
The Build System Packaging Module provides the
build system with the ability to create various packagings
of files. This includes the ability to create tar files,
zip files, etc.
NOTE: Due to limitations in gmake's ability to interpret
generated dependency chains on the fly, making some of
the package targets in a fresh tree may not work in the
first invocation even though the dependencies have been
mapped out. To work around this problem is is recommended
that an 'all' or 'depends' build be invoked separately
before any of the targets provided by this module are
requested.
Macros and Controls
- PACKAGE_ROOT
-
The root of the directory for some packaging module targets.
The default value for this is $(COMPONENT_ROOT)/package.
- PACKAGE_TARGET_DIR
-
The target directory for some package targets. Package
targets share a component wide target directory so
component packages can by built up here piece by piece
as the build progresses through the component source tree.
The default value for this is $(PACKAGE_ROOT)/stage/$(BS_PLATFORM_ARCH_FULL).
- PACKAGE_RELEASE_DIR
-
A final staging dir for deliverable tarballs, bundled package, and files.
The default value for this is $(PACKAGE_ROOT)/release/$(BS_PLATFORM_ARCH_FULL).
The distinction between this and pushing components to dist is fuzzy.
- PACKAGE_VTAG
-
Specify a variant tag for package files. This string will be appended to the
package name for all packages build under the current variant so that differnet
variants may produce package files with non-overlapping names.
Currently, only EPM_TARGETS actually make use of this feature.
Targets
Functions
PACKAGEFILE_TARGETS
PACKAGEFILE_TARGETS Overview
PACKAGEFILE_TARGETS is the pattern target used to package
files from a build into the component wide package
directory for eventual component roll up. In essence, PACKAGEFILE_TARGETS
is a glorified interface to the file copy command. Only files
may be packaged with this pattern target; directories should be packaged
with the PACKAGEDIR_TARGETS
pattern target.
By default, the file packaged by a given PACKAGEFILE_TARGETS pattern target
will be <package file target> found in either the target
dir for the build system's platform or the default
native code tool chain's target platform. This may be overridden
by the <package file target>
<package file target>_FROM option.
PACKAGEFILE_TARGETS will be built during the "posttarget" phase of a build.
PACKAGEFILE_TARGETS may be built in isolation by requesting the "packaging_packagefile"
target.
PACKAGEFILE_TARGETS Options
- <package file target>_DEST
-
Specifies the file name and path under $(PACKAGE_TARGET_DIR) to copy the
<package file target> to. This option must specify a
file location and not a directory, however a directory path may be
part of this option. (e.g. "/usr/local/bin/foo.exe" is acceptable,
but "/usr/local/bin" is not.)
The default value is simply <package file target>.
- <package file target>_ROOT
-
When staging a package file target, substitute this
path for $(PACKAGE_TARGET_DIR). Use this with care since
it may result in files being copied to non-build3 controlled
directories. This option is useful for managing release packages
that are not built by normal build3 release pattern targets like
EPM_TARGETS. (See example below).
- <package file target>_FROM
-
Override the entire default source path to the
<package file target>. Setting this option
makes renders the _PLATFORM option moot.
This option can be used with a <package file target>
to achieve the same behavior provided by the PACKAGE_RAW_TARGETS
of the old build system.
- <package file target>_DEP
-
Specify additional dependancies for the current target.
PACKAGEDIR_TARGETS
PACKAGEDIR_TARGETS Overview
PACKAGEDIR_TARGETS is the pattern target used to package
directories from a build into the component wide package
directory for eventual component roll up. Only directories
may be packaged with this pattern target; files should be packaged
with the PACKAGEFILE_TARGETS
pattern target.
By default, the directory packaged by a given PACKAGEDIR_TARGETS pattern target
will be <package dir target> found in either the target
dir for the build system's platform or the default
native code tool chain's target platform. This may be overridden
by the <package dir target>
<package dir target>_FROM option.
PACKAGEDIR_TARGETS will be built during the "posttarget" phase of a build.
PACKAGEDIR_TARGETS may be built in isolation by requesting the "packaging_packagedir"
target.
WARNING:
PACKAGEDIR_TARGETS pattern targets WILL NOT be cleaned by building the "clean" target.
These pattern targets will only be cleaned by building the "nuke" target.
Furthermore, these targets will be remade with every build of the "posttarget" phase.
These are side effects of directory targets potentially overlapping, and of not having
their full contents enumerated to the build system for dependancy resolution.
PACKAGEDIR_TARGETS Options
- <package dir target>_DEST
-
Specifies the directory name and path under $(PACKAGE_TARGET_DIR) to copy the
<package dir target> to. This option must specify a
directory name. The default value is the basename
of the current target. If the target already exists, the current
target will be overlayed into the existing directory.
- <package dir target>_FROM
-
Override the entire default source path to the
<package dir target>. Setting this option
makes renders the _PLATFORM option moot.
This option can be used with a <package dir target>
to achieve the same behavior provided by the PACKAGE_RAW_TARGETS
of the old build system.
- <package dir target>_SCRUB
-
Specifies a list of files or directories to remove from the
package once it has been copied to the $(PACKAGE_TARGET_DIR).
This option is useful for cleaning out CVS directories or other
ancillary files when packaging directories.
WARNING:Use of the _SCRUB option for PACKAGEDIR_TARGETS
may have unintended consequences when multiple targets overlay into
the same directory.
- <package dir target>_DEP
-
Specify additional dependancies for the current target.
MKDIR_TARGETS
MKDIR_TARGETS Overview
MKDIR_TARGETS is the pattern target used to create empty directories
in the component wide package directory for eventual component roll up.
By default, the directory created by a given MKDIR_TARGETS pattern target
will be <mkdir target>. This may be overridden
by the <mkdir target>
<mkdir target>_DEST option.
MKDIR_TARGETS will be built during the "posttarget" phase of a build.
MKDIR_TARGETS may be built in isolation by requesting the "packaging_mkdir"
target.
WARNING:
MKDIR_TARGETS pattern targets WILL NOT be cleaned by building the "clean" target.
These pattern targets will only be cleaned by building the "nuke" target.
Furthermore, these targets will be remade with every build of the "posttarget" phase.
These are side effects of directory targets potentially overlapping, and of not having
their full contents enumerated to the build system for dependancy resolution.
MKDIR_TARGETS Options
- <mkdir target>_DEST
-
Specifies the directory name and path under $(PACKAGE_TARGET_DIR) to create.
The default value is the basename
of the current target.
EPM_TARGETS
EPM_TARGETS Overview
EPM_TARGETS is the pattern target used to create packages using the epm
utility. The output from these pattern targets will vary depending
on the options selected and the contents of the EPM list file.
Package files created with EPM_TARGETS will be placed in the
$(PACKAGE_RELEASE_DIR). Because the output of an EPM target
may vary, and it is undesirable to create targets that
depend on the results of an EPM target without explicitly knowing what
those results are, EPM targets also generate an output manifest that
lists the files produced by the successful building of a EPM target.
These output manifests are only created when an EPM target has successfully
been created, and are suitable for input to component distribution rules.
(See the Components
build module.) Thie motivation of creating these output manifests is
to discourage subsequent packaging rules that are based on wildcards
or directory searchs; such rules can easilly produce incomplete results
even when they appear to run successfully since their operation is
not guided by an explicit dependency list.
The output manifest file will be placed in the $(BS_ARCH_TARGET_DIR), and
will be named <epm target>-epm.manifest.
EPM_TARGETS will be built during the "posttarget" phase of a build.
EPM_TARGETS may be built in isolation by requesting the "packaging_epm"
target.
EPM_TARGETS Options
- <epm target>_NAME
- Specify an override package name.
The default package name will be
<emp target>.
- <epm target>_EPMLIST=epm list file
-
Specify an override package list file. the default
epm list file is <emp target>.list.
- <epm target>_FORMAT=package format
-
Specify a package format to output. The default is to produce
epm packages, but native package (such as "rpm") may also be
specified.
- <epm target>_ARCH=arch
-
Specify that the package should be build for the indicated
architecture. The default is to build a package for the local architecture.
TARGZ_TARGETS
TARGZ_TARGETS Overview
TARGZ_TARGETS is the pattern target used to create tar'ed and gzip'ed
archive files.
By default, the archive will be created in a file named
$(PACKAGE_RELEASE_DIR)/<targz target>.tgz, but this
may be overridden by target specific controls.
TARGZ_TARGETS will be built during the "posttarget" phase of a build.
TARGZ_TARGETS may be built in isolation by requesting the "packaging_targz"
target.
TARGZ_TARGETS Options
- <targz target>_DEST
- Specify an override location for the archive file
produced by the evaluation of the pattern rules.
The default archive file will be
$(PACKAGE_RELEASE_DIR)/<targz target>.tgz.
- <targz target>_FILES=list of paths
-
Specify a list of files to include in the archive.
- <targz target>_MANIFEST=path
-
Specify a manifest file containing a list of
files to include in the archive. The contents
of the manifest are treated as if they appeared
in the _FILES option.
- <targz target>_CWD=path
-
The parent directory of the files specified
by the _FILES or _MANIFEST options. Files
to appear in a given <targz target>
archive must be located under the directory specified
by the _CWD option, and will have the _CWD directory
prefix stripped prior to being placed in the archive.
The default value for the _CWD option is the
target directory $(BS_ARCH_TARGET_DIR), but
it is expected that values containing $(PACKAGE_TARGET_DIR)
will be useful.
- <targz target>_DO_BSDSIZE=[0/1]
-
Specify that a BSD tgz package style "size" file should be embedded into
the root of the archive. The default is to not embed this file.
- <targz target>_DO_BSDPLATFORM=[0/1]
-
Specify that a BSD tgz package style "platform" file should be embedded into
the root of the archive with the output of sysctl -n kern.ostype.
The default is to not embed this file.
- <targz target>_DO_BSDAPPTYPE=application type
-
Specify that a BSD tgz package style "apptype" file should be embedded into
the root of the archive. The application string specified in this control macro
will be used for the contents of this apptype file. The default is to not embed this file.
- <targz target>_DO_BSDVERSION=version
-
Specify that a BSD tgz package style "version" file should be embedded into
the root of the archive. The version string specified in this control macro
will be used for the contents of this version file. The default is to not embed this file.
NOTE: it is not automatic that version numbrers are also embedded into the
file name of the archive. If the generated archive file should also have a version
number in it, the target should be created with the version number as part of the
target name.
ZIP_TARGETS
ZIP_TARGETS Overview
ZIP_TARGETS is the pattern target used to create zip archive files.
By default, the archive will be created in a file named
$(PACKAGE_RELEASE_DIR)/<zip target>.zip, but this
may be overridden by target specific controls.
ZIP_TARGETS will be built during the "posttarget" phase of a build.
ZIP_TARGETS may be built in isolation by requesting the "packaging_zip"
target.
ZIP_TARGETS Options
- <zip target>_DEST
-
Specify an override location for the archive file
produced by the evaluation of the pattern rules.
The default archive file will be
$(PACKAGE_RELEASE_DIR)/<zip target>.tgz.
- <zip target>_FILES
-
Specify a list of files to include in the archive.
- <zip target>_MANIFEST
-
Specify a manifest file containing a list of
files to include in the archive. The contents
of the manifest are treated as if they appeared
in the _FILES option.
- <zip target>_CWD
-
The parent directory of the files specified
by the _FILES or _MANIFEST options. Files
to appear in a given <zip target>
archive must be located under the directory specified
by the _CWD option, and will have the _CWD directory
prefix stripped prior to being placed in the archive.
The default value for the _CWD option is the
target directory $(BS_ARCH_TARGET_DIR), but
it is expected that values containing $(PACKAGE_TARGET_DIR)
will be useful.
packaging_packagefile
packaging_packagefile Overview
Simple target to trigger the building of PACKAGEFILE_TARGETS
pattern targets independent of the main build "posttarget" phase.
packaging_packagedir
packaging_packagedir Overview
Simple target to trigger the building of PACKAGEDIR_TARGETS
pattern targets independent of the main build "posttarget" phase.
packaging_epm
packaging_epm Overview
Simple target to trigger the building of EPM_TARGETS
pattern targets independent of the main build "posttarget" phase.
packaging_targz
packaging_targz Overview
Simple target to trigger the building of TARGZ_TARGETS
pattern targets independent of the main build "posttarget" phase.
packaging_zip
packaging_zip Overview
Simple target to trigger the building of ZIP_TARGETS
pattern targets independent of the main build "posttarget" phase.
packaging_info
packaging_info Overview
Simple target to display information about the macro
settings of all global macros used by the packaging module of
the build system. The packaging_info target will be
built during the "info" phase of a build, and can be built in
isolation by requesting the packaging_info target.
packaging_man
packaging_man Overview
Simple target to display usage information and help pertaining to
the packaging module of the build system.
The packaging_man target will be built during the "man"
phase of a build, and can be built in isolation by requesting
the packaging_man target.
PACKAGING_FUNC_GET_EPM_FLAGTARGET
This function is provided to translate a epm pattern target
as it is named in the EPM_TARGETS list to the
flag target that is used to track dependencies on a given
epm pattern target.
PACKAGING_FUNC_GET_TARGZ_REALTARGET
This function is provided to translate a targz pattern target
as it is named in the TARGZ_TARGETS list to the
real target that results from the pattern rules.
PACKAGING_FUNC_GET_TARGZ_FLAGTARGET
This function is provided to translate a targz pattern target
as it is named in the TARGZ_TARGETS list to the
flag target that is used to track dependencies on a given
targz pattern target. This flag target is probably of little
use outside the the internals of the packaging build system module,
since PACKAGING_FUNC_GET_TARGZ_REALTARGET provides a better
candidate for chaining a target target in the dependency
list of another pattern target.
PACKAGING_FUNC_GET_ZIP_REALTARGET
This function is provided to translate a zip pattern target
as it is named in the ZIP_TARGETS list to the
real target that results from the pattern rules.
PACKAGING_FUNC_GET_ZIP_FLAGTARGET
This function is provided to translate a zip pattern target
as it is named in the ZIP_TARGETS list to the
flag target that is used to track dependencies on a given
zip pattern target. This flag target is probably of little
use outside the the internals of the packaging build system module,
since PACKAGING_FUNC_GET_ZIP_REALTARGET provides a better
candidate for chaining a target target in the dependency
list of another pattern target.
Example Makefile
COMPONENT_ROOT=../..
BS_ROOT=$(COMPONENT_ROOT)/../build3
include $(BS_ROOT)/defines.mk
#
# The resulting package isn't really useful, just shows how you can use the target options
#
moof_pkg_target=moof-tar1.tgz
PACKAGEDIR_TARGETS=foo-pkg1 $(moof_pkg_target)
TARGZ_TARGETS=moof-tar1
PACKAGEFILE_TARGETS=custom.rpm
foo-pkg1_FROM=$(COMPONENT_ROOT)/sample-srcdir
#foo-pkg1_DEST=$(PROJECT)
foo-pkg1_SCRUB=CVS
moof-tar1_FILES=foo-pkg1
moof-tar1_CWD=$(PACKAGE_TARGET_DIR)
#$(moof_pkg_target)_FROM=$(BS_ARCH_TARGET_DIR)/moof-tar1.tgz # This is the default
$(moof_pkg_target)_DEST=moof-tarball-package-dir/
custom.rpm_DEST=my_custom.rpm
custom.rpm_ROOT=$(PACKAGE_RELEASE_DIR)
include $(BS_ROOT)/rules.mk
$(BS_ARCH_TARGET_DIR)/custom.rpm:
special commans that create custom.rpm


NOTTING HILL RATING: 5.5 / 10 --> Not good enough to recommend
For more reviews and movie trivia, visit http://www.joblo.com/
Hmmm...let's see now. Julia Roberts was adorable in MY BEST FRIEND'S WEDDING (7.5/10) and Hugh Grant was adorable in FOUR WEDDINGS AND A FUNERAL (8/10), so let's slap 'em together in another romantic comedy written by the same dude who wrote the latter film, and voila...another great hit! Well...maybe next time.
PLOT: Ordinary boy meets extraordinary girl (famous movie star). Boy introduces girl to friends and family. Boy falls for girl, girl falls for boy. Boy loses girl to another boy (another famous movie star). Boy sulks. Girl (still the famous movie star) comes back to boy. Happy once again. Boy loses girl again. Darn! Girl comes back to boy...etc, etc, etc...well, you get the picture!
CRITIQUE: Very interesting premise starring two charming leads, offers a few chuckles here and there, an unconvincing romance, languid pacing and a lot of empty scenes played out specifically for laughs, to the detriment of plot. Add that to the ending of this film which goes overboard in my opinion, despite offering us the only true moment of action in the entire bit, and a complete lack of any real drama, and you've got yourself a ho-hum romantic comedy, built around a fantasy dream to which we could probably all relate. In fact, before seeing this film I thought that the premise of this film was a diamond in the rough, but only if they managed to build something more around it than just the simple "boy meets girl, boy loses girl, boy...". After seeing this film, I'm afraid to report that there isn't much more in there, folks.
Frankly, that would be fine if the actors in the film were convincing enough in their roles, but I must say that I was far from convinced of anything more than a simple novelty crush on a fidgety Englishman from the part of Julia Roberts' character. And Hugh, well, every scene he was in basically had him looking like a common Brit who was absolutely overwhelmed and in awe of an American movie actress. Not in love with a woman. In awe of an actress. I never FELT like either of these characters ever really cared for one another as people, especially in the case of Hugh, who could not help but look like a wounded puppy dog in every scene (blinking eyes and all), whilst delivering some of the wittiest repartee this side of a screenwriter's sharpest word processor. The supporting cast was pretty good, but used strategically for laughs, and not much else. Admittedly, some of the things that they were saying went right over my head (English accents and all). Overall, a video rental at best, with a few grins here and around, a fun and dreamy premise, but ultimately too repetitive, unconvincing and just plain boring, to recommend with any enthusiasm.
Go rent WHEN HARRY MET SALLY (10/10) again, and thank me in the morning :)
Little Known Facts about this film and its stars: Hugh Grant received $1,000,000 for his role in this movie. Julia Roberts received $15,000,000 for her role. Julia Roberts turned down the female lead in SHAKESPEARE IN LOVE (5.5/10). At the time, Daniel Day-Lewis was attached to co-star in the film opposite her. She once tried out for a part on the TV soap "All My Children", but was turned down. She is left-handed and stands 5'9". Bra size: 34B. In 1995, Hugh Grant was arrested for lewd conduct after cops found him with Divine Brown, a prostitute, in his car (She was apparently making on him, like a monkey makes a banana). He pleaded no contest and got a $1,180 fine and two years' probation. This is a man who graduated from Oxford University. Screenwriter Richard Curtis based the film in the backdrop of his own residency, Notting Hill, a vibrant West London suburb. He is born in New Zealand, and began writing comedy after leaving Oxford University in 1978. He created the TV program "Mr. Bean" alongside Rowan Atkinson.
Review Date: May 26, 1999 Director: Roger Michell Writer: Richard Curtis Producer: Duncan Kenworthy Actors: Julia Roberts as Anna Scott Hugh Grant as William Thacker Genre: Romantic Comedy Year of Release: 1999 --------------------------------------- JoBlo's Movie Emporium http://www.joblo.com --------------------------------------- (c) 1999 Berge Garabedian
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


pydrake.systems.primitives¶
Bindings for the primitives portion of the Systems framework.
-
pydrake.systems.primitives.
AddRandomInputs
(sampling_interval_sec: float, builder: pydrake.systems.framework.DiagramBuilder_[float]) → int¶ For each subsystem input port in
builder
that is (a) not yet connected and (b) labeled as random in the InputPort, this method will add a new RandomSource system of the appropriate type and connect it to the subsystem input port.- Parameter
sampling_interval_sec
: - interval to be used for all new sources.
Returns: the total number of RandomSource systems added. See also
stochastic_systems
- Parameter
-
pydrake.systems.primitives.
Adder
¶ alias of
pydrake.systems.primitives.Adder_[float]
-
template
pydrake.systems.primitives.
Adder_
¶ Instantiations:
Adder_[float]
,Adder_[AutoDiffXd]
,Adder_[Expression]
-
class
Adder_[float]
¶ Bases:
pydrake.systems.framework.LeafSystem_[float]
An adder for arbitrarily many inputs of equal size. @system{Adder, @input_port{input(0)} @input_port{…} @input_port{input(N-1)}, @output_port{sum} }
- Template parameter
T
: - The type of mathematical object being added.
Instantiated templates for the following kinds of T’s are provided:
- double
- AutoDiffXd
- symbolic::Expression
They are already available to link against in the containing library. No other values for T are currently supported.
-
__init__
(self: pydrake.systems.primitives.Adder_[float], num_inputs: int, size: int) → None¶ Construct an Adder System.
- Parameter
num_inputs
: - is the number of input ports to be added.
- Parameter
size
: - number of elements in each input and output signal.
- Parameter
- Template parameter
-
class
-
pydrake.systems.primitives.
AffineSystem
¶ alias of
pydrake.systems.primitives.AffineSystem_[float]
-
template
pydrake.systems.primitives.
AffineSystem_
¶ Instantiations:
AffineSystem_[float]
,AffineSystem_[AutoDiffXd]
,AffineSystem_[Expression]
-
class
AffineSystem_[float]
¶ Bases:
pydrake.systems.framework.LeafSystem_[float]
A discrete OR continuous affine system (with constant coefficients).
@system{AffineSystem, @input_port{u(t)}, @output_port{y(t)} }
Let
u
denote the input vector,x
denote the state vector, andy
denote the output vector.If
time_period > 0.0
, the affine system will have the following discrete-time state update:\[x(t+h) = A x(t) + B u(t) + f_0,\]where
h
is the time_period. Iftime_period == 0.0
, the affine system will have the following continuous-time state update:\[\dot{x} = A x + B u + f_0.\]In both cases, the system will have the output:
\[y = C x + D u + y_0,\]- Template parameter
T
: - The scalar element type, which must be a valid Eigen scalar.
Instantiated templates for the following kinds of T’s are provided:
- double
- AutoDiffXd
- symbolic::Expression
They are already available to link against in the containing library. No other values for T are currently supported.
See also
LinearSystem
See also
MatrixGain
-
A
(self: pydrake.systems.primitives.AffineSystem_[float]) → numpy.ndarray[float64[m, n]]¶ @name Helper getter methods.
-
B
(self: pydrake.systems.primitives.AffineSystem_[float]) → numpy.ndarray[float64[m, n]]¶
-
C
(self: pydrake.systems.primitives.AffineSystem_[float]) → numpy.ndarray[float64[m, n]]¶
-
D
(self: pydrake.systems.primitives.AffineSystem_[float]) → numpy.ndarray[float64[m, n]]¶
-
__init__
(self: pydrake.systems.primitives.AffineSystem_[float], A: numpy.ndarray[float64[m, n], flags.f_contiguous], B: numpy.ndarray[float64[m, n], flags.f_contiguous], f0: numpy.ndarray[float64[m, 1]], C: numpy.ndarray[float64[m, n], flags.f_contiguous], D: numpy.ndarray[float64[m, n], flags.f_contiguous], y0: numpy.ndarray[float64[m, 1]], time_period: float = 0.0) → None¶ Constructs an Affine system with a fixed set of coefficient matrices
A
, B,``C``, andD
as well as fixed initial velocity offsetxDot0
and output offsety0
. The coefficient matrices must obey the following dimensions : | Matrix | Num Rows | Num Columns | |:-------:|:———–:|:-----------:| | A | num states | num states | | B | num states | num inputs | | C | num outputs | num states | | D | num outputs | num inputs |- Parameter
time_period
: - Defines the period of the discrete time system; use time_period=0.0 to denote a continuous time system. $*Default:* 0.0
Subclasses must use the protected constructor, not this one.
- Parameter
-
f0
(self: pydrake.systems.primitives.AffineSystem_[float]) → numpy.ndarray[float64[m, 1]]¶
-
time_period
(self: pydrake.systems.primitives.AffineSystem_[float]) → float¶
-
y0
(self: pydrake.systems.primitives.AffineSystem_[float]) → numpy.ndarray[float64[m, 1]]¶
- Template parameter
-
class
-
class
pydrake.systems.primitives.
BarycentricMeshSystem
¶ Bases:
pydrake.systems.framework.LeafSystem_[float]
A (stateless) vector system implemented as a multi-linear (barycentric) interpolation on a mesh over the inputs.
This has many potential uses, including representing the policies that are generated by numerical control design methods like approximate dynamic programming.
See also
math::BarycentricMesh
-
__init__
(self: pydrake.systems.primitives.BarycentricMeshSystem, arg0: pydrake.math.BarycentricMesh, arg1: numpy.ndarray[float64[m, n], flags.f_contiguous]) → None¶ Constructs the system from a mesh and the associated mesh values.
output_values
is a matrix with each column representing the value to output if the input is the associated mesh point. It must have the same number of columns as mesh.get_num_mesh_points(); mesh.MeshValuesFrom(function) is one useful tool for creating it.
-
get_mesh
(self: pydrake.systems.primitives.BarycentricMeshSystem) → pydrake.math.BarycentricMesh¶ Returns a reference to the mesh.
-
get_output_values
(self: pydrake.systems.primitives.BarycentricMeshSystem) → numpy.ndarray[float64[m, n]]¶ Returns a reference to the output values.
-
-
pydrake.systems.primitives.
ConstantValueSource
¶ alias of
pydrake.systems.primitives.ConstantValueSource_[float]
-
template
pydrake.systems.primitives.
ConstantValueSource_
¶ Instantiations:
ConstantValueSource_[float]
,ConstantValueSource_[AutoDiffXd]
,ConstantValueSource_[Expression]
-
class
ConstantValueSource_[float]
¶ Bases:
pydrake.systems.framework.LeafSystem_[float]
A source block that always outputs a constant value.
- Template parameter
T
: - The vector element type, which must be a valid Eigen scalar. This
class uses Drake’s
-inl.h
pattern. When seeing linker errors from this class, please refer to https://drake.mit.edu/cxx_inl.html.
Instantiated templates for the following kinds of T’s are provided:
- double
They are already available to link against in the containing library.
-
__init__
(self: pydrake.systems.primitives.ConstantValueSource_[float], value: pydrake.systems.framework.AbstractValue) → None¶ Scalar-converting copy constructor. See system_scalar_conversion.
- Template parameter
-
class
-
pydrake.systems.primitives.
ConstantVectorSource
¶ alias of
pydrake.systems.primitives.ConstantVectorSource_[float]
-
template
pydrake.systems.primitives.
ConstantVectorSource_
¶ Instantiations:
ConstantVectorSource_[float]
,ConstantVectorSource_[AutoDiffXd]
,ConstantVectorSource_[Expression]
-
class
ConstantVectorSource_[float]
¶ Bases:
pydrake.systems.framework.LeafSystem_[float]
A source block that always outputs a constant value.
- Template parameter
T
: - The vector element type, which must be a valid Eigen scalar. This
class uses Drake’s
-inl.h
pattern. When seeing linker errors from this class, please refer to https://drake.mit.edu/cxx_inl.html.
Instantiated templates for the following kinds of T’s are provided:
- double
They are already available to link against in the containing library.
-
__init__
(self: pydrake.systems.primitives.ConstantVectorSource_[float], source_value: numpy.ndarray[float64[m, 1]]) → None¶ Scalar-converting copy constructor. See system_scalar_conversion.
- Template parameter
-
class
-
pydrake.systems.primitives.
ControllabilityMatrix
(arg0: pydrake.systems.primitives.LinearSystem_[float]) → numpy.ndarray[float64[m, n]]¶ Returns the controllability matrix: R = [B, AB, …, A^{n-1}B].
-
pydrake.systems.primitives.
Demultiplexer
¶ alias of
pydrake.systems.primitives.Demultiplexer_[float]
-
template
pydrake.systems.primitives.
Demultiplexer_
¶ Instantiations:
Demultiplexer_[float]
,Demultiplexer_[AutoDiffXd]
,Demultiplexer_[Expression]
-
class
Demultiplexer_[float]
¶ Bases:
pydrake.systems.framework.LeafSystem_[float]
This system splits a vector valued signal on its input into multiple outputs.
The input to this system directly feeds through to its output.
- Template parameter
T
: - The vector element type, which must be a valid Eigen scalar.
Instantiated templates for the following kinds of T’s are provided:
- double
- AutoDiffXd
- symbolic::Expression
They are already available to link against in the containing library. No other values for T are currently supported.
-
__init__
(self: pydrake.systems.primitives.Demultiplexer_[float], size: int, output_ports_sizes: int = 1) → None¶ Constructs Demultiplexer with one vector valued input port of size
size
and vector valued output ports of sizeoutput_ports_sizes
.output_ports_sizes
must exactly dividesize
. Otherwise this constructor throws an exception. The number of output ports is thereforesize / output_ports_sizes
.- Parameter
size
: - is the size of the input signal to be demultiplexed into its individual components.
- Parameter
output_ports_sizes
: - The size of the output ports.
size
must be a multiple ofoutput_ports_sizes
.
- Parameter
- Template parameter
-
class
-
class
pydrake.systems.primitives.
ExponentialRandomSource
¶ Bases:
pydrake.systems.framework.LeafSystem_[float]
-
__init__
(self: pydrake.systems.primitives.ExponentialRandomSource, num_outputs: int, sampling_interval_sec: float) → None¶
-
-
pydrake.systems.primitives.
FirstOrderLowPassFilter
¶ alias of
pydrake.systems.primitives.FirstOrderLowPassFilter_[float]
-
template
pydrake.systems.primitives.
FirstOrderLowPassFilter_
¶ Instantiations:
FirstOrderLowPassFilter_[float]
,FirstOrderLowPassFilter_[AutoDiffXd]
,FirstOrderLowPassFilter_[Expression]
-
class
FirstOrderLowPassFilter_[float]
¶ Bases:
pydrake.systems.framework.LeafSystem_[float]
An element-wise first order low pass filter system that filters the i-th input uᵢ into the i-th output zᵢ. This system has one continuous state per filtered input signal. Therefore, the i-th state of the system zᵢ evolves according to:
żᵢ = -1/τᵢ (zᵢ - uᵢ)
where τᵢ is the time constant of the i-th filter. The i-th output of the system is given by:
yᵢ = zᵢ
The transfer function for the i-th filter corresponds to:
H(s) = 1 / (1 + τᵢ s)
The Bode plot for the i-th filter exhibits a cutoff frequency (angular frequency) at 1/τᵢ and a gain of one. For frequencies higher than the cutoff frequency, the Bode plot approaches a 20 dB per decade negative slope. The Bode plot in phase exhibits a -90 degrees shift (lag) for frequencies much larger than the cutoff frequency and a zero shift for low frequencies.
- Template parameter
T
: - The vector element type, which must be a valid Eigen scalar.
Instantiated templates for the following scalar types
T
are provided:- double
- AutoDiffXd
- symbolic::Expression
They are already available to link against in the containing library. No other values for T are currently supported.
-
__init__
(*args, **kwargs)¶ Overloaded function.
- __init__(self: pydrake.systems.primitives.FirstOrderLowPassFilter_[float], time_constant: float, size: int = 1) -> None
Constructs a FirstOrderLowPassFilter system that filters all input signals with the same time constant, i.e. τᵢ = τ, ∀ i.
- Parameter
time_constant
: - the time constant τ of the filter. It must be a positive number.
- Parameter
size
: - number of elements in the signal to be processed.
- __init__(self: pydrake.systems.primitives.FirstOrderLowPassFilter_[float], time_constants: numpy.ndarray[float64[m, 1]]) -> None
Constructs a FirstOrderLowPassFilter so that the i-th component of the input signal vector is low pass filtered with a time constant given in the i-th component τᵢ of the input
time_constants
vector.- Parameter
time_constants
: - Vector of time constants. Each entry in this vector must be positive.
-
get_time_constant
(self: pydrake.systems.primitives.FirstOrderLowPassFilter_[float]) → float¶ Returns the time constant of the filter for filters that have the same time constant τ for all signals. This method aborts if called on filters if with different time constants per input signal.
See also
get_time_constants_vector().
-
get_time_constants_vector
(self: pydrake.systems.primitives.FirstOrderLowPassFilter_[float]) → numpy.ndarray[float64[m, 1]]¶ Returns the vector of time constants for
this
filter.
-
set_initial_output_value
(self: pydrake.systems.primitives.FirstOrderLowPassFilter_[float], arg0: pydrake.systems.framework.Context_[float], arg1: numpy.ndarray[float64[m, 1]]) → None¶ Sets the initial conditions on the output value of the filtered signal.
- Parameter
context
: - The current system context.
- Parameter
z0
: - The vector on initial conditions on the output value.
- Parameter
- Template parameter
-
class
-
pydrake.systems.primitives.
FirstOrderTaylorApproximation
(system: pydrake.systems.framework.System_[float], context: pydrake.systems.framework.Context_[float], input_port_index: int = -2, output_port_index: int = -4) → pydrake.systems.primitives.AffineSystem_[float]¶ A first-order Taylor series approximation to a
system
in the neighborhood of an arbitrary point. When Taylor-expanding a system at a non-equilibrium point, it may be represented either of the form:\[\dot{x} - \dot{x}_0 = A (x - x_0) + B (u - u_0),\]for continuous time, or
\[x[n+1] - x_0[n+1] = A (x[n] - x_0[n]) + B (u[n] - u_0[n]),\]for discrete time. As above, we denote \(x_0, u_0\) to be the nominal state and input at the provided
context
. The system description is affine when the terms \(\dot{x}_0 - A x_0 - B u_0\) and \(x_0[n+1] - A x_0[n] - B u_0[n]\) are nonzero.More precisely, let x be a state and u be an input. This function returns an AffineSystem of the form:
\[\dot{x} = A x + B u + f_0,\](CT)
\[x[n+1] = A x[n] + B u[n] + f_0,\](DT) where \(f_0 = \dot{x}_0 - A x_0 - B u_0\) (CT) and \(f_0 = x_0[n+1] - A x[n] - B u[n]\) (DT).
This method currently supports approximating around at most a single vector input port and at most a single vector output port. For systems with more ports, use
input_port_index
andoutput_port_index
to select the input for the newly constructed system. Any additional input ports will be treated as constants (fixed at the value specified incontext)
.- Parameter
system
: - The system or subsystem to linearize.
- Parameter
context
: - Defines the nominal operating point about which the system should be linearized.
- Parameter
input_port_index
: - A valid input port index for
system
or kNoInput or (default) kUseFirstInputIfItExists. - Parameter
output_port_index
: - A valid output port index for
system
or kNoOutput or (default) kUseFirstOutputIfItExists.
Returns: An AffineSystem at this linearization point.
Raises: - RuntimeError if the system if the system is not (only) continuous
- or (only) discrete time with a single periodic update.
Note that x, u and y are in the same coordinate system as the original
system
, since the terms involving \(x_0, u_0\) reside in \(f_0\).- Parameter
-
pydrake.systems.primitives.
Gain
¶ alias of
pydrake.systems.primitives.Gain_[float]
-
template
pydrake.systems.primitives.
Gain_
¶ Instantiations:
Gain_[float]
,Gain_[AutoDiffXd]
,Gain_[Expression]
-
class
Gain_[float]
¶ Bases:
pydrake.systems.framework.LeafSystem_[float]
An element-wise gain block with input
u
and outputy = k * u
withk
a constant vector. The input to this system directly feeds through to its output.This class uses Drake’s
-inl.h
pattern. When seeing linker errors from this class, please refer to https://drake.mit.edu/cxx_inl.html.Instantiated templates for the following scalar types
T
are provided:- double
- AutoDiffXd
- symbolic::Expression
They are already available to link against in the containing library.
To use other specific scalar types see gain-inl.h.
- Template parameter
T
: - The vector element type, which must be a valid Eigen scalar.
-
__init__
(*args, **kwargs)¶ Overloaded function.
- __init__(self: pydrake.systems.primitives.Gain_[float], k: float, size: int) -> None
Constructs a Gain system where the same gain is applied to every input value.
- Parameter
k
: - the gain constant so that
y = k * u
. - Parameter
size
: - number of elements in the signal to be processed.
- __init__(self: pydrake.systems.primitives.Gain_[float], k: numpy.ndarray[float64[m, 1]]) -> None
Scalar-converting copy constructor. See system_scalar_conversion.
-
class
-
class
pydrake.systems.primitives.
GaussianRandomSource
¶ Bases:
pydrake.systems.framework.LeafSystem_[float]
-
__init__
(self: pydrake.systems.primitives.GaussianRandomSource, num_outputs: int, sampling_interval_sec: float) → None¶
-
-
pydrake.systems.primitives.
Integrator
¶ alias of
pydrake.systems.primitives.Integrator_[float]
-
template
pydrake.systems.primitives.
Integrator_
¶ Instantiations:
Integrator_[float]
,Integrator_[AutoDiffXd]
,Integrator_[Expression]
-
class
Integrator_[float]
¶ Bases:
pydrake.systems.framework.LeafSystem_[float]
An integrator for a continuous vector input.
- Template parameter
T
: - The type being integrated. Must be a valid Eigen scalar.
Instantiated templates for the following kinds of T’s are provided:
- double
- AutoDiffXd
- symbolic::Expression
They are already available to link against in the containing library. No other values for T are currently supported.
-
__init__
(self: pydrake.systems.primitives.Integrator_[float], arg0: int) → None¶ Scalar-converting copy constructor. See system_scalar_conversion.
- Template parameter
-
class
-
pydrake.systems.primitives.
IsControllable
(sys: pydrake.systems.primitives.LinearSystem_[float], threshold: Optional[float] = None) → bool¶ Returns true iff the controllability matrix is full row rank.
-
pydrake.systems.primitives.
IsObservable
(sys: pydrake.systems.primitives.LinearSystem_[float], threshold: Optional[float] = None) → bool¶ Returns true iff the observability matrix is full column rank.
-
pydrake.systems.primitives.
LinearSystem
¶ alias of
pydrake.systems.primitives.LinearSystem_[float]
-
template
pydrake.systems.primitives.
LinearSystem_
¶ Instantiations:
LinearSystem_[float]
,LinearSystem_[AutoDiffXd]
,LinearSystem_[Expression]
-
class
LinearSystem_[float]
¶ Bases:
pydrake.systems.primitives.AffineSystem_[float]
A discrete OR continuous linear system.
If time_period>0.0, then the linear system will have the following discrete- time state update:
\[x[n+1] = A x[n] + B u[n],\]or if time_period==0.0, then the linear system will have the following continuous-time state update:
\[\dot{x} = A x + B u.\]In both cases, the system will have the output:
\[y = C x + D u,\]where
u
denotes the input vector,x
denotes the state vector, andy
denotes the output vector.- Template parameter
T
: - The vector element type, which must be a valid Eigen scalar.
Instantiated templates for the following kinds of T’s are provided:
- double
- AutoDiffXd
- symbolic::Expression
They are already available to link against in the containing library. No other values for T are currently supported.
See also
AffineSystem
See also
MatrixGain
-
__init__
(self: pydrake.systems.primitives.LinearSystem_[float], A: numpy.ndarray[float64[m, n], flags.f_contiguous], B: numpy.ndarray[float64[m, n], flags.f_contiguous], C: numpy.ndarray[float64[m, n], flags.f_contiguous], D: numpy.ndarray[float64[m, n], flags.f_contiguous], time_period: float = 0.0) → None¶ Constructs a LinearSystem with a fixed set of coefficient matrices
A
, B,``C``, andD
. The coefficient matrices must obey the following dimensions: | Matrix | Num Rows | Num Columns | |:-------:|:———–:|:-----------:| | A | num states | num states | | B | num states | num inputs | | C | num outputs | num states | | D | num outputs | num inputs |Subclasses must use the protected constructor, not this one.
- Template parameter
-
class
-
pydrake.systems.primitives.
Linearize
(system: pydrake.systems.framework.System_[float], context: pydrake.systems.framework.Context_[float], input_port_index: int = -2, output_port_index: int = -4, equilibrium_check_tolerance: float = 1e-06) → pydrake.systems.primitives.LinearSystem_[float]¶ Takes the first-order Taylor expansion of a System around a nominal operating point (defined by the Context).
This method currently supports linearizing around at most a single vector input port and at most a single vector output port. For systems with more ports, use
input_port_index
andoutput_port_index
to select the input for the newly constructed system. Any additional input ports will be treated as constants (fixed at the value specified incontext)
.- Parameter
system
: - The system or subsystem to linearize.
- Parameter
context
: - Defines the nominal operating point about which the system should be linearized. See note below.
- Parameter
input_port_index
: - A valid input port index for
system
or kNoInput or (default) kUseFirstInputIfItExists. - Parameter
output_port_index
: - A valid output port index for
system
or kNoOutput or (default) kUseFirstOutputIfItExists. - Parameter
equilibrium_check_tolerance
: - Specifies the tolerance on ensuring that the derivative vector isZero at the nominal operating point. $*Default:* 1e-6.
Returns: A LinearSystem that approximates the original system in the vicinity of the operating point. See note below.
Raises: - RuntimeError if the system the operating point is not an
- equilibrium point of the system (within the specified tolerance)
Raises: - RuntimeError if the system if the system is not (only) continuous
- or (only) discrete time with a single periodic update.
Note
All inputs in the Context must be connected, either to the output of some upstream System within a Diagram (e.g., if system is a reference to a subsystem in a Diagram), or to a constant value using, e.g. context->FixInputPort(0,default_input);
Note
The inputs, states, and outputs of the returned system are NOT the same as the original system. Denote x0,u0 as the nominal state and input defined by the Context, and y0 as the value of the output at (x0,u0), then the created systems inputs are (u-u0), states are (x-x0), and outputs are (y-y0).
- Parameter
-
pydrake.systems.primitives.
LogOutput
(src: pydrake.systems.framework.OutputPort_[float], builder: pydrake.systems.framework.DiagramBuilder_[float]) → pydrake.systems.primitives.SignalLogger_[float]¶ Provides a convenience function for adding a SignalLogger, initialized to the correct size, and connected to another output in a DiagramBuilder.
DiagramBuilder<double> builder; auto foo = builder.AddSystem<Foo>("name", 3.14); auto logger = LogOutput(foo->get_output_port(), &builder);
-
pydrake.systems.primitives.
MatrixGain
¶ alias of
pydrake.systems.primitives.MatrixGain_[float]
-
template
pydrake.systems.primitives.
MatrixGain_
¶ Instantiations:
MatrixGain_[float]
,MatrixGain_[AutoDiffXd]
,MatrixGain_[Expression]
-
class
MatrixGain_[float]
¶ Bases:
pydrake.systems.primitives.LinearSystem_[float]
A system that specializes LinearSystem by setting coefficient matrices
A
, B, andC
to all be zero. Thus, the only non-zero coefficient matrix isD
. Specifically, given an input signalu
and a statex
, the output of this system,y
, is:\[y = D u\]- Template parameter
T
: - The vector element type, which must be a valid Eigen scalar.
Instantiated templates for the following kinds of T’s are provided:
- double
- AutoDiffXd
- symbolic::Expression
They are already available to link against in the containing library. No other values for T are currently supported.
See also
AffineSystem
See also
LinearSystem
-
__init__
(self: pydrake.systems.primitives.MatrixGain_[float], D: numpy.ndarray[float64[m, n], flags.f_contiguous]) → None¶ A constructor where the gain matrix
D
isD
.
- Template parameter
-
class
-
pydrake.systems.primitives.
Multiplexer
¶ alias of
pydrake.systems.primitives.Multiplexer_[float]
-
template
pydrake.systems.primitives.
Multiplexer_
¶ Instantiations:
Multiplexer_[float]
,Multiplexer_[AutoDiffXd]
,Multiplexer_[Expression]
-
class
Multiplexer_[float]
¶ Bases:
pydrake.systems.framework.LeafSystem_[float]
This system combines multiple vector-valued inputs into a vector-valued output. The input to this system directly feeds through to its output.
- Template parameter
T
: - The vector element type, which must be a valid Eigen scalar.
Instantiated templates for the following
T
values are provided:- double
- AutoDiffXd
- symbolic::Expression
They are already available to link against in the containing library. Currently, no other values for
T
are supported.-
__init__
(*args, **kwargs)¶ Overloaded function.
- __init__(self: pydrake.systems.primitives.Multiplexer_[float], num_scalar_inputs: int) -> None
Constructs a Multiplexer with
num_scalar_inputs
scalar-valued input ports, and one vector-valued output port of sizenum_scalar_inputs
.- __init__(self: pydrake.systems.primitives.Multiplexer_[float], input_sizes: List[int]) -> None
Constructs a Multiplexer with
input_sizes.size()
vector-valued input ports where the i-th input has sizeinput_sizes[i]
, and one vector- valued output port of sizesum(input_sizes)
.- __init__(self: pydrake.systems.primitives.Multiplexer_[float], model_vector: pydrake.systems.framework.BasicVector_[float]) -> None
Scalar-converting copy constructor. See system_scalar_conversion.
- Template parameter
-
class
-
pydrake.systems.primitives.
ObservabilityMatrix
(arg0: pydrake.systems.primitives.LinearSystem_[float]) → numpy.ndarray[float64[m, n]]¶ Returns the observability matrix: O = [ C; CA; …; CA^{n-1} ].
-
pydrake.systems.primitives.
PassThrough
¶ alias of
pydrake.systems.primitives.PassThrough_[float]
-
template
pydrake.systems.primitives.
PassThrough_
¶ Instantiations:
PassThrough_[float]
,PassThrough_[AutoDiffXd]
,PassThrough_[Expression]
-
class
PassThrough_[float]
¶ Bases:
pydrake.systems.framework.LeafSystem_[float]
A pass through system with input
u
and outputy = u
. This is mathematically equivalent to a Gain system with its gain equal to one. However this system incurs no computational cost. The input to this system directly feeds through to its output. This system is used, for instance, in PidController which is a Diagram composed of simple framework primitives. In this case a PassThrough is used to connect the exported input of the Diagram to the inputs of the Gain systems for the proportioanal and integral constants of the controller. This is necessary to provide an output port to which the internal Gain subsystems connect. In this case the PassThrough is effectively creating an output port that feeds through the input to the Diagram and that can now be connected to the inputs of the inner subsystems to the Diagram. A detailed discussion of the PidController can be found at https://github.com/RobotLocomotion/drake/pull/3132.- Template parameter
T
: - The vector element type, which must be a valid Eigen scalar.
This class uses Drake’s
-inl.h
pattern. When seeing linker errors from this class, please refer to https://drake.mit.edu/cxx_inl.html.Instantiated templates for the following kinds of T’s are provided:
- double
- AutoDiffXd
- symbolic::Expression
They are already available to link against in the containing library.
-
__init__
(*args, **kwargs)¶ Overloaded function.
- __init__(self: pydrake.systems.primitives.PassThrough_[float], arg0: int) -> None
Constructs a pass through system (
y = u
).- Parameter
vector_size
: - number of elements in the signal to be processed.
- __init__(self: pydrake.systems.primitives.PassThrough_[float], arg0: pydrake.systems.framework.AbstractValue) -> None
Constructs a pass through system (
y = u
).- Parameter
abstract_model_value
: - A model abstract value.
- Template parameter
-
class
-
pydrake.systems.primitives.
Saturation
¶ alias of
pydrake.systems.primitives.Saturation_[float]
-
template
pydrake.systems.primitives.
Saturation_
¶ Instantiations:
Saturation_[float]
,Saturation_[AutoDiffXd]
,Saturation_[Expression]
-
class
Saturation_[float]
¶ Bases:
pydrake.systems.framework.LeafSystem_[float]
An element-wise hard saturation block with inputs signal
u
, saturation values \(u_{min}\) and/or \(u_{max}\), and outputy
respectively as in:\[y = u, u_{min} < u < u_{min}\]\[y = u_{min}, u \le u_{min}\]\[y = u_{max}, u \ge u_{max}\]The input to this system directly feeds through to its output.
Instantiated templates for the following scalar types
T
are provided:- double
- AutoDiffXd
- symbolic::Expression
Note that \(u_{min}\), and \(u_{max}\), and \(u\) are all vectors of same dimension, and the following condition holds elementwise in runtime.
\[u_{min} <= u_{max}\]The quantities \(u_{min}\), and \(u_{max}\) can be supplied as inputs in separate ports or be initialised as constants using the appropriate constructor by passing their default value. If these quantities are not defined as constants but they are not connected to appropriate sources, their values are taken by default to be \(u_{min} = -\infty\), and \(u_{max} = \infty\) respectively. In this “variable” configuration, at least one of the input ports must be connected.
-
__init__
(self: pydrake.systems.primitives.Saturation_[float], min_value: numpy.ndarray[float64[m, 1]], max_value: numpy.ndarray[float64[m, 1]]) → None¶ Constructs a constant Saturation system where the upper and lower values are represented by vectors of identical size supplied via this constructor.
- Parameter
u_min
: - the lower (vector) limit to the saturation.
- Parameter
u_max
: - the upper (vector) limit to the saturation.
Please consult this class’s description for the requirements of
u_min
andu_max
.- Parameter
-
class
-
pydrake.systems.primitives.
SignalLogger
¶ alias of
pydrake.systems.primitives.SignalLogger_[float]
-
template
pydrake.systems.primitives.
SignalLogger_
¶ Instantiations:
SignalLogger_[float]
,SignalLogger_[AutoDiffXd]
,SignalLogger_[Expression]
-
class
SignalLogger_[float]
¶ Bases:
pydrake.systems.framework.LeafSystem_[float]
A sink block which logs its input to memory. This data is then retrievable (e.g. after a simulation) via a handful of accessor methods. This class essentially holds a large Eigen matrix for data storage, where each column corresponds to a data point. This system saves a data point and the context time whenever its Publish() method is called.
- Template parameter
T
: - The vector element type, which must be a valid Eigen scalar.
Instantiated templates for the following kinds of T’s are provided:
- double
- AutoDiffXd
- symbolic::Expression
-
__init__
(self: pydrake.systems.primitives.SignalLogger_[float], input_size: int, batch_allocation_size: int = 1000) → None¶ Construct the signal logger system.
- Parameter
input_size
: - Dimension of the (single) input port. This corresponds to the number of rows of the data matrix.
- Parameter
batch_allocation_size
: - Storage is (re)allocated in blocks of input_size-by-batch_allocation_size.
- Parameter
-
data
(self: pydrake.systems.primitives.SignalLogger_[float]) → numpy.ndarray[float64[m, n], flags.f_contiguous]¶ Access the logged data.
-
reset
(self: pydrake.systems.primitives.SignalLogger_[float]) → None¶
-
sample_times
(self: pydrake.systems.primitives.SignalLogger_[float]) → numpy.ndarray[float64[m, 1]]¶ Access the (simulation) time of the logged data.
- Template parameter
-
class
-
class
pydrake.systems.primitives.
TrajectorySource
¶ Bases:
pydrake.systems.framework.LeafSystem_[float]
A source block that generates the value of a Trajectory for a given time. The output is vector values, and may vary with the time (as reflected in the context) at which the output is evaluated.
- Template parameter
T
: - The vector element type, which must be a valid Eigen scalar.
Instantiated templates for the following kinds of T’s are provided:
- double
They are already available to link against in the containing library. No other values for T are currently supported.
-
__init__
(self: pydrake.systems.primitives.TrajectorySource, trajectory: pydrake.trajectories.Trajectory, output_derivative_order: int = 0, zero_derivatives_beyond_limits: bool = True) → None¶ - Parameter
trajectory
: - Trajectory used by the system.
- Parameter
output_derivative_order
: - The number of times to take the derivative. Must be greater than or equal to zero.
- Parameter
zero_derivatives_beyond_limits
: - All derivatives will be zero before the start time or after the
end time of
trajectory
.
- Parameter
- Template parameter
-
class
pydrake.systems.primitives.
UniformRandomSource
¶ Bases:
pydrake.systems.framework.LeafSystem_[float]
-
__init__
(self: pydrake.systems.primitives.UniformRandomSource, num_outputs: int, sampling_interval_sec: float) → None¶
-
-
pydrake.systems.primitives.
WrapToSystem
¶ alias of
pydrake.systems.primitives.WrapToSystem_[float]
-
template
pydrake.systems.primitives.
WrapToSystem_
¶ Instantiations:
WrapToSystem_[float]
,WrapToSystem_[AutoDiffXd]
,WrapToSystem_[Expression]
-
class
WrapToSystem_[float]
¶ Bases:
pydrake.systems.framework.LeafSystem_[float]
An element-wise wrapping block that transforms the specified indices of the input signal
u
into the interval[low, high)
. Precisely, the output elementi
is given the value:outputᵢ = inputᵢ + kᵢ*(highᵢ-lowᵢ)
for the unique integer value
kᵢ
that lands the output in the desired interval.Instantiated templates for the following scalar types
T
are provided:- double
- AutoDiffXd
- symbolic::Expression
-
__init__
(self: pydrake.systems.primitives.WrapToSystem_[float], arg0: int) → None¶ Constructs a system to pass through a fixed-size input vector to the output. Additional calls to set_interval() are required to produce any wrapping behavior.
-
set_interval
(self: pydrake.systems.primitives.WrapToSystem_[float], arg0: int, arg1: float, arg2: float) → None¶ Sets the system to wrap the
index
element of the input vector to the interval[low, high)
. If this method is called multiple times for the same index, then only the last interval will be used.low
andhigh
should be finite, and low < high.
-
class
-
pydrake.systems.primitives.
ZeroOrderHold
¶ alias of
pydrake.systems.primitives.ZeroOrderHold_[float]
-
template
pydrake.systems.primitives.
ZeroOrderHold_
¶ Instantiations:
ZeroOrderHold_[float]
,ZeroOrderHold_[AutoDiffXd]
,ZeroOrderHold_[Expression]
-
class
ZeroOrderHold_[float]
¶ Bases:
pydrake.systems.framework.LeafSystem_[float]
A ZeroOrderHold block with input
u
, which may be vector-valued (discrete or continuous) or abstract, and discrete outputy
, where the y is sampled from u with a fixed period.Note
For an abstract-valued ZeroOrderHold, transmografication is not supported since AbstractValue does not support it.
-
__init__
(*args, **kwargs)¶ Overloaded function.
- __init__(self: pydrake.systems.primitives.ZeroOrderHold_[float], period_sec: float, vector_size: int) -> None
Constructs a ZeroOrderHold system with the given
period_sec
, over a vector-valued input of sizevector_size
. The default initial value for this system will be zero.- __init__(self: pydrake.systems.primitives.ZeroOrderHold_[float], period_sec: float, abstract_model_value: pydrake.systems.framework.AbstractValue) -> None
Constructs a ZeroOrderHold system with the given
period_sec
, over a abstract-valued inputabstract_model_value
. The default initial value for this system will beabstract_model_value
.
-
-
class


| Exception | Description |
|---|---|
| InvalidOrUnsupportedTimeZoneDefinitionException |
The Class InvalidOrUnsupportedTimeZoneDefinitionException.
|
| PropertyException |
Represents an error that occurs when an operation on a property fails.
|
| ServiceLocalException |
Represents an error that occurs when a service operation fails locally (e.g.
|
| ServiceObjectPropertyException |
Represents an error that occurs when an operation on a property fails.
|
| ServiceValidationException |
Represents an error that occurs when a validation check fails.
|
| ServiceVersionException |
Represents an error that occurs when a request cannot be handled due to a
service version mismatch.
|
| ServiceXmlDeserializationException |
Represents an error that occurs when the XML for a response cannot be
deserialized.
|
| ServiceXmlSerializationException |
Represents an error that occurs when the XML for a request cannot be
serialized.
|
| TimeZoneConversionException |
Represents an error that occurs when a date and time cannot be converted from
one time zone to another.
|


Summary Report – Board of Directors
Celebrating its 150th anniversary year, Ziraat Bank proceeded step by step in realizing its goals with the dynamism brought by reorganization. Ziraat Bank has worked intensively towards achieving the Bank’s transformation in Service for Bank Customers model which is shaped by “Customer Oriented Banking”, with the underlying motto in this transformation being “Together, to a Better Future”. In this respect, Ziraat Bank switched to a portfolio management system upon completion of customer and branch segmentation, in order to provide services to customers through accurate channels. The General Management, Regional and Branch Organization have been restructured in accordance with principles such as “division of powers” and “customer orientation”.
Branch and customer segmentation has been carried out in line with the one-to-one Customer Relationships Management study. Under the framework of customer orientation, branches have been diversified in order to meet different financial needs of the customers. The Bank switched to a customer representation model - in compliance with Portfolio Management principles - and a number of infrastructural IT projects have been completed in order to allow Bank to follow-up customer needs. Consequently, Ziraat Bank turned into a bank with the most extensive network which aims to meet all financial needs of the customers in a customer centric way.
Within the context of the project, the “Operations Center” was activated and operations gradually transferred to the Center in order to reduce operational density and simplify our services. An Individual Performance System started to be employed in parallel with the objective and transparent HR policies, which are at the heart of the motto of “Together, to a Better Future”.
In line with the “Together toward the Target” strategy, which marks the second stage of the reorganization, work on the corporate development projects continued unabated within Ziraat Bank and corresponding banks and branches abroad. The primary objective of “Together toward the target” is to ensure the transformation of customers from “Bank Customers” to “Ziraat Customers”, with the ultimate goal of ensuring all our partners and international branches operate efficiently, in compliance with our understanding of global banking under the “Ziraat” brand and serve our customers with the same quality of service in every country, and therefore, turn into a bank with a high brand and market value which operates on an international scale.
Infrastructural IT investments for our international partners and branches are carried out in alignment with our target, and basic banking systems are renewed. As a consequence of this work, the Bank became more prepared to tackle the competition in the sector and the volatility in the markets, and rounded off a successful performance in 2013, despite the challenges of the instabilities in the fluctuations.
Ziraat Bank increased its total assets by 27% YoY to TL 207.5 billion by the end of 2013. By re-establishing credit evaluation, allocation, management and risk appetite by institutionalizing these processes, the Bank achieved a record 55% increase in total credits and raised its total credit balance to TL 111 billion. Consequently, the ratio of credit in total assets was realized as 54%.
As one of the country’s most important assets, the Bank continued to increase its support for the real sector. The Bank realized this by strategically placing itself in the entrepreneurial customer segment, mainly in the SME segment. Additionally, the Bank is poised to continue adding value to the national economy by involving itself in investment and project financing operations in those sectors which are contributing to reducing the current account deficit.
Ziraat Bank is close to its customers in financing the agricultural sector and considers the growth and development of the agricultural sector as one of its primary objectives, helping the sector become competitive on a global scale. Being involved in every stage of the financing of agricultural production, agricultural industry and industrial production, the Bank strives for all players in this value chain, as part of the transformation process. In the agricultural industry Ziraat Bank is close to the customer in every stage of the production process from the ground to the shelf, starting from production right up to the sale and marketing of goods in both domestic and foreign markets, from the very first product to the end customers of the Bank. Anticipating that agriculture will be as important as energy as a business line, the Bank will remain a key supporter of the agricultural sector while increasing its efficiency and competitiveness.
Building its deposit resources on a solid basis, Ziraat Bank continued to fund its assets at low cost by concentrating on its deposit base in 2013. Deposits, which accounted for the highest weighting in assets, amounted to TL 141.7 billion. The share of demand deposits in total deposits reached around 20%. In order to extend funding maturities, the Bank purchased syndication loans for USD 700 million and placed priority on the issue of domestic bank bills and bonds during the process of diversification in the structure of resources.
Ziraat Bank completely renewed its Internet Branch. The New Generation Internet Branch is categorized according to customers’ various needs and received the Best in its Class award in the Financial Services category in the Interactive Media Awards, in view of its accessible homepage and user-friendly structure. This award, granted to Ziraat Bank’s New Generation Internet Branch, was also the first award given by the IMA to an Internet Branch in Turkey.
The Bank leads the sector in terms of the number of cards in circulation, with more than 20 million cardholders. In the framework of increasing the utilization of debit cards in shopping purposes, the Bank activated the Bankkart project which provides cash to cardholders whenever they spend using their Bankkart - the Bank’s own brand. The Bankkart was the first bank card to allow its holders to earn while both spending and saving.
The Bank opened 150 new branches in its 150th year. The number of ATMs increased by 1,120 in 2013, with 243 added in the last quarter to reach a total of 5,353, helping the Bank meet customer’s demands more rapidly and efficiently.
The ratio of equity - amounting to TL 18.3 billion - in total liabilities stood at 8.9% at the end of 2013, with our Bank commanding a capital adequacy ratio of 13.2%. The main constituent of the equity was the net profit, which was realized as TL 3.3 billion in 2013, placing the Bank as the most profitable bank in the sector.
Performing well on the basis of many profitability and efficiency ratios including net interest margin and capital efficiency, the Bank realizes its aim with a dedicated project discipline and continues to work to generate value for customers and the country with its global banking vision and dynamic new structure.
TÜRKİYE CUMHURİYETİ ZİRAAT BANKASI A.Ş.
Hüseyin AYDIN |
Muharrem KARSLI |


Howdy! Welcome to SPEED Spec R3. Should work better on a phone (Safari on iPhone excepted).
See also the GitHub Read Me file
See also the SPEED Spec gbXML Sample File Viewer to view sample files generated by this script. Now with a view surface normals button.