This is a design document detailing the plan for refactoring the internal
structure of Ganeti, and particularly the set of daemons it is divided into.
Ganeti is comprised of a growing number of daemons, each dealing with part of
the tasks the cluster has to face, and communicating with the other daemons
using a variety of protocols.
Specifically, as of Ganeti 2.8, the situation is as follows:
- Master daemon (MasterD)
It is responsible for managing the entire cluster, and it’s written in Python.
It is executed on a single node (the master node). It receives the commands
given by the cluster administrator (through the remote API daemon or the
command line tools) over the LUXI protocol. The master daemon is responsible
for creating and managing the jobs that will execute such commands, and for
managing the locks that ensure the cluster will not incur in race conditions.
Each job is managed by a separate Python thread, that interacts with the node
daemons via RPC calls.
The master daemon is also responsible for managing the configuration of the
cluster, changing it when required by some job. It is also responsible for
copying the configuration to the other master candidates after updating it.
- RAPI daemon (RapiD)
- It is written in Python and runs on the master node only. It waits for
requests issued remotely through the remote API protocol. Then, it forwards
them, using the LUXI protocol, to the master daemon (if they are commands) or
to the query daemon if they are queries about the configuration (including
live status) of the cluster.
- Node daemon (NodeD)
- It is written in Python. It runs on all the nodes. It is responsible for
receiving the master requests over RPC and execute them, using the appropriate
backend (hypervisors, DRBD, LVM, etc.). It also receives requests over RPC for
the execution of queries gathering live data on behalf of the query daemon.
- Configuration daemon (ConfD)
- It is written in Haskell. It runs on all the master candidates. Since the
configuration is replicated only on the master node, this daemon exists in
order to provide information about the configuration to nodes needing them.
The requests are done through ConfD’s own protocol, HMAC signed,
implemented over UDP, and meant to be used by parallely querying all the
master candidates (or a subset thereof) and getting the most up to date
answer. This is meant as a way to provide a robust service even in case master
is temporarily unavailable.
- Query daemon (QueryD)
- It is written in Haskell. It runs on all the master candidates. It replies
to Luxi queries about the current status of the system, including live data it
obtains by querying the node daemons through RPCs.
- Monitoring daemon (MonD)
- It is written in Haskell. It runs on all nodes, including the ones that are
not vm-capable. It is meant to provide information on the status of the
system. Such information is related only to the specific node the daemon is
running on, and it is provided as JSON encoded data over HTTP, to be easily
readable by external tools.
The monitoring daemon communicates with ConfD to get information about the
configuration of the cluster. The choice of communicating with ConfD instead
of MasterD allows it to obtain configuration information even when the cluster
is heavily degraded (e.g.: when master and some, but not all, of the master
candidates are unreachable).
The current structure of the Ganeti daemons is inefficient because there are
many different protocols involved, and each daemon needs to be able to use
multiple ones, and has to deal with doing different things, thus making
sometimes unclear which daemon is responsible for performing a specific task.
Also, with the current configuration, jobs are managed by the master daemon
using python threads. This makes terminating a job after it has started a
difficult operation, and it is the main reason why this is not possible yet.
The master daemon currently has too many different tasks, that could be handled
better if split among different daemons.
In order to improve on the current situation, a new daemon subdivision is
proposed, and presented hereafter.
- LUXI daemon (LuxiD)
- It will be written in Haskell. It will run on the master node and it will be
the only LUXI server, replying to all the LUXI queries. These includes both
the queries about the live configuration of the cluster, previously served by
QueryD, and the commands actually changing the status of the cluster by
submitting jobs. Therefore, this daemon will also be the one responsible with
managing the job queue. When a job needs to be executed, the LuxiD will spawn
a separate process tasked with the execution of that specific job, thus making
it easier to terminate the job itself, if needeed. When a job requires locks,
LuxiD will request them from WConfD.
In order to keep availability of the cluster in case of failure of the master
node, LuxiD will replicate the job queue to the other master candidates, by
RPCs to the NodeD running there (the choice of RPCs for this task might be
reviewed at a second time, after implementing this design).
- Configuration management daemon (WConfD)
- It will run on the master node and it will be responsible for the management
of the authoritative copy of the cluster configuration (that is, it will be
the daemon actually modifying the config.data file). All the requests of
configuration changes will have to pass through this daemon, and will be
performed using a LUXI-like protocol (“WConfD proto” in the graph. The exact
protocol will be defined in the separate design document that will detail the
WConfD separation). Having a single point of configuration management will
also allow Ganeti to get rid of possible race conditions due to concurrent
modifications of the configuration. When the configuration is updated, it
will have to push the received changes to the other master candidates, via
RPCs, so that RConfD daemons and (in case of a failure on the master node)
the WConfD daemon on the new master can access an up-to-date version of it
(the choice of RPCs for this task might be reviewed at a second time). This
daemon will also be the one responsible for managing the locks, granting them
to the jobs requesting them, and taking care of freeing them up if the jobs
holding them crash or are terminated before releasing them. In order to do
this, each job, after being spawned by LuxiD, will open a local unix socket
that will be used to communicate with it, and will be destroyed when the job
terminates. LuxiD will be able to check, after a timeout, whether the job is
still running by connecting here, and to ask WConfD to forcefully remove the
locks if the socket is closed.
Also, WConfD should hold a serialized list of the locks and their owners in a
file (locks.data), so that it can keep track of their status in case it
crashes and needs to be restarted (by asking LuxiD which of them are still
running).
Interaction with this daemon will be performed using Unix sockets.
- Configuration query daemon (RConfD)
- It is written in Haskell, and it corresponds to the old ConfD. It will run on
all the master candidates and it will serve information about the static
configuration of the cluster (the one contained in config.data). The
provided information will be highly available (as in: a response will be
available as long as a stable-enough connection between the client and at
least one working master candidate is available) and its freshness will be
best effort (the most recent reply from any of the master candidates will be
returned, but it might still be older than the one available through WConfD).
The information will be served through the ConfD protocol.
- Rapi daemon (RapiD)
- It remains basically unchanged, with the only difference that all of its LUXI
query are directed towards LuxiD instead of being split between MasterD and
QueryD.
- Monitoring daemon (MonD)
- It remains unaffected by the changes in this design document. It will just get
some of the data it needs from RConfD instead of the old ConfD, but the
interfaces of the two are identical.
- Node daemon (NodeD)
- It remains unaffected by the changes proposed in the design document. The only
difference being that it will receive its RPCs from LuxiD (for job queue
replication), from WConfD (for configuration replication) and for the
processes executing single jobs (for all the operations to be performed by
nodes) instead of receiving them just from MasterD.
This restructuring will allow us to reorganize and improve the codebase,
introducing cleaner interfaces and giving well defined and more restricted tasks
to each daemon.
Furthermore, having more well-defined interfaces will allow us to have easier
upgrade procedures, and to work towards the possibility of upgrading single
components of a cluster one at a time, without the need for immediately
upgrading the entire cluster in a single step.
While performing this refactoring, we aim to increase the amount of
Haskell code, thus benefiting from the additional type safety provided by its
wide compile-time checks. In particular, all the job queue management and the
configuration management daemon will be written in Haskell, taking over the role
currently fulfilled by Python code executed as part of MasterD.
The changes describe by this design document are quite extensive, therefore they
will not be implemented all at the same time, but through a sequence of steps,
leaving the codebase in a consistent and usable state.
- Rename QueryD to LuxiD.
A part of LuxiD, the one replying to configuration
queries including live information about the system, already exists in the
form of QueryD. This is being renamed to LuxiD, and will form the first part
of the new daemon. NB: this is happening starting from Ganeti 2.8. At the
beginning, only the already existing queries will be replied to by LuxiD.
More queries will be implemented in the next versions.
- Let LuxiD be the interface for the queries and MasterD be their executor.
Currently, MasterD is the only responsible for receiving and executing LUXI
queries, and for managing the jobs they create.
Receiving the queries and managing the job queue will be extracted from
MasterD into LuxiD.
Actually executing jobs will still be done by MasterD, that contains all the
logic for doing that and for properly managing locks and the configuration.
At this stage, scheduling will simply consist in starting jobs until a fixed
maximum number of simultaneously running jobs is reached.
- Extract WConfD from MasterD.
The logic for managing the configuration file is factored out to the
dedicated WConfD daemon. All configuration changes, currently executed
directly by MasterD, will be changed to be IPC requests sent to the new
daemon.
- Extract locking management from MasterD.
The logic for managing and granting locks is extracted to WConfD as well.
Locks will not be taken directly anymore, but asked via IPC to WConfD.
This step can be executed on its own or at the same time as the previous one.
- Jobs are executed as processes.
The logic for running jobs is rewritten so that each job can be managed by an
independent process. LuxiD will spawn a new (Python) process for every single
job. The RPCs will remain unchanged, and the LU code will stay as is as much
as possible.
MasterD will cease to exist as a deamon on its own at this point, but not
before.
- Improve job scheduling algorithm.
The simple algorithm for scheduling jobs will be replaced by a more
intelligent one. Also, the implementation of Filtering of jobs for the Ganeti job queue can be
started.
Job death detection
Requirements:
- It must be possible to reliably detect a death of a process even under
uncommon conditions such as very heavy system load.
- A daemon must be able to detect a death of a process even if the
daemon is restarted while the process is running.
- The solution must not rely on being able to communicate with
a process.
- The solution must work for the current situation where multiple jobs
run in a single process.
- It must be POSIX compliant.
These conditions rule out simple solutions like checking a process ID
(because the process might be eventually replaced by another process
with the same ID) or keeping an open connection to a process.
Solution: As a job process is spawned, before attempting to
communicate with any other process, it will create a designated empty
lock file, open it, acquire an exclusive lock on it, and keep it open.
When connecting to a daemon, the job process will provide it with the
path of the file. If the process dies unexpectedly, the operating system
kernel automatically cleans up the lock.
Therefore, daemons can check if a process is dead by trying to acquire
a shared lock on the lock file in a non-blocking mode:
- If the locking operation succeeds, it means that the exclusive lock is
missing, therefore the process has died, but the lock
file hasn’t been cleaned up yet. The daemon should release the lock
immediately. Optionally, the daemon may delete the lock file.
- If the file is missing, the process has died and the lock file has
been cleaned up.
- If the locking operation fails due to a lock conflict, it means
the process is alive.
Using shared locks for querying lock files ensures that the detection
works correctly even if multiple daemons query a file at the same time.
A job should close and remove its lock file when completely finishes.
The WConfD daemon will be responsible for removing stale lock files of
jobs that didn’t remove its lock files themselves.
Statelessness of the protocol: To keep our protocols stateless,
the job id and the path the to lock file are sent as part of every
request that deals with resources, in particular the Ganeti Locks.
All resources are owned by the pair (job id, lock file). In this way,
several jobs can live in the same process (as it will be in the
transition period), but owner death detection still only depends on the
owner of the resource. In particular, no additional lookup table is
needed to obtain the lock file for a given owner.
Considered alternatives: An alternative to creating a separate lock
file would be to lock the job status file. However, file locks are kept
only as long as the file is open. Therefore any operation followed by
closing the file would cause the process to release the lock. In
particular, with jobs as threads, the master daemon wouldn’t be able to
keep locks and operate on job files at the same time.
Job execution
As the Luxi daemon will be responsible for executing jobs, it needs to
start jobs in such a way that it can properly detect if the job dies
under any circumstances (such as Luxi daemon being restarted in the
process).
The name of the lock file will be stored in the corresponding job file
so that anybody is able to check the status of the process corresponding
to a job.
The proposed procedure:
- The Luxi daemon saves the name of its own lock file into the job file.
- The Luxi daemon forks, creating a bi-directional pipe with the child
process.
- The child process creates and locks its own, proper lock file and
handles its name to the Luxi daemon through the pipe.
- The Luxi daemon saves the name of the lock file into the job file and
confirms it to the child process.
- Only then the child process can replace itself by the actual job
process.
If the child process detects that the pipe is broken before receiving the
confirmation, it must terminate, not starting the actual job.
This way, the actual job is only started if it is ensured that its lock
file name is written to the job file.
If the Luxi daemon detects that the pipe is broken before successfully
sending the confirmation in step 4., it assumes that the job has failed.
If the pipe gets broken after sending the confirmation, no further
action is necessary. If the child doesn’t receive the confirmation,
it will die and its death will be detected by Luxid eventually.
If the Luxi daemon dies before completing the procedure, the job will
not be started. If the job file contained the daemon’s lock file name,
it will be detected as dead (because the daemon process died). If the
job file already contained its proper lock file, it will also be
detected as dead (because the child process won’t start the actual job
and die).
WConfD details
WConfD will communicate with its clients through a Unix domain socket for both
configuration management and locking. Clients can issue multiple RPC calls
through one socket. For each such a call the client sends a JSON request
document with a remote function name and data for its arguments. The server
replies with a JSON response document containing either the result of
signalling a failure.
Any state associated with client processes will be mirrored on persistent
storage and linked to the identity of processes so that the WConfD daemon will
be able to resume its operation at any point after a restart or a crash. WConfD
will track each client’s process start time along with its process ID to be
able detect if a process dies and it’s process ID is reused. WConfD will clear
all locks and other state associated with a client if it detects it’s process
no longer exists.
Configuration management
The new configuration management protocol will be implemented in the following
steps:
- Step 1:
Implement the following functions in WConfD and export them through
RPC:
- Obtain a single internal lock, either in shared or
exclusive mode. This lock will substitute the current lock
_config_lock in config.py.
- Release the lock.
- Return the whole configuration data to a client.
- Receive the whole configuration data from a client and replace the
current configuration with it. Distribute it to master candidates
and distribute the corresponding ssconf.
WConfD must detect deaths of its clients (see Job death
detection) and release locks automatically.
In config.py modify public methods that access configuration:
- Instead of acquiring a local lock, obtain a lock from WConfD
using the above functions
- Fetch the current configuration from WConfD.
- Use it to perform the method’s task.
- If the configuration was modified, send it to WConfD at the end.
- Release the lock to WConfD.
This will decouple the configuration management from the master daemon,
even though the specific configuration tasks will still performed by
individual jobs.
After this step it’ll be possible access the configuration from separate
processes.
- Step 2:
- Reimplement all current methods of ConfigWriter for reading and
writing the configuration of a cluster in WConfD.
- Expose each of those functions in WConfD as a separate RPC function.
This will allow easy future extensions or modifications.
- Replace ConfigWriter with a stub (preferably automatically
generated from the Haskell code) that will contain the same methods
as the current ConfigWriter and delegate all calls to its
methods to WConfD.
- Step 3:
- In a later step, the impact of the config lock will be reduced by moving
it more and more into an internal detail of WConfD. This process will be
detailed in a forthcoming design document.
Locking
The new locking protocol will be implemented as follows:
Re-implement the current locking mechanism in WConfD and expose it for RPC
calls. All current locks will be mapped into a data structure that will
uniquely identify them (storing lock’s level together with it’s name).
WConfD will impose a linear order on locks. The order will be compatible
with the current ordering of lock levels so that existing code will work
without changes.
WConfD will keep the set of currently held locks for each client. The
protocol will allow the following operations on the set:
- Update:
- Update the current set of locks according to a given list. The list contains
locks and their desired level (release / shared / exclusive). To prevent
deadlocks, WConfD will check that all newly requested locks (or already held
locks requested to be upgraded to exclusive) are greater in the sense of
the linear order than all currently held locks, and fail the operation if
not. Only the locks in the list will be updated, other locks already held
will be left intact. If the operation fails, the client’s lock set will be
left intact.
- Opportunistic union:
- Add as much as possible locks from a given set to the current set within a
given timeout. WConfD will again check the proper order of locks and
acquire only the ones that are allowed wrt. the current set. Returns the
set of acquired locks, possibly empty. Immediate. Never fails. (It would also
be possible to extend the operation to try to wait until a given number of
locks is available, or a given timeout elapses.)
- List:
- List the current set of held locks. Immediate, never fails.
- Intersection:
- Retain only a given set of locks in the current one. This function is
provided for convenience, it’s redundant wrt. list and update. Immediate,
never fails.
- Addidional restrictions due to lock implications:
Ganeti supports locks that act as if a lock on a whole group (like all nodes)
were held. To avoid dead locks caused by the additional blockage of those
group locks, we impose certain restrictions. Whenever A is a group lock and
B belongs to A, then the following holds.
- A is in lock order before B.
- All locks that are in the lock order between A and B also belong to A.
- It is considered a lock-order violation to ask for an exclusive lock on B
while holding a shared lock on A.
After this step it’ll be possible to use locks from jobs as separate processes.
The above set of operations allows the clients to use various work-flows. In particular:
- Pessimistic strategy:
- Lock all potentially relevant resources (for example all nodes), determine
which will be needed, and release all the others.
- Optimistic strategy:
- Determine what locks need to be acquired without holding any. Lock the
required set of locks. Determine the set of required locks again and check if
they are all held. If not, release everything and restart.
Future aims:
- Add more fine-grained locks to prevent unnecessary blocking of jobs. This
could include locks on parameters of entities or locks on their states (so that
a node remains online, but otherwise can change, etc.). In particular,
adding, moving and removing instances currently blocks the whole node.
- Add checks that all modified configuration parameters belong to entities
the client has locked and log violations.
- Make the above checks mandatory.
- Automate optimistic locking and checking the locks in logical units.
For example, this could be accomplished by allowing some of the initial
phases of LogicalUnit (such as ExpandNames and DeclareLocks) to be run
repeatedly, checking if the set of locks requested the second time is
contained in the set acquired after the first pass.
- Add the possibility for a job to reserve hardware resources such as disk
space or memory on nodes. Most likely as a new, special kind of instances
that would only block its resources and allow to be converted to a regular
instance. This would allow long-running jobs such as instance creation or
move to lock the corresponding nodes, acquire the resources and turn the
locks into shared ones, keeping an exclusive lock only on the instance.
- Use more sophisticated algorithm for preventing deadlocks such as a
wait-for graph. This would allow less union failures and allow more
optimistic, scalable acquisition of locks.
There is a possibility that a job will finish performing its task while LuxiD
and/or WConfD will not be available.
In order to deal with this situation, each job will update its job file
in the queue. This is race free, as LuxiD will no longer touch the job file,
once the job is started; a corollary of this is that the job also has to
take care of replicating updates to the job file. LuxiD will watch job files for
changes to determine when a job was cleanly finished. To determine jobs
that died without having the chance of updating the job file, the Job death
detection mechanism will be used.


Economist Ross Garnaut returns to Ballarat for forum on renewable economy opportunities
by Alex FordProfessor Ross Garnaut was in Ballarat in August, speaking at the Grampians New Energy Taskforce's Decarbonising Victoria event.
Since then, he's released a book, Superpower: Australia's Low-Carbon Opportunity, and he said Ballarat is a superb example of how to make the most of this opportunity to harness renewable energy for cheaper electricity and more jobs.
"I was impressed," he said.
"I was very interested in the focus of the region in building on these assets to create a bigger economic future in the region.
READ MORE: Ballarat hosts zero emissions forum
"There's a lot of good thought being given to the possibilities, and that made me very interested in keeping in touch."
He'll return on Wednesday for a public forum to discuss a low-carbon future, led globally by Australia.
The book notes decarbonisation of electricity is a path to nearly complete decarbonisation of transport, and partial decarbonisation of industry, and that could be the foundation for Australia to become an economic "superpower" - hence the title of the book.
The wind turbines being installed across the district, and solar panels on roofs, will be part of a bigger plan, he adds - once enough green electricity is being generated, other problems can be solved more easily.
"I mention briefly in the book the very low cost of renewable energy transforms the economics of moving water, recycling water, and desalinating water," he said.
"I'm interested in bringing that into the conversation about western Victoria."
Also speaking at the event on Wednesday is City of Ballarat deputy mayor Belinda Coates.
READ MORE: Ballarat's journey to carbon neutrality
She said when economists like Professor Garnaut say there is an "enormous opportunity", then "everyone should be pricking their ears up".
"Having the foresight and vision to put in some investment now for a really big return - not only does it make comm more resilient, it creates jobs along the way and reduces impact on the environment," she said.
"It really is win-win-win."
Professor Garnaut had a simple message for people still not convinced.
"There's already a lot of interest in Ballarat and western Victoria, there's opportunity, I'd like to confirm for them that it's real, it's big, and within the grasp of the region
The Committee for Ballarat will host the public forum at the Ballarat Tech School on Wednesday from 5.30pm.
Limited free tickets are available online.


Computes a 3-D convolution given 5-D input
and filter
tensors.
tf.compat.v1.nn.conv3d( input, filter=None, strides=None, padding=None, data_format='NDHWC', dilations=[1, 1, 1, 1, 1], name=None, filters=None )
In signal processing, cross-correlation is a measure of similarity of two waveforms as a function of a time-lag applied to one of them. This is also known as a sliding dot product or sliding inner-product.
Our Conv3D implements a form of cross-correlation.
input
: A Tensor
. Must be one of the following types: half
, bfloat16
, float32
, float64
.
Shape [batch, in_depth, in_height, in_width, in_channels]
.filter
: A Tensor
. Must have the same type as input
.
Shape [filter_depth, filter_height, filter_width, in_channels,
out_channels]
. in_channels
must match between input
and filter
.strides
: A list of ints
that has length >= 5
.
1-D tensor of length 5. The stride of the sliding window for each
dimension of input
. Must have strides[0] = strides[4] = 1
.padding
: A string
from: "SAME", "VALID"
.
The type of padding algorithm to use.data_format
: An optional string
from: "NDHWC", "NCDHW"
. Defaults to "NDHWC"
.
The data format of the input and output data. With the
default format "NDHWC", the data is stored in the order of:
[batch, in_depth, in_height, in_width, in_channels].
Alternatively, the format could be "NCDHW", the data storage order is:
[batch, in_channels, in_depth, in_height, in_width].dilations
: An optional list of ints
. Defaults to [1, 1, 1, 1, 1]
.
1-D tensor of length 5. The dilation factor for each dimension of
input
. If set to k > 1, there will be k-1 skipped cells between each
filter element on that dimension. The dimension order is determined by the
value of data_format
, see above for details. Dilations in the batch and
depth dimensions must be 1.name
: A name for the operation (optional).A Tensor
. Has the same type as input
.


Open your browser's console and reload this page, to see the event handling/dispatching simulation.
Event Handling Element


Single User View
Internal facing single user view that displays multiple PCN's for single users. This should help identify repeat offenders or recurring issues with vulnerable people building up many large penalties.
Prototypes
Don't use any of this prototype code on production services, it doesn't adhere to development standards and is hacked together quickly and roughly.
What needs tested - Readability of notes and transactions, continual back office testing and overpayment reports.
CCS
- CCS Version 5- Generate payment token
- CCS Version 5 - Direct Debit status and ref. - April 2019
- CCS Version 5
- CCS Version 4 - March 2018
BO
- BO Version - Refunding Gov Pay payments - August 2019
- BO Version - Direct Debit set up - May 2019
- BO Version - Populated login screen
- BO Version - September 2018
- BO version - Open record (Decmeber 2018)
- BO version - Open record
- BO version - locked record
- BO version - Closed record for debt collection
- Overpayment report
Errors
- No results found
- Something's gone wrong (temporary fix)
- Something's gone wrong (future fix)
- Mandatory fields and Multiple error messages
- Error messages on the action popups
Easement scenarios
- Simon's scenario one Penalty to be eased
- Simon's scenario one Easement applied
- Simon's scenario one Prescription paid
- Simon's scenario two Surcharge to be eased
- Simon's scenario two Surcharge eased
- Simon's scenario two Partial payment made
Experimental features (post MVP)
CCS
- CCS Direct Debits - June 2019, v.2
- CCS - Pre-CN (w/ Payment Plans)
- CCS Direct Debits - April 2019, v.1 [PDF]
- CCS Version 5 - June 2018
BO
- BO - Card Payments
- Back office Version 4 - March 2018
- Back office HC3 case
- Back office letter prepopulate
- BO - (Edit transaction)
Features to be tested
- Personal details history
- Record locked until
- Manual linking/delinking
- BO: Balance transfer
- BO: Process refund
- BO: Letter prepopulate
Version 3 - February 2018
What we tested - We further tested functionality with dragable pop out windows that allow agents to see the record side by side with the function they are performing. We also briefly tested the possibility of having the multiple PCN's presented in this way. The purpose of this was to find the most effective way for users to perform daily functions and thus deal with cases quicker.
Version 2 - January 2018
What we tested - Following the A/B test from v1, We tested the customer centered version with some dummy functionality links. We also tested a back office version of this that included a dummy button for reports and additional dummy options for transactions. The purpose of this testing was to discover more about the interactions that agents need to make with cases on a day to day basis.
Version 1 - November 2017
What we tested - Version one of SUV journey was created to provide call center agents with a better view of patients that may have multiple PCN's. We tested two different layouts with 5 agents and 1 back office staff member. The matches and possible matches tabs received good feedback with agents appreciating the value of this feature. The customer centered view was the preferred layout.
Version 0 - September 2017
What we created - Very early mock ups of what screens may look like. Most styles have since been removed and the width has been increased to better accomodate everything on one screen. Partly inspired by Infected blood support internal screens.


We are all watching carefully the evolution of the coronavirus and have been responding deliberately and pragmatically. We would like to share some of the steps we are taking to ensure that all colleagues are protected. We have a well-established business continuity plan that covers outbreaks such as this, and the resilience and health and safety teams have been working closely with the regional management teams to put our plans into action. Our top priority is your health and safety. These actions are in concert with relevant government agencies, and also allow for our operations to continue with minimal adverse effect.
Some of the key actions that affect all colleagues globally are as follows:
- Travel to China and Hong Kong is restricted. Any travel must be business critical, and requires the approval of a member of the China (for travel to China) or Hong Kong (for travel to HK) Management Teams
- Travel to Wuhan and Hubei province is not permitted
- All colleagues who are returning, or have recently returned, from mainland China – or who are resident with someone who has recently returned from mainland China - should inform their line manager/HR, and work from home for 14 days. ‘Recently returned’ from mainland China means within the last 14 days.
As a pragmatic step we would encourage colleagues to avoid travelling for business purposes unless necessary, and instead use VCs or calls where possible.
In addition, please take note of all Bridge, email or SMS communications that have been sent to your specific business unit or country with additional guidance. This is particularly important in the GCNA region, where additional actions such as split working, hygiene precautions, and office closures/deep cleaning operations are in place.
In addition to anything we say, please defer to your own common sense. Your health and safety - wherever you are - is of paramount importance.
Bill and Ben
|
|
|


Sign
Enter Challenge
Copy
Signature
Copy
My Wallet Address
Copy
Sign
Sign/Submit
Settings
Monero Wallet RPC Port
Save
Test Connection


API Documentation
The Pyrite3D API is a RESTful service that provides 3 discrete facilities to callers.- Discovery - discover the models stored and exposed by Pyrite3D server
- Query - run spatial queries against the model
- Download - download cubes and related texture assets
Data Concepts
The models are stored by name and version - such that I can have different versions of the same model.API Cheatsheet
| Method | Pattern | Description |
|---|---|---|
| GET | /sets |
Returns list of available set names |
| GET | /sets/<setname> |
Returns list of available versions for set <setname> |
| GET | /sets/<setname>/<version> |
Returns metadata for specified version of set <setname> |
| GET | /sets/<setname>/<version>/models/<lod>/<x,y,z>[?fmt=<format>] |
Returns model data for the data at the specified world coordinates and level of detail |
More Information
For updated information about the Pyrite3D API please refer to the project wiki page.


Below are our Terms of Service, which outline a lot of legal goodies, but the bottom line is it’s our aim to
always take care you and we won't include any terms apart from what we absolutely have to
- Application of Terms
- By visiting and OnTrack, you confirm that you are in agreement with and bound by the terms
outlined below. These terms apply to the website, emails, or any other communication.
- Login
- By using our account service you agree to be registered to our database as well as possibly
receiving the occassional email from us if we're changing any terms and cond or have a
promotion.
- Our Site
- We reserve the right to change our website in whatever way and whenever we choose to.
- Ownership
- Ownership of the product is governed by the usage licenses.
- Membership & Content
- Membership is a benefit for those who follow our terms and policies. We may at any time suspend
or terminate your account.
- We can view and/or remove any content for any reason at our own discretion. This will typically
only be exercised for issues needing immediate resolution, such as, but not limited to, the
posting of unauthorized content, offensive content, illegal content, or anything breaching
anyone else’s rights.
- Requesting, Modifying or Deleting Your Data (GDPR)
- We are a small operation, but we work hard to make sure your data remains safe and we only
collect what is needed to provide our services. If you want to request an export of your data, a
modification to any data we have related to your account, or delete of all data permanently,
please contact us and we will do it as soon as is possible.
- Changes to terms
- If we change our terms of use we will post those changes on this page.
{% endblock %}


Plant
{{ planting.pattern }}
{{ planting.interRowSpacingMin }}
to
{{ planting.interRowSpacingMax }}
Inches between plants
{{ planting.rowSpacingMin }}
to
{{ planting.rowSpacingMax }}
Inches between rows
{{ planting.germinationStart }}
to
{{ planting.germinationEnd }}
Days to germination
{{ planting.depth }}
Inches below surface
{{ planting.soilTemperatureMin }}
to
{{ planting.soilTemperatureMax }}
°F


To save the purring kitty from getting drowned, you have to get the food name correct, within 6 guesses!


We all get the same 24 hours. So put aside your fears. Understand potential alone wont cut it. And dont't wait until someday. Because actions always speak loudest. And doing is how you say to the world, "this is me". Do great things.
Project Rocket to the moon
Project Ultron
Blog


On this page:
General options
- List only tools available in site: This option will automatically filter the list of tools presented on the Report editing page with the tools available in site.
Chart presentation options
- Display item labels on bar charts: This option will display labels with total values on charts that don't require labels to be shown (e.g., Pie charts always require values to be displayed).
- Charts alpha-transparency: This option allows to specify a transparency level for rendered charts.
Tools/events processed as 'Activity'
This option allows to select the tool events that will count as
Activity on the tool
Overview page. Some considerations:
- Clicking on All tools will always use all existing tool events. Since tools can be added/removed from a site or made available/unavailable on current LMS installation, this option ensures that all tools are always selected.
- Clicking on a Tool will select/unselect all related tool events.
- Clicking on a Event will select/unselect only that event.


Goals
This week, we hope you’ll become experts at proving functions are uncomputable (and occasionally, computable). We introduce the “proof by reduction” technique, which is a tremendously useful way to prove properties about problems, and (as you will see in the Algorithms class) also to develop and analyze algorithmic solutions.
The main goals for Week 10 are to:
- Become comfortable with the terms decidable, recognizable, and computable, and how we talk about these properties for languages, functions, and problems.
- Learn how to do a proof by reduction, and to avoid the common pitfalls in constructing reduction proofs.
- Gain experience proving problems are computable and uncomputable (we use the terms uncomputable and noncomputable interchangably).
Schedule
The schedule this week is a webb of complexity because of Election Day, Tuesday 3 November, but we hope everyone will abide by these carefully devised changes. We will not hold any official course activities (assessed cohort meetings or scheduled office hours) on Election Day.
Please vote (and if you can, volunteer to be a poll worker)! (Note: if you are voting in Virginia, early voting is a great option, but ends on October 31.)
The schedule changes impact the “Tuesday” cohorts. Until now, the Tuesday cohorts have been the first to meet for a given week. This week, they will not meet on November 3, but will instead move to be the last cohorts to meet in Week 10 (and subsequent weeks) on November 10. The schedule lists Tuesday cohorts on “Break” from Wednesday 28 Oct through Wednesday 4 November (without the normal preparation Cohort Meeting that would be on 31 Oct/1 Nov). You can decide to meet if you would like then, of course, and use the opportunity to review past weeks or get an early start on Week 10, but that’s up to you. (If any other cohorts are thinking it is unfair that the Tuesday cohorts get this week break, recall that they had their first assessed cohort meetings on 1 September, only four days after the cohorts were arranged. We are, unfortunately, not able to provide a break week for the other cohorts since the semester ends on Tuesday, 24 November.)
For Thursday cohorts who have preparation meetings on Tuesdays, we hope you will arrange within your cohort a schedule that works for everyone. It is fine to move the preparation meeting to Monday or Wednesday if you can find a time that works for everyone, or to meet as normal on Tuesday if everyone has been able to vote early and does not have other election day commitments. If you aren’t able to find a solution that works for your cohort, please let us know.
| Day | "Tuesday" Cohort | "Wednesday" Cohort | "Thursday" Cohort | "Friday" Cohort | "Sunday" Cohort | "Monday" Cohort | |
|---|---|---|---|---|---|---|---|
| Wed 28 Oct | Break | (Week 9) | (Week 9) | (Week 9) | (Week 9) | (Week 9) | |
| Thu 29 Oct | Break | Preparation | (Week 9) | (Week 9) | (Week 9) | (Week 9) | |
| Fri 30 Oct | Break | Preparation | Preparation | (Week 9) | (Week 9) | (Week 9) | |
| Sat/Sun 31 Oct/1 Nov | Break | Preparation | Preparation | Preparation | (Week 9) | (Week 9) | |
| Mon 2 Nov | Break | Cohort Meeting | Preparation | Preparation | Preparation | (Week 9) | |
| Tue3 Nov | Election Day (no assessed cohort meetings or deadlines) | ||||||
| Wed 4 Nov | Preparation | Assessed Cohort Meeting | Preparation | Cohort Meeting | Preparation | Preparation | |
| Thu 5 Nov | Preparation | Write-up Due | Assessed Cohort Meeting | Preparation | Cohort Meeting | Preparation | |
| Fri 6 Nov | Preparation | Preparation | Write-up Due | Assessed Cohort Meeting | Preparation | Cohort Meeting | |
| Sat/Sun 7/8 Nov | Cohort Meeting | Week 11 | Week 11 | Write-up Due | Assessed Cohort Meeting | Preparation | |
| Mon 9 Nov | Preparation | Week 11 | Week 11 | Week 11 | Write-up Due | Assessed Cohort Meeting | |
| Tue 10 Nov | Assessed Cohort Meeting | Week 11 | Week 11 | Week 11 | Week 11 | Write-up Due | |
| Wed 11 Nov | Write-up Due | Week 11 | Week 11 | Week 11 | Week 11 | Week 11 |
Cohort Problems
These are the problems you should discuss in your Cohort Meeting, and everyone in your cohort should be prepared to present and discuss solutions to at the Assessed Cohort Meeting:
Cohort Problems for Week 10 [PDF]
The problems are posted here and we think its a good idea to look at them early, but you’re not expected to be able to solve them until after doing the readings and watching the videos below.
After the Assessed Cohort Meeting, your Cohort Leader will select one problem that your cohort needs to write-up and submit. The write-up is due by 11:59pm on the day after your assessed cohort meeting (see the schedule above).
Problem Set 10 Template [zip].
Reading
Chapter 9: Universality and uncomputability [PDF]
You should have already read through the Section 9.3 (but reread any parts you are confused on), and read the new Sections 9.4 and 9.5 for this week.
Videos
You can play all the videos using this playlist, but don’t forget to take breaks: Week 10 Playlist
These videos are edited from these cs3102 classes (we don't generally recommend watching the unedited versions, but they are available if you want to):
-
(Fall 2019) Class 16: Reductions: Full Video, Slides
-
(Fall 2019) Class 17: Rice’s Theorem: Full Video, Slides. (Note that we do not include the first half or so of this class in the edited videos, which presents two more examples of uncomputability proofs by reduction. If you’d like to see more examples of these kinds of problems, please watch the full video for this class.)
-
(Fall 2019) Class 18: Review for Exam 2: Full Video, Slides. We include a few example problems from this exam review lecture, that we think will be helpful to you for the cohort problems this week.
Decidable, Recognizable, Computable (7:18)
An Undecidable Problem (8:10)
Proof by Reduction (17:54)
HALTS is Undecidable (7:19)
Finite is Undecidable (11:38)
Prints3 and IsMalware Are Undecidable (5:15)
Rice's Theorem (15:28)
The following three videos are problems from the exam review, so do not introduct new material, but provide more examples of how to prove functions are computable or uncomputable. You can find the problems they cover here: Fall 2019 Exam 2 Practice Problems, and are encouraged to try to solve them yourself before watching the videos. The Natural Numbers are Computable video is about Problem 9, and the Proving Uncomputability video is about Problem 14.
Proving Computability and Noncomputability (7:57)
The Natural Numbers are Computable (2:43)
Proving Uncomputability (Busy Boas and Busier Beavers) (8:55)


CrimPapers
Articles published on 12 August 2018
On 12 August 2018, 1 new articles were published in 1 journals.
Al-Qaeda 2.0: A Critical Reader, Edited By Donald Holbrook, London, Hurst and Company, 2017, 296 Pp., £25 (paperback), Isbn<PHONE_NUMBER>101 by Paul Stott


Storage and Keydown by Drae
A floating point number
type "A" to ADD them. You make text box for I = Intergers, B = Boolean, C = Char and S = String,
...
True
False


Chapter 9 Equality Constrained Optimization
9.1 Cost Minimization Decreasing Returns
Go back to fan’s MEconTools Package, Matlab Code Examples Repository (bookdown site), or Math for Econ with Matlab Repository (bookdown site).
We have already solved the firm’s maximization problem before given decreasing return to scale: Firm Maximization Problem with Capital and Labor (Decreasing Return to Scale)
Now, Let’s solve the firm’s problem with constraints. We can divide the profit maximization problem into two parts: 1, given a desired level of output, optimize over the optimal bundle of capital and labor; 2, given the result from the first part, optimize over the quantity of outputs. Here we focus on the first part, which can be thought of as a cost minimization or profit maximization problem.
9.1.1 Profit Maximization with Constraint
Let’s now write down the firm’s cost minimization problem with the appropriate constraints, using the Cobb-Douglas production function.
We can state the problem as a profit maximization problem:
\(\displaystyle \max_{K,L} \left\lbrace p\cdot AK^{\alpha } L^{\beta } -w\cdot L-r\cdot K\right\rbrace\)
such that: \(AK^{\alpha } L^{\beta } =q\), where \(q\) is some desired level of output
We can write down the lagrangian for this problem:
- \(\displaystyle \mathcal{L}=\left\lbrace p\cdot AK^{\alpha } L^{\beta } -w\cdot L-r\cdot K\right\rbrace -\mu \cdot (AK^{\alpha } L^{\beta } -q)\)
Now, the maximization problem has three choice variables, \(L,K,\mu\), where \(\mu\) is the lagrange multiplier.
Step 1: We can plug things into matlab’s symbolic toolbox
% These are the parameters
syms p A alpha beta w r q
% These are the choice variables
syms K L m
% The Lagrangian
lagrangian = (p*A*(K^alpha)*(L^beta) - w*L - r*K) - m*(A*(K^alpha)*(L^beta) - q)
lagrangian =
1em \(\displaystyle m\,{\left(q-A\,K^{\alpha } \,L^{\beta } \right)}-L\,w-K\,r+A\,K^{\alpha } \,L^{\beta } \,p\)
Step 2: As before, we can differentiate and obtain the gradient
d_lagrangian_K = diff(lagrangian, K);
d_lagrangian_L = diff(lagrangian, L);
d_lagrangian_m = diff(lagrangian, m);
GRADIENT = [d_lagrangian_K; d_lagrangian_L; d_lagrangian_m]
GRADIENT =
1em \(\displaystyle \left(\begin{array}{c} A\,K^{\alpha -1} \,L^{\beta } \,\alpha \,p-A\,K^{\alpha -1} \,L^{\beta } \,\alpha \,m-r\\ A\,K^{\alpha } \,L^{\beta -1} \,\beta \,p-A\,K^{\alpha } \,L^{\beta -1} \,\beta \,m-w\\ q-A\,K^{\alpha } \,L^{\beta } \end{array}\right)\)
Step 3: We can solve the problem. Let’s plug in some numbers (matlab in this case is unable to solve the problem with symbols):
% Given we have many symbols, type K, L, mu at the end to let matlab know what we are solving for
GRADIENT = subs(GRADIENT, {A,p,w,r,q,alpha,beta},{1,1,1,1,2,0.3,0.7});
solu = solve(GRADIENT(1)==0, GRADIENT(2)==0, GRADIENT(3)==0, K, L, m, 'Real', true);
soluK = double(solu.K);
soluL = double(solu.L);
soluM = double(solu.m);
disp(table(soluK, soluL, soluM));
soluK soluL soluM
______ ______ ________
1.1052 2.5788 -0.84202
Step 4: What is the gradient at the optimal choices?
These are almost all exactly zero, which is what we expect, at the optimal choices, gradient should be 0. (SB P460)
gradientAtOptimum = double(subs(GRADIENT, {K,L,m}, {soluK, soluL, soluM}))
gradientAtOptimum = 3x1
1.0e+-15 *
-0.0156
0.0131
-0.1296
Step 5: What is the hessian with respect to \(K,L\) (excluding \(\mu\)) at the optimal choices?
The second derivative condition is a little bit more complicated. You can see details on P460 of SB. In practice, we find the hessian only with respect to the real choices, not the multipliers, and we check if the resulting matrix is negative definite. If it is, we have found a local maximum.
HESSIAN = [diff(GRADIENT(1), K), diff(GRADIENT(2), K);...
diff(GRADIENT(1), L), diff(GRADIENT(2), L)];
HESSIANatOptimum = double(subs(HESSIAN, {K,L,m}, {soluK, soluL, soluM}))
HESSIANatOptimum = 2x2
-0.6334 0.2714
0.2714 -0.1163
Is the Hessian Positive definite or negative definite? Let’s prove by trial and try some random vectors and use the \(xAx^{\prime }\) rule:
% An empty vector of zeros
xAxSave = zeros(1,100);
% Try 100 random xs and see what xAx equal to
for i=1:100
x = rand(1,2);
xAxSave(i) = x*HESSIANatOptimum*x';
end
% Let's see the first 5 elements:
xAxSave(1:5)
ans = 1x5
-0.0946 -0.2636 -0.3029 -0.1754 -0.0002
% OK the first 5 elements are negative, what about the rest?
% This command creates a new vector equal to FALSE (or 0) if above or equal 0, and TRUE (or 1) if below 0
is_negative = (xAxSave < 0);
is_negative(1:5)
ans = 1x5 logical array
1 1 1 1 1
% This counts how many are negative, should be 100, because this is a maximum
sum(is_negative)
ans = 100
9.1.2 Cost Minimization with Constraint
We can actually re-write the problem as a cost minimization problem, because the first term in the objective function actually is always equal to \(q\), so that does not change regardless of the choices we make, so we can take it out, and say we are minimizing the cost. So we can re-write the problem as:
\(\displaystyle \min_{K,L} \left\lbrace w\cdot L+r\cdot K\right\rbrace\)
such that: \(AK^{\alpha } L^{\beta } =q\), where \(q\) is some desired level of output
We can write down the lagrangian for this problem:
- \(\displaystyle \mathcal{L}=\left\lbrace w\cdot L+r\cdot K\right\rbrace -\mu \cdot (AK^{\alpha } L^{\beta } -q)\)
This problem looks a little different, will we get the same solution? Yes, we can call the solutions below as the solutions to the COO’s problem.
9.1.3 Cost Minimization Problem–Optimal Capital Labor Choices
Taking derivative of \(L\), \(K\) and \(\mu\) with respect to the lagrangian, and setting first order conditions to \(0\), we can derive the optimal constrained capital and labor choices using the first order conditions above, they are (they would be the same if we derived them using the constrained profit maximization problem earlier):
\(\displaystyle K^* (w,r,q)={\left(\frac{q}{A}\right)}^{\frac{1}{\alpha +\beta }} \cdot {\left\lbrack \frac{\alpha }{\beta }\cdot \frac{w}{r}\right\rbrack }^{\frac{\beta }{\alpha +\beta }}\)
\(\displaystyle L^* (w,r,q)={\left(\frac{q}{A}\right)}^{\frac{1}{\alpha +\beta }} \cdot {\left\lbrack \frac{\alpha }{\beta }\cdot \frac{w}{r}\right\rbrack }^{\frac{-\alpha }{\alpha +\beta }}\)
If you divide the optimal constrained capital and labor choice equations above, you will find the optimal ratio is the same as what we derived in the unconstrained profit maximization problem: Firm Maximization Problem with Capital and Labor (Decreasing Return to Scale):
- \(\displaystyle \frac{K^* (r,w)}{L^* (r,w)}=\frac{w}{r}\cdot \frac{\alpha }{\beta }\)
This means the constraint does not change the optimal capital and labor ratio.
9.1.4 Cost Minimization Problem–Solving on Matlab
Step 1: We can plug things into matlab’s symbolic toolbox
clear all
% These are the parameters
syms p A alpha beta w r q
% These are the choice variables
syms K L m
% The Lagrangian
lagrangianMin = (w*L + r*K) - m*(A*(K^alpha)*(L^beta) - q)
lagrangianMin =
1em \(\displaystyle K\,r+L\,w+m\,{\left(q-A\,K^{\alpha } \,L^{\beta } \right)}\)
Step 2: As before, we can differentiate and obtain the gradient
d_lagrangianMin_K = diff(lagrangianMin, K);
d_lagrangianMin_L = diff(lagrangianMin, L);
d_lagrangianMin_m = diff(lagrangianMin, m);
GRADIENT = [d_lagrangianMin_K; d_lagrangianMin_L; d_lagrangianMin_m];
disp(GRADIENT);
1em \(\displaystyle \left(\begin{array}{c} r-A\,K^{\alpha -1} \,L^{\beta } \,\alpha \,m\\ w-A\,K^{\alpha } \,L^{\beta -1} \,\beta \,m\\ q-A\,K^{\alpha } \,L^{\beta } \end{array}\right)\)
Step 3: We can solve the problem. Let’s plug in some numbers:
% Given we have many symbols, type K, L, mu at the end to let matlab know what we are solving for
GRADIENT = subs(GRADIENT, {A,p,w,r,q,alpha,beta},{1,1,1,1,2,0.3,0.7});
solu = solve(GRADIENT(1)==0, GRADIENT(2)==0, GRADIENT(3)==0, K, L, m, 'Real', true);
soluK = double(solu.K);
soluL = double(solu.L);
soluM = double(solu.m);
disp(table(soluK, soluL, soluM));
soluK soluL soluM
______ ______ _____
1.1052 2.5788 1.842
Step 4: What is the gradient at the optimal choices?
These are almost all exactly zero, which is what we expect, at the optimal choices, gradient should be 0. (SB P460)
gradientAtOptimum = double(subs(GRADIENT, {K,L,m}, {soluK, soluL, soluM}))
gradientAtOptimum = 3x1
1.0e+-15 *
0.0156
-0.0131
-0.1296
Step 5: What is the hessian with respect to \(K,L\) (excluding \(\mu\)) at the optimal choices?
The second derivative condition is a little bit more complicated. You can see details on P460 of SB. In practice, we find the hessian only with respect to the real choices, not the multipliers, and we check if the resulting matrix is positive definite. If it is, we have found a local minimum.
HESSIAN = [diff(GRADIENT(1), K), diff(GRADIENT(2), K);...
diff(GRADIENT(1), L), diff(GRADIENT(2), L)];
HESSIANatOptimum = double(subs(HESSIAN, {K,L,m}, {soluK, soluL, soluM}))
HESSIANatOptimum = 2x2
0.6334 -0.2714
-0.2714 0.1163
disp(HESSIANatOptimum);
0.6334 -0.2714
-0.2714 0.1163
Is the Hessian Positive definite or negative definite? Let’s prove by trial and try some random vectors and use the \(xAx^{\prime }\) rule:
% An empty vector of zeros
xAxSave = zeros(1,100);
% Try 100 random xs and see what xAx equal to
for i=1:100
x = rand(1,2);
xAxSave(i) = x*HESSIANatOptimum*x';
end
% Let's see the first 5 elements:
disp(xAxSave(1:5));
0.0096 0.0280 0.0142 0.0384 0.0133
% OK the first 5 elements are positive, what about the rest?
% This command creates a new vector equal to FALSE (or 0) if below or equal 0, and TRUE (or 1) if above 0
isPositive = (xAxSave > 0);
disp(isPositive(1:5));
1 1 1 1 1
% This counts how many are postiive, should be 100, because this is a minimum
disp(sum(isPositive));
100
9.2 Profit Maximization Constant Returns
Go back to fan’s MEconTools Package, Matlab Code Examples Repository (bookdown site), or Math for Econ with Matlab Repository (bookdown site).
We have already solved the firm’s maximization problem before given decreasing return to scale: Firm Maximization Problem with Capital and Labor (Decreasing Return to Scale). We have also solved the constrained profit maximization or cost minimization problem as well: Profit Maximize and Cost Minimize.
9.2.1 What is the Profit of the firm at Constrained Optimal Choices?
We derived the optimal constrained \(K\) and \(L\) equations here: Profit Maximize and Cost Minimize. The constrained profit equation given, \(p,q,w,r\), is:
- \(\displaystyle \Pi^{*\textrm{cost}\;\textrm{minimize}} (p,q,w,r)=p\cdot q-w\cdot L^* (w,r,q)-r\cdot K^* (w,r,q)\)
9.2.2 Profit Maximization and Marginal Cost
Imagine a firm is now trying to decide how much to produce, given our cost minimization problem, now rather than thinking about the firm directly choosing \(K\) and \(L\) to maximize profit, we can think of the marginal cost and marginal profit of the firm as \(q\) changes for the firm. If the firm can choose \(q\), it will want to choose the \(q\) that maximizes profit.
\[\max_q \left(p\cdot q-w\cdot L^* (w,r,q)-r\cdot K^* (w,r,q)\right)\]
The solution to this problem has to be the same as the problem we solved earlier where we directly chose \(K\) and \(L\), but now when formulated this way, we can think about the marginal cost and marginal revenue for the firm when \(q\) changes:
\(\displaystyle \textrm{MC(w,r)}=\frac{\partial (w\cdot L^* (w,r,q)+r\cdot K^* (w,r,q))}{\partial q}\)
\(\displaystyle \textrm{MR}(w,r)=p\)
Marginal revenue is of course constant at \(p\) and marginal cost is the derivative of the cost minimizing \(L\) and \(K\) choices multiplied by respective prices with respect to \(q\). Note we drived previously that these are functions of \(q\). Together with what we derived here: Firm Maximization Problem with Capital and Labor (Decreasing Return to Scale), the Cobb-Douglas Production function firm’s problem has given us on the return side: marginal productivity of capital, marginal productivity of labor, and marginal revenue. On the cost side: marginal cost of capital, marginal cost of labor, marginal cost of additional output (given cost minimization). These six marginal ideas are crucial to any firm’s problem, the specific functional forms differ depending on our production function specifications, but formulating how firms operate with these marginal ideas is at the heart of economic analysis.
9.2.3 Constant Return to Scale
In our previous exercise decreasing return to scale, Firm Maximization Problem with Capital and Labor (Decreasing Return to Scale), firms chose optimal \(K\) and \(L\) to maximize profit. We showed that the log linearized coefficient matrix is not full rank and invertible with constant return to scale, and hence firms did not have unconstrained profit maximizing \(K\) and \(L\) choices. Why is that?
Formulating the problem with marginal cost and marginal revenue helps us to understand what is going on.
It turns out that if \(\alpha +\beta =1\), that is, the firm has constant return to scale (CRS)–the elasticities of inputs sum up to 1–the cost minimizing optimal \(K\) and \(L\) choices are linear in terms of \(q\). The equations we derived in Profit Maximize and Cost Minimize, become, with CRS:
\(\displaystyle K^* (w,r,q)=q\cdot \left\lbrace \frac{1}{A}\cdot {\left\lbrack \frac{\alpha }{1-\alpha }\cdot \frac{w}{r}\right\rbrack }^{1-\alpha } \right\rbrace\)
\(\displaystyle L^* (w,r,q)=q\cdot \left\lbrace \frac{1}{A}\cdot {\left\lbrack \frac{\alpha }{1-\alpha }\cdot \frac{w}{r}\right\rbrack }^{-\alpha } \right\rbrace\)
These equations mean that the marginal cost of producing one more unit of \(q\), given CRS, is not impacted by \(q\), hence, it is a constant (determined by \(A,\alpha ,w,r\)):
- \(\displaystyle \textrm{MC(w,r)}=r\cdot \left\lbrace \frac{1}{A}\cdot {\left\lbrack \frac{\alpha }{1-\alpha }\cdot \frac{w}{r}\right\rbrack }^{1-\alpha } \right\rbrace +w\cdot \left\lbrace \frac{1}{A}\cdot {\left\lbrack \frac{\alpha }{1-\alpha }\cdot \frac{w}{r}\right\rbrack }^{-\alpha } \right\rbrace\)
With CRS, this means that if a firm makes \(q=1\), the cost would be \(\textrm{MC(w,r)}\), if the firm makes \(q=10\), the marginal cost for making the 10th good, given that the firm is cost minimizing by choosing optimal bundle of capital and labor, is just \(\textrm{MC(w,r)}\), and the total cost is also \(10\cdot \textrm{MC(w,r)}\).
9.2.4 When will the Firm produce, and what is its Profit?
With decreasing return to scale, for any prices, there will be profit maximizing \(K\) and \(L\) choices that lead to some profit maximizing output, as shown here: Firm Maximization Problem with Capital and Labor (Decreasing Return to Scale).
With CRS:
if \(p<\textrm{MC}(w,r)\), the firm does not produce, supply is perfectly inelastic
if \(p>\textrm{MC}(w,r)\), the firm produces infinity, every additional unit brings \(p-\textrm{MC(w,r)}\) unit of profit, so the firm would want to produce up to infinity
if \(p=\textrm{MC}(w,r)\). There is no profit, but there is also no loss. Households can also produce any amount, because there is nothing lost from producing.
So the firm makes a profit when: \(p>\textrm{MC}(w,r)\),
Given perfect competition, firms do not have pricing power, and take \(p\) as given, at equilibrium,\(p=\textrm{MC}(w,r)\). With CRS and perfect competition, firms will not make a profit. The fact that marginal cost is constant and profit is linear in \(q\) lead to this result. If there is monopolistic competition, there could be profits given CRS because firms would then be able to shift price as they shift quantity.
9.3 Intertemporal Utility Maximization
Go back to fan’s MEconTools Package, Matlab Code Examples Repository (bookdown site), or Math for Econ with Matlab Repository (bookdown site).
We previously solved for the unconstrained household’s savings and borrowing problem: unconstrained problem.
9.3.1 Utility Maximization over Consumption in Two Periods
Utility: \(U(c_1 ,c_2 )=\log (c_1 )+\beta \cdot \log (c_2 )\)
Budget Today: \(c_1 +b\le Z_1\)
Budget Tomorrow: \(c_2 \le b\cdot (1+r)+Z_2\)
\(c_1 >0\), \(c_2 >0\)
We have solved this problem as an unconstrained maximization problem by eliminating the consumption terms (unconstrained problem). If we keep the consumption terms but eliminatethe \(b\) term, then the problem is a constrained maximization problem with an income constraint:
- Budget Today and Tomorrow Together: \(c_2 =(Z_1 -c_1 )(1+r)+Z_2\)
Note that we have replaced the inequality symbol by an equality symbol. The income constraints are always going to bind because households will not waste income given log utility which is always increasing in consumption. This also means we don’t have to worry about the positive consumption constraints, because households will never consume at 0 since utility is not defined. We can rewrite the budget constraint as follows:
- Budget Today and Tomorrow Together: \(c_1 \cdot (1+r)+c_2 =Z_1 \cdot (1+r)+Z_2\)
Rewriting the problem as we do above has a nice interpretation. In this model, there is no production, endowment is fixed, and we allow the household to freely transfer resources from today to tomorrow and vice-versa. So in effect, we have two good that we are buying, \(c_1\) and \(c_2\). They seem to be the same good so they should have the same price, but they do not, because consumption in the first period is more expensive, since if you don’t consume in the first period, and save, you can earn interests and have higher \(c_2\). The price of \(c_1\) is hence \(1+r\). On the other hand, the price of \(c_2\) is just \(1\). The total resource available is on the right-hand-side of the equation. Your grandmother is transferring resources \(Z_1\) and \(Z_2\) to you, but the resources transfered in the first period is worth more because of the possibility of saving it. Again, we can bring the two periods together because the household is allowed to borrow and save. Given that we do not have uncertainty, our two period intertemporal problem has actually only one budget constraint. We can not do this for the problem with uncertainty.
The problem here is stated for \(c_1\) and \(c_2\), and is the intertemporal optimal choice problem. However, replace \(c_1\) by apples consumed today, \(c_2\) by bananas consumed today, and change the budget so that \(Z_1\) is the endowment from your grandmother who is an apple producer, and \(Z_2\) is the endowment from your other grandmother who is a banana producer. All solutions follow. We would replace \((1+r)\) by \(P_A\), the price of apples, and we can also add in \(P_B\) , the price of bananas. The key thing about building these models is that we can easily relabel variables and use the same framework to analyze different types of problems. For each type of problem, we could modify how the budget works, what is exactly in the utility function, but the structure of optimizing utility given budget is the same.
9.3.2 First Order Conditions of the Constrained Consumption Problem
Note again we already know the solution of this problem from: unconstrained problem. What we are doing here is to resolve the problem, but now directly for \(c_1\) and \(c_2\), rather than \(b\). But the results are the same because once you know \(b\) you know the consumption choices from the budget, and vice-versa. The solution method here is more complicated because we went from an one-choice problem in unconstrained problem to a three choice problem below. But the solution here is more general, allowing us to have addition constraints that can not be easily plugged directly into the utility function.
To solve the problem, we write down the Lagrangian, and solve a problem with three choices.
- \(\displaystyle \mathcal{L}=\log (c_1 )+\beta \cdot \log (c_2 )-\mu \left(c_1 \cdot (1+r)+c_2 -Z_1 \cdot (1+r)-Z_2 \right)\)
We have three partial derivatives of the lagrangian, and at the optimal choices, these are true:
\(\frac{\partial \mathcal{L}}{\partial c_1 }=0\), then, \(\frac{1}{c_1^{\ast } }=\mu (1+r)\)
\(\frac{\partial \mathcal{L}}{\partial c_2 }=0\), then, \(\frac{\beta }{c_2^{\ast } }=\mu\)
\(\frac{\partial \mathcal{L}}{\partial \mu }=0\), then, \(c_1^{\ast } \cdot (1+r)+c_2^{\ast } =Z_1 \cdot (1+r)+Z_2\)
9.3.3 Optimal Relative Allocations of Consumptions in the First and Second Periods
Bringing the firs two conditions together, we have:
\(\displaystyle \frac{\beta }{c_2^{\ast } }=\frac{1}{c_1^{\ast } \cdot (1+r)}\)
\(\displaystyle \frac{c_1^{\ast } }{c_2^{\ast } }=\frac{1}{\beta \cdot (1+r)}\)
\(\displaystyle c_1^{\ast } =\frac{1}{\beta \cdot (1+r)}\cdot c_2^{\ast }\)
Which tells us that the optimal ratio of consumption in the two periods is determined not by total resource available but by the interest rate \(r\) and preference for future \(\beta\). If the interest rate is higher, one will consume less today relative to tomorrow. If \(\beta\) is higher, which means we like the future more, one will also consume less today relative to tomorrow.
9.3.4 Optimal Consumption Choices
Using the third first order condition, and the optimal consumption ratio, we have:
\(\displaystyle \frac{1}{\beta \cdot (1+r)}\cdot c_2^{\ast } \cdot (1+r)+c_2^{\ast } =Z_1 \cdot (1+r)+Z_2\)
\(\displaystyle \frac{c_2^{\ast } }{\beta }+c_2^{\ast } =Z_1 \cdot (1+r)+Z_2\)
\(\displaystyle c_2^{\ast } =\frac{Z_1 \cdot (1+r)+Z_2 }{1+\frac{1}{\beta }}\)
Now we have the optimal consumption level. If endowments in either the first or second periods are higher, the household would consume more in the second period. If the interest rate is higher, the household would consume more in the second period, if \(\beta\) moves from 1 to 0, the numerator gets larger, and the optimal choice gets smaller: this means the more you dislike to future relative to today, the less you will consume in the future.
With the solution for \(c_2^{\ast }\), we also know:
\(\displaystyle c_1^{\ast } =\frac{1}{\beta \cdot (1+r)}\cdot \frac{Z_1 \cdot (1+r)+Z_2 }{1+\frac{1}{\beta }}\)
\(\displaystyle c_1^{\ast } =\frac{Z_1 +Z_2 \cdot \frac{1}{1+r}}{1+\beta }\)
This means similar to the optimal choice for \(c_2\), households will consume more if endowments are higher. Now, opposite from before, if interest rate is higher, the numerator gets smaller, and the household consume less in the first period. If \(\beta\) gets closer to 0, the household will consume more today as well.
The solutions here are Marshallian.
9.3.5 Indirect Utility
We have a special name for the utility function when it is evaluated at the optimal choices, it is called indirect utility:
- Indirect Utility function: \(U(c_1^{\ast } (r,Z_1 ,Z_2 ),c_2^{\ast } (r,Z_1 ,Z_2 ))=V^{\ast } (r,Z_1 ,Z_2 )\)
Given the solutions, we have:
\(\displaystyle V^{\ast } (r,Z_1 ,Z_2 )=\log \left(\frac{Z_1 +Z_2 \cdot \frac{1}{1+r}}{1+\beta }\right)+\beta \cdot \log \left(\frac{Z_1 \cdot (1+r)+Z_2 }{1+\frac{1}{\beta }}\right)\)
\(\displaystyle V^{\ast } (r,Z_1 ,Z_2 )=\log \left(\frac{Z_1 \cdot \left(1+r\right)+Z_2 }{\left(1+\beta \right)\cdot \left(1+r\right)}\right)+\beta \cdot \log \left(\frac{Z_1 \cdot (1+r)+Z_2 }{\left(1+\beta \right)\cdot \beta^{-1} }\right)\)
\(\displaystyle V^{\ast } (r,Z_1 ,Z_2 )=\left(1+\beta \right)\log \left(\frac{Z_1 \cdot \left(1+r\right)+Z_2 }{1+\beta }\right)+\log \left(\frac{\beta^{\beta } }{1+r}\right)\)
\(\displaystyle V^{\ast } (r,Z_1 ,Z_2 )=\log \left({\left(\frac{Z_1 \cdot \left(1+r\right)+Z_2 }{1+\beta }\right)}^{\left(1+\beta \right)} \cdot \left(\frac{\beta^{\beta } }{1+r}\right)\right)\)
9.3.6 Optimal Borrowing and Savings Choices
We can also now find the optimal borrowing and savings choice, which is, given \(c_1^{\ast } +b^{\ast } =Z_1\):
\(\displaystyle b^{\ast } =Z_1 -\frac{Z_1 +Z_2 \cdot \frac{1}{1+r}}{1+\beta }\)
\(\displaystyle b^{\ast } =\frac{\beta \cdot Z_1 -Z_2 \cdot \frac{1}{1+r}}{1+\beta }\)
You could also express the above expression as: \(b^{\ast } =\frac{\beta \cdot (1+r)\cdot Z_1 -Z_2 }{\left(1+\beta \right)\cdot \left(1+r\right)}\), which is what we obtained before from the unconstrained problem. Looking at the optimal borrowing and savings choice, we can see that sometimes the household wants to borrow, sometimes save, depending on the numerator, specifically:
\(b^{\ast } >0\) if \(\beta \cdot (1+r)>\frac{Z_2 }{Z_1 }\)
\(b^{\ast } \le 0\) if \(\beta \cdot (1+r)\le \frac{Z_2 }{Z_1 }\)
This tells us that whether a househodl borrows is dependent on the ratio of endowments: \(\frac{Z_2 }{Z_1 }\), and the discount rate multiplied by \(1+r\). The preference for future multiplied by the total return to savings must be higher than the ratio of endowment tomorrow versus today for households to want to save. In another word, suppose \(\beta \cdot (1+r)>1\), the household will be willing to save even if there is more endowment tomorrow than today.
9.3.7 Computational Solution to the Equality Constrained Problem
Matlab can solve the optimal choices for us. We can use diff and solve.
beta = 0.95;
z1 = 1;
z2 = 2;
r = 0.05;
syms r c1 c2 mu
% The Lagrangian
lagrangian = (log(c1) + beta*log(c2)) - mu*( c2 + (1+r)*c1 - z1*(1+r) - z2)
lagrangian =
1em \(\displaystyle \log \left(c_1 \right)+\frac{19\,\log \left(c_2 \right)}{20}-\mu \,{\left(c_2 -r+c_1 \,{\left(r+1\right)}-3\right)}\)
% Derivatives
d_lagrangian_c1 = diff(lagrangian, c1);
d_lagrangian_c2 = diff(lagrangian, c2);
d_lagrangian_mu = diff(lagrangian, mu);
GRADIENTmax = [d_lagrangian_c1; d_lagrangian_c2; d_lagrangian_mu]
GRADIENTmax =
1em \(\displaystyle \left(\begin{array}{c} \frac{1}{c_1 }-\mu \,{\left(r+1\right)}\\ \frac{19}{20\,c_2 }-\mu \\ r-c_2 -c_1 \,{\left(r+1\right)}+3 \end{array}\right)\)
% Given we have many symbols, type K, L, mu at the end to let matlab know what we are solving for
solu = solve(GRADIENTmax(1)==0, GRADIENTmax(2)==0, GRADIENTmax(3)==0, c1, c2, mu, 'Real', true);
soluC1 = (solu.c1)
soluC1 =
1em \(\displaystyle \frac{20\,{\left(r+3\right)}}{39\,{\left(r+1\right)}}\)
soluC2 = (solu.c2)
soluC2 =
1em \(\displaystyle \frac{19\,r}{39}+\frac{19}{13}\)
soluMu = (solu.mu)
soluMu =
1em \(\displaystyle \frac{39}{20\,{\left(r+3\right)}}\)
9.3.8 Fmincon Solution to the Constrained Problem
We can use fmincon again. What we are doing here is to explicitly solve the initially stated utility maximization problem, with both inequality constraints for consumption. This is not necessary because households would never choose consumption to be zero. Nevertheless, we can still use the fmincon set-up to solve the problem with all its constraints.
\(\displaystyle c_2 +(1+r)c_1 \le Z_1 (1+r)+Z_2\)
\(\displaystyle -c_1 <0\)
\(\displaystyle -c_2 <0\)
To useThis is a linear system, the equations above are equal to:
\(\displaystyle (1)c_2 +(1+r)c_1 \le Z_1 (1+r)+Z_2\)
\(\displaystyle (0)c_2 +(-1)c_2 <0\)
\(\displaystyle (-1)c_2 +(0)c_2 <0\)
Which mean that we have a \(A\) matrix and \(q\) vector:
- \(\displaystyle \left\lbrack \begin{array}{cc} 1 & 1+r\\ 0 & -1\\ -1 & 0 \end{array}\right\rbrack \cdot \left\lbrack \begin{array}{c} c_2 \\ c_1 \end{array}\right\rbrack \le \left\lbrack \begin{array}{c} Z_1 (1+r)+Z_2 \\ 0\\ 0 \end{array}\right\rbrack\)
Now we can set up the inputs for fmincon
% Parameters
beta = 0.90;
z1 = 1;
z2 = 2;
r = 0.05;
% Write down the objective function, we will define it as a function handle, negative utility for minimization
U_neg = @(x) -1*(log(x(2)) + beta*log(x(1)));
% Constraint derived above
A = [1,1+r;0,-1;-1,0];
q = [(z1*(1+r) + z2);0;0];
Now call fminunc to solve
c_init = [0.5,0.5]; % starting value to search for optimal choice
% U_neg_num = matlabFunction(subs(U_neg, {beta, z1, z2, r}, {beta_num, z1_num, z2_num, r_num}));
[c_opti,U_neg_at_c_opti] = fmincon(U_neg, c_init, A, q);
Local minimum found that satisfies the constraints.
Optimization completed because the objective function is non-decreasing in
feasible directions, to within the value of the optimality tolerance,
and constraints are satisfied to within the value of the constraint tolerance.
<stopping criteria details>
c2Opti = c_opti(1);
c1Opti = c_opti(2);
UatCOpti = -1*U_neg_at_c_opti;
disp(table(c1Opti, c2Opti, UatCOpti));
c1Opti c2Opti UatCOpti
______ ______ ________
1.5288 1.4447 0.75563
Note that consumption in the two periods are similar. Households generally want to smooth consumption over time given their differential endowments in each period.
9.4 Intertemporal Expenditure Minimization
Go back to fan’s MEconTools Package, Matlab Code Examples Repository (bookdown site), or Math for Econ with Matlab Repository (bookdown site).
We previously solved for the unconstrained household’s savings and borrowing problem: unconstrained problem. And also the constrained optimization problem with asset choice.
9.4.1 Utility Maximization over Consumption in Two Periods
We solved the constrained utility maximization probem already.
Utility: \(U(c_1 ,c_2 )=\log (c_1 )+\beta \cdot \log (c_2 )\)
Budget Today and Tomorrow Together: \(c_1 \cdot (1+r)+c_2 =Z_1 \cdot (1+r)+Z_2\)
We found the indirect utility given optimal choices:
clear all
% previous solution, indirect uitlity
U_at_c_opti = 0.75563;
c1_opti = 1.5288;
c2_opti = 1.4447;
% parameters
beta = 0.90;
z1 = 1;
z2 = 2;
r = 0.05;
9.4.2 The Expenditure Minimization Problem
We can represent the budget constraint and utility function (objective function) graphically. When we plug the optimal choices back into the utility function, we have the indirect utility.
- Indirect Utility function: \(V(c_1^* (r,Z_1 ,Z_2 ),c_2^* (r,Z_1 ,Z_2 ))=V(r,Z_1 ,Z_2 )\)
Note that the indirect utility is a function of the price \(r\) that households face, and the resources the have available–their income–\(Z_1 ,Z_2\). We can also write:
- \(\displaystyle V(r,Z_1 ,Z_2 )=\max_{c_1 ,c_2 } U(c_1 ,c_2 ;r,Z_1 ,Z_2 )\)
Similar to the firm’s profit maximization and cost minimization problems, which gave us similar optimality conditions, we can solve the household’s expenditure minimization problem given \(V^*\), and the optimal choices will be the same choices that gave us \(V^*\) initially. Specifically:
\[\min_{c1,c2} \left(c_2 +(1+r)c_1 \right)\]
- such that:
\[\log (c_1 )+\beta \log (c_2 )=V^{\ast } (r,Z_1 ,Z_2 )\]
9.4.3 First Order Conditions of the Constrained Consumption Problem
Note again we already know the solution of this problem from: unconstrained problem. What we are doing here is to resolve the problem, but now directly for \(c_1\) and \(c_2\), rather than \(b\). But the results are the same because once you know \(b\) you know the consumption choices from the budget, and vice-versa. The solution method here is more complicated because we went from an one-choice problem in unconstrained problem to a three choice problem below. But the solution here is more general, allowing us to have addition constraints that can not be easily plugged directly into the utility function.
To solve the problem, we write down the Lagrangian, and solve a problem with three choices.
- \(\displaystyle \mathcal{L}=c_2 +(1+r)c_1 -\mu \left(\log (c_1 )+\beta \log (c_2 )-V^* (r)\right)\)
We have three partial derivatives of the lagrangian, and at the optimal choices, these are true:
\(\frac{\partial \mathcal{L}}{\partial c_1 }=0\), then, \(\frac{\mu }{c_1^{\ast } }=(1+r)\)
\(\frac{\partial \mathcal{L}}{\partial c_2 }=0\), then, \(\frac{\beta \cdot \mu }{c_2^{\ast } }=1\)
\(\frac{\partial \mathcal{L}}{\partial \mu }=0\), then, \(\log (c_1^{\ast } )+\beta \log (c_2^{\ast } )=V^{\ast } (r,Z_1 ,Z_2 )\)
9.4.4 Optimal Relative Allocations of Consumptions in the First and Second Periods
Bringing the firs two conditions together, we have:
\(\displaystyle \frac{\beta }{c_2^{\ast } }=\frac{1}{c_1^{\ast } \cdot (1+r)}\)
\(\displaystyle \frac{c_1^{\ast } }{c_2^{\ast } }=\frac{1}{\beta \cdot (1+r)}\)
\(\displaystyle c_1^{\ast } =\frac{1}{\beta \cdot (1+r)}\cdot c_2^{\ast }\)
This is the same as for the constrained utility maximization problem: constrained utility maximization probem.
9.4.5 Optimal Expenditure Minimization Consumption Choices
Using the third first order condition, and the optimal consumption ratio, we have:
\(\displaystyle \log (\frac{1}{\beta \cdot (1+r)}\cdot c_2^{\ast } )+\beta \log (c_2^{\ast } )=V^{\ast } (r,Z_1 ,Z_2 )\)
\(\displaystyle c_2^{\ast } =\exp \left(\left(V^{\ast } (r,Z_1 ,Z_2 )+\log (\beta \cdot (1+r))\right)\cdot \frac{1}{1+\beta }\right)\)
Subsequently, we can obtain optimal expenditure minimization \(c_1\) and \(b\).
The solutions here are Hicksian, these are the dual version of the Marshallian problem from: constrained utility maximization probem
9.4.6 Compuational Solution
Solving the problem with the same parameters as before given \(V^*\), we will get the same solutions that we got above:
syms c1 c2 lambda
% The Lagrangian given U_at_c_opti found earlier
lagrangian = (c2 + (1+r)*c1 - lambda*( log(c1) + beta*log(c2) - U_at_c_opti));
% Derivatives
d_lagrangian_c1 = diff(lagrangian, c1);
d_lagrangian_c2 = diff(lagrangian, c2);
d_lagrangian_mu = diff(lagrangian, lambda);
GRADIENTmin = [d_lagrangian_c1; d_lagrangian_c2; d_lagrangian_mu]
GRADIENTmin =
1em \(\displaystyle \left(\begin{array}{c} \frac{21}{20}-\frac{\lambda }{c_1 }\\ 1-\frac{9\,\lambda }{10\,c_2 }\\ \frac{75563}{100000}-\frac{9\,\log \left(c_2 \right)}{10}-\log \left(c_1 \right) \end{array}\right)\)
solu_min = solve(GRADIENTmin(1)==0, GRADIENTmin(2)==0, GRADIENTmin(3)==0, c1, c2, lambda, 'Real', true);
soluMinC1 = double(solu_min.c1);
soluMinC2 = double(solu_min.c2);
soluMinLambda = double(solu_min.lambda);
disp(table(soluMinC1, soluMinC2, soluMinLambda));
soluMinC1 soluMinC2 soluMinLambda
_________ _________ _____________
1.5288 1.4447 1.6053
9.4.7 Graphical Representation
At a particular \(r,Z_1 ,Z_2\), we have a specific numerical value for \(V^*\). We have different bundles of \(c_1 ,c_2\) that can all achieve this particular utility level \(V^*\). We can draw these and see visually where the optimal choices are. So we have two equations that we can draw:
Budget: \((1)c_2 +(1+r)c_1 \le Z_1 (1+r)+Z_2\)
Indifference at \(V^*\): \(V^* =\log (c_1 )+\beta \log (c_2 )\), which is: \(c_2 =\exp \left(\frac{V^* -\log (c_1 )}{\beta }\right)\)
Think of \(c_1\) as the x-axis variable, and \(c_2\) as the y-axis variable, we can plot them together
% Numbers defined before, and U_at_c_opti found before
syms c1
% The Budget Line
f_budget = z1*(1+r) + z2 - (1+r)*c1;
% Indifference at V*
f_indiff = exp((U_at_c_opti-log(c1))/(beta));
% Graph
figure();
hold on;
% Main Lines
fplot(f_budget, [0, (z1 + z2/(1+r))*1.25]);
fplot(f_indiff, [0, (z1 + z2/(1+r))*1.25]);
% Endowment Point
scatter(c1_opti, c2_opti, 100, 'k', 'filled', 'd');
plot(linspace(0,c1_opti,10),ones(10,1) * c2_opti, 'k-.', 'HandleVisibility','off');
plot(ones(10,1) * c1_opti, linspace(0,c2_opti,10), 'k-.', 'HandleVisibility','off');
% Optimal Choices Point
scatter(z1, z2, 100, 'k', 's');
plot(linspace(0,z1,10),ones(10,1) * z2, 'k-.', 'HandleVisibility','off');
plot(ones(10,1) * z1, linspace(0,z2,10), 'k-.', 'HandleVisibility','off');
% Labeling
ylim([0, (z1 + z2/(1+r))*1.25])
title(['beta = ' num2str(beta) ', z1 = ' num2str(z1) ', z2 = ' num2str(z2) ', r = ' num2str(r) ' '])
xlabel('consumption today');
ylabel('consumption tomorrow');
legend({'Budget', 'Utility at Optimal Choices', 'Optimal Choice', 'Endowment Point'})
grid on;
9.5 Intertemporal Income and Substitution Effects
Go back to fan’s MEconTools Package, Matlab Code Examples Repository (bookdown site), or Math for Econ with Matlab Repository (bookdown site).
We solved previously the Marshallian Utility Maximization Problem and the Hicksian Expenditure Minimization Problem, now we solve for the effect of a change in price (relative price) on optimal choices. We decompose the effects to two ingredients, the income and substitution effects. This is the Slutsky Decomposition. The key point here is that when price changes, that has changes both the relative costs but also changes income directly and indirectly.
9.5.1 Utility Maximization over Consumption in Two Periods
We solved the constrained utility maximization probem already.
Utility: \(U(c_1 ,c_2 )=\log (c_1 )+\beta \cdot \log (c_2 )\)
Budget Today and Tomorrow Together: \(c_1 \cdot (1+r)+c_2 =Z_1 \cdot (1+r)+Z_2\)
9.5.2 Solving for the Substitution Effect
There are different definitions of the substitution effect. One way of thinking about it is that given that the change in \(r\), what would the consumption bundle be at the new prices that would give the household the same level of utility as before. To find this point, we can solve for the household’s Hicksian Expenditure Minimization Problem. But unlike before, we have to worry about two different prices, in our case two different interest rates. Our objective function uses the second interest rate, the new interest rate that we have shifted to. But the targeted utility level we are trying to achieve is based on the previous, existing interest rate.
Specifically, the difference between the solution to the problem below and the optimal choices from the Marshallian problem given the initial prices \(r_1\) represents the substitution effect. The difference betwen the solution to the problem below and the Marshallian problem given the new prices \(r_2\) represent the income effects:
- Expenditure we want to minimize given new price \(r_2\):
\[\min_{c1,c2} \left(c_2 +(1+r_2 )c_1 \right)\]
The constraint is however, a function or \(r_1\), where \(r_1\) determines the \(V^*\), we are shifting to some point along the blue dashed line:
- Constraint we need to satisfy given Indirect Utility with old price \(r_1\):
\[\log (c_1 )+\beta \log (c_2 )=V^* (r_1 )\]
The problem here is solves in terms of consumption in two periods, we can relabel consumptions in the first and second periods as consumption of Apples and Bananas in the same period. The solution method is the same. Our first order conditions are the same as when we did the Hicksian Expenditure Minimization Problem problem. The only difference is what the \(V^{\ast }\) is based on. Following our algebra before, the optimal choice from this problem above is:
\[c_2^{\ast ,\textrm{substitution}} =\exp \left(\left(V^{\ast } (r_1 ,Z_1 ,Z_2 )+\log (\beta \cdot (1+r_2 ))\right)\cdot \frac{1}{1+\beta }\right)\]
Then we can find the \(c_1^{\ast }\) choice as well. Below we show the results graphically
9.5.3 Optimal Consumption Choices with Different Interest Rates
In the following sections, we show the substitution and income effects graphically. First, we already solved the constrained utility maximization probem already, and derived the analytical solutions. Below, we solve for the numerical values directly using matlab. We could have also used our analytical solutions, and plugged in values. Sometimes, if it is possible for matlab to analytically solve an equation for you, it is perhaps better to rely on matlab to take derivatives and solve. This way, we reduce potential errors in our algebraic derivations. We often do like to derive the solution analytically by hand as we did in constrained utility maximization probem to gain more insights about how parameters impact optimal choices.
Below is our numerical solutions based on matlab’s analytical solution combined with numerical values. We provide two interest rates below, and graphically show the optimal consumption choices with corresponding budgets and indifference curves at for each interest rate.
beta = 0.90;
z1 = 0.5;
z2 = 2.5;
syms r c1 c2 mu
% The Lagrangian
lagrangian = (log(c1) + beta*log(c2)) - mu*( c2 + (1+r)*c1 - z1*(1+r) - z2);
% Given we have many symbols, type K, L, mu at the end to let matlab know what we are solving for
solu = solve(diff(lagrangian, c1)==0, diff(lagrangian, c2)==0, diff(lagrangian, mu)==0, c1, c2, mu, 'Real', true);
solu_c1 = (solu.c1);
solu_c2 = (solu.c2);
At two different interest rate levels, the optimal choices and utility at optimal choices are of course different, we can plot both out graphically following what we did before. Note that changing \(r\) directly changes both left hand side and right hand side of budget. If we were considering just apples and bananas, unless you sell apples or bananas, the price change would only impact the left-hand-side of the budget (which still lead to both income and substitution effects).
% Get Optimal Choices and Utility at Optimal Choices
syms c1
r1 = 0.05;
r2 = 1;
c1star_r1 = double(subs(solu_c1, {r}, {r1}));
c1star_r2 = double(subs(solu_c1, {r}, {r2}));
c2star_r1 = double(subs(solu_c2, {r}, {r1}));
c2star_r2 = double(subs(solu_c2, {r}, {r2}));
disp(table(c1star_r1, c1star_r2, c2star_r1, c2star_r2));
c1star_r1 c1star_r2 c2star_r1 c2star_r2
_________ _________ _________ _________
1.5163 0.92105 1.4329 1.6579
U_at_c_opti_r1 = log(c1star_r1) + beta*log(c2star_r1)
U_at_c_opti_r1 = 0.7400
U_at_c_opti_r2 = log(c1star_r2) + beta*log(c2star_r2)
U_at_c_opti_r2 = 0.3728
% The Budget Line at r1
f_budget_r1 = z1*(1+r1) + z2 - (1+r1)*c1;
% Indifference at V* at r1
f_indiff_r1 = exp((U_at_c_opti_r1-log(c1))/(beta));
% The Budget Line at r2
f_budget_r2 = z1*(1+r2) + z2 - (1+r2)*c1;
% Indifference at V* at r2
f_indiff_r2 = exp((U_at_c_opti_r2-log(c1))/(beta));
% Graph
figure();
hold on;
% r1
fplot(f_budget_r1, [0, (z1 + z2/(1+r2))*2], 'b');
fplot(f_indiff_r1, [0, (z1 + z2/(1+r2))*2], 'b--');
% r2
fplot(f_budget_r2, [0, (z1 + z2/(1+r2))*2], 'r');
fplot(f_indiff_r2, [0, (z1 + z2/(1+r2))*2], 'r--');
% optmial points
scatter(c1star_r1, c2star_r1, 100, 'b', 'filled');
scatter(c1star_r2, c2star_r2, 100, 'r', 'filled');
% Endowment Point
scatter(z1, z2, 100, 'k', 'filled', 'd');
plot(linspace(0,z1,10),ones(10,1) * z2, 'k-.', 'HandleVisibility','off');
plot(ones(10,1) * z1, linspace(0,z2,10), 'k-.', 'HandleVisibility','off');
% legends
ylim([0, (z1 + z2/(1+r2))*2])
xlabel('consumption today');
ylabel('consumption tomorrow');
legend({'Budget R1', ['Utility at Optimal Choices R1=' num2str(r1)],...
'Budget R2', ['Utility at Optimal Choices R2=' num2str(r2)],...
'Optimal Choices ar R1', 'Optimal Choices at R2', 'Endowment'})
title({['r increases from ' num2str(r1) ' to ' num2str(r2)],...
['this tilts the budget line clock-wise (c today more expensive)'],...
['this also shifts the budget line out (z today worth more)']})
grid on;
9.5.4 Graphical Illustration of the Income and Substitution Effect
Based on our solution method above, we can solve for the substitution effects and income effects. The solid red dot below is the new point we added based on the minimization problem earlier.
syms c1 c2 lambda
% The Lagrangian given U_at_c_opti found earlier
lagrangian = (c2 + (1+r2)*c1 - lambda*( log(c1) + beta*log(c2) - U_at_c_opti_r1));
% Solve
solu_min_substitution = solve(diff(lagrangian, c1)==0, diff(lagrangian, c2)==0, diff(lagrangian, lambda)==0, c1, c2, lambda, 'Real', true);
solu_min_substitution_c1 = double(solu_min_substitution.c1);
solu_min_substitution_c2 = double(solu_min_substitution.c2);
total_cost = solu_min_substitution_c2 + (1+r2)*solu_min_substitution_c1;
disp(table(solu_min_substitution_c1, solu_min_substitution_c2, total_cost));
solu_min_substitution_c1 solu_min_substitution_c2 total_cost
________________________ ________________________ __________
1.1174 2.0114 4.2463
We have found the bundle along the dashed blue line where the tangent line to the dashed blue line has the same slope as the solid red line. We can now graph this out:
% Same as before: The Budget Line at r1
f_budget_r1 = z1*(1+r1) + z2 - (1+r1)*c1;
% Same as before: Indifference at V* at r1
f_indiff_r1 = exp((U_at_c_opti_r1-log(c1))/(beta));
% Rather than plugging in z1*(1+r2) + z2, now we are pushing the red budget line out
% z1_substi*(1+r2) + z2_substi = solu_min_substitution_c2 + (1+r2)*solu_min_substitution_c1
f_budget_substitution = total_cost - (1+r2)*c1;
% Graph
figure();
hold on;
% Substitution Effect
fplot(f_budget_substitution, [0, (z1 + z2/(1+r2))*2], 'r');
scatter(solu_min_substitution_c1, solu_min_substitution_c2, 100, 'r', 'filled');
% r1
fplot(f_indiff_r1, [0, (z1 + z2/(1+r2))*2], 'b-.');
fplot(f_budget_r1, [0, (z1 + z2/(1+r2))*2], 'b-.');
fplot(f_budget_r2, [0, (z1 + z2/(1+r2))*2], 'r-.');
fplot(f_indiff_r2, [0, (z1 + z2/(1+r2))*2], 'r-.');
% legends
ylim([0, (z1 + z2/(1+r2))*2])
% optmial points
scatter(c1star_r1, c2star_r1, 100, 'b');
scatter(c1star_r2, c2star_r2, 100, 'r');
% Endowment Point
scatter(z1, z2, 100, 'k', 'filled', 'd');
plot(linspace(0,z1,10),ones(10,1) * z2, 'k-.', 'HandleVisibility','off');
plot(ones(10,1) * z1, linspace(0,z2,10), 'k-.', 'HandleVisibility','off');
% legends
ylim([0, (z1 + z2/(1+r2))*2])
xlabel('consumption today');
ylabel('consumption tomorrow');
legend({'Substitution Effect', ['Bundle with R2=' num2str(r2) ' and V*(R1=' num2str(r1) ')'] ...
'Budget R1', ['Utility at Optimal Choices R1=' num2str(r1)],...
'Budget R2', ['Utility at Optimal Choices R2=' num2str(r2)],...
'Optimal Choices ar R1', 'Optimal Choices at R2', 'Endowment'})
title({['Substitution Effect when r increases from ' num2str(r1) ' to ' num2str(r2)]...
['Blue Hollow Circle to Red Solid Circle = Substitution Effect']...
['Red Solid Circle to Red Hollow Circle = Income Effect']});
grid on;
In the graph above, the shift between the empty blue circle and the red solid circle is the substitution effect. Remaining changes between empty blue circle and red blue circle are due to income effects. Note that in this problem, the substitution effect–given higher interest rate for a household that would like to borrow due to low endowment today–is to reduce consumption today and increasing consumption tomorrow. The income effect, however, is moving both consumption today and tomorrow down.
It might be puzzling whey the income effect is shifting both \(c_1\) and \(c_2\) lower. This is because even though the higher interest rate increases the right hand side of the budget constraint, that increase in income is small relative to the effective loss in income due to the dramatically higher cost of borrowing. In another word, the dollar level of the household is higher due to higher interest rate, but the purchasing power of that wealth is significantly lower due to higher interest rate, so the higher dollar level is actually worth less in consumption units. There is a decrease in the household’s ability to purchase consumption in both periods given the increase in interest rate. Given that the household was borrowing before (notice where the endowment point is), the household is hurt by the increase in interest rate. The household now still borrows, but borrows less.
This type of problem works in the Apples and Bananas case as well. Suppose you have endowments in Apples and Bananas, when the price of apple increases, your wealth directly increases from selling your apples endowments at higher prices, but you also have to pay higher cost when you buy apple which leads to an indirect income effect and substitution effect. In general, when our endowments are in terms of goods, changing price tilts the budget constraint but the constraint still has to pass through the black endowment point. If we have just some total endowment in cash, and not in goods, meaning our endowments are not related to prices, then our budget line, given price change would tilt at the y and x intercepts.


|
Master Aiken: A group of Dwarven bandits called Magpie Brothers have abused the divine protection given to Dwarves by Maphr to rob graves within the National Cemetery. Hopefully we will soon put an end to their vandalism, though, since I recently trained the guards in Dwarven capture techniques. |
|
Learn skills |
|
Skill Enchantment |
|
Tell me about Skill Enchantment |


https://devcentral.f5.com/s/articles/powershell-abcs-j-is-for-javascript
PowerShell has the ability to integrate scripts directly into its scripting environment with it's access to the COM libraries and specifically the ScriptControl control. You can work with any language that ScriptControl supports
Generic function to insert any script. Args are language and code:
function Create-ScriptEngine()
{
param([string]$language = $null, [string]$code = $null);
if ( $language )
{
$sc = New-Object -ComObject ScriptControl;
$sc.Lanuage = $language;
if ( $code )
{
$sc.AddCode($code);
}
$sc.CodeObject;
}
}
Javascript
PS> $jscode = @"
function jslen(s)
{
return s.length;
}
"@
PS> $js = Create-ScriptEngine "JScript" $jscode;
PS> $str = "abcd";
PS> $js.jslen($str);
4
VBScript
PS> @vbcode = @"
Function vblen(ByVal s)
vblen = Len(s)
End Function
"@
PS> $vbs = Create-ScriptEngine "VBScript" $vbcode;
PS> $str = "abcd";
PS> $vbs.vblen($str);
4


0">Select only 1= 2">a contact to have ability to send a message
Please add a least 1 contact
{{errorString}}


{% comment %}{% endcomment %}
The All-NBA Team is an annual National Basketball Association (NBA) honor
bestowed on the best players in the league following every NBA season.
The team has been selected
in every season of the league's existence, dating back to its inaugural
season in 1946.
The All-NBA Team originally had two teams, but
since 1988 it is composed of three five-man lineups—a first, second,
and third team, typically comprising a total of 15 roster spots.
In particular the changes between the NBA season have been:
The voting is conducted by a panel of sportswriters and broadcasters
throughout the United States and Canada.
Players receive
The five players with the highest point totals make the first team, with the next five making the second team and so forth. In the case of a tie at the fifth position of any team, the roster is expanded. If the first team consists of six players due to a tie, the second team will still consist of five players with the potential for more expansion in the event of additional ties.


{{IISER-Pune-India/navbar}}
Smaller screens like this may not display the model viewer correctly. This works best on desktop screens.


(.) acne PTAC –.% ERC treatment tree tea *** {border-style px;} #ffffff;} study vera lesions oil patients (mean) Percentage change clinical topical used cream erythema propolis index Aloe days Placebo activity efficacy products propolis, compared effective number oil, reducing vulgaris different erythromycin natural skin ASI Figure TLC acnes anti-acne antimicrobial extracts instrumental mild moderate placebo px; using {font-family Clin Dermatol ERC, PTAC, Table days. font-size group new obtained resistance total use (%) anti-inflammatory antibacterial based containing difference double; effects eritromicin lesion papular papules plant reduction severity therapy values Acne Erythema P=.) Propionibacterium Sassari, active antibiotic baseline border-color border-width cream; data did epidermidis evaluated gel greater healthy higher mean properties results significantly solid; statistically studies study, time {font-style {font-weight Abbreviations: Clinical Efficacy Gollnick Med Microbiol P≤., Staphylococcus action bold calculated characteristics comparison considered courier; cream. demonstrated double-blind effective, em; erythematous face group, important improvement inflammatory leaf lesions. mainly oral product pt;} reported resistant scars showed shown significant tests treated treatment.


{{/* TODO: Should also see about having the images pull from GH directly during build vua URL predefined in a config */}} {{ $textHead := .Get "textHead" | default "Team" }} {{ $textSub := .Get "textSub" | default `Take a look at this amazing team and all the great work they have done!.` }}
{{ $textSub | markdownify }}
{{ .membername }}
{{ .position }}
Engineering Person
Engineer
Engineering Person
Engineer
Engineering Person
Engineer
Release Person
Release Manager
Design Person
Designer
Engineering Lead
Manager


Activate the emsdk:
Go to emsdk directory and run the commands below to activate the emsdk and prepare the environment variables
./emsdk activate latest
source ./emsdk_env.sh
Build and run the project:
Go to the project directory and run the commands below
mkdir build
cd build
emconfigure cmake ..
emmake make
Run the web server:
Go to the project "web" directory and execute the server.py
./emsdk activate latest
source ./emsdk_env.sh
Loading...
Ajax Async Test
Ajax Sync Test
https://emscripten.org/docs/api_reference/fetch.html


English
Vietnamese
KANJI GROUPED BY ONYOMI
Meaning with * — kanji is in old form
Meaning with ** — kanji is an alternative form
Show Meanings


menu
Home
Events
Register
Rules
Team
Contact
Home
Events
Register
Rules
Team
Contact
Contact Us
account_circle
Enter Name:
perm identity
Enter Roll No
phone
Phone No
turned in
Email
feedback
Type Your Query Here...
cloud
Send Message


M.Eng. Cybersecurity grad@UMD
graduated from SVNIT, Surat majoring in Computer Engineering in 2019.
worked on Preserving Location Privacy for my senior year project. read the paper.
GIAC Security Essentials Certified (GSEC)- credentials!
Associate of (ISC)2 (provisionally passed CISSP) - credentials!
Google Cloud Platform - Associate Cloud Engineer (GCP-ACE) - credentials!
Read my cybersecurity journey here on (ISC)2 blog- JOURNEY INTO CYBERSECURITY – CONVERSATIONS WITH CYBER NEWCOMERS
want to talk more, drop a hi at - mail me
not digital, need on paper? - resume


{% extends 'helpcentre-detail.html' %} {% block pageTitle %} What to do if your Linkage Key, O.D.S. Code and Account I.D. have already been used {% endblock %} {% block beforeContent %} {% endblock %} {% block content %}
If you see error code reference CID7004, this means your details have already been used to prove who you are on a different NHS login.
This can happen if you are trying to set up a new NHS login with a different email address. You can use the 3 registration details from your GP surgery’s online services just once to prove who you are on one NHS login only. Once you have used them to prove who you are, you cannot use them again on a different NHS login using a different email address.
If you want to change the email address on your NHS login you can do so in your account settings.
If you think that someone else may have used your 3 registration details to set up an NHS login, you should contact the National Service Desk for help.
Email<EMAIL_ADDRESS>Phone: 0300 303 5035
Include this reference in your email or phone call: CID7004