| NEWS | R Documentation |
C-level functions set_pomp_userdata
and unset_pomp_userdata
are no longer exported.
stew
now returns timing information by default.
The spurious warnings associated with NULL userdata
have been eliminated.
The new option on_load
allows one to specify a C snippet that will be executed at the time the C snippet library is loaded.
Internally, the userdata
are made available via calls to pompLoad
rather than within each call to a pomp workhorse.
The data frames returned by cond_logLik
and eff_sample_size
when format="data.frame"
have been improved.
In particular, they contain (as variable time
) the times (rather than the index of the time vector as before).
Changes to the report generated by spy
.
Some documentation improvements.
The manual pages have been reorganized, with improved cross-linking.
A bug in filter_traj
etc. arising when not all state variables have names was fixed.
This version adds the new basic component dinit
for evaluating the probability density function of the initial-state distribution.
There is a corresponding workhorse function, dinit()
.
The constructor pomp
now takes the optional argument nstatevars
, which can be used to increase the dimension of the latent state-vectors created by rinit
.
By default, nstatevars = length(statenames)
, and nstatevars
can only be used to increase, not to decrease, the dimension of the latent state process.
Moreover, nstatevars
has no effect if the rinit
basic component is furnished as an R function.
Name checking on internally-created vectors and arrays is less strict than previously.
In particular, it is possible to have variables without names (i.e., ""
).
reulermultinom
now returns NA
rather than NaN
, in keeping with the behavior of rbinom
.
Thanks to John Drake for calling attention to this issue.
A bug in stew
resulting in namespace conflicts has been repaired.
We no longer import directly from tidyverse functions. This reduces the list of packages upon which pomp depends from 20 to 5. This does introduce a dependency on the data.table package.
When the archive directory does not exist, bake
and stew
now create it.
We no longer import from plyr.
The dimnames
attributes of various arrays that appear in pomp, including arrays of observables, state variables, parameters, covariates, and so on, have been made uniform.
In particular, when a dimension of an array corresponds to variables with different names, this dimension is itself named “name”.
Previously, its name was sometimes “variable” and sometimes “parameter”.
This change is meant to streamline interaction with the tidyverse.
Some minor bugfixes.
Functions with names.that.contain.dots that have been deprecated since version 4.5.1 are now defunct. Attempts to use such functions will generate an error with a message indicating the replacement function.
plot
now removes NA
.
Better handling of ‘listie’s (lists of ‘pomp’ objects).
New concat
function to turn lists of ‘pomp’ objects into ‘listies’.
Bug fix in filter_traj
applied to ‘pfilterList’ and ‘pmcmcList’ objects.
The states
and obs
methods take a new optional argument, format
.
Setting format="data.frame"
causes the method to return the states or data in a convenient data-frame format.
When melt
is applied to a list, the identifier variable is now “.Lx
”, where x
denotes the level.
This applies when as.data.frame
is used to coerce a list of ‘pomp’ objects, and when saved_states
is used to extract the particles from a list of ‘pfilterd_pomp’ objects.
logmeanexp
can now compute the effective sample size, which can be useful in determining the reliability of its estimate.
To do so, set ess=TRUE
in a call to logmeanexp
.
logmeanexp
now returns a fully-named vector when either se=TRUE
or ess=TRUE
.
A new format
argument has been added to the extractor functions cond_logLik
, eff_sample_size
, filter_mean
, filter_traj
, forecast
, pred_mean
, pred_var
, and saved_states
.
This allows the user to extract the relevant elements in data-frame format if desired.
pomp no longer depends on the superseded package reshape2.
The melt
function for converting arrays and nested lists into data frames is accordingly no longer re-exported from reshape2.
It has been replaced by a stricter version of melt
.
The magrittr pipe %>%
is no longer re-exported by pomp: use the native R pipe |>
instead.
The package now requires R version 4.1 at least.
All pomp functions with names.that.contain.dots have been deprecated in favor of functions in ‘snake_case’. This is to avoid anticipated problems with CRAN checks, which (falsely) assume that certain functions with dotted.names are S3 methods. From this point, no exported pomp function has such a name.
The dimnames
attributes for some of the arrays computed in pfilter
and pmcmc
computations have changed.
In particular, whereas in previous versions, the time
dimension was given names that were character strings composed of decimal representations of the time (difficult to work with and prone to roundoff error), the time
dimension now is not given names.
A bug that resulted in gompertz
giving different simulations on Windows machines has been fixed.
A bug in trajectory computation for maps (discrete-time dynamical systems) has been fixed. Thanks to Felicia Magpantay for noticing it and tracking it down.
Minor documentation improvements.
The weighted quantile function wquant
now uses the Harrell-Davis estimator instead of the type-7 estimator used previously.
This eliminates bugs associated with non-integer weights.
It is now possible to retrieve the weighted particles computed in the course of a pfilter
computation.
To accomplish this, set save.states="weighted"
in the call to pfilter
and retrieve the particles and their weights using saved.states
.
Previously, one could obtain only the unweighted particles.
Some documentation improvements.
The new function wquant
computes weighted quantiles.
The precise order in which the pmcmc
function computes prior and likelihood of furnished and proposed parameters has changed slightly.
This prevents proposals that are incompatible with the prior from being passed to pfilter
and forestalls an associated class of errors.
A consequence of this change, pmcmc
computations using the new version will differ very slightly from previous computations, even with the RNG seed fixed at its previous values.
There is now a C interface to the bspline_eval
function.
See the pomp C API documentation for details.
The bspline.basis
function now takes the optional argument rg
which allows one to specify the range over which the basis will be constructed.
By default, this is range(x)
, which agrees with the behavior in earlier versions.
Documentation improvements.
The archiving functions bake
and stew
now use a slightly less exacting comparison of the expression, expr
, they are furnished.
NB: Running bake
or stew
with archives created by earlier versions may result in recomputation.
The time
method has been extended to pompList
and related objects.
All workhorse functions except partrans
have new default arguments.
Some documentation improvements.
The archiving functions bake
and stew
now take the argument dir
, which is the directory holding the archive files.
By default, this is the current working directory or the value of the global option pomp.archive.dir
.
A new global option, pomp_archive_dir
, can be used to specify the locations of archive files used by bake
and stew
.
Documentation repair of issue flagged by Kurt Hornik (9 June 2022).
Minor changes, invisible to the user.
Minor changes to the C codes to keep up with R-devel.
Minor changes to the C codes to keep up with R-devel.
Minor changes in the implementation of bake
and stew
.
Change in the names of the variables returned by as.data.frame
applied to a ‘pfilterd.pomp’ object.
Fixed bug found by Jesse Wheeler and Ed Ionides, to do with 'simulate()' with 'include.data=TRUE'.
It is now possible to plot lists of ‘pomp’ and ‘pomp’-derived objects using a single call to plot
.
The rbetabinom
and dbetabinom
functions, long present as part of the C API, are now available as R functions.
The SIR examples sir()
and sir2()
now use a negative binomial measurement model.
parmat
can now take a data frame of parameters and convert it into a matrix suitable for furnishing to the params
argument of any pomp function.
It is now possible to change the parameters in an ‘objfun’ (objective function) object using coef(object)<-value
.
parmat
now takes an optional argument, names
, which allows the user to name the parameter sets.
Independent realizations of the stochastic processes modeled in pomp are now distinguished by different values of .id
.
This behavior is now uniform throughout.
bake
and stew
now send messages instead of warnings when they recompute an archive due to a change in code or dependencies.
The ensemble adjusted Kalman filter (eakf
) has been refactored.
It now makes use of the emeasure
and vmeasure
basic components to compute an approximation of the linear relationship between the latent state and the observed variables.
The forecast
method now works for pfiterd_pomp
objects (i.e., results of pfilter
, pmcmc
, or mif2
computations).
Two new basic model components have been introduced. These are:
which computes the expectation of the observable variables conditional on the latent state;
which computes the covariance matrix of the observables given the latent state.
These are used by the newly refactored ensemble Kalman filter, enkf
.
The basic (linear, Gaussian) Kalman filter is now available as kalmanFilter
.
Computation of Monte Carlo-adjusted profile likelihood is now facilitated by the new mcap
function.
The default return-value format for trajectory
now matches that of simulate
.
Version 4 contains a few changes that are not backward compatible.
These are all to do with the elementary function trajectory
, which computes trajectories of the deterministic dynamical skeleton.
See below for details.
The behavior of trajectory
now fully conforms to the behavior of other pomp elementary functions.
In particular, one can now add, remove, or modify basic model components in a call to trajectory
just as one can with simulate
, pfilter
, probe
, etc.
Before version 4, additional arguments to trajectory
(i.e., those passed via ...
) were passed on to the ODE integrator in the case of continuous-time deterministic skeletons (i.e., vectorfields) and ignored in the case of discrete-time skeletons (i.e., maps).
As of version 4, in order to adjust ODE integrator settings it is necessary to use the ode_control
argument of trajectory
.
This behavior matches that of traj_objfun
.
It is now possible to create a ‘pomp’ object from scratch using trajectory
, together with a specification of the rinit and skeleton components.
Prior to version 4, in order to do so, it was necessary to first create a dummy data set, then call pomp
, and then pass the resulting ‘pomp’ object to trajectory
.
This can now be achieved in one call.
The user now has the option, in a call to trajectory
, to have the results returned as one or ‘pomp’ objects.
In this regard, its behavior matches that of simulate
.
The states
and obs
methods now work for lists of ‘pomp’ objects (‘listies’).
The workhorse function flow
now has default arguments.
The stateful objective function created by traj_objfun
has been refactored so that it is independent of trajectory
.
This change is invisible to the user, but lays the groundwork for future changes in trajectory
.
Stateful objective functions created by traj_objfun
, nlf_objfun
, probe_objfun
, and spect_objfun
now have default arguments.
In particular, the default is argument is a zero-length numeric vector.
Calling such a function with no arguments is valid if and only if the objective function was created with no variables to estimate (empty est
).
Fixed bug in rprior
arising with integer-valued return vectors.
Major improvements to the package manual, including richer cross-linking and better organization.
When simulate
is called with format="data.frame"
and include.data=TRUE
, the interpolated covariates are now included in the data frame that is returned.
bake
takes a new option, timing
, that controls whether information on the timing is returned or merely stored.
By default, this is set to TRUE
, though this default behavior may change in future.
When they encounter an archive produced by an older version, bake
and stew
now update the archive in the new format.
Recomputation should never be triggered in this case:
If recomputation is desired, delete the archive file.
bake
and stew
now archive a digest of the code in expr
and on subsequent calls check to see if the archived version matches the current version.
Thus, changes to the code automatically trigger recomputation.
bake
and stew
take the new argument dependson
.
Using this argument, the user can specify objects upon which the computation depends.
These should be passed as unquoted variables;
if there are multiple dependencies, they can be passed using c
or list
.
Digests of these objects will be archived and checked against current values on subsequent calls.
Thus, changing any dependency will automatically trigger recomputation.
bake
now archives the information pertinent to the bake
call;
this information is no longer returned along with the result of the computation (unless info=TRUE
).
Similarly, stew
stores a list, “.ingredients”, in the file it creates.
In the stew
case, unlike all the other objects that are created by expr
, this list is not by default loaded into the calling environment (e.g., the user's workspace).
It will be loaded if the info
flag is set to TRUE
.
freeze
no longer stores the details of the RNG seed and kind as an attribute of the returned object.
Fix bug in bsmc2
arising when some particles have zero likelihood.
This is Issue #152.
Thanks to Hola-Kwame Adrakey for reporting it.
It is now possible to call partrans
directly on an objective function, such as those created by traj_objfun
, nlf_objfun
, probe_objfun
, or spect_objfun
.
The package manual and help pages has been streamlined.
The mif2
diagnostic plots have been made more flexible.
Some deprecated functions have been removed.
These include cond.loglik
, sliceDesign
, runifDesign
, sobolDesign
, and profileDesign
, which have been replaced by code.logLik
, slice_design
, runif_design
, sobol_design
, and profile_design
, respectively.
A bug in rgammawn
has been fixed.
The pomp C API has been expanded a bit, to facilitate other packages' linking to the pomp library.
The help pages have been improved, with an description of the overall package structure and pages on basic model components, elementary algorithms, and estimation algorithms.
A note to Windows users on avoiding certain C snippet compilation errors has been added to the help pages.
The behavior of profile_design
has changed.
Previously, the same random (or sub-random) sequence was used for all non-profile parameters.
Now, for each profile slice, a distinct set of points is generated.
profileDesign
, sliceDesign
, runifDesign
, and sobolDesign
have been deprecated and will be removed in a future release.
They are replaced by profile_design
, slice_design
, runif_design
, and sobol_design
, respectively.
A new saved.states
method allows one to extract the saved states from a particle filter computation.
All instances of cond.loglik
have been changed to cond.logLik
, to remove a common source of typographical error.
A new sequential importance sampling algorithm has been implemented as wpfilter
.
This is a generalization of the algorithm in pfilter
in that it tracks the weights of the particles and allows the user to customize the resampling scheme.
In mif2
, the specification of particle numbers, Np
, has changed.
When Np
is supplied as a function, Np(0)
is the requested number of particles at the beginning of the time series.
The previous behavior was that Np(1)
specified the requested number of particles.
This behavior now matches that of the other particle filtering algorithms, pfilter
, bsmc2
, and pmcmc
.
bsmc2
can now accept a variable number of particles, as do the other particle-filter based algorithms pfilter
, pmcmc
, and mif2
.
The internal systematic_resample
function now allows the user to specify the number of samples desired.
Previously, these were always equal to the number of weights supplied.
As promised from version 2.4.1, the tol
and max.fail
arguments have been removed completely from all particle-filtering algorithms, including pfilter
, pmcmc
, bsmc2
, and mif2
.
See the pomp news blog (https://kingaa.github.io/pomp/blog.html) for more information.
The long-deprecated functions onestep.dens
, onestep.sim
, discrete.time.sim
, euler.sim
, gillespie.sim
, gillespie.hl.sim
, conv.rec
, and values
have been removed.
These have been replaced as follows
onestep.dens | direct specification of dprocess component |
onestep.sim | onestep |
discrete.time.sim | discrete_time |
euler.sim | euler |
gillespie.sim | gillespie |
gillespie.hl.sim | gillespie_hl |
conv.rec | traces |
values | as.data.frame or as(x,"data.frame") |
Trap error from non-finite likelihoods in pmcmc
.
New test of pmcmc
codes in ‘tests/issue109.R’.
Trap error from missing accumulator variables in trajectory
.
The Euler step size in sir
is now adjustable.
As promised, the default value of tol
in the particle-filtering algorithms pfilter
, pmcmc
, mif2
, and bsmc2
has been changed to zero.
A warning continues to be issued if tol
is set to anything other than 0.
In a future release, the option to choose a nonzero tolerance will be removed entirely.
In traces and diagnostic plotting methods, the nfail
variable (tracking numbers of filtering failures) has been dropped.
Another documentation bug was fixed.
A documentation bug, identified by K. Hornik, was fixed.
In anticipation of forthcoming algorithmic changes, the tol
and max.fail
arguments of pfilter
, bsmc2
, pmcmc
, and mif2
are now deprecated.
A warning is issued if tol
is set to anything other than 0.
In a future release, these options will be removed entirely: the behavior will be similar to that obtained in the present release by setting tol=0
.
A new example illustrating the accumvars
argument has been provided.
Internal computations now use increased precision for means, variances, and certain calculations with likelihoods.
A new help page, pomp_examples
, lists the various example datasets and pomp objects provided with the package.
The source codes underlying specification of basic model components via R functions has been reworked to remove reliance on deep PROTECT
stacks.
Thanks to Thomas Kalibera for showing the way!
A bug in the documentation for filter.traj
, pointed out by Pierre Jacob, has been fixed.
The C API for pomp is no longer explained only in comments in the “pomp.h” header file. It is now described and explained in the new C API vignette.
The new pomp_cdir
global option allows one to set the directory holding C snippet files globally.
A bug caused by re-use of the cfile
argument has been fixed.
Re-use now triggers an error, with an informative message.
Some documentation improvements.
A bug in runifDesign
(and therefore profileDesign
when type="runif"
) has been fixed.
There are now plot
methods for objects of classes ‘probe_match_objfun’ and ‘spect_match_objfun’.
Released to CRAN.
The melt
function can now be applied to arbitrary ‘pomp’ objects.
A new function, runifDesign
allows construction of design matrices using samples from multivariate uniform distributions.
The profileDesign
function takes a new argument, type
, with two options:
"sobol"
, the default, constructs the design using sobolDesign
, as before.
"runif"
uses the new runifDesign
function.
A new example, comprising models and data for the 2014–2016 west African Ebola virus disease outbreak, is included.
See ?ebola
for details.
It is now possible to adjust the observation times and zero-time in the sir
and sir2
examples.
One can also change the default RNG seed used in generating the simulated data.
The codes underlying the rprocess
workhorse have been streamlined to obviate an unnecessary copy operation.
As a result, the interface to the rprocess
workhorse has been changed.
The interface to the new flow
workhorse has been changed to match.
The new flow
workhorse allows integration/iteration of the deterministic skeleton at arbitrary times from an arbitrary initial condition.
When coef
is applied to a ‘listie’, the result can be more usefully melt
ed.
The probe-names returned by probe.acf
and probe.ccf
have changed.
A bug, whereby the ‘coef’ method from other packages was masked, has been fixed.
Errors in the documentation have been corrected.
There is a new as.data.frame
method for ‘listie’s.
Some problems with the exposure of internal objects for package developers have been corrected.
The magrittr pipe operator, %>%
, is now re-exported.
More examples have been included.
Minor changes to error messages.
The names of the ‘objfun’ methods have been changed to probe_objfun
, spect_objfun
, traj_objfun
, and nlf_objfun
.
The package directory structure has been modified to include a new ‘examples’ directory, which holds the examples used in the documentation.
The names of the ‘objfun’ methods have been shortened.
It is now permissible that the sequence of observation times (and sequences of covariate times) be merely non-decreasing sequences. Previously, pomp insisted on strictly increasing time sequences.
The default cooling schedule (cooling.type
) in mif2
is now “geometric”, in contrast to “hyperbolic”, as before.
pomp now requires at least R version 3.5.
The zeronames
argument has been renamed accumvars
.
In the course of ordinary work, one should never need to interact with the low-level pomp
constructor function now.
The pompExample
function has been dropped.
The various examples are now included as regular functions that construct ‘pomp’ objects.
The bbs
example has been dropped.
One can now modify basic model components at (almost) any stage in a pipeline of pomp computations.
All the top-level inference functions, plus probe
, pfilter
, and simulate
now allow modification of basic model components.
The rprocess
plugins onestep.sim
, discrete.time.sim
, euler.sim
, gillespie.sim
, and gillespie.hl.sim
have been renamed onestep
, discrete_time
, euler
, gillespie
, and gillespie_hl
, respectively.
The old usage is available but deprecated.
One can now call simulate
on a model without reference to any data.
The covariate table facility (covariate_table
) now supports piecewise constant interpolation.
The syntax with which one includes covariates via covariate_table
has become more flexible.
Specifically, the arguments to covariate_table
are now evaluated sequentially, so that later ones can depend on earlier ones.
Once evaluated, the covariates are bound column-wise into a single data frame.
The manner in which one writes R functions to specify basic model components has been totally changed. Before, one wrote functions that took specific arguments such as 'x', 'params', and 'covars'. Now, one writes such functions with any or all state variables, observables, covariates, and/or time as arguments.
simulate
now returns more informative results when simulations from multiple parameter sets are simultaneously computed.
Specifically, if params
has column names, these are used to identify the resulting simulations.
Thus when format = "pomps"
(the default), the names of the resulting list will be constructed from the column names of params
.
Likewise, when format = "arrays"
, the resulting arrays will have informative column names;
When format = "data.frame"
, the identifier variable will make use of the column names.
The basic particle filter, pfilter
, has a simpler mode of operation:
params
should be a single parameter set only.
That is, it is no longer possible to pass a matrix of parameters to pfilter
.
The Liu-West algorithm, bsmc2
, has a simpler mode of operation:
params
should be a single parameter set only:
the SMC particles are drawn from rprior
.
The as.data.frame
, states
, and obs
options for simulate
have been done away with.
One now chooses the format of the returned simulations via the format
argument.
When one simulates at multiple parameter sets, list names, array dimnames
, or identifying variables in the output data frame help to correlate simulations with parameter sets.
The as.data.frame
argument to trajectory
has been removed in favor of a new format
argument that allows one to choose between receiving the results in the form of an "array"
or a "data.frame"
.
All the basic model components now have defaults.
The default rinit
behavior remains as it was:
it assumes the initial state distribution is concentrated at a point mass determined by parameters with “.0
” or “_0
” suffices.
The default process model is “missing”: calls to dprocess
and rprocess
will result in missing values (NA
).
The default measurement model is “missing” as well.
The default prior is flat and improper:
all calls to the default dprior
result in 1
(0
if log = TRUE
, and all calls to rprior
result in NA
.
The default skeleton is missing.
The default parameter transformations remain the identity.
The transform
argument present in many pomp algorithms has been removed.
Parameter transformations are now automatically performed when appropriate.
The default parameter transformation remains the identity.
The old probe.match
and traj.match
functions have been removed.
The new approach to parameter estimation based on numerical optimization involves constructing stateful objective functions.
There are now three of these: traj.match.objfun
, probe.match.objfun
, and spect.match.objfun
.
The documentation system has been thoroughly overhauled.
In skeleton
, the t
argument has been replaced by times
, to make this uniform with the other workhorse functions.
Covariates are now included using the covariate_table
construction, passed via the covar
argument to pomp
.
The tcovar
argument is no longer used.
Instead of providing separate fromEstimationScale
and toEstimationScale
arguments to pomp
, one now provides a single partrans
argument constructed by means of the new function parameter_trans
.
In addition, references to “fromEstimationScale” and “toEstimationScale” have been abbreviated to “fromEst” and “toEst”, respectively, throughout the package.
When writing C snippets for parameter transformations, the notation T_p
refers to the value of p
on the estimation scale.
Thus, if parameter alpha
is to be log-transformed for estimation, the toEst
snippet would contain the line T_alpha = log(alpha);
and the fromEst
snippet would include alpha = exp(T_alpha);
.
The parameter_trans
function now takes optional arguments log
, logit
, and barycentric
, with names of parameters to be log-, logit-, and log-barycentric transformed, respectively.
The measurement.model
argument to pomp
has been removed.
It is now necessary to specify the measurement model directly using rmeasure
and/or dmeasure
.
The initializer
is no longer referred to by that name.
It is now rinit
, since it draws from the distribution of the latent state at the initial time.
The low-level function init.state
has been replaced by rinit
.
The conv.rec
method has been deprecated, replaced by the new traces
method.
The euler.sir
example has been renamed sir
.
The gillespie.sir
example has been renamed sir2
.
The covmat
method can now be applied to a probed.pomp
object.
It returns the estimated covariance matrix of the probes.
When trajectory
calls on deSolve routines to numerically integrate a model vectorfield, more informative error messages are generated, and diagnostics are printed when verbose = TRUE
.
The show
method applied to pomp objects is now quite terse.
To obtain detailed information, the spy
method is available.
The spy
method now returns the information formerly displayed in a call to show
, in addition to the C files associated with any C snippets.
The use of $
methods to access the slots of pomp S4 objects has now been removed.
These classes are no longer exported (for the most part).
The transform
argument to the probe.quantile
function has been removed (as it is entirely redundant!).
The old and deprecated mif
and bsmc
methods have been removed.
The obs
and states
arguments of simulate
are deprecated and will be removed in a forthcoming release.
The C-level interface for apply_probe_sims
has changed: the new argument rho
must be the “package:pomp” environment.
A bug in pfilter
(and hence pmcmc
) when filter.traj=TRUE
was discovered and fixed.
In the buggy version, the filter trajectory was sampled with incorrect weights.
Timo Voipio contributed a pull request that traps the error resulting from sannbox
being passed a candidate.dist
that is not a function.
show
and print
methods have been made very terse:
they simply report on the class of the object in question.
To see more detailed information about a ‘pomp’ object, use spy
.
New (unexported) solibs<-
method allows developers of packages extending pomp to incorporate C snippets into object that contain ‘pomp’ objects.
New verbose
option in trajectory
gives diagnostic information from deSolve integration routines.
Of course, this is pertinent only if the model skeleton is a vectorfield.
Bug in the display of istate
when deSolve::ode
errors has been fixed.
New hitch
function facilitates construction of pomp.fun
objects from R functions, C snippets, and links to external libraries.
Native routines needed to access pomp.fun
objects in C are now registered for use by other packages.
coef(object) <- NULL
, where object
is of class ‘pomp’, erases any parameters stored in object
.
The euler.sir
, gillespie.sir
, blowflies
, ricker
, bbs
, dacca
, and rw2
examples are all now implemented using C snippets.
A new ‘pomp_defines.h’ header is provided for developers of packages that depend on pomp.
Internally, rprocess
is no longer stored as an R function.
The use of plugins is now required for the implementation of the rprocess
component.
Currently, there are five plugins available:
onestep.sim
, discrete.time.sim
, euler.sim
, gillespie.sim
, and gillespie.hl.sim
.
The new hitch
function automates the building and linking of C snippets and R functions into pomp.fun
s.
The handling of dprocess
has changed.
The onestep.dens
plugin is now deprecated and will soon be removed.
dprocess
is now specified directly using either a C snippet or an R function, in much the same way that, for example, dmeasure
is specified.
The old ‘forward’ and ‘inverse’ options for the dir
argument of partrans
have been dispensed with.
The much more descriptive options ‘toEstimationScale’ and ‘fromEstimationScale’ remain.
The C snippet compiling facilities have been thoroughly reworked.
onestep.dens
can now take a Csnippet
specification of the process-model transition density.
All inference functions can now take a list in the start
or params
arguments.
When altering parameters in a call to probe
on a probed.pomp
object, the new parameters were ignored.
This bug has been fixed.
mif2
, pfilter
, probe
, probe.match
, and probe.match.objfun
can now gracefully handle a list in the start
or params
arguments.
New spy
method displays the C snippet file(s) associated with a pomp
object.
The long-deprecated seed
argument to bsmc
and bsmc2
has been removed.
More work to obviate warnings generated by T. Kalibera's latest rchk
checks.
Messages from the compiler resulting from attempts to compile C snippets are now suppressed on all platforms except in case of failure.
Setting verbose=TRUE
forces display of these messages.
Source codes have been revisited to obviate warnings generated by T. Kalibera's latest rchk
checks.
Fix a minor bugs in spect
.
Improve test coverage.
spect.match
has been refactored, with small changes to the interface.
pomp
now handles specification of workhorse functions (i.e., rprocess
, dprocess
, rmeasure
, dmeasure
, initializer
, skeleton
, rprior
, dprior
, fromEstimationScale
, toEstimationScale
) as NULL
more consistently.
Fix bug in systematic resampler when np != nw
.
Fix bug in conv.rec
when only one parameter is requested.
Correct and improve documentation for conv.rec
.
coef<-
can now take a list of parameters:
it simply applies unlist
to turn the list into a numeric vector.
Simplify conv.rec
.
In pfilter
, Np
is now a required argument unless params
is specified as a matrix of particles.
Thanks to Carles Breto for catching the unintended behavior.
The bug reported in issue #57 has been fixed.
A bug arising when building pomp objects with Csnippets in certain Windows configurations has been fixed.
Issue #56, in which covariate names are discarded when coercing a pomp object to a data frame, has been fixed. Thanks to Eamon O'Dea for reporting this bug.
More informative error messages are given when bake
or freeze
return NULL
.
In such a case, these functions now generate a warning and return a character-string message, with attributes.
Improve documentation of traj.match
, in response to Issue #57.
A new facility, gillespie.hl.sim
, allows implementation of Gillespie's algorithm for exact stochastic simulation of continuous-time Markov processes via a streamlined C snippet interface.
The old facility for Gillespie simulations, gillespie.sim
, now accepts C snippets for faster calculation of event rates.
The old skeleton.type
and skelmap.delta.t
arguments of the pomp
constructor, which have generated error messages since version 1.9.2, have been done away with completely.
Eamon O'Dea identified a bug (Issue #54) occurring when pomp
is called with a single-row data frame.
This has been fixed using his contributed patch.
A new dmultinom
function is provided in ‘pomp.h’.
This provides the probability distribution function for the multinomial distribution.
Improved tests.
Fixed bugs emerging in R-devel due to refactoring of underlying R source code.
Eamon O'Dea pointed out that the bug in gillespie.sim
, addressed by version 1.12.3, was not completely fixed.
This problem has now been resolved.
In addition, covariates are now guaranteed to be evaluated at least once per observation interval.
The new argument hmax
to gillespie.sim
allows the user to specify the maximum step size that will be taken before covariates are evaluated.
The K-leap method has been removed. Its accuracy is low on test problems and it is difficult to make it compatible with the pomp paradigm. In particular, it does not readily accomodate time-varying covariates in a sensible way, nor does it lend itself to simulations at pre-specified times.
bspline.basis
and periodic.bspline.basis
now take an optional non-negative integer argument deriv
.
When deriv > 0
, the order-deriv
derivative of each basis function is returned.
A new function, periodic_bspline_basis_eval_deriv
, has been added to the C API.
This function gives access, at the C level, to evaluation of the derivatives of periodic B-splines.
Upgrade license to GPL version 3.
Fix buffer-flow problem identified by valgrind
.
Fix bug found by Eamon O'Dea in gillespie.sim
.
Fix bug in onestep.sim
.
The Ricker example has a new parameter, c
, which scales the (unobserved) population size.
By default, c=1
, so that the behavior is as before.
Improved error trapping.
Some changes have been made to the use of random numbers in some codes (the stochastic simulations in gillespie.sim
and the resampling in the particle-filtering codes).
These changes will mean that calculations performed before will not be reproducible in perfect detail, but will be statistically equivalent.
Minor changes in C codes to obviate warnings generated by T. Kalibera's rchk
checks.
The rare and fascinating “Bug of St. Patrick” has been fixed. Thanks to Carles Breto for finding the bug and helping to isolate it.
More informative error messages are generated when dmeasure
returns a non-finite likelihood in any of the particle filtering codes.
Some streamlining of codes.
Callable routines are now registered.
More verbosity is provided with verbose=TRUE
.
The functions bake
, stew
, and freeze
now preserve information about the system time used in computation as an attribute of the returned object.
In addition, these functions store information about the RNG settings.
Some documentation improvements, courtesy of Sebastian Funk.
Documentation improvements.
More verbosity in building of Csnippets.
Better handling of pomp
's times
argument.
New logLik
method for pmcmcList
objects.
The deprecated options to supply a matrix or numeric vector as the data
argument to pomp
have been removed and doing so now generates an error.
The first argument to pomp
, data
, must now be provided either as a data frame or as an object of class pomp
.
See ?pomp
for details.
The deprecated skeleton.type
and skelmap.delta.t
arguments to pomp
have been removed.
Using these arguments will now generate an error message.
The correct method of specifying the deterministic skeleton is now explained in the help pages (?pomp
).
Source code fixes to eliminate warnings during compilation.
Improved test suite.
Minor documentation correction.
During particle filtering, when non-finite dmeasure
values are generated, an error is generated and the offending parameters, states, data, and time are reported.
In methods that use parameter transformations (transform=TRUE
), the reported parameters were on the transformed (estimation) scale, which can be confusing.
The error message now gives the parameters on the natural (model) scale.
Modified ‘src/ssa.c’ to fix UBSAN errors.
C codes have been modified to take advantage of changes to the R API (R SVN REVISION 71180).
A bug in mif2
arising when filtering fails in the final timestep has been fixed.
In this case, when all particles are deemed inconsistent with the data, we use an unweighted mean (with a warning) in place of the default weighted mean.
The stochastic simulation algorithms underlying the Gillespie and K-leap methods (gillespie.sim
, kleap.sim
) have been refactored in C.
In addition, errors due to accumulation of round-off error have been repaired.
The result will be more accurate, but somewhat slower when there are a very large number of reactions.
Further improvements to the test suite. Code coverage is now 100%.
In Sobol' sequence generation (sobolDesign
, profileDesign
), we now use the suggestion of Joe & Kuo (2003) to choose a better sequence start point.
The generation of Sobol' sequences (sobolDesign
, profileDesign
) is now performed using the NLopt routines written in C instead of the original TOMS 659 FORTRAN codes.
The copyright notices are located in the source code.
Improved testing suite.
Made rw.sd
even more robust via new safecall
class.
Refactored rw.sd
for greater stability.
Fixed a bug in plot
on pomp
objects with more than 10 variables to plot.
Added the shlib.args
option to pomp
, allowing arbitrary options to be passed to the compiler when C snippets are used.
Modified the “dacca” example to use C snippets.
Refactored rw.sd
for greater stability.
Made Sobol' codes more robust.
Modified the demos to use best practices.
Improved the test suite.
Improve the test suite and error messages.
Replace the automatic “verbose” setting during compilation under Windows. This was dropped in version <IP_ADDRESS>, when it no longer appeared to be necessary. Apparently, it is, at least under some Windows OS/R combinations.
Fix probe
bug introduced in version <IP_ADDRESS>.
Several obscure bug-fixes.
Improvement of the test suite and of error messages.
Remove the automatic “verbose” setting during compilation under Windows. This was introduced in version 0.63-6 as a workaround. It appears no longer to be necessary.
Improve the show
method for pomp
objects.
Change the print
method for pomp
objects.
Improve messages for plugin errors.
Some internal refactoring.
Improve error messages for missing basic components.
Fix typos in one of the help-page examples.
Add some references.
Major revisions to the package help pages and manual.
The separate documentation on C snippets and process-model plugins has been merged into the main pomp
help page, which now has comprehensive instructions on building a pomp
object.
Update to the package help page.
The matrix and numeric vector options for the data
argument to pomp
are now deprecated and will be removed in a future release.
In calls to pomp
, data
should be either a data frame or a pomp
-class object.
Many more errors are now trapped and reported with more informative messages.
Redundant bootstrap
argument to nlf
has been removed.
More improvements to the testing suite.
Major improvements to error and warning handling.
Fix bugs that might arise in rare circumstances in simulate
and eulermultinom
functions.
More improvements to the testing suite.
Many improvements to the test suite.
Fixed a bug in pompExample
.
Major overhaul of error handling system and error messages.
There is a new plugin for rprocess
called kleap.sim
.
This implements the so-called “K-leap method” of Cai & Xu (2007).
Many improvements to the test suite.
More improvements to the test suite.
Fixed bugs found as a result of improved testing.
In mif2
, it is now required that Nmif>0
.
More improvements to the test suite.
Fixed bugs found as a result of improved testing.
Fixed bug in specification of skeleton in pompExamples.
Improved the test suite to obtain better code coverage.
pomp
is no longer an S4 method.
Its new status as an ordinary function abbreviates and consolidates the code and simplifies the documentation.
Some minor improvements to error messages.
A bug restricting access in C code to userdata
has been fixed.
Fixed bug in pompExample(...,show=TRUE)
.
New methods for the Ensemble Kalman Filter (enkf
) and Ensemble Adjustment Kalman Filter (eakf
) have been added to the package.
A better interface for specifying a model's deterministic skeleton is provided.
One specifies skeleton=map(f,delta.t)
for a discrete-time skeleton (a map) and skeleton=vectorfield(f)
for a continuous-time skeleton (a vectorfield).
The old arguments skeleton.type
and skelmap.delta.t
are deprecated and will be removed in a future release.
The pfilter
help page has been improved.
Specifically, the discussion of filtering failures is better.
Miscellaneous improvements to the help pages.
mif2
no longer computes filter means.
The new argument show
of pompExamples
allows one to display the example code instead of executing it.
The minimum version of R supported is now 3.1.2.
init.state
now has the optional argument nsim
.
Using this, one can request multiple initial state vectors per parameter vector.
pfilter
now uses less memory when it is asked to run at a single point in parameter space.
A bug associated with the rw.sd
argument to mif2
on Windows platforms has been fixed.
The method="mif2"
option to mif
has been removed.
Use mif2
instead.
The particles
method (rarely if ever used), has been removed to streamline the mif
codes.
The method="mif2"
option to mif
is now deprecated.
It will be removed in a future release.
Use mif2
instead.
Following the publication of the Journal of Statistical Software announcement paper, the ‘CITATION’ has been modified to include the appropriate citation.
Please use citation("pomp")
to learn about how to cite pomp correctly.
conv.rec
on the results of a mif2
computation now play nicely with reshape2::melt
.
It is now possible to direct pomp
to place Csnippet
codes in a specified location.
This is accomplished via the new cdir
and cfile
arguments to pomp
.
When several concurrent R processes attempt to simultaneously compile Csnipet
code from copies of a pomp
object on the same machine, a race condition exists.
This release fixes this by ensuring that Csnippet
codes are written and compiled in a process-specific directory.
This release removes several long-deprecated features.
The seed
argument to pfilter
has been removed.
Use freeze
to obtain similar functionality.
The redundant pars
argument to mif
has been removed.
Names of parameters to be estimated are taken from the nonzero entries of rw.sd
.
Initial-value parameters are designated using the ivps
argument.
The old parameter.transform
and parameter.inv.transform
arguments to pomp
have been removed.
They were superseded by the arguments fromEstimationScale
and toEstimationScale
in version 0.65-1.
Some internal changes to mif2
by C. Breto, in support of panel methods under development.
Bug fix: for POMPs with a scalar state variable, the filter.mean
, pred.mean
, and pred.var
methods dropped the singleton dimension of the respective arrays, in conflict with the assumptions of certain plot
methods.
This resolves issue #3.
Documentation improvements.
Specifically, the details of how step-sizes are chosen in the euler.sim
, discrete.time.sim
, and onestep.sim
plugins has been spelled out explicitly.
Also, incompleteness in the sannbox
documentation has been corrected.
Provide filter.traj
method for pmcmcList
objects.
Fixed a bug in mif
and mif2
when cooling.type="hyperbolic"
and cooling.fraction.50=1
.


(8)
Free exploits
(7)
How to fly
(8)
Something
(2)
Nvm i fixed it
(2)
Called it
(2)
RLua Puzzle
(5)
Buyer Rank Gone?
(3)


Write keywords (comma separated)
Removes unwanted posts from your Facebook News Feed
Save
Posts hidden:
...


We are so excited and thankful for your ordering with us!
__PRODUCT__
Ship to: __ADDRESS__
Click here to track your order: https://www.slaterobots.com/order/__ID__?token=__TOKEN__
Reply to this email if you have any questions. You will get another email when your order has shipped.
Thank you!
Zach Allen
CEO, Slate Robotics


{% extends "reviews/reviewable_base.html" %} {% load djblets_extensions rb_extensions i18n %} {% ext_css_bundle extension "commits" %} {% block title %}{{review_request.summary}} | {% trans "Review Request" %}{% endblock %} {% block content %}
Something's gone wrong in either retrieving or manipulating these review requests. Sorry about that. Please consider filing a bug, and including the following information:
Close


KiSSFLOW is a workflow tool & business process workflow management software to automate your workflow process.
A workflow consists of an orchestrated and repeatable pattern of business activity ,a sequence of operations, declared as work of a person or group an organization of staff, or one or more simple or complex mechanisms
Roles and Responsibilities
Design and maintain workflow engine algorithm which takes certain inputs and decides set of business actions.
Develop and maintain rule-engine which supports Excel formula which can be used by end-users to create custom formula and also by workflow system.
Integrate Recurring billing services with the system.
ReduceData is a Saas based RTB platform.Real-time bidding (RTB) is platform by which advertising inventory is bought and sold on a per-impression basis, via programmatic instantaneous auction .
With real-time bidding, advertising buyers bid on an impression and, if the bid is won, the buyer’s ad is instantly displayed on the publisher’s site.
Roles and Responsibilities
Analyze, Brainstorme, Re Design and research on different technologies to improvise the performance of the system to achieve High Performance, Scalability, High Availability, Low Latency with lesser cost.
Build High responsive pages and responsible for implementing visual elements that users see and interact with in a web application
write algorithms that efficiently analyzes the request from SSP and filter the creatives based on the filter criteria and bid creative space for an optimal price.


Username is required
Username must be at least 3 characters
Name is required
Name must be at least 3 characters
Email is required
Email must be a valid email address
Phone is required
Phone must be at least 10 characters
Password is required
Password must be at least 3 numbers
Confirm password is required
Confirm password must be at least 3 numbers
Not matched


It is important to make a diagnosis immediately. If it’s an infection, it can instantly spread to your brain if not treated right away. This can occur in either adults or children, and vision can be lost quickly and permanently. Go to an emergency room immediately for evaluation and treatment. Ideally have someone drive you there.
You might not notice this problem unless you check each eye separately. Your eyes work together to give you your best vision, so if one eye has a problem, the other eye may compensate for it, hiding this important warning signal.
Cover one eye and look directly at something with straight edges, like a desk or window. Then switch—cover the other eye and look at the same object. You can also do this by looking at a page of letters in a book. Look for straight lines that appear wavy, distorted, and/or broken. Look for a spot in the center of your vision that is fuzzy or darkened.
These may be warning signs of macular degeneration, a common problem in people over age fifty. Macular degeneration causes a loss of central vision. It does not immediately lead to complete blindness but can prevent you from driving, reading, recognizing faces, and performing daily tasks.
If you notice any of these changes, get a dilated eye examination from an ophthalmologist (eye doctor) as soon as you can. The doctor may be able to treat this problem and prevent further vision loss. Early treatment is necessary.
Seeing spots can be caused by a variety of medical problems. Some spots are normal, like seeing blood vessels when you are staring up at a blue sky or seeing spots for just a second when you stand up quickly. Some are essentially meaningless, like a floater that drifts across your vision and moves away when you try to focus on it. However, some are important and may precede a serious event such as blindness.
One such condition is an outpouching of the blood vessels of the retina (the back part of the eye where vision is recorded and transmitted to the brain), called retinal microaneurysm. In a more advanced eye disease, for example, one caused by diabetes, new abnormal blood vessels grow and are at risk of rupturing. If these vessels rupture, blood can flow inside the eye, causing the sudden and severe loss of vision.
So, if you notice the onset of many spots in your field of vision, contact an ophthalmologist immediately. Since these symptoms may be associated with diabetes, diabetics should have their eyes checked every year to find and treat any abnormal growths of the blood vessels and prevent the complications that cause these symptoms.
Most of us experience floaters from time to time and some people have more than others. They are caused when the clear jelly inside the eyeball shrinks with age. This jelly, called the vitreous, can tug on the retina of the eye, releasing a few cells or strings of cells. These are the spots and threads we see when we look at a white wall or a blue sky. The tugging can also cause little electrical currents to flash.
But if you see a change in floaters or any flashes of light, it might be a sign of retinal detachment, which could cause sudden, permanent vision loss or blindness. If you see your eye doctor (an ophthalmologist) immediately, you may be able to save your vision. Don’t delay. If you can’t reach an eye doctor, go to the emergency room.


The country is regarded as safe, but note that there have been a few incidences of piracy in the Gulf of Guinea.
São Tomé and Principe has a tropical climate. The wet season runs from October to May with June to September being drier. The temperature does not vary greatly with average high around 30°C and average low around 22°C.
For links to free global weather information, forecast services and extreme weather information see the Noonsite Weather Page.
* indicates port of entry


Doris,2016.6.15,chapter 9 #Doris
chapter 9
note
tuple
is an example of a data structure — a mechanism for grouping and organizing data to make it easier to use.
a=(a,b,c,d)
a[0]---a
a[1]---b
a[2]---c
slice:a[:1]---a,b
>>> tup = (5,)
>>> type(tup)
<class 'tuple'>
>>> x = (5)
>>> type(x)
<class 'int'>
packing & no packing
a=(a,b,c)packing
each of those in turn can be another tuple, a list, a string, or any other kind of Python value. This property is known as being heterogeneous, meaning that it can be composed of elements of different types.
exercise
1.
def tuple_can_be_arguement(n):
return n
print(tuple_can_be_arguement(('a','b')))
2.
tuple a generalization of a pair
3.
pair is a kind of tuple


Reports the methods identical to their super methods. Such methods have the same signatures
as their super methods and either have duplicated bodies or only include the super method's call in their bodies.
These methods are redundant and can be removed.
Use the checkbox below to run the inspection for the methods that override library methods.
Checking library methods may slow down the inspection.


|
THE
INTRODUCTORY RITES |
|
In the name of the Father, and of the Son, and of the Holy Spirit. |
|
Amen. |
|
A. The grace of our Lord Jesus Christ, and the love of God, and the communion of the Holy Spirit be with you all. |
|
Or |
|
B. Grace to you and peace from God our Father and the Lord Jesus Christ. |
|
Or: |
|
C. The Lord be with you. |
|
The people reply: |
|
And with your spirit. |
|
In this first
greeting a Bishop, instead of The lord be with you, says: |
|
C.
Peace be with you. |
|
Penitential Act |
|
Brethren (brothers and sisters), let us acknowledge our sins, and so prepare ourselves to celebrate the sacred mysteries. |
|
A brief pause for silence follows. Then all recite together the formula of general confession: |
|
I confess to almighty God and to you, my brothers and
sisters, that I have greatly sinned, in my thoughts and in my words, in what
I have done and in what I have failed to do, |
|
And, striking
their breast, they say: |
|
through my fault, through
my fault, through my most grievous fault; |
|
Then they
continue: |
|
therefore I ask blessed
Mary ever-Virgin, all the Angels and Saints, and you, my brothers and
sisters, to pray for me to the Lord our God. |
|
The absolution by the Priest follows: |
|
May almighty God have mercy on us, forgive us our sins, and bring us to everlasting life. |
|
The people reply: |
|
Amen. |
|
Or: |
|
The Priest invites
the faithful to make the penitential Act: |
|
Brethren (brothers and
sisters), let us acknowledge our sins, and so
prepare ourselves to celebrate the sacred mysteries. |
|
A brief pause for
silence follows. The Priest then says: |
|
Have mercy on us, O Lord. |
|
The people reply: |
|
For we have sinned against
you. |
|
The Priest: |
|
Show us, O Lord, your
mercy. |
|
The people: |
|
And grant us your
salvation. |
|
The absolution by
the Priest follows: |
|
May almighty God have mercy
on us, forgive us our sins, and bring us to everlasting life. |
|
The people reply: |
|
Amen. |
|
Or: |
|
The Priest invites
the faithful to make the penitential Act: |
|
Brethren (brothers and
sisters), let us acknowledge our sins, and so
prepare ourselves to celebrate the sacred mysteries. |
|
A brief pause for
silence follows. The Priest, or a deacon or another minister, then says the
following or other invocations with Kyrie, eleison (Lord, have mercy): |
|
You were sent to heal the
contrite of heart: Lord, have mercy. Or Kyrie, eleison. |
|
The people reply: |
|
Lord, have mercy. Or:
Kyrie, eleison. |
|
The Priest: |
|
You came to call sinners:
Lord, have mercy. Or Kyrie, eleison. |
|
The people: |
|
Lord, have mercy. Or:
Kyrie, eleison. |
|
The Priest: |
|
You are seated at the right
hand of the Father to intercede for us: Lord, have mercy. Or
Kyrie, eleison. |
|
The people: |
|
Lord, have mercy. Or:
Kyrie, eleison. |
|
The absolution by the
Priest follows: |
|
May almighty God have mercy
on us, forgive us our sins, and bring us to everlasting life. |
|
The people reply: |
|
Amen. |
|
Kyrie |
|
Priest: Lord, have
mercy. People: Lord, have mercy. Priest: Christ, have mercy. People: Christ, have mercy. Priest: Lord, have mercy. People: Lord, have mercy. |
|
Then, when it is prescribed, this hymn is either sung or said: |
|
Glory to God in the highest, and on earth peace to
people of good will.  Lord Jesus Christ, Only
Begotten Son, Lord God, Lamb of God, Son of the Father, you take away the
sins of the world, have mercy on us; you take away the sins of the world,
receive our prayer; you are seated at the right hand of the Father, have
mercy on us.  Amen. |
|
Opening Prayer Proper |
|
Let us pray. |
|
And all pray in silence with the Priest for a while. |
|
Then the Priest, with hands extended, says the Collect prayer, at the end of which the people acclaim: |
|
Amen. |
|
THE LITURGY OF THE WORD |
|
Then the reader goes to the ambo and reads the first reading, while all sit and listen. To indicate the end of the reading, the reader acclaims: |
|
The Word of the Lord. |
|
All reply: |
|
Thanks be to God. |
|
The psalmist or cantor sings or says the Psalm, with the people making the respond. |
|
After this, if there is to be a second reading, a reader reads it from the ambo, as above. To indicate the end of the reading, the reader acclaims: |
|
The Word of the Lord. |
|
All reply: |
|
Thanks be to God. |
|
There follows the
Alleluia or another chant laid down by the rubrics, as the liturgical time
requires. The Deacon or the Priest proceeds to the ambo, accompanied, if appropriate, by ministers with incense and candles. There he says: |
|
The Lord be with you. |
|
The people reply: |
|
And with your spirit. |
|
The Deacon, or the Priest: |
|
A reading from the holy Gospel according to N. |
|
And, at the same
time, he makes the Sign of the Cross on the book and on his forehead, lips,
and breast. The people acclaim: |
|
Glory to you, O Lord. |
|
Then, the Deacon, or the Priest, incenses the book, if incense is used, and proclaims the Gospel. |
|
At the end of the gospel, the Deacon, or the Priest, acclaims: |
|
The Gospel of the Lord. |
|
All reply: |
|
Praise to you, Lord Jesus Christ. |
|
Then he kisses the book, saying quietly: |
|
Through the words of the Gospel may our sins be wiped away. |
|
Homily |
|
Then follows the homily, which is to be preached by a Priest or Deacon on all Sundays and holy days of obligation; on other days, it is recommended. |
|
Creed |
|
At the end of the homily, the Symbol or Profession of Faith or Creed, when prescribed, is either sung or said: |
|
I believe in one God, the Father almighty, maker of heaven and earth, of all things visible and invisible. I believe in one Lord Jesus Christ, the only Begotten Son of God, born of the Father before all ages. God from God, Light from Light, true God from true God, begotten, not made, consubstantial with the Father; through him all things were made. For us men and for our salvation he came down from heaven, |
|
At the words that follow, up to and including and became man, all bow. |
|
and by the Holy Spirit was incarnate of the Virgin Mary, and became man. For our sake he was crucified under Pontius Pilate, he suffered death and was buried, and rose again on the third day in accordance with the Scriptures. He ascended into heaven and is seated at the right hand of the Father. He will come again in glory to judge the living and the dead and his kingdom will have no end. I believe in the Holy Spirit, the Lord, the giver of life, who proceeds from the Father and the Son, who with the Father and the Son he is adored and glorified, who has spoken through the prophets. I believe in one, holy, catholic and apostolic Church. I confess one baptism for the forgiveness of sins and I look forward to the resurrection of the dead and the life of the world to come. Amen. |
|
Instead of the Niceno-Constantinopolitan Creed, especially
during Lent and Easter time, the baptismal Symbol of the Roman Church, known
as the Apostlesí Creed, may be used. |
|
I believe in God, the Father almighty, Creator of heaven and earth,
and in Jesus Christ, his only Son, our Lord, |
|
At the words that follow, up to and including the Virgin Mary, all bow. |
|
Who was conceived by the Holy Spirit, borne of the Virgin Mary,
suffered under Pontius Pilate, was crucified, died and was buried; he
descended into hell; on the third day he rose again from the dead; he
ascended into heaven, and is seated at the right hand of God the Father
almighty; from there he will come to judge the living and the dead. I believe
in the Holy Spirit, the holy catholic Church, the communion of saints, the
forgiveness of sins, the resurrection of the body, and life everlasting.
Amen. |
|
Then follow the Universal Prayer, that is, the Prayer of the Faithful or Bidding Prayers. |
|
The
Liturgy of the Eucharist |


Research and analysis
Ofsted good practice example showing how childminder Nicola Phillips improves children’s communication and language development.
MS Word Document , 476KB
PDF , 160KB , 4 pages
This good practice example shows how childminder Nicola Phillips improves children’s communication and language development. She teaches children through play-based activities that are rooted in their interests and learning needs. She makes sure that children’s experiences provide a healthy mix of education and fun.
Her teaching is based on solid assessment of what each child can do so that learning opportunities are wholly suited to each child. As a result, children do exceptionally well in her care.
This is part of a set of 8 Ofsted good practice examples showcasing good practice in early years to support the report: ‘Teaching and play in the early years – a balancing act?’ .
Published: 13 July 2015


{% extends 'main/base.html' %} {% block title %} The Good Life Meal Prep Subscribers | Weekly Menu {% endblock %} {% block content %} {% if current_user.remaining_meals <= 0 %}
Uh oh! It looks like you've run out of meals on your subscription plan. We hope you enjoyed our service and if you would like to add more meals to your plan, please click the link below.
We are sorry, but the ordering for this week's menu ended at 11:59 pm on Thursday. Please stop by next week to place your orders!
Here are our delicious meals for the week. There's no need to click a button to submit your order; simply update your order as many times as you would like before the ordering window closes at 11:59 pm on Thursday.
{{ meal.item }}
{{ meal.item.description }}
{{ meal.item.proteins }}C/{{ meal.item.carbs }}P/{{ meal.item.fats }}F {{ meal.item.calories }}CAL


Home
Resume
Contact
Gallery
About
Thank you for visiting! Website is currently under construction...


Hello, we give this html code, to see how it can be display easily with html.
To see the source code, just open this file : example.html with Notepad or other editor.


A card is a sheet of material that serves as an entry point to more detailed information.
Cards may contain a photo, text, and a link about a single subject. They may display content containing elements of varying size, such as photos with captions of variable length.
In the next example we will show you how to create a card.


Greetings from the beautiful land of Zimbabwe. I am Joseph Made of Lands, Agriculture, & Rural Resettlement ministry of Zimbabwe. As a member of cabinet and former stuanch supporter of President Mugabe's government I was opportuned to be in the know as to what led to the struggle for farm lands and subsequent fall out of my government with the Western world. As of today I would be more than glad if the case of what happened can be reversed as I have come to see that it was all in pursuit of the selfish interest of one man, the president! After all said and done, it has become obvious that my president like any other African leaders needed to make sure that he remains in power to not just consolidate his fortunes but also to make sure that he bleeds the country to death by siphoning the money meant for developmental infrastrure abroad. Of course with the help of some foreigners who do not see anythng wrong in helping him steal the country blind. I may very well be sounding like a disgruntled and dis-appointed person but the truth is that he has shifted his gaze from the foreigners to his own very people. He sees any suggestions or opinions that does not agree with his own has been that of a sabortuer and the person therefore must be purnished. In other words, we the followers have come to realise that he feels threatened by not just our presence but coupled with the fact that most of us are privy to what transpired and are very much aware of the movement of large sums of money abroad. As it stands now I and many others are of the strong opinion that sooner or later it will be our turn to be flushed out of the composition of members of cabinet and replaced with loyals who obviously have sworn to an oath of allegiance and loyalty via fetish and ritualistic methods. This being the norm does not appeal to some of us and therefore we are now targets to be dismissed/disgraced from service or face possible extermination. I have contacted you on the consideration that I could discuss with you the possibility of placing some funds with you for management purpose either in your existing establishment or other venture to be undertaken after due delibrations and under terms to be agreed upon. I will prefers that this investment be made in your country if and when we have arrived at a compromise. I sincerely appologise for writing you via this means even without prior established acquaintance. But I do beleive that as we get along you will come to understand the reason for my writing through this means. I thank you for taking time to read my letter and hope that you will respond soon with any inquiries that may help you decide on your next line of action. Regards, JM. My Secured Email Address:joseph_m333@latinmail.com


[gecode-users] Bug in TupleSet?
Michal D.
michal.dobrogost at gmail.com
Tue Dec 16 06:17:22 CET 2008
>
> There seems to be a bug in TupleSet. If you add a particular tuple
> more than twice, the next call to extensional will segfault. Eg:
>
> TupleSet tuples;
>
> int n = 3; // works if n <= 2
>
> for (int i = 0; i < n; i++) {
> IntArgs pair(2);
> pair[0] = 0;
> pair[1] = 1;
>
> tuples.add(pair);
> }
>
> TestSpace* space = new TestSpace();
>
> IntVarArray x(space, 2, 0, 1);
> space->add(x);
>
> extensional(space, x, tuples); // segfault if n >= 3
>
> (where TestSpace is a simple Space implementation)
>
> GDB shows:
>
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
> 0x0057f857 in (anonymous namespace)::FullTupleCompare::operator() ()
> at gecode/int/extensional/tuple-set.cc:55
> 55 if (a[i] < b[i]) {
>
> Malcolm
>
I just noticed this message, and it's the exact same problem I was having
(see http://article.gmane.org/gmane.comp.lib.gecode.user/2053). Just for
reference: extensional() calls tupleSet::finalize() which calls quicksort()
on the tuples and eventually produces this seg fault. I confirmed that with
duplicates removed quicksort() terminates using the "<=" comparison and a
stack depth of 32 for my data. However, this does not clear the use of "<="
comparisons in quicksort (see the other thread).
Sorry for spamming everyone with all these posts but hopefully we're making
progress. I do have two actual questions:
1) Is a tupleSet shared if it is used as part of multiple extensional()
constraints?
2) Do the unneeded tuples in a given extensional() constraint get discarded at
some point? Ie. is it ok to have extra values that will be dropped on the first
propagation or will they stay on as runtime overhead forever?
Thanks,
Michal
More information about the gecode-users
mailing list


Having spent a lot of my weekend playing it (after representing Teloga at the 26th Annual Auburn Alumni Band Reunion), I wanted to make a quick, mostly spoiler-free post about 999: 9 Hours, 9 Persons, 9 Doors (2010). It’s a visual novel / room escape / puzzle / adventure game for the Nintendo DS.
Marked-down Resume
A project that had been almost as long overdue as reviving http://www.stevenclontz.com was updating my neglected resume.
The tl;dr version: check it out at http://resume.stevenclontz.com! But if you think that looks nice and would like to check out the web app that powers it, please read on. :-)
Auburn Puzzle Party 5
In case you hadn’t heard me talk about it yet, here’s my wrap-up of Auburn Puzzle Party 5 on the Auburn Puzzle Party wiki.
And if you haven’t checked out the APP5 videos, including the Puzzle Rock Anthem yet, you’re missing out. See if you can solve the “hidden” puzzle in the videos too.
-SXC
New Blog Powered by Octopress
Hey everyone! Thanks for checking out my new blog*. After deciding I didn’t need to waste so much cash on domain names I don’t use and web space I barely needed, I took down stevenclontz.com along with most of my other old PHP/Wordpress sites. I’ll get stevenclontz.com to point here sometime soon.
Thanks to James Dabbs for showing Octopress to me the other day - a blogging system with Git revision control and hosting by Heroku sounds alright to me.
I’ll be working on my About page and getting my Resume up to date over the coming days. Email me at<EMAIL_ADDRESS>if you need to get in touch with me! See ya.
-SXC
*Is this sentence obligatory for a first blog post? I almost always see it, and it sounded awkward not to include it. Thanks again I guess. :-)
Hello World
I am learning about Octopress here. Hiya everyone.


In this chapter you may find some interesting examples of how to use the logging writers. These examples are split into different sections according to their use cases. Below find the list of every single section. Please note, chapter Empty Examples includes an overview of how to generally use this logging writer.
The installation of every of these logging writers is explained in chapter Installation.


--- layout: default layout_keyword: knowledge_base_page title: Change your password tags: basic_user_pages left_col_section_nav: [basic_user_nav] user_help_videos: [basic_user_videos] ---
When your account is created, you either chose a password or a password was generated for you. If you need to change this password, you can do so from the Change Password page.
Click the AllPlayers.com logo or Home button at the top of any page to go to your home page.
Click Account in your side navigation menu, then click Change Password in the submenu.
Enter your new password in the Change Password and Confirm Password box.
Click Change Password to save your changes.


Because of your smile, you make life more beautiful
Thick Nhat HanhMaking mistakes is better than faking perfection
9 mins5040
It is better to end something and start another than to imprison yourself in hoping for the impossible
10 mins
We live in the world when we love it.
29 mins
You never have to chase what wants to stay.
9 mins
We are afraid of not knowing what comes next, and so we make our lives predictable. Don't be afraid of what comes next. You'll be okay.
9 mins
Soon, when all is well you're going to look back on this period of your life, and be glad that you didn't give up.
9 mins
Things never happen the same way twice.
9 mins
Sometimes it's easier to say you don't care than to explain all the reasons why you do.
9 mins
We must be willing to let go of the life we have planned, so as to have the life that is waiting for us.
9 mins
Old minds are like old horses; you must exercise tham if you wish to keep them in working order.
9 mins
Fear is the foundation of most governments
9 mins
Change your life today. Don't gamble on the future, act now, without delay.
9 mins
Most people have the will to win, few have the will to prepare to win.
9 mins
Oaths are but words and words are but wind.
9 mins
You will never find the time for anything. If you want time, you must make it.
9 mins
Be true to your work, your word, and your friend.
9 mins
It's hard to be humble, when you're as great as I am.
9 mins
There is a role and function for beauty in our time.
9 mins
It's ok to show all your colors.
9 mins
To love for the sake of being loved is human, but to love for the sake of loving is angelic.
9 mins
One is loved because one is loved. No reason is needed for loving.
9 mins
The true art of memory is the art of attention.
9 mins
Everything has its wonders, even darknes and silence. I learn, whatever state I may be in, therein to be content.
9 mins
Bachelors know more about women than married men; if they didn't they'd be married too.
9 mins
If 'pro' is the opposite of 'con' what is the opposite of 'progr
9 mins
Infuse your life with action. Don't wait for it to happen. Make it happen. Make your own future. Make your own hope.
9 mins
Never regret yesterday. Life is in you today and you make your tomorrow.
9 mins
I have learned that friendship isn't about who you've known the longest.  It's a symbol of friendship and peace.
9 mins
a friend is someone who gives you tatal freedom to be yourself.
9 mins


 I hate pretty people. is on Facebook. To connect with I hate pretty people., sign up for Facebook today. Sign UpLog In · Like · Create a Page · Privacy .
http://www.facebook.com/pages/I-hate-pretty-people/241151296144
Why I Hate Beauty | Psychology Today
Jul 1, 2001 . But I hate beauty. I live in what is . You might expect that to make me feel good, as we normally like being around attractive people. But my .
http://www.psychologytoday.com/articles/200107/why-i-hate-beauty
so many pretty people | Tumblr
There are so many attractive people and then theres me. image .  Merrr there's this really pretty androgynous girl sitting across from me in the quad.
http://www.tumblr.com/tagged/fucking%20pretty%20people
pretty people make me sad | Tumblr
do you ever get angry when a really pretty person doesn't know they're really pretty . I hate being around attractive people, wondering if they think I'm attractive.
http://www.tumblr.com/tagged/pretty%20people%20make%20me%20sad
Samantha Brick on the downsides to looking pretty: 'Why women ...
Apr 5, 2012 . 'There are downsides to looking this pretty': Why women hate me for being . ' Many of my clients are models, yet people are always astounded .
http://www.dailymail.co.uk/femail/article-2124246/Samantha-Brick-downsides-looking-pretty-Why-women-hate-beautiful.html


Unit II
home
Back
Syllabus
Reference models: OSI model and TCP/IP reference model. Physical layer: Transmission media-twisted pair, coaxial cable, optical fibre. Wireless transmission-radio, microwave, infrared and millimeter waves, telephone systems, cell phones.
Footer Text


Lancaster County Solid Waste Management Authority
Lancaster, Pennsylvania
Jack D. Lausch, Sr. Transfer Station
One of the Authority's oldest facilities is the Jack D. Lausch, Sr. Transfer Station, located just beyond the city limits of Lancaster at 1291 Harrisburg Pike.
Built in 1968, expanded in 1978 and 1984, and completely renovated in 1990, the transfer station serves as a central drop-off point for trash haulers who collect refuse within the 946 square miles which make up Lancaster County.
At the transfer station, waste is compacted into Authority transfer trailers and trucked to either the Frey Farm Landfill or the Resource Recovery Facility.
Every day, more than 200 commercial haulers and residents pass over the transfer station's electronic scales which record, via computer, the amount of waste contained in each vehicle. Trash is deposited in one of four bays, where the waste is compacted into Authority transfer trailers. Each day, these transfer trailers haul approximately 800 tons of waste to either the resource recovery facility, the Frey Farm Landfill or a recycling center.
In addition to being centrally located within the county, the transfer station also provides Authority compliance officers the opportunity to inspect each load of waste to make sure the materials are acceptable and to dispatch that waste to the appropriate disposal site. Combustible materials go to the resource recovery facility while noncombustible items are directed to the Frey Farm Landfill.
The Authority sends recyclables to various recycling markets, while the on-site Household Hazardous Waste Facility collects hazardous wastes generated in area homes.
The Authority also requires separate delivery of materials which may be better disposed through methods other than resource recovery or landfilling. For example, all tires and white goods (household appliances) must be delivered separately from other refuse. Tires are sent to a recycling facility and white goods, after chlorofluoro- carbon gas removal, are taken to recycling centers.
The transfer station includes a maintenance facility, where mechanics perform most repair work and state inspections on Authority vehicles and equipment. The maintenance facility also houses a tire changing room, welding shop, wash bay, paint bay and offices.
For the convenience of the employees who work at the transfer station, the complex includes a lunchroom and locker rooms.
For more information or if you have questions, please contact the Authority office in Lancaster County at<PHONE_NUMBER>.


Brief
This is a program where a worker at a pizza company may enter orders received over the phone into a computer system. This system will store a customer's name, address, and order information, and use this to calculate a price total and print a receipt.
Below is the initial project backlog:
Sprint One
Aim
This is the first sprint of the program - this aims to add a simple pizza menu, and have the start of a main function that welcomes the user and prints that menu.
Planning
Test
This shows a successful test, where items off the menu are printed alongside their prices.
Reflection
This version has a simple menu that I can work with during the early stages of this project, as well as the beginning to the main loop that will allow the program to run; these elements all work as expected, which can be seen by the screenshot of the outcomes in the testing. Next steps will be to allow the program operator to enter their choice of the pizza, which must be stored by the program.
Sprint Two
Aim
In this sprint I am implementing the start of the "order" function. The menu will be printed, and the user is asked to enter the pizza they would like, along with a quantity and order comments. An order_list will also be created, which the information the user enters will be added to.
Planning
Test
This shows the code working as planned: the menu prints, the user is able to interact with the system and ask for what they want, and the order information printed at the end shows that that information is successfully stored by the program.
Reflection
The program now takes a user's order and stores it in the system, and is able to recall it later
when asking for the user's confirmation. As I was writing the code in this sprint, it occurred to me
that I hadn't actually planned to include an option where the operator could edit the order after
initially entering it. This would mean the program is very inflexible and the operator would have to
start again from scratch if he made a mistake. Therefore, I have updated the project backlog and
plan to create another function that allows the user to edit the order. I probably won't implement
this in the next sprint, but will instead wait until the receipt and delivery/pickup functions
have been added.
In the next version, I want to add a function where where the operator asks whether the customer
wants their food delivered to their home address or not, then asks for and processes the relevant
personal information (e.g. name, address, phone number, delivery charge).
There are a few problems with this version - the formatting on the printed lists is not as clean
as it could be, and of course it still can't cope with any kind of unexpected input. I plan to
address all of these minor issues when I have finished writing the main code.
Sprint Three
Aim
This sprint aims to add a "get_customer_info" function that will find out if the order is for pickup or delivery, and ask for customer information based on that (name, address, etc.) and adds a delivery charge if appropriate.
Planning
Tests
These tests show the get_customer_info function working correctly, with different information being requested based on whether they want their order delivered or picked up.
Reflection
The program now allows the user to tell it whether they would like their order to be
delivered, or if the customer will pick it up from the pizza store themselves. The program then
takes the customer's personal information based on this, and adds a $3 delivery charge where
appropriate.
As we can see from the testing, currently the code runs in a linear fashion - calling one function
after the other and not giving the user the option of going back to change something or choose which
information they want to enter first. In the next sprint I want to restructure the code so that the
program is based around a "menu" of options from which the user can decide what to do with their
order. I believe
this will allow for greater flexibility within the program, so the user has more control. It will also
make it easier to edit user orders, a function which I plan to implement in my next sprint.
Sprint Four
Aim
This sprint aims to restructure the program by making all of the code run from a central options
menu which the user interacts with. This makes the program more predictable for the user, and it is
easy for them to "retrace their steps" if they would like to change anything about their order.
It will also add functions for validating user input (integers and strings), which will
prevent the program from crashing so easily by making the program feed back to the user if they
make mistakes like exceeding the character length or entering the wrong type of character.
Finally, it will allow the user to view their receipt and edit what they have ordered.
Planning
Planned menu attributes
Reflection
In this sprint, I completely restructured my code so that it was centred around a central menu,
from which the user can make requests. This means that the program is more predictable and easier
for a first-time user to navigate. I also added in several new functions, including two
functions for validating user input to prevent crashes, and greatly altered the function for
getting the customer information, so that it detects when the user already has information stored
and allows them to edit it more efficiently. I have split the get_customer_info function into
four separate functions (get_delivery_info, get_pickup_info, and get_address) to make this part of
the process as efficient as possible.
However, the original goal of this sprint has not been completed. I came across problems with the
print_menu functionality early on, which was a major component of my plans for the edit_order
function. I then realised that I was too ambitious with early planning for this sprint and decided
to change my focus to troubleshooting, fixing bugs, implementing simple validation functions, and
updating the edit_customer_info function so that it had a more flexible design, elements of which
I plan to reuse in the edit_order function.
In this program the user is still unable to delete things from the order or view their receipt.
The delay in implementing these functions is due to the problems with the print_menu functions,
which are currently not working. In the next sprint, I will fix this, which should allow me to
implement the previously-planned edit_order function I had intended to add in this sprint.
Once sprint five has been completed, I will be able to start fixing any final bugs and getting the
program ready for completion.
Testing
This screenshot shows the new structure of the program in action - a main menu is printed from which the user can access all of the program's capabilities. When a function finishes, they return to the main menu.
In this screenshot we see the get_integer and get_controlled_string validation functions working. When the user tries to enter a non-integer, or something that is below or above the character limit, they are notified and are asked to enter their information again.
This test shows the unplanned update to the get_customer_info function that was implemented in this sprint to take advantage of the new validation functions. If the user has already entered information into the system, the system now recognises that and allows for the realistic possibility that the user has only made one or two mistakes in their address, so they now do not have to re-type every detail of their address. This makes interactions with the program less frustrating for the user.
Sprint Five
Aim
In this sprint, I want to have a working print_receipt function. This means that I will need to fix the broken print_menu and print_menu_indices functions, which are currently returning errors when called in several situations and early tests of the print_receipt function. Once this is done I will use this code to implement a very simple confirm_order function.
Planning
Errors
At the start of this sprint, I planned to write a very simple, short print_receipt function using of the existing print_menu function. The print_receipt function could then be included in a more complex confirm_order function, which was the main goal of the sprint. However, the print_menu function I had planned on using returned a somewhat mangled output (as seen below) when used with my lists. Eventually, I decided the best way to collect delivery/pickup information would be using a dictionary, and modified the program accordingly. Switching the format of one list to a dictionary also meant that I had to create another function for printing dictionaries, as well as restoring the original print_menu function.
Tests
After the print_menu and print_dict functions had been created, I was able to implement the print_receipt and confirm_orders more or less as planned; we see them working in the test screenshots above. However, we can also see that my changes have created a new bug in the code.
Reflection
This sprint was successful as far as fulfilling my goals was concerned. I now have working functions
for printing both dictionaries and multi-dimensional lists, and working print_receipt and
confirm_order functions. The extensive testing process after this version also allowed me to identify
several bugs both minor and major, such as the way the user's address was being recorded - many of
the minor bugs have now been fixed.
There are three remaining major flaws in the code. After the changes made in this sprint, it appears
that the total_cost variable does not update according to the information from the add_to_order
loop - something that had worked in previous versions (the error discovered in this version's testing is
pictured above. I am unclear how this happened; however, I will
not be fixing it in this sprint, as I plan on dealing with the cost calculation in a new way altogether
going forward, so it would be a wasted effort.
On top of this, there is a possible exploit where a user could get $3 off their order total by entering
the "edit customer details" menu, and changing their order to "pickup" an unlimited amount of times.
While this could be prevented, it would require writing repetitive code, whereas I believe a better
solution would again be calculating costs through a separate "calculator" function, so that the
total is not constantly passed through arguments and altered by 3-4 different functions. This will
make it much easier to edit code pertaining to it in the future. This will be addressed in the next
sprint.
The other issue is shown in the second test image - if a user orders the same kind of pizza
twice, it will not print as, for example, "2 cheese pizzas" but as two sets of "1 cheese pizza".
This will create an inconvenience for the user when I implement the planned "edit_order" function -
therefore, this will have to be fixed in the next sprint, before the edit_order function is added.
Sprint Six
Aim
In this sprint, I am aiming to implement a "cost calculation" function, which will change the way the program calculates the user's total for the order. This will prevent the problems that have been caused by changes to the delivery method (which requires the $3 delivery charge to be added or removed). I am also planning a "quantity calculator" function, so that the receipt prints all pizzas ordered of a certain kind together (e.g. 2x Hawaiian instead of printing 1x Hawaiian twice.) These functions are necessary for the smooth implementation of the planned edit_order function.
Planning
Test
This test shows the cost-calculating function working correctly, and appears to show the quantity-adder function working as well.
Reflection
The cost calculation and "quantity_adder" function have both now been successfully implemented, and the goals of this sprint have been completed. I had to trial several different methods, particularly in order to make my calculator function work. Eventually, I decided to create a "costs" list that would be updated from inside the add_to_order function - this would contain the prices of all items ordered from the menu (by adding the result of quantity ordered * unit cost to the cost list). However, when the "total" needs to be calculated, the program will call the cost_calculator function which determines if the $3 delivery fee is applicable and adds it to the total. The total only needs to be calculated at three points in the code, so this solution - of having the total individually calculated at each of these points - is more efficient than writing repetitive code to prevent exploits such as those explained in the Sprint 5 reflection. The quantity_adder function also appears to be working in the tests, which means that both the major flaws that could have caused problems with the edit_order function (as well as decreased the strength of the program in general) have been fixed. Therefore, in Sprint Seven I will be able to implement the final planned menu function, edit_order, where the user can remove items from their pizza order.
Sprint Seven
Aim
In this sprint, I want to add an edit_order function that will allow the user to delete items from their pizza order.
Planning
Tests
Reflection
The screenshotted tests above show the edit_order function working successfully. The user can choose
which menu item they want to remove and how many of that item they will be removing. Once all the
units of a certain pizza have been removed that pizza is removed from the order list entirely
(shown in the first test photo with Hawaiian pizza) instead of remaining visible with a quantity of 0.
These steps have been taken in order to avoid annoyance or confusion for the user and increase the
program's usability.
As can be seen from the project backlog below, all of this program's
original goals have been achieved at the end of this sprint. Therefore the final testing process
can now begin.
Program goals
Sprint Eight
Aim
After the conclusion of Sprint Seven, I thought that my program was finished - however, during final testing an outside user discovered that my quantity_adder function didn't actually work at all, and only appeared to because my testing wasn't comprehensive enough (I tested it by ordering multiple cheese pizzas, "cheese" being the first item on the menu. However, the code produces the below output if you attempt to order multiple of any item on the menu, other than the first one.). This clearly needs to be fixed, and I plan to have a working alternative to the quantity_adder function by the end of this sprint.
Error
Planning
Tests
Final test (outside user)
Reflection
The testing above shows that the sprint's goals have been successful. I was thankfully able to reuse most of my original quantity_adder code; only two lines had to be modified to fix the bug, as identified in the paper plan, and the "updated" boolean was also inserted to make the program more efficient, in that it identifies quickly whether or not there is an existing quantity in the order list to be altered, or if the new order can just be appended as normal. After the main work of the sprint was completed, I asked an outside user to test my code; after reviewing the footage and listening to her feedback, I was able to identify two minor problems that I have also fixed as part of the work on this final sprint. ((1) The add_to_order function previously allowed the user to order a nonexistent eleventh menu item, due to my use of len(pizza_menu) as the given maximum for their input (which meant they could enter "10" when they should only have been able to enter numbers 0-9. This was fixed to prevent the program from crashing in this scenario. (2) There were two minor typos in user feedback throughout that have now been taken out to avoid confusion from the user.
Further information
To create this program, I used the AGILE development method. That meant following the core principles of documentation and modelling. I started the project by creating a rough to-do list in the form of a kanban board (the project backlog) and divided the work into "sprints" based on each element of this project backlog. This helped me to prioritise, especially in the early stages of my program, and helped me to construct a linear and logical path towards a complete program - with basic functionality coming before complicated embellishments. This made my code very flexible and all changes to the design could be easily performed. Before each sprint I defined my aims, created another kanban board, and then a rough plan for how I envisioned the code to be laid out. This helped me to remain efficient during a sprint and undoubtedly sped up my work. All updates to the code were tested in a separate file specifically intended for testing before being integrated into the main code document, so as to avoid setbacks if the new code didn't integrate as well as planned; comprehensive testing should also make the theoretical user experience better, as by fully testing the program after each sprint I or other testers were able to catch and fix many small errors or even identify major design flaws as they continued to cause problems throughout the development process. Finally, the practice of writing a reflection or sprint review after each sprint was completed allowed me to improve the quality of future sprints by analysing my own mistakes. Overall, the use of the AGILE development method greatly increased my productivity, my efficiency, and the overall quality of my work. My use of Github was an essential part of maintaining my dedication to this method - regular commits after each sprint made keeping track of my progress much easier, and through it I was able to complete my reflections as well as the kanban board and plans. Below is a screenshot of my commits for sprints one through seven.
Git commit history
Relevant Implications Summary
Future proofing
"Future proofing" means that this program will continue to be flexible and easy to work with well into the future. It means the code is easy to update and expand upon, and easy to understand for any new developer who may potentially come to work on it. To address this, I have tried my best to keep the structure of the program simple and easy to follow. All code runs out of a main function, with a central menu. All functions and variables are sensibly named and the code has been thoroughly commented, so that all of it is explained. This makes it easy to come back to or look at for the first time and understand what's happening. The code has been run through a PEP8 online checker, which checks that my code follows all standard conventions for the Python language; as the screenshot immediately below reveals, these conventions have been met. This confirms that my code will be easy to read and understand for anyone familiar with Python. Finally, my use of Github and Agile processes mean that I - and anyone with access to my notes - have a detailed record of this program's design and potential weaknesses.
Functionality
"Functionality" means that the program functions as it should, without crashes or glitches. To address this I have personally tested the program every time I added or altered code, performed a formal test after each sprint, and documented the most important tests on this document. I have also asked other people not familiar with the project to test it for me, which resulted in the discovery of several places where the code crashed unexpectedly, as well as the identification of barriers to usability. It is my belief that there are no longer errors or glitches in my code - I have created several validation functions specifically designed to combat these glitches, which have been well documented throughout the planning process.
Usability
"Usability" means that a program is easy to use to somebody unfamiliar with its workings. That means it is easy to navigate, interact with, and understand. I believe my program complies with this heuristic due to the extensive validation as well as the way it is laid out. The program is predictable, running from a central menu that the user returns to after each completed task. The user is provided with clear instructions and every step. If they do something wrong, a feedback message is printed that clearly explains what they have done wrong and what they must do to fix it. They are also given a chance to fix their own mistakes, and are usually asked to "please try again" after they have entered something the system cannot process. The program also takes advantage of the Python functions .lower(), .upper(), and .title() to make sure the user doesn't have to worry about simple things like capitalising their input. The code has also been tested by somebody unfamiliar with my code who identified typos that have now been removed, as well as giving feedback on the usability; after performing revisions based on his advice I am confident my program provides clear feedback and instructions even for a first-time user, and is free of typos that may interfere with understanding.


--- layout: default ---
Create a seed file (eg. /path/to/seeds/20150928000000_initial_seed.rb
)
Sequel.seed(:development, :test) do # Applies only to "development" and "test" environments def run User.create \ full_name: "Richard Feynman", profession: "Theoretical physicist", username: "rfeynman", password: "271828" end end Sequel.seed do # Wildcard Seed; applies to every environment def run [ ['USD', 'United States dollar'], ['BRL', 'Brazilian real'] ].each do |abbr, name| Currency.create abbr: abbr, name: name end end end
Set the environment (optional — if omitted, it will fulfil wildcard Seeds only)
Sequel::Seed.setup(:development)
Load the extension
require 'sequel' require 'sequel/extensions/seed' Sequel.extension :seed
Apply the seeds/fixtures
DB = Sequel.connect(...) Sequel::Seeder.apply(DB, "/path/to/seeds")
Work with Model's associations inside JSON & YAML files
If you need any help (or have found any bug 🐞), please post it on /issues. Check out the documentation if you need help on how to create seed/fixture files using Ruby, YAML and JSON code and how to apply them over a database instance.


Kanye West
9/13/15
This is a description. I am doing this and I need a rapberry pie. Please donate something to me. I'm poor and don't have any money.  I am doing this and I need a rapberry pie. Please donate something to me. I'm poor and don't have any money.  I am doing this and I need a rapberry pie. Please donate something to me. I'm poor and don't have any money.