class Solution: def maxAverageRatio(self, classes: List[List[int]], extraStudents: int) -> float: heap = [] for i in range(len(classes)): p, t = classes[i] heapq.heappush(heap, ((p/t) -(p + 1) / (t + 1) ,t, p)) for i in range(extraStudents): _, t, p = heapq.heappop(heap) t, p = t + 1, p + 1 heapq.heappush(heap, ((p/t) -(p + 1) / (t + 1), t, p)) #print(heap) res = 0 for _, t, p in heap: res += p / t res /= len(classes) return res


Social Icons
Primary Color on Hover
Brand Color on Hover
Boxed
Boxed & Bordered
Boxed & Rounded
Boxed & Colored
Cycling
Sizes
Buttons
Use our custom button styles for actions in forms, dialogs, and more. Includes support for a handful of contextual variations, sizes, states, and more.
Round
Outline
Circular
Sizing
App Download
Alerts
Provide contextual feedback messages for typical user actions with the handful of available and flexible alert messages.
Well done! You successfully read this important alert message.
Heads up! This alert needs your attention, but it's not super important.
Warning! Better check yourself, you're not looking too good.
Oh snap! Change a few things up and try submitting again.
Dissmissable
Holy guacamole! You should check in on some of those fields below.
Form Controls
TheSaaS provides several form control styles, layout options, and custom components for creating a wide variety of forms.
Checkbox and Radio
Input groups
@
@example.com
$
.00
@
@
@
Round inputs
Transparent input
Glass input
Iconbox
Wrap your icons inside a square or round box.
Outline
Square
Colors
Pagination
Pagination links indicate a series of related content exists across multiple pages.
Pager


Use this property to provide a quick-and-dirty recommended ordering for buckets in the UI. Most UIs will likely want to forsake this for something more custom and manual.
An enum value for what items can be found in the bucket. See the BucketCategory enum for more details.
If True, this bucket is enabled. Disabled buckets may include buckets that were included for test purposes, or that were going to be used but then were abandoned but never removed from content cough.
if a FIFO bucket fills up, it will delete the oldest item from said bucket when a new item tries to be added to it. If this is FALSE, the bucket will not allow new items to be placed in it until room is made by the user manually deleting items from it. You can see an example of this with the Postmaster's bucket.
If TRUE, there is at least one Vendor that can transfer items to/from this bucket. See the DestinyVendorDefinition's acceptedItems property for more information on how transferring works.
The unique identifier for this entity. Guaranteed to be unique for the type of entity, but not globally.
When entities refer to each other in Destiny content, it is this hash that they are referring to.
The index of the entity as it was found in the investment tables.
The maximum # of item "slots" in a bucket. A slot is a given combination of item
For instance, a Weapon will always take up a single slot, and always have a quantity of 1. But a material could take up only a single slot with hundreds of quantity.
Sometimes, inventory buckets represent conceptual "locations" in the game that might not be expected. This value indicates the conceptual location of the bucket, regardless of where it is actually contained on the character/account.
See ItemLocation for details.
Note that location includes the Vault and the Postmaster (both of whom being just inventory buckets with additional actions that can be performed on them through a Vendor)
If this is true, then there is an entity with this identifier/type combination, but BNet is not yet allowed to show it. Sorry!
Where the bucket is found. 0 = Character, 1 = Account
An Inventory (be it Character or Profile level) is comprised of many Buckets. An example of a bucket is "Primary Weapons", where all of the primary weapons on a character are gathered together into a single visual element in the UI: a subset of the inventory that has a limited number of slots, and in this case also has an associated Equipment Slot for equipping an item in the bucket.
Item definitions declare what their "default" bucket is ( DestinyInventoryItemDefinition.inventory.bucketTypeHash), and Item instances will tell you which bucket they are currently residing in (DestinyItemComponent. bucketHash). You can use this information along with the DestinyInventoryBucketDefinition to show these items grouped by bucket.
You cannot transfer an item to a bucket that is not its Default without going through a Vendor's "accepted items" (DestinyVendorDefinition.acceptedItems). This is how transfer functionality like the Vault is implemented, as a feature of a Vendor. See the vendor's acceptedItems property for more details.


Add your name to the "Requesting Enlightenment" board
name:
request:
Add to List
Students seeking enlightenment:
You are currently
in line to see Calvin. Approximate wait time is
minutes
In the meantime, google your question here:


--- layout: post title: "Ed-Tech Funding Data: November 2016" date: 2016-11-30 10:35:00 +0000 tags: image: https://s3.amazonaws.com/hackedu/2016-11-30-turkey.jpg imagecredits: https://www.flickr.com/photos/thirdworld/6183493892 ---
I have updated this project with November funding information. As always, the data is freely and openly available via the GitHub repository that powers this site.
The amount of money raised in November was the lowest of any month so far this year: just $85 million. I wrote almost the same sentence last month: “October was the lowest of any month so far this year: $111 million.” I’ll repeat this one from October too: “The number of deals and the number of acquisitions were also the lowest they’ve been all year.” That is to say, VC interest in education technology waned in October, and that trend has continues to spiral downward.
This list of those ed-tech startups who’ve raised the most money this year remains unchanged from October’s update.
The total invested so far in 2016 is off significantly from this time last year. More analysis to come as I examine "The Business of Ed-Tech" next week as part of my annual year-in-review.


Deprivation of smoke can lead to curiosity, which has been said to kill cats. Fortunately, I'm not a cat.
Prompted by a longterm lack of cigarettes and weed, I decided, a few days ago, to pick some sage leaves out of an herb box out on the porch and try to smoke it. I left them on a high cabinet where they wouldn't be disturbed for a few days, actually about half a week, to dry. I would've used an oven, but I researched and found the boiling point of Thujone, the supposed active chemical in Sage, to be slightly lower than that of water.
I checked on the leaves earlier today, and by checking that one of them burned quite nicely when lit with a match I determined they were dry enough to smoke. I took two thin OCB papers and stuck them together so there would be more paper to help the plant burn, as I was unaware of how well sage burns, and I often either double-paper or spliff when I'm burning particularly moist weed. I broke up the leaves, observing quite a strong smell that made me think of minty lotion. I saved a little for later and came out with a relatively thin cigarette.
I had tried once before to smoke sage from a box in my spice cabinet, but it was finely ground into a powder and the cigarette didn't drag well. I also assume the company must've heated the plant up to dry it quicker, boiling out the water and all the Thujone.
I wasn't expecting much from my sage cigarette as I headed outside, but I figured I might as well smoke it, just to enjoy the act of smoking. I lit it and found it to burn nicely, though the double papering was a bit unnecessary and the cigarette burned somewhat quickly. The smoke had that same minty lotion taste and it stung my mouth a bit as I inhaled. My lungs are quite numb to smoke, so I'd be a poor judge of whether or not it was particularly harsh. My mindset was clear, though I was obviously bored enough to be smoking garden sage.
I began to experience a bit of light headedness, which I believe happens whenever someone inhales smoke. But, to my great surprise, I began to feel mildly inebriated. And it didn't go away. It slowly got stronger. I decided that this first cigarette had worked nicely and I'd try a second, rolling the rest of what I had, this time into just one paper. I smoked it and the effects began to kick in stronger.
The high is mild, though there was certainly a high. I felt a nice buzzy feeling inside my head, as I always do from drinking or weed. There was almost no body high. Weed has often given an effect I like to call “crazy thoughts,” or the rapid flow of ideas. Sage provided very little of that, though I was feeling quite spacey. I smoked the sage about 3 and a half hours ago and I still have a nice buzz in my head.
Overall, fresh Sage gives a nice, and I reiterate, surprisingly nice head buzz and it definitely makes me high, though it's DEFINITELY NOT weed. I did a little more research, though and found Thujone to be toxic to the liver and brain, so I would not recommend this.
Anyway, that's about it. Peace.
Experience Reports are the writings and opinions of the individual authors who submit them.
Some of the activities described are dangerous and/or illegal and none are recommended by Erowid.


--- title: Deploy a Hugo website with Netlify author: Norman Bieri date: '2020-05-11' slug: deploy-a-hugo-website-with-netlify categories: - DevOps tags: - Blogdown - GitHub - Netlify draft: TRUE ---
A static website written in Hugo ( or e.g. Jekyll, Hexo) is much easier to deploy, than websites that require dynamic server-side languages. All you need is to upload the files to a server, and usually your website will be up and running shortly. One recommend provider, considering the cost and friendliness to starter, could be Netlify (https://www.netlify.com). Just use your GitHub account to automate the upload process.
Basically, you have to host all source files of your website in a GIT repository. You do not need to put the public/
directory under version control because it will be automatically generated. Usually you have some other files that are part of the project (e.g. dockerfile, data, R) but not the website. I recommend to have a file directory download/
only for the build process of the static website.
For a new site generated by Netlify, you have to specify a command to build your website, as well as the path of the publish directory. Netlify also supports multiple versions of Hugo, you need to create an environment variable HUGO_VERSION on Netlify. See the Netlify documentation for more information. The publish directory should be public unless you have changed it in your config.toml. Figure 3.1 shows the settings of the website https://t.yihui.org. You do not have to follow the exact settings for your own website; in particular, you may need to change the value of the environment variable HUGO_VERSION to a recent version of Hugo.36
Netlify is a solution in this chapter that does not require you to prebuild your website. You only need to update the source files, push them to GitHub, and Netlify will build the website for you.
the netlify.toml file


{% extends 'components/shell.html' %} {% block content %}
If you want your account to get credit for this import, make sure you're logged in!
{% endif %}
Learn how to get your session key
Your session key is used to collect posts from your feed. After downloading missing posts, the key is immediately discarded and never stored unless you agree for it to be used for debugging by the developers. If you choose to allow your key to be used for debugging, it will be encrypted using a strong RSA key. Even if the server was compromised, your session key would be unreadable and your account would remain secure.
If you're having trouble with the importer, contact the team on {% include 'components/telegram_link.html' %}.


Day 1: Marrakech
Arrival at the Menara airport. Transfer to a hotel or riad.
Day 2: Marrakech – Aguelmame Ouiouane (1650m) (366km)
After breakfast, we depart for the Ouiouane Lake in the Middle Atlas, passing by Beni Mellal, and Khénifra. Overnight stay in a local gîte.
Day 3: Aguelmame Ouiouane
Free day for walking and exploring the beautiful area around the lake. Overnight stay in a local gîte.
Day 4: Aguelmame Ouiouane – Imouzzer-du-kandar (130km)
After breakfast we’ll take the road passing by the Ifran NP, the Cedar forests, the ski resort of Mischliffen and the Valley of Rocks to Imouzzer-du-Kandar. Overnight stay in a hotel or an appartment.
Day 5: Imouzzer-du-kandar
Today we’ll drive to the Ifrah Lake for a walk. In the area there are more “Dayets” (Lakes) such as the Dayet Aoua and the Dayet Hachlaf which we will visit depending on the time that remains. Overnight stay in Imouzzer-du-kandar.
Day 6: Imouzzer-du-kandar - Imichil (300km)
A long drive will bring us via Midelt to Imilchil. Imilchil is known for the Wedding Festival, the “Moussem des fiancailles”. The legendary tale of the Imilchil Marriage Festival is a berber Romeo and Juliet story. Overnight stay in an auberge.
Day 7: Imilchil
We will pack a picnic and go for a daywalk around the 2 beautiful lakes Isli and Tislit. Overnight stay in the auberge.
Day 8: Imilchil – Bin el Ouidane (130km)
Today we will take the road passing the Col Tizi-n’Isly and drive to the South (stopping to visit the Rock Cathedral, also called Mastfrane Cathedral) to the large and beautiful lake of the Barrage Bin el Ouidane. Overnight stay in an auberge at the lake.
Day 9: Bin el Ouidane – Ouzoud Falls - Marrakech (230km)
On the way to Marrakech we will visit the Ouzoud waterfalls. Overnight stay in a riad in the medina.
Day 10: Marrakech
Got to catch that airplane!


[Hide]
QuoteEntryID (299)
Unique identifier for a quote. The QuoteEntryID stays with the quote as a static identifier even if the quote is updated.
Type: String
Used in Messages:
Used in Components:
[QuotEntryGrp]
[QuotEntryAckGrp]


Clean carbon nanotubes with superb properties
| Source: | Aalto University |
| Summary: | Scientists have found a new way to make ultra-clean carbon nanotube transistors with superior semiconducting properties. |
Single-wall carbon nanotubes (SWCNT) have found many uses in electronics and new touch screen devices. Carbon nanotubes are sheets of one atom-thick layer of graphene rolled up seamlessly into different sizes and shapes. To be able to use them in commercial products like transparent transistors for phone screens, researchers need to be able to easily test nanotubes for their materials properties, and the new method helps with this.
Professor Esko I. Kauppinen's group at Aalto has years of experience in making carbon nanotubes for electronic applications. The team's unique method uses aerosols of metal catalysts and gasses containing carbon. This aerosol-based method allows the researchers to carefully control the nanotube structure directly.
Fabricating single carbon nanotube transistors is usually tedious. It often takes days from raw carbon nanotube material to transistors, and the devices were contaminated with processing chemicals, degrading their performance. However the new method makes it possible to fabricate hundreds of individual carbon nanotube devices within 3 hours, an over ten times increase in efficiency.
Most importantly, these fabricated devices do not contain degrading processing chemicals on their surface. These so-called ultra-clean devices have been previously even more difficult to manufacture than regular single carbon nanotube transistors.
'These clean devices help us to measure the intrinsic material properties. And the large number of devices helps to get a more systematic understanding of the nanomaterials, rather than just a few data points.' says Dr. Nan Wei, a postdoctoral researcher in the group.
This study shows the aerosol-based nanotubes are superb in terms of their electronic quality, their ability to conduct electricity is almost as good as theoretically possible for SWCNTs.
More importantly, the new method can also contribute to applied research. One example is that by studying the conducting property of SWCNT bundle transistors, scientists may find ways to improve performance of flexible conductive films. This could prove useful for designers trying to build flexible, smash-proof phones. Follow-up work by the groups in Japan and Finland is already underway.
make a difference: sponsored opportunity
Story Source:
Materials provided by Aalto University.
Note: Content may be edited for style and length.
Journal Reference:
- Nan Wei, Patrik Laiho, Abu Taher Khan, Aqeel Hussain, Alina Lyuleeva, Saeed Ahmed, Qiang Zhang, Yongping Liao, Ying Tian, Er‐Xiong Ding, Yutaka Ohno, Esko I. Kauppinen. Fast and Ultraclean Approach for Measuring the Transport Properties of Carbon Nanotubes. Advanced Functional Materials, 2019; 1907150 DOI: 10.1002/adfm.201907150
Cite This Page:
| MLA | Aalto University. "Clean carbon nanotubes with superb properties." ScienceDaily. ScienceDaily, 19 November 2019. <www.sciencedaily.com/releases/2019/11/191119105530.htm>. |
| APA | Aalto University. (2019, November 19). Clean carbon nanotubes with superb properties. ScienceDaily. Retrieved November 19, 2019 from www.sciencedaily.com/releases/2019/11/191119105530.htm |
| Chicago | Aalto University. "Clean carbon nanotubes with superb properties." ScienceDaily. www.sciencedaily.com/releases/2019/11/191119105530.htm (accessed November 19, 2019). |


Choose Your Bean: House Blend Shade Brown Organic Guatemala Kenya
Type: Whole Bean Ground
Extras: Gift Wrap Include Catalog with Order
Ship to Name: Address: City: State: Zip: Customer Comment:


Significant changes were made in the SML module system in SML '97. The motivations for this change were to simplify the semantics of the module system, mainly by weakening the notion of structure sharing, and to improve the expressiveness of signatures by adding definitional type specifications. The addition of definitional type specifications is accompanied with new restrictions on type sharing specs. In many cases where type sharing specs would have been used in SML '90, in SML '97 it is necessary, or perhaps just better style, to use definitional type specifications. In SML '97, structures do not have unique, checkable static identities, and structure sharing is viewed as an abbreviation for implied type sharing. The lack of a structure level equivalent of definitional type specs was soon found to be awkward, and SML/NJ has implemented this useful feature ( Section 1.6.2).
1.3.1. Type abbreviations in signatures
SML '97 Definition, Section G.1.
It has long been realized that the original signature language of SML '90 was not expressive enough for some purposes. In particular, it was not possible in general to indicate both the existence and the definition of a type component in a specification. In special cases, one could use a definitional type sharing specification, as in
signature S = sig type t sharing type t = int endbut this would not work ift
's definition was a type expression likeint list
. So in SML '97 the definition of type specification is extended to allow specifications of the form:type tyvarseq tycon = tyWe call such a specification a definitional spec (also sometimes referred to as type abbreviation spec). Using this sort of specification, we can rewrite the above signature more neatly as follows:signature S = sig type t = int list endAllowing type definition specs in signatures makes it possible to write a signature that more fully captures or constrains the type information in a structure. It also makes it more practical to use the opaque form of signature matching described below (Section 1.3.9), because one has more control over which exported types are abstract (opaque) and which are concrete (transparent).Type definition specs were introduced in SML/NJ starting with version 0.93, and they have also been supported in Caml Special Light and Ocaml(?). The main improvement made in SML '97 is to reduce confusing interactions between type definition specs and type sharing specs by placing new restrictions on type sharing specs. We restrict the types that can appear in a sharing spec to those specified within the current signature (Section 1.3.4), and we ban definitional sharing specs (Section 1.3.5). We also increase the usefulness of definitional specs by using the "
where type
" syntax to attach definitions to previously defined signatures (Section 1.3.3). The resulting design gives us more expressive power than SML '90.The motivations for introducing type definition specs also apply to structure specs. In SML '90 programs we often use definitional structure sharing specs, bug this form of sharing spec is not allowed is SML '97. Clearly a structure analogue of type definition specs would be a convenient replacement, but unfortunately SML '97 does not provide them. So SML/NJ fills this gap, as described below in the section on structure definition specs (Section 1.6.2).
1.3.2. Datatype replication specs
Datatype replication declarations were described in Section 1.1.5. An analogous datatype replication specification form has been provided for signatures, and it has the same syntax as the declarations:
datatype tycon = datatype longtyconDatatype replication specs serve the same purpose for datatype specs as definitional type specs do for simple type specs, and we use the term definitional specifications to cover these two forms. Here is an examplestructure A = struct datatype 'a t = C | D of 'a * 'a t end signature S = sig datatype t = datatype A.t endNote that even thoughA.t
(and hencet
) is a unary type constructor, we do not include formal type variable parameters in the datatype replication spec. The effect of this spec is to define type componentt
to be the same asA.t
, and in addition it implicitly specifies the data constructorsC
andD
associated withA.t
. Thus in a functor declaration such asfunctor F(X: S) : sig val f : 'a X.t -> 'a A.t end = struct fun f(X.C) = X.C | f(X.D(x,y)) = A.D(x,X.D(x,y)) endit is guaranteed thatX.t
andA.t
are the same type andA.D
andX.D
are the same data constructor.As explained below in Section 1.3.6, one of the main uses of datatype replication specs is to substitute for definitional sharing constraints, which are no longer allowed.
1.3.3. Modifying signatures with
where type
Sometimes it's "too late" to use a definitional type spec when we need one. By this I am refering to cases where the type we would like to define is specified in a signature that has already been declared, perhaps in a library. For example, suppose
S1
is a large signature with a simple specification of typet
:signature S1 = sig type t ... (* twenty other specifications *) endLater we want to useS1
, but we want to specify in addition thatt
isint list
).One could insert
S1
's defining signature expression in place ofS1
, modified with the appropriate definition oft
, but this is obviously undesirable whenS1
is a large signature. SML '97 provides another solution to this problem in the form of thewhere type
definition. It modifies an existing signature by adding a definition of one of it's types. In our example, we would use it as follows:signature S2 = sig structure A : S1 where type t = int list endHere thewhere type
definition modifies or augments the signatureS1
, andS1 where type A.t = int
is a new form of signature expression. Withwhere type
we are able to express things that we couldn't express before with definitional sharing constraints, likesignature S2 = sig structure A : S1 where type t = int list endWe can even usewhere type
clauses in cases where the type to be defined is buried inside a substructure, as in the following examplesignature U = sig structure A : S1 ... end signature S2 = sig structure B : U where type A.t = int list endNote that here the left hand side of thewhere type
clause is a symbolic pathA.t
(a longtycon in the Definition's terminology), and the effect is to augment the specification oft
inS1
.Datatypes defined by where clauses. The type defined by a
where type
clause can be one that was specified as a datatype.structure A = struct datatype 'a t = C | D of 'a * 'a t end signature S = sig datatype 'a t = C | D of 'a * 'a t end signature U = S where type 'a t = 'a A.tIn this example, thewhere type
is equivalent to an embedded datatype replication spec, so signatureU
could equivalently have been defined assignature U = sig datatype t = datatype A.t endTechnically, the Definition is rather lenient about consistency between the affected primary specification and its definition in a where clause. For instance, the following signature declaration is legal,signature S = sig datatype t = T end where type t = intthough such a signature cannot be realized because the base specification oft
and its definition in the where clause are not consistent. A compiler might check for such obvious inconsistencies (but SML/NJ does not).Context of right hand side of where definition. The type expression on the right hand side of a
where type
definition cannot mention types that are specified in the signature it modifies. So the following example is illegal (assuming no typet
is defined in the context of this declaration).signature S = sig type s type t end where type s = tThe reason for this restriction is that we want to avoid examples like the followingsignature S = sig type s structure A : sig type t val x : s * t end end signature U = S where type s = A.t * A.tIf theA.t
on the right hand side of thewhere type
clause refers to the type specified inside the signatureS
, then we will have created a kind of undesirable circular dependency, where types
depends on the substructureA
because of the where definition, whileA
depends ons
becauses
is mentioned inA
's signature.We would like to be able to replace any signature definition using the
where type
construct by an equivalent definition that replaces the where definitions with type abbreviation specs and datatype replication specs. It is clear that the signatureU
in the last example could not be expressed without thewhere type
clause under this interpretation of the context of the clause's right hand side. This is why we exclude the body of the modified signature from the context of the right hand side and thereby make this example illegal.
SML/NJ Discrepancy: The natural way of thinking of thewhere type
construct is that is is a way of introducing type abbreviation specs (or datatype replication specs) into a previously defined signature, thereby producing an augmented version of that signature. It should in principle be possible to equivalently define that augmented signature with the definitions placed directly at the points of specification of the affected types. This is in fact how SML/NJ implementswhere type
definitions. Thussignature S = sig type t end where type t = intis tranformed by the compiler into the declarationsignature S = sig type t = int endThus treating type abbreviation specs as the primary construct and definingwhere type
in terms of it.However, for technical reasons the Definition does things backward, treating
where type
as a primary notion and defining type abbreviation specs (but not datatype replication specs) in terms ofwhere type
andinclude
. Thus in the Definition,signature S = sig type t = int endis translated intosignature S = sig include sig type t end where type t = int endFor the most part, this difference in approaches does not matter. The Definition's version admits more signatures as legal, but we argue that they are not signatures that good programmers would want to write. Here is an example of a legal signature that is not accepted by SML/NJ (due to Marin Elsman, see SML/NJ bug 1330):signature S = sig type s structure U : sig type 'a t type u = (int * real) t end where type 'a t = s end where type U.u = intWe leave it as an exercise for diligent language lawyers to verify that this is acceptible under the definition, but it is pretty clearly not the sort of thing we want to encourage programmers to write. Determining whether this signature makes sense is an exercise in setting up a system of equations in higher-order variables (s
,u
, andt
) and then seeking a solution of that system. We would prefer that the sensibility of a signature definition should be more obvious.One particular reason why this signature declaration is not accepted by SML/NJ is that SML/NJ does not allow a
where type
definition to apply to a type constructor that already has a definitional specification. A simpler example of a signature that is rejected for this reason is:signature S = sig type s type t = s end where type t = intA more sensible way to write this would besignature S = sig type s type t = s end where type s = intwhich is acceptible to SML/NJ.1.3.4. Restriction of sharing to local paths
In SML '90, a sharing specification is an independent specification in a signature, but in SML '97, sharing specifications modify the specifications (a sequencial spec) that they follow textually in the signature. The components mentioned in the sharing constraint must all come from the specifications modified by the sharing constraint. Thus, in
[1] signature S = [2] sig [3] type s [4] structure A : sig [5] type t [6] type u [7] sharing type t = u [8] sharing type t = s [9] end [10] endthe sharing constraint in line [7] applies to the preceding specs in lines [5] and [6], and is legal because the type namest
andu
mentioned in the sharing constraint are bound in those specs. The sharing constraint at line [8], on the other hand, is not legal, because its "scope" consists of lines [5-7], while it mentions the types
bound lin line [3]. The same rule applies to structure sharing constraints.This scope restriction on sharing constraints is the main reason why sharing constraints may need to be converted into definitional specs or
where
definitions. The declaration ofS
above can be rewritten as the following legal SML '97 declaration.[1] signature S = [2] sig [3] type s [4] structure A : sig [5] type t = s [6] type u = t [7] end [8] endIt can also be legally rewritten (according to the Definition) as[1] signature S = [2] sig [3] type s [4] structure A : sig [5] type t = s [6] type u [7] sharing type t = u [8] end [9] endbut this version raises a delicate and controversial point. Notice that the typet
is defined in its specification at line [5], and it is further constrained by the sharing constraint at line [7].1.3.5. Noninterference of sharing and definitional specs
In SML '90, there were two flavors of type sharing, one where both types involved are "formal" or unknown, which we call coherence sharing, and the other sort, where one type is unknown and the other is known, which we call definitional sharing. Here is a typical example of coherence sharing:
signature S = sig type t type s sharing type t = s endIn this case, neithert
nors
is determined, but the sharing spec requires that when they are instantiated, they are both instantiated to the same type.A simple example of definitional sharing is:
signature S = sig type t sharing type t = int endwhere typet
is effectively defined to be equal toint
by the sharing constraint.In SML '97, it is possible to define a type directly, in its original specification, or after the fact, using the "where type" syntax, so definitional sharing seems redundant. Furthermore, the interaction between definitional sharing and direct definition could create puzzles, such as the following:
signature S = sig type s type t = s list type 'a u type v = int u sharing type t = v endHere, typest
andv
are defined directly in terms of the formal typess
andu
, and then they are equated by the sharing specification. If we wanted to determine whether this signature is satisfiable, we would have to see whether types s and u exist that satisfy the equations list = int uSolving such second-order equations is a messy problem in general, perhaps unsolvable. To solve this problem, the SML '97 design excludes such examples by outlawing definitional sharing. In other words, the types involved in a sharing specification are required to be formal or "flexible".Technically, the Definition requires that a type constructor involved in a sharing constraint be (1) not defined as a type function, and (2) not defined in terms of some "rigid" type constructor (i.e. a type constructor previously defined in the context).
We choose to define "sharable" as meaning simply that there is no definition applying to a type constructor. We'll use the term "defined" for the opposite of sharable. A more subtle definition is possible; see note "Sharable Types" below.
Thus the following signature is illegal
signature S = sig type s = int (* s is defined *) type t (* t is sharable *) sharing type t = s (* s is not sharable *) endand has to be reexpressed as (for instance):signature S = sig type s = int type t = s endWith "where type" definitions, things are a little more complicated. An inner type sharing constraint can be affected by an outer definitional constraint, as in the following example:signature S1 = sig type s type t sharing type t = s (* ok, because s and t are sharable here *) end where type t = int; (* this converts both s and t to rigid types *)This is legal, but the following declaration is not:signature S2 = sig structure A : S1 type v sharing type v = A.s (* A.s not flexible *) end;However, S2 can easily be converted to the legal S3 below by replacing the outer sharing constraint by a definition.signature S3 = sig structure A : S1 type v = A.s end;In general, we recommend avoiding sharing constraints that can easily be expressed by definitional specs. So one should always prefertype t = stotype t sharing type t = s.The same applies to structure sharing and structure definition specs (which are an SML/NJ language extension). Violations of this newly enforced constraint can often be eliminated by replacing structure sharing by structure definition specs, e.g. replacingstructure A : SIGA sharing A = B.Cwithstructure A : SIGA = B.C.<IP_ADDRESS> SML/NJ Exception for Structure Sharing with Same Signature
SML/NJ provides one important exception to the rule about sharing rigid types. This is the case where the type sharing is implied by structure sharing between two structures with the same signature.
Here is an example
signature S = sig type t = int end signature S1 = sig structure A : S structure B : S sharing A = B endThis is allowed in SML/NJ because A and B have the same signature, even though the sharing constraint is equivalent tosharing type A.t = B.tand A.t and B.t have the rigid spectype t = int.<IP_ADDRESS> What Types Are Sharable [Mostly for language lawyers]
There is some controversy about what type constructors should be allowed in sharing constraints. We can illustrate this by the following example
signature S = sig type s type t = s type u sharing type t = u endBy our definition above,t
is defined, and therefore not sharable, and this signature declaration is rejected. Technically, however, the semantic representation oft
in the signature is the type function\().(()ns)
(a nullary type function, wherens
is the semantic type "name" fors
), and this type function is eta-equivalent tons
, a simple flexible type name. Therefore, if this eta-reduction is assumed,t
meets the requirements of the definition and can appear in the sharing constraint. On the other hand, considersignature S = sig type s type t = s list type u sharing type t = u endHere the representation oft
is the type function\().(()ns) list
, which does not reduce to a simple type name, so the sharing constraint is clearly illegal. The reasons that we adopt the simpler and more restrictive meaning of sharable are that it is easier to explain and it admits all sensible usages. We claim that it promotes a cleaner and simpler style in signature writing. It is also much simpler more efficient to implement (at least for SML/NJ). Here are some example signatures that are admitted under the more complicated version of the definition (thanks to Martin Elsman of DIKU):signature S1 = sig type t type s = t end where type s = int signature S2 = sig type t type s = t sharing type t = s end signature S3 = sig type s structure U : sig type 'a t type u = (int * real) t end where type 'a t = s end where type U.u = intIt is not clear that examples like these have any importance to anyone other than language lawyers. The last is particularly perverse: reading a signature should not be an exercise in puzzle solving!1.3.6. Replacement of "definitional" sharing by definitional specs
We used to be able to use a definitional sharing specification, as illustrated by:
signature S2 = sig structure A : S1 sharing type A.t = int endBut this sharing is no loner legal, becauseint
is not a path local to the body ofS2
. There are situations where you have a choice of using sharing specifications or type definition specs orwhere type
clauses. For instance, the following three declarations of signatureS
are equivalent:signature T = sig type s end signature S = sig type t structure A : T sharing type t = A.s end signature S = sig type t structure A : sig type s = t end (* expanding T *) end signature S = sig type t structure A : T where type s = t endThis last example might suggest that one could always replace type sharing specs with type definition specs orwhere type
clauses, but this is not quite the case, as shown by the following example:signature S = sig type s structure A : sig datatype d = D of s datatype t = K end sharing type s = A.t endThere is no way to rearrange the definition of the signatureS
so that the sharing spec can be replaced by a definition. However, this example is rather contrived, and it is not clear that there would be any serious practical impact if we gave up the ability to write such signatures and uniformly used definitional specs in place of sharing.The
where type
construct can also be used to define types specified as datatypes in the base signature, and this makes it related to the datatype replication specs described below. Here is an example.structure A = struct datatype t = T end signature S = sig datatype t = T end signature S1 = S where type t = A.tThis capability to define a datatype spec is needed in order to replace definitional sharing constraints like in the following example:signature S = sig datatype t = T sharing type t = A.t endThe definition in this case does not require a check that the datatype "signature" of the spec and its definition in thewhere type
clause have to agree, but a compiler could perform some level of checking. It might at least check that the type on the right hand side of the definition is also a datatype, and beyond that it might check that the number and names of data constructors agree.1.3.7. Structure sharing as derived form for type sharing
In SML '97, structure sharing has been weakened from a first-class feature to a derived syntax feature, i.e. a feature that is explained in terms of translation to type sharing syntax. This is a real weakening of the expressiveness of the module system. In SML '90, where each structure had a unique static identity and structure sharing could be checked statically, one could use structure sharing to guarantee not only that types in two structures agreed, but that the values making up the associated interface to those types were also shared. For instance, if two structures
A
andB
have the signatureORD
defined belowsignature ORD = sig type t val comp : t * t -> t endthe sharing specificationsharing A = Bguarantees not only that the typesA.t
andB.t
are the same but that the comparison operationsA.comp
andB.comp
were the same, i.e. thatA
andB
implement the same ordering over the same type.In SML '97, we can still write such sharing specification, but they are viewed as abbreviations for all possible implied type sharing specs. In this case, the above structure sharing spec translates to the following type sharing spec:
sharing type A.t = B.tThis does not imply that the comparison operators A.comp and B.comp agree, so it is strictly weaker than the structure sharing spec in SML '90.One can recover something like the old structure sharing functionality when the structures in question contain a (generative) type that is used to uniquely identify the structure. In effect, the type is used as a unique tag to guarantee identity of the structure as a whole. This works if there is no "cheating", i.e. if no other independently defined structure incorporates this same tagging type.
Another thing to note about the weak version of structure sharing is that it is not transitive. For instance
sharing A = B and B = Cdoes not necessarily imply thatsharing A = Cis satisfied. Here is an examplesignature S0 = sig type t end signature S = sig structure A : S0 structure B : sig end structure C : S0 sharing A = B and B = C endSince structureB
has no type components, the sharing equationsA = B
andB = C
are vacuous, and translate into no type sharing at all. In particular, they do not guarantee thatA.t = C.t
, and therefore do not imply the sharing constraintA = C
.The paths appearing is structure sharing specs must also satisfy the locality restriction described in Section 1.3.4. That is, the structures that are specified to share must all be components (or subcomponents) of the same signature that contains the sharing spec. This will guarantee that the type sharing specs that the structure sharing translates into will satisfy the locality constraint for type sharing.
This locality rule will generally preclude "definitional structure sharing specs", which are used fairly frequently in SML '90. How should we rewrite such definitional structure sharing specs? One approach is to expand the structure sharing into the corresponding set of type sharing specs, and then replace the definitional type sharing specs with the appropriate "where type" definitions. For example, given a structure A defined as follows:
structure A = struct datatype t = T endthe SML '90 signaturesignature S = sig structure B : sig type t end sharing B = A endcan be rewritten assignature S = sig structure B : sig type t end where type t = A.t endOf course, if there were a dozen types involved in A rather than just one, this can lead to an unpleasant expansion of the code. For this reason, it would have been desirable to have a structure analogue of definitional specs, so that we could write something like:signature S = sig structure B : sig type t end = A endSuch definitional structure specs are in fact supported in SML/NJ; see Section <IP_ADDRESS>.3.8.
include sigexp
The syntax of the
include
spec has been generalized to allow arbitrary signature expressions as well as signature names. The purpose of this extension is to allow definitional type specs to be defined in terms ofinclude
andwhere type as a derived form. Thus
type t = tyis supposed to be an abbreviation forinclude sig type t end where type t = tyThis seems somewhat convoluted, since the simple type definition spec seems to be a more elementary concept in its own right, but this approach was chosen because of technical convenience in the Definition. There is a technical problem with treating simple definitional specs as the primitive construct and definingwhere type
via a syntactic translation into definitional specs, and that is the issue of free variable capture. For instance, in the following signature definition the typeu
appearing in thewhere type
clause is different from the typeu
specified in the body ofS
.signature S = sig type u type t end where type t = u * uIf we were to eliminate thewhere type
clause in the following definition by textually moving the definition inward to the point wheret
is specified, we would have signature S = sig type u type t = u * u end which is clearly incorrect, because the free occurences ofu
in the definition oft
have been captured by the local binding ofu
. So though this approach to eliminatingwhere type
can work at the level of semantic structures, it doesn't work as a textual transformation (i.e. as a derived form).1.3.9. opaque signature matching
:>
Previous versions of SML/NJ supported a special structure declaration form
abstraction S : SIG = struct ... endwhose purpose was to create an "abstract" instance of the signatureSIG
. This feature was left out of SML '90 for various reasons, but the need for it was real.In SML '97, a similar feature has been provided in the form of "opaque" signature matching using the special signature constraint syntax
S :> SIG
. For example, the following declaration has the same effect as the old "abstraction" declaration given above.structure S :> SIG = struct ... endThe effect of opaque signature matching is that the formal or flexible types in the signature SIG get fresh, abstract instantiations that are distinct from the corresponding types in the structure expression being constrained. Here is a more detailed example:signature SIG = sig type s type t = int val zero : s val succ : s -> s val f : s -> t end strucutre Transp : SIG = struct type s = int type t = int val zero = 0 fun succ x = x+1 fun f x = x end strucutre Opaque :> SIG = struct type s = int type t = int val zero = 0 fun succ x = x+1 fun f x = x endBecause of the normal transparent signature matching, Transp.s is equivalent toint
, as is Transp.t. But in the case ofOpaque
,Opaque.t
is still equivalent toint
, because of the definition in the signature, butOpaque.s
is a new abstract type that is different fromint
.There are two places where it may make sense to use opaque signature matching. First in a normal structure declaration as in the above examples, and second in specifying the result signature of a functor.
functor F(X: PSIG) :> SIG = struct ... endWhen a functor is defined with an opaque result signature like this, each time the functor is applied a new abstract instantiation of the result signature is created.It does not make sense to use the opaque signature matching form for the formal parameter of a functor (i.e. on the input side as opposed to the output side).
1.3.10. equality type specs, inferred equality properties
1.3.11. open and local specification forms deleted
The Definition of SML '90 had two special forms of specification that could be used in signatures:
local...in..end
andopen. These forms, particularly local specs, were introduced for technical reasons within the definition. These specification forms have both been dropped in SML '97. These features were controversial in SML '90, because when used in full generality their behavior had no clear intuitive justification, despite their having a precise technical meaning and a technical role in the Definition's semantics. The utility of these features was also dubious, except for one special restricted case, where open and local were combinded to allow the abbreviation of type paths in specifications. For example:
structure A = struct type t = int end; signature S = sig local open A in val x : t end end;Here theopen A
specification allowsA.t
to be abbreviated tot
, while thelocal
form prevents the components ofA
from being added toS
as specifications. So this definition of signatureS
is equivalent to writingsignature S = sig val x : A.t end;In SML/NJ, local and open were never fully implemented according to the SML '90 Definition, but they were partially implemented to support just the above path abbreviation idiom. In fact, the open form was implemented so that it could be used for abbreviational effect even without the surrounding local spec. Thus in SML/NJ 0.93 it was possible to write simply
signature S = sig open A val x : t end;with the same effect.Since these forms have been dropped in SML '97, when converting SML '90 (or SML/NJ 0.93) code it is necessary to find and eliminate uses of local and open in signatures and write out the full type paths for those types which were thereby abbreviated.
Any (non SML/NJ) code that uses local specs in their full generality to achieve some strange effect will have to be rewritten to achieve the desired effect some other way [dbm: I would be interested in seeing examples of this].
1.3.12. no repeated specifications of an identifier
1.3.13. behavior of include (Defn vs SML/NJ)


Home
1
2
The cults are crazy
Yes, I'm using my free time to imagine random cults and apply styles to them
I have fun, okay?
Okay!!?
I hope you have fun too


Programming languages such C and Perl that use format string functions
Programming languages such C and Perl use string functions, like printf(), that allow users to pass a format for the input string. Attackers can manipulate the input parameters passed to these functions to make the function work differently. Attackers can use format string bugs to overwrite parts of the stack, corrupt memory, and crash the system. They can use this vulnerability to execute different kind of attacks such as elevation of privileges, authentication bypass, information disclosure, and denial of services.
Note that since Perl is interpreted, it doesn't suffer from all the problems present in C. In C the attacker can get execution control of the program similar to buffer overrun attacks. In Perl, on the other hand, the most common attacks are denial of service due to resource consumption, information disclosure, and unwanted modification of variables.
Below is a summary of steps needed for testing for format string bugs
Step 1: Understand Attack Scenarios
To realize a format string attack the attacker needs to find a vulnerable format string function and gain control of its input. A common attack will look like the following:
A common format string bug looks like this:
int func (char * buffer) { printf(buffer); return 0; }
The programming error is to not use printf("%s", buffer). The attacker can exploit the code above by adding format specifiers to input variable. If the buffer contains the "%n" string the application is very likely to crash. Using this string an attacker can start a denial of service attack.
Functions that copy a string to another like sprint() are even more dangerous. For instance, below the first sprint copies input to buffer setting allowing maximum eight characters to be copied:
void func(char * input) { char buffer[16]; char message[16]; sprintf (buffer, "Name: %.8s", input); sprintf (message, buffer); printf(message); }
If an attacker feeds a large string of A's then the message is properly managed:
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
outputs the following string:
"Name: AAAAAAAA"
But when the attacker inserts format string characters to the input string the result is a buffer overrun:
"%.30dAAAAAAAAAAAAAAA"
The %.30d allocates a thirty character string and then appends A's at the end of it. When doing the second copy, the buffer overruns the message and EIP ends of being x41414141. This bug can be used to gain control of the application's execution and run arbitrary code.
"%.30d<payload code>"
Inside of the payload code placeholder in the above, the attacker can insert executable code to run malicious commands that execute with the privileges of the attacked program, similar to buffer overflow attacks. These commands can include installing a Trojan, opening a remote shell, and propagating a worm, among others.
Format string bugs can also lead to information disclosure attacks as when the getting debug information using the %x tag or to execute repudiation attacks.
Step 2: List High Risk Components and Entry Points
Identify high risk components
The next step in format string vulnerability testing is to identify all uses of the family of format string API's. When having access to the code, this task can be done as a quick code review or using string searches over the source code directories. If no access to the code is given, then use black box approaches such as API monitoring, network sniffing, and debugging to isolate the binary components or design modules that use these functions.
The following C functions are vulnerable to this bug:
Win32 also provides a set of replacement printf() functions such as:
Perl is also vulnerable to format strings through these functions in particular
Note: This list doesn't contain all format string functions. There are many more functions that take a format string as an argument, including a large number of functions who's primary purpose is something separate, even though they still invoke a sprintf-like function along the way. Always check the latest programming library documentation for your platform to properly cover all format strings issues. Different versions of C (Unix vs. Microsoft for instance) have different format string functions. Make sure to look at the documentation for all variants of format string manipulation functions.
Match high risk components with entry points
After listing all the high risk modules, examine all the ways in which you can bass format data to the high risk components. This is similar to walking all paths from each high risk component back to the attacker; each path is an entry point. Common entry points for format string components include:
Every component using format string functions gathers its input from entry points like the ones above. Make a relation of all the high risk components identified with their entry points during this step.
Step 3: Start Testing and Exploring
During this step start testing the application with common attack vectors and watch the application reaction to them.
Attach a debugger
Attaching a debugger is a basic task in testing for format strings. Any crash in the application due to access violations will break into the debugger. The tester can then use debug information to determine if the crashes are exploitable such as buffer or heap overflows.
Start with simple fuzz strings
The next step is to start testing with basic strings and observe how the application reacts to them. The next string can yield in a crash very fast:
%n%s
Feed the above string to the application and look for a crash in the debugger. Then keep trying basic fuzz strings are look both at the debugger and at the application's output (message box, UI, web page, etc) depending on the case. Look at the output when testing %x since it may divulge memory locations. Look at the debugger when testing strings expansions such as %128d.
Continue with common fuzz vectors
Continue exploring different flags passed to format string functions. The OWASP fuzz vectors show a comprehensive list of what to try first:
Step 4: Tune test case data
Modify test data according its entry points
The next step is to continue modifying test strings based on each of the entry points. For example, if the application receives strings from a file it is necessary to modify the string values of a file.
The hex editor shows that the machine name "BOX 01" is stored at offset 164 and in UNICODE (zeros in between). Therefore to test the %n string tune it to look like the one below (hex Unicode) and insert it at this offset:
\x25\x00\x6E\x00
Another example of data tuning is it is going through the URL. If your application uses the URL to get the variable name then pass the following string to it:
http://www.xvulnerablesite.com/input.php?name=%25n
Try different payloads:
There are different payloads depending on what the attacker might want to do. Next are some examples of additional payloads:
Denial of service due to crash. - passing strings such as these to vulnerable system leads to a crash almost always:
Denial of service due to memory consumption. - passing the string below causes the application to allocate an extremely long string and consume excessive memory:
%9999999s
Denial of service due to integer overflow. - passing a float type in a string can cause a nearby integer to be affected:
%.650f
Information disclosure from the stack: - passing the following strings reveal the pointer location and stack:
Testing for format string bugs is straight forward. An important step is to identify well all entry points to format strings and test through them. Then tune test cases based on entry point and payload to execute. Pay attention to how the application reacts to each test case using the debugger, system and network monitoring tools, and the output and behavior of the application under test.


Tools for getting metadata of pdqr-function: a function which represents
distribution with finite support and finite values of probability/density.
The key metadata which defines underline distribution is "x_tbl". If two
pdqr-functions have the same "x_tbl" metadata, they represent the same
distribution and can be converted to one another with as_*()
family of
functions.
meta_all(f)
meta_class(f)
meta_type(f)
meta_support(f)
meta_x_tbl(f)
| f | A pdqr-function. |
|---|
meta_all()
returns a list of all metadata. meta_class()
,
meta_type()
, meta_support
, and meta_x_tbl()
return corresponding
metadata.
Internally storage of metadata is implemented as follows:
Pdqr class is a first "appropriate" ("p", "d", "q", or "r") S3 class of
pdqr-function. All "proper" pdqr-functions have full S3 class of the form:
c(cl, "pdqr", "function")
, where cl
is pdqr class.
Pdqr type, support, and "x_tbl" are stored into function's environment.
Pdqr class is returned by meta_class()
. This can be one of "p", "d", "q",
"r". Represents how pdqr-function describes underlying distribution:
P-function (i.e. of class "p") returns value of cumulative distribution
function (probability of random variable being not more than certain value)
at points q
(its numeric vector input). Internally it is implemented as
direct integration of corresponding (with the same "x_tbl" metadata)
d-function.
D-function returns value of probability mass or density function (depending
on pdqr type) at points x
(its numeric vector input). Internally it is
implemented by directly using "x_tbl" metadata (see section '"x_tbl"
metadata' for more details).
Q-function returns value of quantile function at points p
(its numeric
vector input). Internally it is implemented as inverse of corresponding
p-function (returns the smallest "x" value which has cumulative probability
not less than input).
R-function generates random sample of size n
(its single number input)
from distribution. Internally it is implemented using inverse transform
sampling: certain amount of points from standard uniform distribution is generated, and the output is values of
corresponding q-function at generated points.
These names are chosen so as to follow base R convention of naming distribution functions. All
pdqr-functions take only one argument with the same meaning as the first ones
in base R. It has no other arguments specific to some parameters of
distribution family. To emulate their other common arguments, use the
following transformations (here d_f
means a function of class "d", etc.):
For d_f(x, log = TRUE)
use log(d_f(x))
.
For p_f(q, lower.tail = FALSE)
use 1 - p_f(q)
.
For p_f(q, log.p = TRUE)
use log(p_f(q))
.
For q_f(p, lower.tail = FALSE)
use q_f(1 - p)
.
For q_f(p, log.p = TRUE)
use q_f(exp(p))
.
Pdqr type is returned by meta_type()
. This can be one of "discrete" or
"continuous". Represents type of underlying distribution:
Type "discrete" is used for distributions with finite number of outcomes. Functions with "discrete" type has a fixed set of "x" values ("x" column in "x_tbl" metadata) on which d-function returns possibly non-zero output (values from "prob" column in "x_tbl" metadata).
Type "continuous" is used to represent continuous distributions with piecewise-linear density with finite values and on finite support. Density goes through points defined by "x" and "y" columns in "x_tbl" metadata.
Pdqr support is returned by meta_support()
. This is a numeric vector with
two finite values. Represents support of underlying distribution: closed
interval, outside of which d-function is equal to zero. Note that inside
of support d-function can also be zero, which especially true for "discrete"
functions.
Technically, pdqr support is range of values from "x" column of "x_tbl" metadata.
Metadata "x_tbl" is returned by meta_x_tbl()
. This is a key metadata which
completely defines distribution. It is a data frame with three numeric
columns, content of which partially depends on pdqr type.
Type "discrete" functions have "x_tbl" with columns "x", "prob", "cumprob".
D-functions return a value from "prob" column for input which is very near
(should be equal up to ten digits, defined by round(*, digits = 10)) to corresponding value of "x" column. Rounding is done to
account for issues with representation of numerical values (see Note section
of ==
's help page). For any other input, d-functions return
zero.
Type "continuous" functions have "x_tbl" with columns "x", "y", "cumprob". D-functions return a value of piecewise-linear function passing through points that have "x" and "y" coordinates. For any value outside support (i.e. strictly less than minimum "x" and strictly more than maximum "x") output is zero.
Column "cumprob" always represents the probability of underlying random variable being not more than corresponding value in "x" column.
All metadata of pdqr-functions are not meant to be changed directly. Also change of pdqr type, support, and "x_tbl" metadata will lead to a complete change of underlying distribution.
To change pdqr class, for example to convert p-function to d-function,
use as_*()
family of functions: as_p()
, as_d()
, as_q()
, as_r()
.
To change pdqr type, use form_retype()
. It changes underlying
distribution in the most suitable for user way.
To change pdqr support, use form_resupport()
or form_tails()
.
Change of "x_tbl" metadata is not possible, because basically it means
creating completely new pdqr-function. To do that, supply data frame with
"x_tbl" format suitable for desired "type" to appropriate new_*()
function:
new_p()
, new_d()
, new_q()
, new_r()
. Also, there is a form_regrid()
function which will increase or decrease granularity of pdqr-function.
#> List of 4
#> $ class : chr "d"
#> $ type : chr "continuous"
#> $ support: num [1:2] 0 1
#> $ x_tbl :'data.frame': 10001 obs. of 3 variables:
#> ..$ x : num [1:10001] 0e+00 1e-04 2e-04 3e-04 4e-04 5e-04 6e-04 7e-04 8e-04 9e-04 ...
#> ..$ y : num [1:10001] 1 1 1 1 1 1 1 1 1 1 ...
#> ..$ cumprob: num [1:10001] 0e+00 1e-04 2e-04 3e-04 4e-04 5e-04 6e-04 7e-04 8e-04 9e-04 ...
meta_class(d_unif)
#> [1] "d"meta_type(d_unif)
#> [1] "continuous"meta_support(d_unif)
#> [1] 0 1#> x y cumprob
#> 1 0e+00 1 0e+00
#> 2 1e-04 1 1e-04
#> 3 2e-04 1 2e-04
#> 4 3e-04 1 3e-04
#> 5 4e-04 1 4e-04
#> 6 5e-04 1 5e-04


Chapter 4 OLS Assumptions
- Linearity: \(y_i = x'_i \beta + u_i\)
- Random/iid sample: \((y_i, x'_i)\) are a iid sample from population
- No perfect collinearity: \(X\) is an \(n \times (k + 1)\) matrix with rank \(k + 1\)
- Zero conditional mean \(E(u_i | x_i) = 0\)
- Homoskedasticity: \(V(u_i | x_i) = \sigma_u^2\)
- Normality \(u_i | x_i \sim N(0, \sigma_u^2)\)
- Unbiasedness: 1–5 in large samples
Gauss-Markov
Suppose that \[ y = X \beta + \epsilon \] where \(y, \epsilon \in R^n\), \(\beta \in R^K\) and \(X \in R^{n \times K}\).
With the following assumptions on the errors,
- mean zero \(E(\epsilon_i | x_i) = 0\)
- homoskedastic \(Var(\epsilon_i) = \sigma^2 < \infty\)
- uncorrelated \(Cov(\epsilon_i, \epsilon_j) = 0\) for all \(i \neq j\).
Then OLS is BLUE: “best linear unbiased estimator”
- linear estimator: estimator can be written as a weighted sum of the responses. OLS is a linear estimator since \[ \hat{\beta} = \underbrace{(X' X)^{-1} X'}_{\text{weight}} y \]
- unbiased: \(E(\hat{\beta} - \beta) = 0\)
- best: of all the unbiased linear estimators it has the lowest variance, \(V(\beta)\).
4.1 Covariance/variance interpration of OLS
\[ \Mat{X} = \sum_{i = 1}^N \begin{bmatrix} y_i \\ y_i x_{i1} \\ y_i x_{i2}\\ \vdots \\ y_i x_{iK} \end{bmatrix} \approx \begin{bmatrix} n\bar{y} \\ \widehat{\Cov}[y_i, x_{i1}] \\ \widehat{\Cov}[y_i, x_{i2}] \\ \vdots \\ \widehat{\Cov}[y_i, x_{iK}] \end{bmatrix} \]
\[ \Mat{X}\T \Mat{X} = \sum_{i = 1}^N \begin{bmatrix} 1 & x_{i1} & x_{i2}& \cdots & x_{ik} \\ x_{i1} & x_{i1}^2 & x_{i2} x_{i1} & \cdots & x_{i1} x_{iK} \\ x_{i2} & x_{i1} x_{i2} & x_{i2}^2 & \cdots & x_{i2} x_{iK} \\ \vdots & \vdots & \vdots & \ddots & \vdots \\ x_{iK} & x_{i1} x_{iK} & x_{i2} x_{iK} & \cdots & x_{ik} x_{iK} \end{bmatrix} \approx \begin{bmatrix} n\bar{y} \\ \widehat{\Cov}[y_i, x_{i1}] \\ \widehat{\Cov}[y_i, x_{i2}] \\ \vdots \\ \widehat{\Cov}[y_i, x_{iK}] \end{bmatrix} \]


Hello, I am a user experience and graphic designer.
Design is my passion and what can be better than helping people by doing what you love most!
I started several years ago as a freelance graphic designer working on brand identity, logos and marketing materials. Throughout the years I was constantly learning new techniques, exploring new tools and keeping up with ever-changing world of design.
I discovered UX design when I was asked to re-design a website and re-imagine some of the workflows they were offering. While doing some research I stumbled upon UX design and just the idea was very interesting. That's where I learned bringing order into chaos through simplicity and enjoyed doing it ever since.


class: center, middle, inverse, title-slide # Lecture 13 ## Contingent valuation method ### Ivan Rudik ### AEM 4510 --- exclude: true ```r if (!require("pacman")) install.packages("pacman") ``` ``` ## Loading required package: pacman ``` ```r pacman::p_load( tidyverse, xaringanExtra, rlang, patchwork, nycflights13, broom, viridis, vembedr, tweetrmd ) set.seed(1) options(htmltools.dir.version = FALSE) knitr::opts_hooks$set(fig.callout = function(options) { if (options$fig.callout) { options$echo <- FALSE } knitr::opts_chunk$set(echo = TRUE, fig.align="center") options }) red_pink <- "#e64173" blue <- "#3C93DC" red <- "#ff0000" # A blank theme for ggplot theme_empty <- theme_minimal() + theme( legend.position = "none", title = element_text(size = 24), axis.text.x = element_text(size = 24), axis.text.y = element_text(size = 24), axis.title.x = element_text(size = 24), axis.title.y = element_text(size = 24), panel.grid.minor.x = element_blank(), panel.grid.major.y = element_blank(), panel.grid.minor.y = element_blank(), panel.grid.major.x = element_blank(), panel.background = element_rect(fill = "#eeeeee", colour = NA), plot.background = element_rect(fill = "#eeeeee", colour = NA), axis.line = element_line(colour = "black"), axis.ticks = element_line(), ) theme_blank <- theme_minimal() + theme( legend.position = "none", title = element_text(size = 24), axis.text.x = element_blank(), axis.text.y = element_blank(), axis.title.x = element_blank(), axis.title.y = element_blank(), panel.grid.minor.x = element_blank(), panel.grid.major.y = element_blank(), panel.grid.minor.y = element_blank(), panel.grid.major.x = element_blank(), panel.background = element_rect(fill = "#eeeeee", colour = NA), plot.background = element_rect(fill = "#eeeeee", colour = NA), axis.line = element_blank(), axis.ticks = element_blank(), ) ``` ``` ## Warning: 'xaringanExtra::style_panelset' is deprecated. ## Use 'style_panelset_tabs' instead. ## See help("Deprecated") ``` ``` ## Warning in style_panelset_tabs(...): The arguments to `syle_panelset()` changed ## in xaringanExtra 0.1.0. Please refer to the documentation to update your slides. ``` --- # Roadmap - How do stated preference methods differ from revealed preference methods? - How do we do contingent valuation? --- class: inverse, center, middle name: background # Stated vs revealed preference

 --- # Revealed preference methods The two method's we've learned so far are called .hi[revealed preference methods] -- This is because people's preferences or valuations are *revealed* through their own private actions -- Hedonics: purchasing of houses of different attributes and costs Travel cost: visits to sites of different attributes and costs -- We then used our economic theory to show how we could use the market prices/costs to reveal people's valuation for non-market goods --- # Stated preference methods The other way we could do this is with .hi[stated preference methods] Stated preference methods derive people's valuations from responses to hypothetical choices they make in surveys -- This particular approach is called .hi[contingent valuation]: a survey-based method for eliciting total economic values, usually WTP, that people place on goods, services, and amenities --- # Contingent valuation method (CVM) Here's some basic facts about CVM: - A highly-structured survey is administered to consumers/citizens to determine value they place on change in amenity or service -- - Draws on psychology as well as economics -- - Only valuation methods that can be used to estimate non-use value (although studies elicit total value; if non-users, we have non-use value) -- - Very time-consuming and expensive if well done --- # Contingent valuation method (CVM) CVM has had a lot of impact on policy: - Executive and legislative: regulatory impact analysis (RIAs) - Judicial: private litigation, government litigation --- # CVM history 1963: Robert Davis values changes in Maine recreational areas in Harvard PhD dissertation -- 1967: Concept of non-use value introduced by Krutilla (Conservation Reconsidered) -- 1980 Comprehensive Environmental Response, Compensation, and Liability Act (CERCLA): Federal and state agencies were regarded as resource trustees that could recover appropriate damages from “potentially responsible parties.” In order to sue, must compute monetary equivalent of damages -- 1986: Non-use values recognized as a property right of U.S. citizens (Ohio v. U.S. Dept of Interior) – must be measurable --- # CVM history 1989: Exxon Valdez oil spill — non-use value losses estimated by CV method to exceed $2.2 billion; Exxon launches research & campaign to discredit CV
--- # CVM history 1992: NOAA Panel rules that results from CV studies were valid and sufficiently reliable for use in litigation (as “starting point”); also offers guidelines for future use .center[ ![](13-slides-contingent-valuation_files/figure-html/unnamed-chunk-3-1.png) ] --- # CVM applications Damages from Exxon Valez oil spill -- Damages from Deepwater Horizon oil spill -- Benefits from visibility improvements at the Grand Canyon -- Benefits from improving water quality --- # How do we conduct a CVM study? - Clearly identify the good/service and the (policy-induced) change in the good/service to be valued — oil spill on beach (what’s valued? A day at the beach; a view of the beach, a degraded beach, water pollution?) -- - Identify whose values are to be estimated: geographical scope of “market” through focus group and pretest -- - Design information component of the survey instrument. Describe item to be valued, payment vehicle (tax, user fee, product prices) --- # How do we conduct a CVM study? - Select a data collection mode: in person, mail, phone; and choose statistical sampling design -- - Administer survey to a random sample of the market -- - Conduct statistical analyses, do validity test, use elicited WTP for policy analysis --- # CVM components .hi[Collect information] on consumer’s past, present, and expected future use of good, demographics, etc -- .hi[Present hypothetical scenario], describing change in good to be valued -- .hi[Present payment vehicle], (tax, user fee, product prices) must be plausible and understandable -- .hi[Elicit respondent’s WTP], remind respondents of existence of substitutes & budget constraint -- .center[ .hi-blue[How do we elicit WTP?] ] --- # CVM elicitation There's a lot of options, some are better than others -- .hi[Ask for WTP (open-ended)] – unfamiliar, few real markets in which we’re asked to generate our reservation price - "What is your max you would pay to create four self-sustaining wolf packs in four remote areas of Colorado?" This type of question is called "open-ended" CVM --- # CVM elicitation .hi[Bidding Game] – start with a WTP number, ask for yes-no response, then increase/decrease until indifference (Problem: starting-point bias) - I ask, "Would you pay 1 dollar to create four self-sustaining wolf packs in four remote areas of Colorado?" If you say "yes", I can ask about 2 dollars. If you say yes to 2 dollars, then I ask a larger amount, etc. Questions stop when you say no. Can also play this game starting with a large amount and work down. --- # CVM elicitation .hi[Payment Card] – present a card with a set of possible payments, respondent circles largest value they would pay - On the following payment card (a card with a bunch of different $ amounts) circle the largest amount you would be willing to pay to create four self-sustaining wolf packs in four remote areas of Colorado. This is a payment-card question --- # CVM elicitation .hi[Referendum (Discrete Choice)] – start with different baseline WTP number for each respondent, get yes or no; stop. Minimizes bias, recommended by NOAA. Problem: requires more data, and so more costly - "Creating four self-sustaining wolf packs in four remote areas of Colorado will increase your state taxes by 10 dollars a year for five years. Would you vote for such a proposal?" This is a "referendum CVM" question, dollar amounts vary across respondents) --- # CVM elicitation media .hi[Mail survey:] cheapest; but systematic non-responses big problem; difficult to control flow of information -- .hi[Phone survey:] cheap; but selection bias (autodialing does not access cell phones); self-selection bias among those willing/available; no visual cues can be used -- .hi[Online Surveys:] most common recently due to cost -- .hi[In-person survey:] expensive, but reliable; recommended by NOAA Panel; problems: interviewer bias? socially-correct responses? --- # Potential CVM problems .hi[Hypothetical Markets:] We are asking people to value something in a market that isn’t real, answers might not reflect real preferences - "warm glow" - Protest zeros - Hypothetical bias: a tendency to overstate values (especially in terms of WTA instead of WTP) when no money is actually at stake We try to address this with .hi-blue[entreaties:] scripts read before a stated preference survey to try to induce the respondent to not give a biased response - Reminds respondents to consider budget constraint - "Cheap talk" - explicit discussion of hypothetical bias --- # Cheap talk (Cummings and Taylor, 1999) > ... in a recent study, several different groups of people voted on a referendum just like the one you are about to vote on. Payment was hypothetical for these groups, as it will be for you. No one had to pay money if the referendum passed. The results of these studies were that on average, across the groups, 38 percent of them voted "yes". With another set of groups with similar people voting on the same referendum as you will vote on here, but where payment was real and people really did have to pay money if the referendum passed, the results on average across the groups were that 25 percent voted yes. That's quite a difference, isn't it? --- # Cheap talk (Cummings and Taylor, 1999) This difference between hypothetical outcomes and real stakes outcomes is called .hi[hypothetical bias] -- > How can we get people to think about their vote in a hypothetical referendum like they think in a real referendum, where if enough people vote "yes," they'll really have to pay money? How do we get them to think about what it means to really dig into their pocket and pay money, if in fact they really aren't going to have to do it? --- # Cheap talk (Cummings and Taylor, 1999) > Let me tell you why I think that we continually see this hypothetical bias, why people behave differently in a hypothetical referendum than they do when the referendum is real. I think that when we hear about a referendum that involves doing something that is basically good – helping people in need, improving environmental quality, or anything else – our basic reaction in a hypothetical situation is to think: sure, I would do this. I really would vote "yes" to spend the money.... --- # Cheap talk (Cummings and Taylor, 1999) > But when the referendum is real, and we would actually have to spend our money if it passes, we think a different way. We basically still would like to see good things happen, but when we are faced with the possibility of having to spend money, we think about our options: if I spend money on this, that's money I don't have to spend on other things... we vote in a way that takes into account the limited amount of money we have.... This is just my opinion, of course, but it's what I think may be going on in hypothetical referenda. --- # Cheap talk (Cummings and Taylor, 1999) > So if I were in your shoes… I would ask myself: if this were a real referendum, and I had to pay $10.00 if the referendum passed: do I really want to spend my money this way? If I really did, I would vote yes; if I didn't, I would vote no.... -- > In any case, I ask you to vote just exactly as you would vote if you were really going to face the consequences of your vote: which is to pay money if the proposition passes. Please keep this in mind in our referendum. --- # "Cheap talk" referendum question .hi[The Nature Conservancy Proposition:] > “Everyone here in the room will contribute $10.00 to the Georgia Chapter of the Nature Conservancy. The contribution is to be used for the purpose of purchasing additional lands in the state of Georgia to be protected and held in stewardship by the Nature Conservancy.” --- # "Cheap talk" referendum question Ask this question to three groups: - real referendum - hypothetical referendum - hypothetical referendum with cheap talk --- # Potential CVM problems .hi[Incentives to Strategically Misrepresent:] Related to hypothetical bias, respondents may misrepresent their preferences in order to influence the outcome -- - Believe they won’t have to pay but believe their answer matters for passage `\(\rightarrow\)` overstate -- - Believe that they will have to pay but also believe that their answer does not matter for passage `\(\rightarrow\)` understate -- We need to make the respondent believe their answer matters for passage (i.e., it's "pivotal") and that they will have to pay what they say (no free riding) --- # Potential CVM problems .hi[Information Problems:] How can the interviewer provide enough information for the respondent to be able to form preferences without creating existence value where there had been none? -- .hi[Value Cues:] Does the way that the question is asked suggest a correct answer to the respondent (e.g., starting-point bias, yea-saying bias) --- # CVM example: Improvements in the Adirondacks Major air quality initiatives have cited reduced acid precipitation as a benefit of further reductions in sulfur dioxide (SO2) and nitrogen dioxides (NOx) - 1990 Clean Air Act Amendments - 2005 Clean Air Interstate Rule - 2004 Clear Skies Proposal -- Programs are costly: clear skies cost 4.3 bil. (2010) rising to 6.3 bil. (2020) - Aggregated benefits estimated to be 336 million to 1.1 billion (accounting for statistical uncertainties these estimates could halve or double) --- # CVM example: Improvements in the Adirondacks .pull-left[ .center[  ] ] .pull-right[ The survey introduces an intervention where New York State would run a tax-financed program to drop lime from airplanes onto lakes and affected forests to neutralize the acidity This was a necessary ruse that was accepted by respondents ] --- # Summary of the science Adirondack Park covers 20% of NY State: .hi-red[three times the area of Yellowstone National Park] -- 1/6 of the park is designated as "wilderness", 85% of all wilderness area in the northeast -- Adirondack Park has: - 6 major river basins, 3000 lakes - Largest set of old growth forests in the east - 33 tree species, lots of native plants - 9 million visitors --- # Summary of the science In 1984: 19% of lakes chronically acidic -- Depending on chemical thresholds under the 1990 CAAA, this could fall to 11% by 2040 or rise to 43 percent --- # Summary of the science .center[  ] --- # ADK map .center[  ] --- # Eliciting WTP .center[  ] --- # Eliciting WTP > If the majority of voters support this program, your household's share of its cost would be $250 [$900, $1500, $2500] in total, or $25 [$90, $150, $250] per year, paid as an additional tax over the next ten years -- > If a vote were held today, would you vote For the program or Against it? [ Yes / no ] (Circle one answer) --- # WTP for base scenario .center[  ] --- # Average WTP by region .center[  ] --- # WTP estimates Depending on improvement scenario and estimation method, estimated median WTP ranged from 48 to 159 dollars per household per year -- Aggregated across 7 million residents in NY state and using a range of discount rates, estimate aggregate annualized benefits of 336 million to 1.1 billion dollars --- # Test for validity .pull-left[ WTP increased with: - Income - Personal stake (e.g. frequency of visits) - Proximity - Self-stated environmentalist, liberal, etc ] .pull-right[  ] --- # Exxon Valdez (1989) The Exxon Valdez oil spill occurred in Prince William Sound, Alaska, March 24, 1989 -- *Exxon Valdez*, an oil tanker, struck Prince William Sound's Bligh Reef 1.5 mi west of Tatitlek, Alaska -- It spilled 10.8 million US gallons of crude oil over the next few days -- Considered to be one of the worst human-caused environmental disasters -- Second largest spill after 2010 Deepwater Horizon --- # Exxon Valdez (1989) Exxon spent $2 billion on cleaning up the efforts -- In *Exxon v. Baker*, an Anchorage jury awarded $287 million for actual damages and $5 billion for punitive damages -- The punitive damages were reduced to $507.5 million after multiple appeals including the last one to the Supreme court --- # CVM and Exxon Valdez .pull-left[ “Contingent Valuation and Lost Passive Use: Damages from the Exxon Valdez” by Richard T. Carson, Robert C. Mitchell, W. Michael Hanemann, Raymond J. Kopp, Stanley Presser, and Paul A. Ruud We will look at their survey instrument to see how "best practices" are followed ] .pull-right[  ] --- # CVM and Exxon Valdez: background .center[  ] --- # CVM and Exxon Valdez: background .center[  ] --- # CVM and Exxon Valdez: background .center[  ] --- # CVM and Exxon Valdez: background .center[  ] --- # CVM and Exxon Valdez: wildlife .center[  ] --- # CVM and Exxon Valdez: wildlife .pull-left[  ] .pull-right[  ] --- # CVM and Exxon Valdez: spill .center[  ] --- # CVM and Exxon Valdez: spill .center[  ] --- # CVM and Exxon Valdez: spill .center[   ] --- # CVM and Exxon Valdez: clean up .center[  ] --- # CVM and Exxon Valdez: wildlife consequences .center[  ] --- # CVM and Exxon Valdez: wildlife consequences .center[  ] --- # CVM and Exxon Valdez: hypothetical market .center[  ] --- # CVM and Exxon Valdez: hypothetical market .center[  ] --- # CVM and Exxon Valdez: hypothetical market .center[  ] --- # CVM and Exxon Valdez: hypothetical market .center[  ] --- # CVM and Exxon Valdez: hypothetical market .center[  ] --- # CVM and Exxon Valdez: hypothetical market .center[  ] --- # CVM and Exxon Valdez: valuation .center[  ] --- # CVM and Exxon Valdez: valuation .center[   ] --- # CVM and Exxon Valdez: valuation .center[  ] --- # CVM and Exxon Valdez: valuation .center[   ] --- # CVM and Exxon Valdez: valuation .center[  ] --- # CVM and Exxon Valdez: valuation .center[  ]