Overview
PerSE is a visual analytics web application for periodicity detection and analysis.
What is PerSE?
PerSE is a web application designed and built to aid users in the detection and analysis of periodicity within event data sets. Hence, PerSE stands for "Periodicity in Spatio-temporal Events".
The main idea behind PerSE is that different groups of people use different calendars systems, for instance, Gregorian, Islamic (Hijri), Hebrew, and Persian. Therefore, we should analyze event data sets (e.g. car-crashs, crimes, terrorist acts, etc.) through the lens of the calendar system relative to the communities and areas of interest.
PerSE is composed of several crossfiltering views: the Voronoi Subplots Map, Main Toolbar, Attribute View, Time-Wheel, Timeline, and Table. To detect and analyze periodicity within event data sets, users must use the mouse to interactively set and release filters on one or more of the views.
For more information on periodicity, calendars, and why the two are important, please check out the About page.
How do I use this page?
This page has two purposes:
- Use the Quickstart section to become familiar with PerSE through a fast paced tutorial.
- Use the Views section to get an in-depth description of the views that make up PerSE.
Quickstart
Become familiar with PerSE.
In this quickstart guide I will walk you through the interface of the PerSE. I'll try to provide as many images as possible to illustrate what I'm talking about, but it may be helpful to experiment with PerSE as you follow along.
Keep in mind, I will only point out the major features of PerSE. For more information check out the Views section on this page.
Lets begin!
Getting Started
Before we attempt to access PerSE, you will need to have an updated version of a modern browser like Chrome (Recommended), Safari (OK), or Firefox (Slow). PerSE's core libraries don't jive well with Internet Explorer, so don't use that for PerSE testing or analysis.p
Also, PerSE was developed to be used on a desktop or laptop. Operations are not supported on iPads, iPhones, tablets, etc.
If you have the correct browser and a laptop/desktop computer, you can access PerSE right now by following this link.
On navigating to PerSE, you will see a modal dialog with the words, "Loading...", which should last for about 2-3 seconds.
PerSE comes with a built-in data set, meaning the data automatically loads into the browser before you can even see the interface. So, if the "Loading..." modal dialog has disappeared, then you are ready to get started!
Voronoi Subplots Map
The Voronoi Subplots Map is the largest view in PerSE. A view is simply a visible top level component of the app. Some people call them widgets, charts, plots, visualizations, etc., but I will refer to them as views. This view gets it's name from being the mix of two different methods: Small Multiples and Voronoi Diagram.
The Voronoi Subplots Map can be used to detect and analyze periodicity at multiple scales through user interaction. The map displays selected events based on their latitude and longitude. You will also notice that events have different colors. These colors are based on the event's Event Type attribute. These colors are also reflected in all the other views. If you click one of the events, you will see a pop-up with the event's description and recorded fatalities.
When you brush the mouse over the map you will notice that semi-transparent white boundary will highlight. This boundary marks one of the a voronoi diagram cells on the map. Furthermore, you will also notice a light gray circle within each boundary. These circles are the voronoi diagram seeds that control the boundaries of the voronoi cells.
When you brush the mouse over a voronoi cell you will also see one of the subplots along the side of the map highlight. The highlighted subplot displays data points located within the boundary of the voronoi cell. These subplots are positioned to be close to their respective seed coordinate.
Subplots within the Voronoi Subplots Map are always plotted with the same scale to prevent misleading analysis, and are linked to other subplots and the map for dynamic interaction. To illustrate this linking, brush the mouse over the arc "January" within one of the subplots. Two things should happen: a) all other subplots will display their "January" value and b) only "January" events will be displayed on the map. Keep in mind the subplots do not perform any filtering beyond the Voronoi Subplots Map.
You can change the subplots settings with and subplot calendar with .
You can alter voronoi seeds with Add, Move, and Remove in . Also in this drop-down, you can change how the seeds determine their Positioning: Auto or Manual.
For more information see the Voronoi Subplots Map Views section on this page.
To filter events by location, Draw a spatial filter through .
Sometimes it might be difficult to determine if a view within PerSE is filtering the data set. To check if a view is filtering look at the view's filter button. means it is filtering; means it is NOT filtering.
To remove a filter on any view, simply click .
Main Toolbar
The Main Toolbar is a convenience toolbar used for syncing all views. Its purpose is to change the calendar system used within all views, and/or reset all the filters/views.
When PerSE starts-up all views are synced to one calendar. However, over the course of analysis, you may decide to display one view in Gregorian and another in Islamic. To sync all the views back to one calendar click on the Main Toolbar, and then click your desired calendar. This is essentially the same as changing the calendar in every view manually.
At some point during analysis you may wish to reset all filters/views within PerSE. To reset all filters/views click on the Main Toolbar. This is essentially the same as clicking on every view.
PerSE starts up with the Nigeria data set, but you can view another data set by clicking on the Main Toolbar and select a new data set. The interface should then change over to a the new data within 3 to 6 seconds... It's slow because some of the data sets are pretty large for PerSE.
Attribute View
The Attribute View is a space-saving view that displays all non-required data set attributes (i.e. NOT date or location). The Attribute View initializes with the Event Type displaying, but you can display other non-required attributes by clicking the on the Attribute View toolbar title. There are currently three different non-required attributes that you can view in the Attribute View:
- Event Type: The type of event. Also used to symbolize all other views.
- Actor: The acting group or persons in the event; the predicate.
- Fatalities: Amount of deaths.
The Attribute View handles each non-required attribute in one of two ways: numerical and non-numerical.
Numerical
Numerical attributes like Fatalities are displayed as histograms. You can create a filter on a histogram by pressing and holding the mouse button down with the left mouse button, dragging the mouse across the histogram, and then releasing the mouse button.
Non-numerical
Non-numerical attributes like Event-Type and Actor are displayed as a bar-plots. Events are binned by unique values and symbolized as bars based on count (i.e. frequency) of events. To create a filter on the bar plot click individual bars on the bar plot.
Since each unique value is assigned a rectangle and there could be a large amount of unique values (the Actor attribute has +100 unique values), this plot is scrollable! You can scroll the plot using the mouse wheel or the scroll bar.
Sometimes you may only want to view a single unique value, for instance "Boko Haram" Actor events. You can save your self a lot of time by clicking to clear all events, and then select the desired unique attribute value (see image below).
Time-Wheel
The Time-Wheel is a compact radial plot for displaying units of a calendar system. There are three rings on the Time-Wheel:
- Outer: Aggregates all selected events by day of month.
- Middle: Aggregates all selected events month of year.
- Inner: Aggregates all selected events by day of week.
When an arc is hovered, labels are displayed in the top right corner of the view to provide information on the calendar unit and the frequency (i.e. count) of events.
You can create a filter with this view by clicking any of the arcs. To remove the filter click .
To change the calendar represented click in the view's toolbar, and select a calendar.
Timeline
The Timeline displays the count (i.e. frequency) of events per calendar unit in chronological order in the form of a bar chart. The Timeline's x-axis spans from the floor date to ceiling date of the data set (i.e. oldest to youngest).
Change the calendar unit used to aggregate events in . Potential calendar units include:
- Year: Aggreagte events by the calendar year.
- Month: Aggregate events by the calendar month.
- Week: Aggregate events by the calendar week. (Default)
- Day: Aggregate events by the calendar day.
You can create a range filter with this view by pressing the left mouse button down and holding it, dragging the mouse across the Timeline, and then releasing the left mouse button.
Much like all the other views, the calendar can be changed with , and the filter can be removed by clicking .
Table
Below the Timeline you will see a table filled with events. This table displays selected events much like all the other views, however it doesn't provide any filtering capability. It's only duty is to display the raw data in chronological order.
The table only shows 25 events at a time. To see the next 25 selected events click . To see the previous selected events click .
You can also click to change the calendar in which the date is displayed.
Although primitive, the Table can be fairly useful. Next time you find an interesting pattern or finding, drill-down on it with all the views and then look at the table to connect the dots.
Wrap-Up
Well, this is the end of the Quickstart section. If you were confused or would like more detail on any of the views within PerSE, please check out the section on this page titled Views. In that section, I'll go over each top level view in much greater detail, including some background information, interactions, buttons, etc.
If you have any questions about the PerSE as a whole, for instance, technology used to build it, license, why it was developed, etc., you should check out the About page.
Views
An in depth description of PerSE's views.
Before we start, what is a view? A view is simply a visible component of the app. Some people call them widgets, charts, plots, visualizations, etc, but we will refer to them as views. PerSE has a total of six top level views:
In the following sections I'll go over the above top level views in detail. If you are brand new to PerSE or are looking for a brief introduction I recommend the Quickstart section on this page.
Attribute View
A space saving view that displays non-required attributes.
The Attribute View was built to display data attributes that PerSE does not require or anticipate. Therefore, the attribute view could potential consist of any amount non-require data attributes. Each non-required data set attribute is displayed as a single plot or chart, and can filter the data set independent of any non-required or required attribute. The content of the plots are colored by the Event Type non-required attribute. The built in data set has three non-required data attributes.
- Event Type: The type of event recorded.
- Actor: The acting group or persons in the event; the predicate.
- Fatalities: Amount of deaths.
Since PerSE is crunched for screen space, only one non-required attribute in the Attribute View is visible at a time. To change the non-required attribute in the Attribute View click the on the Attribute View's toolbar title. You will then be able to select one of the three non-required data attributes.
After selecting a new non-required attribute the Attribute View will change to reflect the newly selected non-required attribute.
Although there are many different types of data (i.e. nominal, ordinal, etc.), the Attribute View currently handles an attribute in one of two ways: numerical and non-numerical. Both are explained in the following paragraphs.
Numerical
If all attribute values are numerical, then an attribute is determined to be a numerical attribute, and will be displayed as a histogram. To illustrate a numerical non-required attribute click the on the Attribute View's toolbar title and select Fatalities. The view will display a histogram of the Fatalities attribute.
Numerical attribute histograms are binned automatically by an internal algorithm.
Non-Numerical
If not all attribute values are numerical, then the attribute is determined to be a Non-numerical attribute, and will be displayed as a bar chart. Events are binned by unique values and symbolized as horizontal rectangles based on count (i.e. frequency) of events.
Since each unique value is assigned a rectangle and there could be a large amount of unique values (the Actor attribute has +100 unique values), this plot is scrollable! You can scroll the plot using the mouse wheel or the scroll bar.
Filter
Numerical
Numerical attributes can perform range filtering on the data set through user interaction. For example, select all events with reported Fatalities of 10 to 50.
To filter a numerical attribute hover the mouse over the histogram, press the left mouse button down and hold it, drag the mouse across the histogram, and then release the mouse. You should see a gray box during this procedure. After you release the mouse, the gray box will disappear and the plot will scale to the selected range.
There are two ways to remove a filter on the histogram. Like all the other views you can remove the active filter by clicking on the view's tool-bar, or you can single click anywhere on the histogram.
Non-Numerical
Non-numerical attributes can perform selection filtering the data set through user interaction. For example, For example, select all events where Actor is "Boko Haram".
To filter a non-numerical attribute single click individual bars with the left mouse button.
As mentioned above, sometimes there can be a large amount of unique values for an attribute. In these situations, it is difficult to drill-down on a specific attribute value. For instance, to select only "Boko Haram" Actor events we would be required to manually deselect +100 rectangles. To bypass this, click to clear/deselect all unique values in the bar plot, and then select the attribute values you are interested in. For instance, to select only "Boko Haram" Actor events click to clear all events in the plot, and then click "Boko Haram" to view only "Boko Haram" events.
Buttons
| # | Name | Description | Options |
|---|---|---|---|
| Clear | Clears all attributes from the view. Only available for Non-numerical views. This is the equivalent of deselecting all unique attribute values, and is useful for when there are >10 unique values. | n/a | |
| Filter | Remove the current filter within the Numerical or Non-numerical Attribute. This only eliminates the filter for the represented/visible attribute, and will not remove the filters from other non-required attributes within the Attribute View. This button is enabled if the view is currently filtering. | n/a |
Main Toolbar
One toolbar to rule them all.
The Main Toolbar is a convenience toolbar used for syncing all views with a single command.
Change Data Set
PerSE starts up with the Nigeria data set, but you can view another data set by clicking on the Main Toolbar and select a new data set. The interface should then change over to a the new data within 3 to 6 seconds... It's slow because some of the data sets are pretty large for PerSE.
Change Calendar
When PerSE starts-up all views are synced to one calendar. However, over the course of analysis, you may decide to display one view in Gregorian and another in Islamic. To sync all the views to one calendar system click on the Main Toolbar, and then click the desired calendar. This is equivalent to selecting the desired calendar in every top level view.
Filter
At some point during analysis you may wish to reset all filters/views within PerSE. To do so click on the Main Toolbar. This is equivalent to clicking the filter button in every top level view.
Buttons
| # | Name | Description | Options |
|---|---|---|---|
| Change Data Set | View a different data set with PerSE. |
|
|
| Calendar | Sync all views in PerSE to a specified calendar. |
|
|
| Filter | Reset all filters within PerSE, essentially reseting the interface. This button is always enabled. | n/a |
Table
Primitive, but surprisingly useful...
The Table is located below the Timeline and can be used to provide context regarding currently selected events (i.e. events that pass every filtering view). Events are displayed as rows, 25 rows displayed at a time, and each row is given a background color to indicate their attribute value (i.e. in the current data set this attribute is Event Type). Furthermore, the table always sorts data in chronological order.
The Table is most useful for verification or examination of findings. To verify an interesting pattern or finding, do your best to drill-down on it with all the top level views and then look at the table to connect the dots.
Future efforts will be made to make this table more like a shoebox so that users can store and export events/data points.
Paging
The Table limits row output to 25 rows at a time. Row output is limited because adding and removing many rows becomes an expensive DOM operation. Especially when the selection is large and changes a lot! To side step this issue the Table implements paging, click in the view's toolbar to see the next 25 events, or click in the view's toolbar to see the previous 25 events.
Change Calendar
Within the Table there is a column, titled Date, which displays the date of the event. To convert this date to another calendar system, click in the view's toolbar, and select a calendar.
Filter
The table is not able to filter the data set at this point in time.
Buttons
| # | Name | Description | Options |
|---|---|---|---|
| Previous | View the previous 25 events within the current selection. | n/a | |
| Next | View the next 25 events within the current selection. | n/a | |
| Calendar | Convert the date column to a specified calendar. |
|
Timeline
A chronological display of calendar units and range filtering.
The Timeline displays the count (i.e. frequency) of events per calendar unit in chronological order in the form of a bar chart. Calendar units are symbolized as vertical bars/rectangles, and colored by the Event Type attribute.
The Timeline's x-axis is fixed, and spans from the floor date to ceiling date (i.e. oldest to youngest), while the y-axis scales to the maximum event count per calendar unit.
Chart Settings
To change the calendar unit used to aggregate the events within the Timeline click on the view's toolbar, and select one of the following parameters:
- Year: Aggregate events by the calendar year.
- Month: Aggregate events by the calendar month.
- Week: Aggregate events by the calendar week. (Default)
- Day: Aggregate events by the calendar day.
Change Calendar
To change the calendar used to aggregate events within the Timeline click on the view's toolbar, and select a calendar. After you select a new calendar the timeline will update the calendar units within the Timeline.
Note, some calendar units will not appear to change. For instance, Day and Week are identical calendar units in the Gregorian and Islamic calendar.
Filter
The Timeline can filter the data set with a range filter. For example, select all events between year 2008 and 2010. To create a range filter hover the mouse over the Timeline, press the left mouse button down and hold it, drag the mouse across the Timeline, and then release the mouse.
For precise range filters, look at the label in the top right corner of the view for the exact To and From dates.
To remove a Timeline filter click or single-click anywhere on the Timeline.
Buttons
| # | Name | Description | Options |
|---|---|---|---|
| Chart | Change the calendar unit used to aggregate events. Calendar units are represented as bars/rectangles on the Timeline. |
|
|
| Calendar | Change the calendar used to bin events in the Timeline. |
|
|
| Filter | Remove the current filter within the Timeline. This button is enabled if the view is filtering. | n/a |
Time-Wheel
A compact radial plot that displays calendar units.
The Time-Wheel is a compact visualization for displaying calendar units. There are three rings on the Time-Wheel:
- Outer: Aggregates all selected events by day of month.
- Middle: Aggregates all selected events month of year.
- Inner: Aggregates all selected events by day of week.
The arcs within each ring represent the calendar units (i.e. days within a month, months within a year). Arcs are filled based on the count (i.e. frequency) of events whose date is contained by the calendar unit, and are color based on the Event Type attribute.
When an arc is hovered, labels are displayed in the top right corner of the view to provide information on the calendar unit and the frequency (i.e. count) of events.
Change Calendar
To change the calendar used to aggregate the events click in the view's toolbar, and select a calendar. After you select a new calendar the Time-Wheel will re-aggregate the selected data using the new calendar.
Filter
The Timeline can filter the data set with a range filter. For example, select all events between year 2008 and 2010. To create a range filter hover the mouse over the Timeline, press the left mouse button down and hold it, drag the mouse across the Timeline, and then release the mouse.
The Time-Wheel can filter the data set with a select filter. For example, select all events that occurred within the Gregorian Month of January. To create a select filter hover the mouse over the Time-Wheel, and single-click any of the arcs within the ring. To remove the filter click .
Buttons
| # | Name | Description | Options |
|---|---|---|---|
| Calendar | Change the calendar used to bin events in the Time-Wheel. |
|
|
| Filter | Remove the current filter within the Time-Wheel. This button is enabled if the view is filtering | n/a |
Voronoi Subplots Map
A map backed by an adjustable voronoi diagram + small multiples.
The Voronoi Subplots Map is the main view within PerSE. This view is used to detect where and to what extent periodicity exists. The Voronoi Subplots Map combines two well know information visualization methods: the voronoi diagram and small multiples.
In the following sections I will go over the voronoi diagram, small multiples, and how those two concepts integrate into the Voronoi Subplots Map.
Voronoi Diagram
A voronoi diagram is a diagram that partitions a surface based on a set of seeds or points and their nearness/distance to each other. Each seed forms a cell where everything within is closer to its respective seed than to any other seed. Cell boundaries indicate the location where it is equal distance to neighboring seeds.
The Voronoi Subplots in PerSE uses a voronoi diagram to determine which events go to which subplot. This can be useful in situations where boundaries are fuzzy or unknown. For instance, the boundaries between two communities, cities, or cultural groups.
Small Multiples
Small Multiples are a set of similar charts, plots, or gylphs at the same scale. Small Multiples are primarily used for identifying phenomena by comparison. Are some of the multiples similar, different, any outliers? For more information on this method check out Edward Tufte's Envisioning Information (1990).
The Voronoi Subplots Map uses the small multiples as a way to visualize the content within the voronoi diagram cells. The underlying voronoi diagram is used to aggregate events based on their location. Later, these collections of events are visualized using multiples that support reasoning about periodicity. In order link the multiples back to the map, the Voronoi Subplots Map places each small multiple near its respective voronoi seed/cell.
Map
The map displays selected events based on their latitude and longitude and colors them based on the Event Type attribute. If you click one of the events, you will see a pop-up with the event's description and recorded fatalities.
As mentioned above, this view makes use of a voronoi diagram. If you brush the mouse over the map you will notice that a semi-transparent white boundary on the map will highlight. These boundaries are voronoi diagram cells. Furthermore, you will also notice a light gray circle within each boundary. These circles are the voronoi diagram seeds that control the boundaries of the voronoi cells.
Voronoi Seeds
When you brush the mouse over a voronoi cell you will also see one of the subplots along the side of the map highlight. The highlighted subplot displays data points located within the boundary of the voronoi cell. These subplots are positioned to be close to their respective seed coordinate.
Remove
PerSE starts-up with six voronoi seeds on the map. Sometimes six can be to many, especially if there are few data points or if we want to compare less than six regions. You can get rid of a voronoi seed by clicking on the view's toolbar, and then select Remove. Afterward you should see the seeds highlighted. To remove a seed, simply single click the seed with the mouse. If you successfully removed a seed, the seed and it's respective subplot will disappear, and finally the Voronoi Subplots Map will recalculate the voronoi diagram.
After you are finished removing a voronoi seeds, ensure that you disable the Remove setting in by single clicking the Remove setting.
Add
If you have less than six voronoi seeds on the map, then you can add a voronoi seed to the Voronoi Subplots Map. First click on the view's toolbar, and then select Add. Afterward your cursor should light up on the map hinting that you can add a voronoi seed. If you click on the map, a voronoi seed and its respective subplot will be placed on the map, and finally the voronoi diagram will recalculate.
After you are finished adding a voronoi seeds, ensure that you disable the Add setting in by single clicking the Add setting.
Positioning
Unless you change the voronoi seeds Positioning setting the seeds will always snap to a gridded position. This is because the Positioning setting in is set to Auto (Default). Auto can be a nice setting because it attempts to figure out the best position for the voronoi seeds every time the selection changes. For example, if we removed a seed from the Voronoi Subplots Map when Positioning is set to Auto, then the voronoi seeds would automatically grid the remaining space (See the image on the right).
If you want more control over the voronoi seeds, you can set the Positioning to Manual by clicking on the view's toolbar, and then selecting Manual under Positioning. Now voronoi seeds will not reposition when the selection changes. For example, if we removed a seed from the Voronoi Subplots Map when Positioning is set to Manual, then the remaining voronoi seeds would stay in the exact same location, and the voronoi cell boundaries would adjust to compensate for a missing seed.
To move the voronoi seed ensure that Positioning is set to Manual, and click on the view's toolbar, and then select Move. This will allow you to move a voronoi seed and its respective subplot anywhere on the map. After you move the seed the voronoi diagram will recalculate and the voronoi seeds respective subplot will reposition to a better docking station if the layout permits.
Reset
At some point during analysis you may want to reset voronoi seed locations. To reset, click on the view's toolbar, and select Reset. By doing so, voronoi seeds will be added to the map until it reaches the maximum seeds (six). Then the seeds and their respective plots will reposition into a gridded layout similar to Auto Positioning. Finally, the subplots will update with the newly aggregated data.
Subplots
As mentioned above, subplots display event data derived from their respective voronoi cell, and colored by the Event Type attribute.
Subplots within the Voronoi Subplots Map are always plotted with the same scale to prevent misleading analysis, and are linked to other subplots and the map for dynamic interaction. To illustrate this linking, a mouse brush over the arc "January" within one of the subplots will cause two things to happen: a) all other subplots will display their "January" value and b) only "January" events will be displayed on the map. Keep in mind the subplots do not perform any filtering beyond the Voronoi Subplots Map.
There are two types of subplots in the Voronoi Subplots Map: Time-Wheel (default) and Line Plot. To change the Plot Type click on the view's toolbar, and select either Time-Wheel or Line Plot.
Time-Wheel
The Time-Wheel is radial plot used to display calendar units. Each ring around the plot is segmented by arcs which represent a calendar unit. For example, Day of the Month, Month of the Year, Day of the Week. Each ring aggregates all selected events by their date.
The Time-Wheels in the Voronoi Subplots Map are almost exactly the same as the one in the top level view, however there are some small differences. The Time-Wheels in the Voronoi Subplots Map cannot filter outside of the Voronoi Subplots Map, meaning they are not "clickable". Second, since these plots are all linked, they place a burden on the DOMs rendering capabilities. Thus, they do not transition as smoothly as the top level view Time-Wheel.
Line-Plot
The Line Plot is useful for visualizing the linear aspects cyclical units of time. Each line is a temporal segment (e.g. year, month, week) and is segmented by a calendar unit (e.g. month of year, day of month, day of week). Lines are given a Y-value based on the count (i.e. frequency) of events that took place during the temporal segment.
To change the cycle length for all Line Plots within the Voronoi Subplots Map, click clicking in the view's toolbar, and then select an option within the Cycle section.
Change Calendar
Like most of the top level views in PerSE, the Voronoi Subplots Map allows you to change the calendar used to aggregate events. To change the calendar click on the view's toolbar and select one of the calendar systems. After you have changed the calendar, the subplots in the Voronoi Subplots Map will re-aggregate the data with the new calendar.
Filter
Draw
In addition to periodicity detection and analysis, the Voronoi Subplots Map can also be used to perform spatial filters on the entire data set. For example, select all events within a polygon. To create a spatial filter first click on the view's toolbar, and then click Draw. Much like adding a voronoi seed, your cursor will highlight on the map, and you will be able to draw a polygon by clicking to plot a vertex. To end a drawing session double click or single click the starting vertex. After a polygon is created PerSE will filter the entire data set based on the boundaries of the newly created polygon. Note, at this time PerSE only supports one filtering polygon.
Modify
If you would like to change the boundary of a spatial filter polygon click on the view's toolbar, and then click Modify. You will notice that the spatial filter polygon becomes highlighted, and your mouse cursor will snap to the boundary when near. To modify the spatial filter polygon drag a boundary vertex or edge to the desired location. You can also remove a vertex by single clicking the vertex.
Move
If you would like to move the spatial filter polygon (i.e. change coordinates, but preserve the geometry and orientation.), click on the view's toolbar, and click Move. Much like Modify you will notice that the spatial filter polygon becomes highlighted and when you hover over it your cursor will turn into "move-arrows". To move the spatial filter polygon hover over the spatial filter polygon, press the left mouse button down and hold, drag it to the desired location, and release. When you release the mouse button the spatial filter polygon will fix to that location, and the entire data set will update with the new filter.
Remove
There are two ways to remove a spatial filter polygon. The easiest of the two is to simply click on the views toolbar. After you click this button the spatial filter polygon will be removed from the map, and the Voronoi Subplots Map filter will reset.
The long way to remove a spatial filter is to click on the view's toolbar, and then click Remove. This performs the exact same function as the above method, but was included because it naturally fits on the toolbar.
Buttons
| # | Name | Description | Options |
|---|---|---|---|
| Zoom-In | Zoom-in on the map. | n/a | |
| Zoom-Out | Zoom-out on the map. | n/a | |
| Chart | Change subplot type and settings. |
|
|
| Calendar | Change the calendar used to bin events within the subplots. |
|
|
| Draw/Edit | Draw a spatial filter polygon or edit the spatial filter polygon. |
|
|
| Voronoi Seed | Alter the voronoi seeds or change their positioning. |
|
|
| Filter | Remove and spatial filter polygon. This button is enabled if the view is filtering. | n/a |


HOUSING - BOX and PANEL by WILLIAM HAROLD SOUPCOFF B. Arch., University of Cincinnati 1972 SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE ‘DEGREE OF MASTER OF ARCHITECTURE 4°S: at the MASSACHUSETTS INSTITUTE OF TECHNOLOGY June, 1975
Signature of Author. S os.retem re. Tes in tie wi fie A /\ May
/ Certified by. tu. .qeer 7 ace e a Cece eee een cennee
‘ \A - Thesis Supervisor
Accepted by..... rs PRTTTT Torta ce eeee () Chairman, Departmental
- Committee
ARCHIVES
“pass. (RST, Eee
JUN 12 1975
LIBRARIES


Constructor
new BezierCurve(controlPoints)
Creates a curve from control points.
Parameters:
| Name | Type | Description |
|---|---|---|
controlPoints |
Array.<Array.<number>> | The control points that define a Bezier curve |
Methods
at(t) → {Array.<number>}
Evaluates the bezier curve at the given value of t.
Parameters:
| Name | Type | Description |
|---|---|---|
t |
number | The parameter to plug in. (Clamped to the interval [0, 1]) |
Returns:
The point at which t equals the provided value.
- Type
- Array.<number>
solve(axisopt, valueopt) → {Array.<number>}
Finds all values of t for which a particular dimension is equal to a particular value.
Parameters:
| Name | Type | Attributes | Default | Description |
|---|---|---|---|---|
axis |
number |
<optional> |
0 | The index of the axis along which to solve (i.e. if your vectors are [x, y, z], 0 means solve for when x = value). |
value |
number |
<optional> |
0 | The value to solve for (i.e. the Bezier cubic is on the left of an equation and this value is on the right). |
Returns:
All real roots of the described equation on the interval [0, 1].
- Type
- Array.<number>


--- layout: archive title: Zulip Chat Archive permalink: /stream/113488-general/topic/obtain.20with.20.7C.html ---
I thought that obtain
had the same parser as rcases
and rintro
, but it doesn't work when there is a bar at the top level:
import tactic.basic example (p : true ∨ true) : true := begin obtain (h | h) : true ∨ true := p, -- parser fail { exact h }, { exact h }, end
The parentheses shouldn't even be necessary in this case since the :
terminates the pattern, so obtain h | h : true ∨ true := p
could even be made to work
but the docs seem to suggest that a \< \> has to come at the top level
I'm almost certain obtain
uses the rcases
parser, so this is probably a precedence issue or something. Could you open an issue (if you don't feel like fixing yourself)? I can look into it but not immediately.
Technically parentheses are not legal there anyway since we are parsing token by token -- they are only supported if there is direct support for them, as in rintro
obtain h | h : true ∨ true := p,
works
oh
yeah, just found that out myself
is this a new tactic?
somewhat?
it's at least 6 months old by now
It's just rcases
with its arguments in a different order
I think the docstring threw me off with obtain ⟨patt⟩ : type := proof
which makes it look like the pattern needs to be in brackets
it would be nice to add support for type ascriptions inside an rcases pattern so you can also write obtain (h : true) | (h : true) := p,
Last updated: Apr 24 2020 at 19:02 UTC


The xmlto package is a front-end to a XSL toolchain. It chooses an appropriate stylesheet for the conversion you want and applies it using an external XSLT processor. It also performs any necessary post-processing.
This package is known to build and work properly using an LFS-9.1 platform.
Download (HTTP): https://releases.pagure.org/xmlto/xmlto-0.0.28.tar.bz2
Download MD5 sum: 93bab48d446c826399d130d959fe676f
Download size: 128 KB
Estimated disk space required: 1.5 MB (with tests)
Estimated build time: less than 0.1 SBU (with tests)
docbook-xml-4.5, docbook-xsl-1.79.2, and libxslt-1.1.34
fop-2.4, dblatex, and PassiveTeX
One of Links-2.20.2, Lynx-2.8.9rel.1, W3m, or ELinks
User Notes: http://wiki.linuxfromscratch.org/blfs/wiki/xmlto
Install xmlto by running the following commands:
LINKS="/usr/bin/links" \ ./configure --prefix=/usr && make
To test the results, issue: make check.
Now, as the root
user:
make install
LINKS="/usr/bin/links"
: This environment
variable fixes a bug causing xmlto to think that links command is the same as
elinks. Setting this
variable does not cause problems if links is not installed,
unless you have ELinks installed, and wish to use it for
text backend post-processing, in which case, remove it.
Last updated on 2020-03-25 07:06:24 -0500


Components DSL Overview
Hyperloop Components are implemented in the HyperComponent Gem.
Hyperloop Component DSL (Domain Specific Language) is a set of class and instance methods that are used to describe your React components.
- Hyperloop::Component
- Macros (Class Methods)
- Data Accessor Methods
- Tag and Component Rendering
- Using Strings
- HAML style class names
- Event Handlers
- Miscellaneous Methods
- Ruby and Hyperloop
- DSL Gotchas
The DSL has the following major areas:
- The
Hyperloop::Component
class and the equivilentHyperloop::Component::Mixin
mixin. - Class methods or macros that describe component class level behaviors.
- The four data accessors methods:
params
,state
,mutate
, andchildren
. - The tag and component rendering methods.
- Event handlers.
- Miscellaneous methods.
To understand the DSL we will walk through an example that will cover each of these areas in detail.
class Clock < Hyperloop::Component param initial_mode: 12 before_mount do mutate.mode params.initial_mode end after_mount do @timer = every(1) { force_update! } end before_unmount do @timer.stop end FORMATS = { 12 => "%a, %e %b %Y %S %I:%M %p", 24 => "%a, %e %b %Y %S %H:%M" } render do DIV(class: 'time') do Time.now.strftime(FORMATS[state.mode]).span SELECT(style: {"margin-left" => 20}, value: state.mode) do OPTION(value: 12) { "12 Hour Clock" } OPTION(value: 24) { "24 Hour Clock" } end.on(:change) do |e| mutate.mode(e.target.value.to_i) end end end end
Hyperloop::Component
Hyperloop Components classes either include Hyperloop::Component::Mixin
or are subclasses of Hyperloop::Component
.
class Component < Hyperloop::Component
end
# if subclassing is inappropriate, you can mixin instead
class AnotherComponent
include Hyperloop::Component::Mixin
end
At a minimum every component class must define a render
macro which returns one single child element. That child may in turn have an arbitrarily deep structure.
class Component < Hyperloop::Component
render do
div # render an empty div
end
end
You may also include the top level element to be rendered:
class Component < Hyperloop::Component
render(DIV) do
# everything will be rendered in a dic
end
end
To render a component, you reference its class name in the DSL as a method call. This creates a new instance, passes any parameters proceeds with the component lifecycle.
class AnotherComponent < Hyperloop::Component
render do
Component() # ruby syntax requires either () or {} following the class name
end
end
Note that you should never redefine the new
or initialize
methods, or call them directly. The equivilent of initialize
is the before_mount
callback.
Macros (Class Methods)
Macros specify class wide behaviors. In our example we use the five most common macros.
class Clock < Hyperloop::Component
param ...
before_mount ...
after_mount ...
before_unmount ...
render ...
...
end
The param
macro describes the parameters the component expects.
The before_mount
macro defines code to be run (a callback) when a component instance is first initialized.
The after_mount
macro likewise runs after the instance has completed initialization, and is visible in the DOM.
The before_unmount
macro provides any cleanup actions before the instance is destroyed.
The render
macro defines the render method.
The available macros are: render, param, state, mutate, before_mount, after_mount, before_receive_props, before_update, after_update, before_unmount
Data Accessor Methods
The four data accessor methods - params, state, mutate, and children
are instance methods that give access to a component's React specific instance data.
The params
method gives (read only) access to each of the params passed to this instance, the state
method allows state variables to be read and written, and children
returns an enumerator of a component's children.
In our example we see
before_mount do
mutate.mode params.mode
end
params.mode
will return the value of the mode
parameter passed to this instance, and mutate.mode
initializes (or updates) the mode
state variable. State variables are like reactive instance variables. They can only be changed using the mutate
method, and when they change they will cause a rerender.
More on the details of these methods can be found in the Component API section.
Tag and Component Rendering
...
DIV(class: :time) do
...
end
...
HTML such as DIV, A, SELECT, OPTION
etc. each have a corresponding instance method that will render that tag. For all the tags the
method call looks like this:
tag_name(attribute1 => value1, attribute2 => value2 ...) do
...nested tags...
end
Each key-value pair in the parameter block is passed down as an attribute to the tag as you would expect, with the exception of the style
attribute, which takes a hash that is translated to the corresponding style string.
The same rules apply for application defined components, except that the class constant is used to reference the component.
Clock(mode: 12)
Using Strings
Strings are treated specially as follows:
If a render method or a nested tag block returns a string, the string is automatically wrapped in a
tag.
The code SPAN { "hello" }
can be shortened to "hello".SPAN
, likewise for BR, PARA, TD, TH
tags.
"some string".BR
generates some string

Time.now.strftime(FORMATS[state.mode]).SPAN # generates ...current time formatted...
...
OPTION(value: 12) { "12 Hour Clock" } # generates <option value=12>12 Hour Clock</option>
HAML style class names
Any tag or component name can be followed by .class_name
HAML style.
div.class1.class2
# short for
div(class: "class1 class2")
In this style, CSS blends with HTML elements. For example, the following two lines are equivalent:
BUTTON(class: 'btn-primary') { "Press me" }
# is the same as
button.btn_primary { "Press me" }
Note that underscores are translated to dashes. So .foo_bar
will add the foo-bar
class to the tag. If you need to use an underscore in a class name use a double underscore which will be translated to a single underscore in the class name.
Event Handlers
Event Handlers are attached to tags and components using the on
method.
SELECT ... do
...
end.on(:change) do |e|
mutate.mode(e.target.value.to_i)
end
The on
method takes the event name symbol (note that onClick
becomes :click
) and the block is passed the React.js event object.
Event handlers can be chained like so
INPUT ... do
...
end.on(:key_up) do |e|
...
end.on(:change) do |e|
...
end
Miscellaneous Methods
force_update!
is a component instance method that causes the component to re-rerender.
as_node
can be attached to a component or tag, and removes the element from the rendering buffer and returns it. This is useful when you need store an element in some data structure, or passing to a native JS component. When passing an element to another Hyperloop Component .as_node
will be automatically applied so you normally don't need it.
render
can be applied to the objects returned by as_node
and children
to actually render the node.
class Test < Hyperloop::Component
param :node
render do
DIV do
children.each do |child|
params.node.render
child.render
end
params.node.render
end
end
end
Ruby and Hyperloop
A key design goal of the DSL is to make it work seamlessly with the rest of Ruby. Notice in the above example, the use of constant declaration (FORMATS
), regular instance variables (@timer
), and other non-react methods like every
(an Opal Browser method).
Component classes can be organized like any other class into a logical module hierarchy or even subclassed.
Likewise the render method can invoke other methods to compute values or even internally build tags.
DSL Gotchas
There are few gotchas with the DSL you should be aware of:
React has implemented a browser-independent events and DOM system for performance and cross-browser compatibility reasons. We took the opportunity to clean up a few rough edges in browser DOM implementations.
- All DOM properties and attributes (including event handlers) should be snake_cased to be consistent with standard Ruby style. We intentionally break with the spec here since the spec is inconsistent. However,
data-*
andaria-*
attributes conform to the specs and should be lower-cased only. - The
style
attribute accepts a Hash with camelCased properties rather than a CSS string. This is more efficient, and prevents XSS security holes. - All event objects conform to the W3C spec, and all events (including submit) bubble correctly per the W3C spec. See Event System for more details.
- The
onChange
event (on(:change)
) behaves as you would expect it to: whenever a form field is changed this event is fired rather than inconsistently on blur. We intentionally break from existing browser behavior becauseonChange
is a misnomer for its behavior and React relies on this event to react to user input in real time. - Form input attributes such as
value
andchecked
, as well astextarea
.
HTML Entities
If you want to display an HTML entity within dynamic content, you will run into double escaping issues as React.js escapes all the strings you are displaying in order to prevent a wide range of XSS attacks by default.
DIV {'First · Second' }
# Bad: It displays "First · Second"
To workaround this you have to insert raw HTML.
DIV(dangerously_set_inner_HTML: { __html: "First · Second"})
Custom HTML Attributes
If you pass properties to native HTML elements that do not exist in the HTML specification, React will not render them. If you want to use a custom attribute, you should prefix it with data-
.
DIV("data-custom-attribute" => "foo")
Web Accessibility attributes starting with aria-
will be rendered properly.
DIV("aria-hidden" => true)
Invoking Application Components
When invoking a custom component you must have a (possibly empty) parameter list or (possibly empty) block. This is not necessary with standard html tags.
MyCustomComponent() # okay
MyCustomComponent {} # okay
MyCustomComponent # breaks
br # okay


#
I'm sorry when I hear
Boris on the news my mind immediately snaps to Yeltsin, not Johnson. I wonder if the Brits thought that through.
#
An idea for Twitter. I'd like to see a list of referring tweets ranked by the number of views they generated. In aggregate and by tweet. That way I'd know who to thank for helping increase the reach of my rants.
#
All right I like the new Twitter design. Lots of white space. I wish it was designed around live video though. So when you tune in tomorrow it would show the Mueller hearings live. A throwback to a time when everyone watched the same TV live.
#
- Here's a list of files that were updated to fix broken links. Under each item is a list of changes. The top items are the original links, the sub-item for each is the link it was replaced with. #
- bitTorrent.html#
- http://bitconjurer.org/BitTorrent/#
- https://web.archive.org/web/20030206052319/http://bitconjurer.org/BitTorrent/#
- https://cyber.harvard.edu/rss/payloadsforrss.html#
- https://cyber.harvard.edu/rss/payloadsForRss.html#
- http://www.legaltorrents.com/rss.xml#
- https://web.archive.org/web/20040803024411/http://www.legaltorrents.com/rss.xml#
- http://radio.weblogs.com/0001014/2003/10/12.html#a4604#
- http://radio-weblogs.com/0001014/2003/10/12.html#a4604#
- http://www.feedster.com/#
- https://web.archive.org/web/20050124014803/http://www.feedster.com/#
- currentBoard.html#
- http://live.curry.com/#
- https://web.archive.org/web/20040707085350/http://live.curry.com/#
- http://www.curry.com/stories/storyReader$27#
- https://web.archive.org/web/20030207142041/http://www.curry.com/stories/storyReader$27#
- http://www.12inches.nl/decibel.html#
- https://web.archive.org/web/20050216124000/http://www.12inches.nl/decibel.html#
- http://live.curry.com/scanlog/#
- https://web.archive.org/web/20040918084454/http://live.curry.com/scanlog/#
- http://www.theinquirer.net/?article=10377#
- https://web.archive.org/web/20041019004302/http://www.theinquirer.net/?article=10377#
- http://www.thetwowayweb.com/payloadsforrss#
- https://web.archive.org/web/20040621044720/https://thetwowayweb.com/payloadsforrss#
- http://www.sbsonline.nl/modules.php?name=radioprogramma&site=ookgoeiemorgen&sid=1#
- https://web.archive.org/web/20031125012037/http://radioveronica.nl/#
- http://blogs.law.harvard.edu/bloggerCon/discuss/msgReader$1119?mode=topic&y=2004&m=4&d=30#
- http://bloggercon.scripting.com/2004/04/09.html#
- enclosuresAggregators.html#
- https://cyber.harvard.edu/rss/payloadsforrss.html#
- https://cyber.harvard.edu/rss/payloadsForRss.html#
- http://live.curry.com/#
- https://web.archive.org/web/20040707085350/http://live.curry.com/#
- howChannelDeanCameToBe.html#
- http://iowa.deanforamerica.com/node/view/1932#
- https://web.archive.org/web/20040109093208/http://iowa.deanforamerica.com/node/view/1932#
- http://xml.deanforamerica.com/channelDean.xml#
- https://web.archive.org/web/20040805114237/http://xml.deanforamerica.com/channelDean.xml#
- http://www.deanforamerica.com/channeldean/faq/#
- https://web.archive.org/web/20040120233945/http://www.deanforamerica.com/channeldean/faq/#
- mediaPostArticleReview.html#
- http://www.mediapost.com/dtls_dsp_news.cfm?newsId=245798#
- https://web.archive.org/web/20040819213941/http://www.mediapost.com/dtls_dsp_news.cfm?newsId=245798#
- myPublicFeedsOpml.html#
- http://www.weblogs.com/changes.xml#
- https://web.archive.org/web/20091025131341/http://oldweblogscomblog.scripting.com/changesXml#
- http://www.opml.org/spec#
- http://dev.opml.org/spec1.html#
- relativeURI.html#
- http://weblog.infoworld.com/udell#
- https://web.archive.org/web/20040202052733/http://weblog.infoworld.com/udell/#
- rss.html#
- http://asg.web.cmu.edu/rfc/rfc822.html#
- https://www.ietf.org/rfc/rfc822.txt#
- http://www.gnutellanews.com/information/what_is_gnutella.shtml#
- https://en.wikipedia.org/wiki/Gnutella#
- https://thetwowayweb.com/payloadsforrss#
- https://web.archive.org/web/20040621044720/https://thetwowayweb.com/payloadsforrss#
- rssChangeNotes.html#
- http://www.rssquotes.com/blog/#
- https://web.archive.org/web/20040605034929/http://www.rssquotes.com/blog/#
- http://www.rssquotes.com/#
- https://web.archive.org/web/20040607070931/http://www.rssquotes.com/#
- http://blogs.law.harvard.edu/tech/stories/storyReader$12#
- https://web.archive.org/web/20040220153447/http://blogs.law.harvard.edu/tech/stories/storyReader$12#
- http://simon.incutio.com/#
- https://web.archive.org/web/20040615065633/http://simon.incutio.com/#
- rssVersionHistory.html#
- http://www.purplepages.ie/RSS/netscape/rss0.90.html#
- https://web.archive.org/web/20040404041317/http://www.purplepages.ie/RSS/netscape/rss0.90.html#
- http://www.internetnews.com/bus-news/article.php/3_80051#
- https://web.archive.org/web/20041019050503/http://www.internetnews.com/bus-news/article.php/3_80051#
- http://my.netscape.com/publish/formats/rss-spec-0.91.html#
- https://web.archive.org/web/20040402071322/http://my.netscape.com/publish/formats/rss-spec-0.91.html#
- http://xmlrpc.scripting.com/metaWeblogApi#
- http://xmlrpc.scripting.com/metaWeblogApi.html#
- soapMeetsRss.html#
- http://macros.userland.com/basic/viewRssBox#
- https://web.archive.org/web/20010302134837/http://macros.userland.com/basic/viewRssBox#
- http://radio.weblogs.com/0001015/rss.xml#
- https://web.archive.org/web/20040607125801/http://radio.weblogs.com/0001015/rss.xml#
- toplevelNamespace.html#
- http://feeds.archive.org/validator/#
- https://web.archive.org/web/20030801082250/http://feeds.archive.org/validator/#
- weblogComments.html#
- http://www.docuverse.com/blog/donpark/#
- https://web.archive.org/web/20030603202930/http://www.docuverse.com/blog/donpark/#
- http://www.docuverse.com/blog/donpark/rss.xml#
- https://web.archive.org/web/20030412021443/http://www.docuverse.com/blog/donpark/rss.xml#
- Other changes#
- Did a global replace of \r with \n. This meant I could edit the HTML source in a source code editor. #
- Fixed the link to the background image, and made it HTTPS-friendly. #
- Fixed the inclusion of urchin.js so it was HTTPS-friendly.#


Shadow Days are day-in-the-life tour with a current Waterloo Engineering student. You can request an ambassador in SYDE and spend a day with us on campus. Attending classes with real students is a fantastic way to see if the program will be a good fit for you.
Waterloo Engineering Shadow ProgramOpen Houses are another great way to meet current students and tour campus. Not only will you find a booth featuring SYDE students and professors, but can interact with student design teams and societies.
Fall Open House (Early November) March Break Open House (Mid March)


Tuning random forest with one line. The package is mainly based on the packages 'ranger' and 'mlrMBO'.
| Version: | 0.3 |
| Depends: | R (≥ 3.0.2), ranger (≥ 0.8.0), mlrMBO (≥ 1.1.1), parallel (≥ 3.3.3), lubridate (≥ 1.6.0), lhs (≥ 0.14) |
| Imports: | mlr (≥ 2.11), smoof (≥ 1.5.1), ParamHelpers (≥ 1.10), methods (≥ 3.3.3), BBmisc (≥ 1.11), DiceKriging (≥ 1.5.5) |
| Suggests: | testthat |
| Published: | 2018-08-30 |
| Author: | Philipp Probst [aut, cre], Simon Klau [ctb] |
| Maintainer: | Philipp Probst <philipp_probst at gmx.de> |
| License: | GPL-3 |
| NeedsCompilation: | no |
| Citation: | tuneRanger citation info |
| Materials: | README |
| CRAN checks: | tuneRanger results |
| Reference manual: | tuneRanger.pdf |
| Package source: | tuneRanger_0.3.tar.gz |
| Windows binaries: | r-devel: tuneRanger_0.3.zip, r-release: tuneRanger_0.3.zip, r-oldrel: tuneRanger_0.3.zip |
| OS X binaries: | r-release: tuneRanger_0.3.tgz, r-oldrel: tuneRanger_0.3.tgz |
| Old sources: | tuneRanger archive |
Please use the canonical form https://CRAN.R-project.org/package=tuneRanger to link to this page.


--- layout: post-template title: "The Henna Ladies at Jemaa el-Fnaa" postHeading: "The Henna Ladies at Jemaa el-Fnaa" subHeading: "A poem" tags: poetry travel related: travel date: "13 Aug 2018/" image: "/img/The-Henna-Ladies-at-Jemaa-el-Fnaa/jemaa-el-fnaa-square-marrakech-morocco.jpg" credit: "Photo taken by myself at Jemaa el-Fnaa Square" ---
Stranger things at the Jemaa el-Fnaa Square night market
. . .
“Hello!
Hello, beautiful lady.
Come please.
Yes, beautiful lady.
You like henna?
Henna is good.
Is good for no bad luck.
Is good for sexy, sexy.
See?
See?
See my own hand.
I show you.
No problem.
It no take time.
Only 3 minutes.
Is very, very nice.
I show you what I do.
You no pay.
I show you.
Is free.
You see?
Is very nice on your hand.
You see?
Very nice flower.
You like it?
Very nice, eh?
Is 300 dirham.
Yes, 300.
I want my money.
Please give my money.
I no take 100 dirham.
I no take 200 dirham.
Is 300 dirham.”
. . .
First published on Lit Up magazine


5 ways to naturally get rid of dark elbows and knees
If you want to get rid of your dark elbows and knees, read on to find out the best possible ways to go about it.
Everybody wants to have an even skin tone, especially when it comes to the knuckles, elbows and knees.
But this is not always the case…and even if, sometimes, it does happen with the body, the knuckles, elbows, and knees are usually left out.
The reason for this is because the skin around the elbows and knees are usually thicker than the skin surrounding it. Additionally, it has more folds (because of the joints) and tends to be much drier because those parts do not produce oil.
Owing to these, lack of proper hygiene can result in having darker elbows and knees. But be that has it may, studies have shown that there are natural ways to lighten dark elbows and knees.
So, if you want to get rid of your dark elbows and knees, read on to find out the best possible ways to go about it.
Here are five natural ways to lighten dark elbows and knees
1. Lemon
Lemon has bleaching and exfoliating properties, and these properties can help even skin tone. It also contains a very high amount vitamin C which can help to remove dead cells and promote the regeneration of healthy skin cell as well.
Simply apply lemon juice on elbow, knees, and knuckles; massage gently, leave it for ten minutes and rinse with warm water. Do this for a couple of weeks to get result.
2. Coconut oil
Coconut oil is a wonderful moisturizing agent. The vitamin E which is contained in it helps lighten skin tone and also prevent skin hydration.
And for an effective result, gently massage your elbows and knees with coconut oil for three minutes, before shower. You can also mix one teaspoon of coconut oil and a half teaspoon of lemon juice, rub on your dark elbows and knees every day and wipe off with paper towels after 15 to 20 minutes.
3. Aloe vera
Known for its numerous health benefits, aloe vera is also known to be a natural skin lightener, which does not only keep the skin hydrated and moisturized, but help make the skin supple as well.
Aloe vera is also believed to promote the repair of skin cells damaged by sun exposure.
If you’re using aloe vera, simply apply the gel extracted from a fleshy aloe vera leaf on the elbows and knees. And after letting it sit for about twenty minutes, you can wash it off with warm water.
It is advisable to do this twice a day in two weeks for an effective result.
ALSO READ: Shea butter is all you need to clear your dark knuckles...Here's how
4. Sugar
I bet you're surprised, right? Well, it is what it is: Homemade sugar scrub is excellent for lightening the skin tone of knees and elbow because sugar help exfoliates dead skin cells and soften the skin.
When using sugar to lighten dark elbows and knees, simply mix sugar and olive oil equally and massage your knees and elbows circularly for five minutes, before shower. Continue to this until you see result.
5. Baking soda
Baking soda is another agent of skin lightener and it is also effective for rid of dark elbows and knees.
Simply mix baking soda with milk to get a thick paste, if you’re using baking soda, and apply the paste on your elbows and knees and rinse after five minutes.
You can do this once a week for two months to get the desired result.


CHOP CHOP MAKES IT EASY TO EAT THE VEGGIES & FRUIT YOU NEED
Organic Produce
A wide variety, all sourced locally when possible.
Washed the Right Way
We soak our vegetables in special non-chemical mixtures to ensure cleanliness.
Nicely Diced
Gloved employees with expert cutting skills chop your order.
Compostable Containers
All packages can be composted which help us in our effort to reduce waste.


DRAFT
NOT FOR PUBLIC DISTRIBUTION
PIRCS St. Louis Meeting
June 10, 1998
Regal Riverfront Hotel
Attendees: Chuck Hakkarinen (EPRI); Song-You Hong (NCEP); Bill Lapenta (NASA-Marshall); Glen Liston, Roger Pielke (Colorado State University); John Roads (Scripps); Robert Wilby (NCAR); Ray Arritt, Bill Gutowski, Renato Silva and Gene Takle (Iowa State University)
1. Introduction and agenda
The meeting was preceded by a buffet dinner sponsored by EPRI. Gutowski introduced the meeting agenda, which focuses primarily on results from PIRCS Experiment 1a and plans for their publication. He also thanked EPRI (through Chuck Hakkarinen) for sponsoring the meeting, and NOAA's Rick Lawford for logistical support.
2. Preliminary results from the models
2.1 Precipitation trends
Gutowski showed preliminary analyses by the Iowa State group that focus on a portion of the Upper Mississippi River basin between 37-47 N latitude and 89-99 W longitude. Considerations in selecting this region include: (1) the region will provide a contrast between 1988 and 1993, since it includes the peak precipitation area of the 1993 flood; (2) the area is relatively large from the standpoint of a regional model (of order 400 grid points) but relatively small in terms of a GCM or the NCEP/NCAR Reanalysis; and (3) the region does not extend into Canada, so that U.S. data sets (such as the gridded hourly precipitation data set of Higgins et al. 1996) can be used for comparison to the models.
Gutowski compared results for total precipitation (convective and stable) from seven of the PIRCS models to observed precipitation from the Higgins data set. The models generally are able to replicate wet and dry spells in the observations, but the amounts may be underpredicted or overpredicted. A simple "consensus" (arithmetic mean of the participating models) tracks the observed precipitation rather well. Liston brought up the point that the Higgins data are on a relatively coarse resolution and that we should generate a higher-resolution analysis for comparison to the models. The Iowa State group noted that they had already begun to develop such analyses. The Higgins data were used because of the short lead time for this meeting (models results having been provided as little as two days before).
Evaluation of model performance for different types of events can give a perspective on how the models handle different types of forcing (e.g., large-scale versus convective or mesoscale). Differences between convective and stratiform precipitation in the models can also give information on how the models respond to different types of forcing. To this end, Takle described the synoptic characteristics of specific precipitation episodes during PIRCS 1a. The early part of the period was dominated by large-scale synoptic events; all models captured the timing of these. A dry period around Julian day 159 also was represented by all models as was a convective event around day 160. Days 165-180 had small convective events popping up across the upper Mississippi Basin region, with all models capturing something, though timing may not always be precise. Pielke noted that the models differ on whether precipitation is represented as convective or stratiform. All models give convective precipitation dominating on days 165-180, though Pielke mentioned that all miss the dry period at day 187. A handout was distributed with some of these results.
The two versions of RSM differ in the relative representation of convective and stratiform precipitation for several episodes. The Scripps version of the RSM includes the physics from the operational, global spectral model, while the NCEP version has modifications to the physics introduced by Hong. Liston commented that all the models apparently capture the lateral boundary forcing as indicated by the timing of specific precipitation episodes. Hakkarinen pointed out that the models perform somewhat more poorly toward the end of the period, and several in the audience mentioned that this may point to the implications of soil moisture feedbacks.
Gutowski showed maps of cumulative precipitation from four models. All have a dry area in the lower Mississippi River basin that does not appear in the observations. The nocturnal fraction in most of the models exhibits strong spatial gradients that may not be physically realistic, and the models underrepresent the nocturnal maximum in the central U.S. Hong pointed out that convection schemes generally tend to initiate precipitation during the daytime. RAMS seems to give the most realistic nocturnal maximum in the central U.S., though its precipitation tends to be too low. Wilby asked whether the spatial patterns should be looked at separately for convective or stratiform episodes. Liston mentioned that to evaluate the daytime versus nocturnal precipitation there are several factors that must be accounted for; e.g., there must a significant amount of precipitation and not just a few isolated events. Hakkarinen mentioned that the RAMS precipitation appears to most strongly aligned with the underlying terrain and coastlines.
2.2 Low-level jets
Arritt presented analyses of the low-level jet in several of the models based on the criteria of Bonner (1968, Mon. Wea. Rev.). In 1988 the profilers had not yet been deployed so there is not a good source of observed data. Therefore the NCEP reanalysis is being used for preliminary evaluations. Comparison with profiler observations shows that the reanalysis itself has biases, including too many LLJs (Bonner's criterion 1) in the southern Great Plains and too few in the northern Great Plains. Incidence of strong LLJs (Bonner's criterion 3) is severely underrepresented in the reanalysis, perhaps because the reanalysis terrain is too coarse. It is noteworthy that mesoscale models tend to produce more LLJs than the reanalysis. For 1988 the region of high LLJ frequency tends to be to north of the climatological distribution, as expected in a dry year.
MM5 gives a pattern of LLJ frequency that is similar to the reanalysis, but with generally higher incidence of LLJs. DARLAM does not extend quite as far north in maximum LLJ frequency and tends to get more strong LLJs. RAMS has a relatively high incidence of LLJs and a tendency for spatial patterns of LLJ occurrence to follow the Bermuda high. Several models show a Y-shaped or "branched" distribution with swaths of high LLJ incidence to the west along the foothills of the Rocky Mountains and to the east along the periphery of the Bermuda high. RAMS output was provided on pressure levels and results may be different if data were used on the native levels of the model. The NCEP version of the RSM gives a somewhat lower frequency of LLJs than the other models, extending rather far north (again, as might be expected in a dry year).
2.3 Additional diagnostics
The Iowa State group has recently begun studying whether and how the regional models generate MCCs. This uses analysis of mesoscale anomalies based on the method of Jones et al. (1995, Quart. J. Roy. Met. Soc.). An example was given of (non-PIRCS) MM5 results from 1993 at 250 mb and 600 mb. There was vertically-aligned cyclonic convergence at 600 mb and anticyclonic divergence at 250 mb that compared well with where the predicted precipitation occurred. Pielke noted that it would be of interest to compare different convective parameterizations in the same model.
3. Discussion
Much of the discussion centered around the need to obtain additional data for comparison to the model results. Liston recommended that more work be done on bringing together data sets such as max/min temperature and solar radiation. He asked whether surface radiation could be used from the NCEP reanalysis. Roads mentioned that the reanalysis radiation has errors, but that it still could be useful to compare how the regional models differ from the reanalysis. Liston has processed "Summary of the Day" max/min temperatures in GRADS station format, and he showed maps of the max/min temperatures. Radar observations may be useful at least in a qualitative sense although quantitative rainfall estimates are not available for the PIRCS 1a case. Hakkarinen asked whether there are more details available on the precipitation especially for 1993. Alternative data sources may be available such as Bureau of Reclamation, USGS, Oklahoma Mesonet, and VEMAP. FIFE may have radiation and surface flux data for 1988. Lapenta mentioned that Baldocchi's group at Oak Ridge has long-term radiation data. Global Summary of the Day stations have surface pressure and humidity data.
Pielke suggested calculation of thickness values and comparison with NCEP reanalysis. Roads mentioned that NCEP equitable threat and bias scores for precipitation thresholds could be used to evaluate models. In this vein, Gutowski reported that the Iowa State group is trying to compute histograms of precipitation intensity from cooperative station data. Liston says that surface RH is available on global summary of day; Wilby says these include max/min RH. Liston says first-order Summary of the Day includes additional data (about 300 stations). With regard to the NCEP/NCAR Reanalysis, Hong noted that upper atmosphere variables are fairly accurate but errors in 500 mb geopotential height can be as high as 20 m in southeastern US for 1988. It was pointed out that reanalysis variables in the lower atmosphere are strongly influenced by model physics.
4. Publication of PIRCS results
Gutowski stated that the Iowa State group will do continued analysis and will set up a web page to display the results. After some discussion a consensus was reached that the web page will not be passworded, but will not be publicly announced or linked from the main PIRCS page.
The group as a whole will begin working on papers that report PIRCS. The first will be a general description of the results and procedures, including some examples of analysis products but not in-depth analysis. Shortly following would be a "science paper" with more detailed analysis focusing perhaps on how precipitation is coupled (or not) with mesoscale dynamics. There is a need to show what is the added value of regional models. For example, GCMs can produce low-level jets but still do not properly represent the diurnal cycle of precipitation. Roads mentioned that little attention has previously been given to diurnal variations in the reanalysis.
Liston questioned whether we are ready to release the data sets to others and that we should take time to make sure that the models are at a credible stage. Takle mentioned WGNE and CLIVAR are looking to PIRCS to show added value from regional models. Gutowski noted that PIRCS has ongoing cooperation with MERCURE and that we should proceed in a timely manner in order to share information with them. Hakkarinen mentioned the push for regional impacts for the IPCC TAR and the U.S. national assessment of the state of science of impacts of climate change. New GCM runs also will be done with intent of serving as drivers for regional models. Roads says we need to push for the first paper but for the second we need more of a critical mass of participants, encouraging others to collaborate with us. Roads mentioned Fall AGU as a target date for another meeting.
Pielke suggested the first (overview) paper be submitted for the GCIP special issue of JGR, for which manuscripts are due September 1. Roads mentioned that this would be highly visible. Such a date would be reasonable for the overview paper but the "science" paper would have to be later. Roads suggested a focus on aspects of the hydrological cycle, e.g., evaporation and runoff, and distribution between convective and nonconvective precipitation. Liston recommended that the overview paper include results for upper level heights. Roads says we need to show differences from reanalysis. We could also show differences between 1993 and 1988 in the LLJ, perhaps a sample from one or a few models.
List of acronyms and abbreviations
EPRI - Electric Power Research Institute
GCIP - GEWEX Continental-scale International Project
GEWEX - Global Energy and Water cycle Experiment
LLJ - Low Level Jet
MERCURE - Modeling European Regional Climate: Understanding and Reducing Uncertainties (research program sponsored by the European Community)
NCAR - National Center for Atmospheric Research
TAR - Third Assessment Report (Intergovernmental Panel on Climate Change)
WGNE - Working Group on Numerical Experimentation (World Meteorological Organization)