Namelist defaults.
|
Functions/Subroutines |
|
subroutine | init_namelist |
Variables |
|
integer, parameter | LONG = selected_int_kind(9) |
|
integer(kind=LONG) | nP = 1000 |
| | Number of particles to use.
|
|
real | particleSize = 10.0e-04 |
| | Gaussian particle size in %c.
|
|
logical | gParticle = .false. |
| | Use gaussian particle shape or not.
|
|
character(len=100) | pl_fileName |
| | Input particle list filename.
|
|
character(len=100) | eqdsk_fileName |
| | Input gEqDsk filename.
|
|
real | vPerInRange = 2.0 |
| | vPer grid range in %c
|
|
real | vParInRange = 2.0 |
| | vPar grid range in %c
|
|
integer | sR = 6 |
| | Number of grid points to span with gaussian. Note: choosing a value to small may give discontiuities for large particleSize values.
|
|
integer | R_nBins = 10 |
| | Number of bins in R (Major radius).
|
|
integer | z_nBins = 20 |
| | Number of bins in z (Vertical).
|
|
integer | vPerp_nBins = 64 |
| | Number of vPer bins. Note: set this value low (~16) when gParticle = .false.
|
|
integer | vPar_nBins = 128 |
| | Number of vPar bins. Note: set this value low (~32) when gParticle = .false.
|
|
real | amu = 1.0 |
| | 1.0 for H, 2.0 for D, etc ...
|
|
logical | plotOrbit = .false. |
| | Use DISLIN to plot the orbits when noAveraging = .false. but this only works on dlg-hp now and is primarily for debugging. So leave it off.
|
|
logical | NFO = .false. |
| | Compute orbits without finite orbits.
|
|
logical | noAveraging = .false. |
| | No orbit averaging, just particles where they are.
|
|
logical | pList_is_nCDF = .true. |
| | If using a DLG netCDF input particle list set this. This is used in the sMC-rf code or when re-mapping the ORBIT-rf output on a high resolution sMap grid.
|
|
real | weightLimit = 1.1e18 |
| | If the particle weight is above this number the particle is ignored.
|
|
real | traceStepLength = 0.002 |
| | Approximate step length [m] of integrator in m.
|
|
integer | usePtsPerTrack = 50 |
| | Approximate number of points to use from each track in the orbit averaging.
|
Namelist defaults.


The place ID, address, or textual latitude/longitude value to which you wish to calculate directions. The options for the destination parameter are the same as for the origin parameter.
The place ID, address, or textual latitude/longitude value from which you wish to calculate directions.
Place IDs must be prefixed with place_id:
. You can
retrieve place IDs from the Geocoding API and the Places API
(including Place Autocomplete). For an example using place IDs from
Place Autocomplete, see
Place Autocomplete and Directions. For more about place IDs, see the
Place ID overview.
origin=place_id:ChIJ3S-JXmauEmsRUcIaWtf4MzE
If you pass an address, the Directions service geocodes the string and converts it to a latitude/longitude coordinate to calculate directions. This coordinate may be different from that returned by the Geocoding API, for example a building entrance rather than its center.
origin=24+Sussex+Drive+Ottawa+ON
Using place IDs is preferred over using addresses or latitude/longitude coordinates. Using coordinates will always result in the point being snapped to the road nearest to those coordinates - which may not be an access point to the property, or even a road that will quickly or safely lead to the destination.
If you pass coordinates, the point will snap to the nearest road. Passing a place ID is preferred. If you do pass coordinates, ensure that no space exists between the latitude and longitude values.
origin=41.43206,-81.38992
Plus codes must be formatted as a global code or a compound code.
Format plus codes as shown here (plus signs are url-escaped to
%2B
and spaces are url-escaped to %20
).
849VCWC8%2BR9
).
CWC8%2BR9%20Mountain%20View%20CA%20USA
).
If set to true
, specifies that the Directions service may
provide more than one route alternative in the response. Note that
providing route alternatives may increase the response time from the
server. This is only available for requests without intermediate
waypoints. For more information, see the
guide to waypoints.
Specifies the desired time of arrival for transit directions, in seconds
since midnight, January 1, 1970 UTC. You can specify either
departure_time
or arrival_time
, but not both.
Note that arrival_time
must be specified as an integer.
Indicates that the calculated route(s) should avoid the indicated features. This parameter supports the following arguments:
tolls
indicates that the calculated route should avoid toll
roads/bridges.
highways
indicates that the calculated route should avoid
highways.
ferries
indicates that the calculated route should avoid
ferries.
indoor
indicates that the calculated route should avoid
indoor steps for walking and transit directions.
It's possible to request a route that avoids any combination of tolls, highways and ferries by passing multiple restrictions to the avoid parameter. For example:
avoid=tolls|highways|ferries.
Specifies the desired time of departure. You can specify the time as an
integer in seconds since midnight, January 1, 1970 UTC. If a
departure_time
later than 9999-12-31T23:59:59.999999999Z is
specified, the API will fall back the departure_time
to
9999-12-31T23:59:59.999999999Z. Alternatively, you can specify a value of
now, which sets the departure time to the current time (correct to the
nearest second). The departure time may be specified in two cases:
departure_time
or arrival_time
.
If neither time is specified, the departure_time
defaults
to now (that is, the departure time defaults to the current time).
departure_time
to receive a route and trip duration
(response field: duration_in_traffic) that take traffic conditions into
account. The departure_time
must be set to the current time
or some time in the future. It cannot be in the past.
The language in which to return results.
language
is not supplied, the API attempts to use the
preferred language as specified in the
Accept-Language
header, or the native language of the
domain from which the request is sent.
For the calculation of distances and directions, you may specify the
transportation mode to use. By default, DRIVING
mode is used.
By default, directions are calculated as driving directions. The following
travel modes are supported:
DRIVING
(default) indicates standard driving directions or
distance using the road network.
WALKING
requests walking directions or distance via
pedestrian paths & sidewalks (where available).
BICYCLING
requests bicycling directions or distance via
bicycle paths & preferred streets (where available).
TRANSIT
requests directions or distance via public transit
routes (where available). If you set the mode to transit, you can
optionally specify either a departure_time
or an
arrival_time
. If neither time is specified, the
departure_time
defaults to now (that is, the departure time
defaults to the current time). You can also optionally include a
transit_mode
and/or a
transit_routing_preference
.
The region code, specified as a ccTLD ("top-level domain") two-character value. Most ccTLD codes are identical to ISO 3166-1 codes, with some notable exceptions. For example, the United Kingdom's ccTLD is "uk" (.co.uk) while its ISO 3166-1 code is "gb" (technically for the entity of "The United Kingdom of Great Britain and Northern Ireland").
Specifies the assumptions to use when calculating time in traffic. This
setting affects the value returned in the duration_in_traffic field in the
response, which contains the predicted time in traffic based on historical
averages. The traffic_model
parameter may only be specified
for driving directions where the request includes a
departure_time
. The available values for this parameter are:
best_guess
(default) indicates that the returned
duration_in_traffic should be the best estimate of travel time given
what is known about both historical traffic conditions and live traffic.
Live traffic becomes more important the closer the
departure_time
is to now.
pessimistic
indicates that the returned duration_in_traffic
should be longer than the actual travel time on most days, though
occasional days with particularly bad traffic conditions may exceed this
value.
optimistic
indicates that the returned duration_in_traffic
should be shorter than the actual travel time on most days, though
occasional days with particularly good traffic conditions may be faster
than this value.
The default value of best_guess
will give the most useful
predictions for the vast majority of use cases. It is possible the
best_guess
travel time prediction may be shorter than
optimistic
, or alternatively, longer than
pessimistic
, due to the way the
best_guess
prediction model integrates live traffic
information.
Specifies one or more preferred modes of transit. This parameter may only be specified for transit directions. The parameter supports the following arguments:
bus
indicates that the calculated route should prefer
travel by bus.
subway
indicates that the calculated route should prefer
travel by subway.
train
indicates that the calculated route should prefer
travel by train.
tram
indicates that the calculated route should prefer
travel by tram and light rail.
rail
indicates that the calculated route should prefer
travel by train, tram, light rail, and subway. This is equivalent to
transit_mode=train|tram|subway
.
Specifies preferences for transit routes. Using this parameter, you can bias the options returned, rather than accepting the default best route chosen by the API. This parameter may only be specified for transit directions. The parameter supports the following arguments:
less_walking
indicates that the calculated route should
prefer limited amounts of walking.
fewer_transfers
indicates that the calculated route should
prefer a limited number of transfers.
Specifies the unit system to use when displaying results.
Directions results contain text within distance fields that may be displayed to the user to indicate the distance of a particular "step" of the route. By default, this text uses the unit system of the origin's country or region.
For example, a route from "Chicago, IL" to "Toronto, ONT" will display results in miles, while the reverse route will display results in kilometers. You may override this unit system by setting one explicitly within the request's units parameter, passing one of the following values:
metric
specifies usage of the metric system. Textual
distances are returned using kilometers and meters.
imperial
specifies usage of the Imperial (English) system.
Textual distances are returned using miles and feet.
Specifies an array of intermediate locations to include along the route
between the origin and destination points as pass through or stopover
locations. Waypoints alter a route by directing it through the specified
location(s). The API supports waypoints for these travel modes: driving,
walking and bicycling; not transit. You can supply one or more locations
separated by the pipe character (|
or %7C
), in
the form of a place ID, an address, or latitude/longitude coordinates. By
default, the Directions service calculates a route using the waypoints in
the order they are given. The precedence for parsing the value of the
waypoint is place ID, latitude/longitude coordinates, then address.
place_id:
.
You can retrieve place IDs from the Geocoding API and the Places API
(including Place Autocomplete). For an example using place IDs from
Place Autocomplete, see
Place Autocomplete and Directions. For more about place IDs, see the
Place ID overview.
%2C
) and not a space (%20
) separates the
latitude and longitude values.
enc:
and
followed by a colon (:
). For example:
waypoints=enc:gfo}EtohhU:
.
|
). For example,
waypoints=via:enc:wc~oAwquwMdlTxiKtqLyiK:|enc:c~vnAamswMvlTor@tjGi}L:|
via:enc:udymA{~bxM:
For each waypoint in the request, the directions response appends an entry
to the legs
array to provide the details for stopovers on
that leg of the journey.
If you'd like to influence the route using waypoints without adding a
stopover, add the prefix via:
to the waypoint. Waypoints
prefixed with via:
will not add an entry to the
legs
array, but will route the journey through the waypoint.
The following URL modifies the previous request such that the journey is routed through Lexington without stopping:
https://maps.googleapis.com/maps/api/directions/json?
origin=Boston,MA&destination=Concord,MA
&waypoints=Charlestown,MA|via:Lexington,MA
The via:
prefix is most effective when creating routes in
response to the user dragging the waypoints on the map. Doing so allows
the user to see how the final route may look in real-time and helps ensure
that waypoints are placed in locations that are accessible to the
Directions API.
By default, the Directions service calculates a route through the provided
waypoints in their given order. Optionally, you may pass
optimize:true
as the first argument within the waypoints
parameter to allow the Directions service to optimize the provided route
by rearranging the waypoints in a more efficient order. (This optimization
is an application of the traveling salesperson problem.) Travel time is
the primary factor which is optimized, but other factors such as distance,
number of turns and many more may be taken into account when deciding
which route is the most efficient. All waypoints must be stopovers for the
Directions service to optimize their route.
If you instruct the Directions service to optimize the order of its
waypoints, their order will be returned in the
waypoint_order
field within the routes object. The
waypoint_order
field returns values which are zero-based.
The following example calculates a road journey from Adelaide, South Australia to each of South Australia's main wine regions using route optimization.
https://maps.googleapis.com/maps/api/directions/json?
origin=Adelaide,SA&destination=Adelaide,SA
&waypoints=optimize:true|Barossa+Valley,SA|Clare,SA|Connawarra,SA|McLaren+Vale,SA
Inspection of the calculated route will indicate that calculation uses waypoints in the following waypoint order:
"waypoint_order": [ 3, 2, 0, 1 ]
Generated from the OpenAPI specification. Edit Report bug


Uruha:
The malignant spirit of Shilen? The devourer of innocents? Please, leave these miserable creatures alone. They have suffered enough.


wildscribe:help
Full name:
org.jboss.wildscribe:wildscribe-maven-plugin:2.0.0.Final:help
Description:
Display help information on wildscribe-maven-plugin.
Call mvn wildscribe:help -Ddetail=true -Dgoal=<goal-name> to display parameter details.
Call mvn wildscribe:help -Ddetail=true -Dgoal=<goal-name> to display parameter details.
Attributes:
Optional Parameters
| Name | Type | Since | Description |
|---|---|---|---|
| detail | boolean | - | If true, display all settable properties for each
goal. Default value is: false. User property is: detail. |
| goal | String | - | The name of the goal for which to show help. If unspecified, all
goals will be displayed. User property is: goal. |
| indentSize | int | - | The number of spaces per indentation level, should be positive. Default value is: 2. User property is: indentSize. |
| lineLength | int | - | The maximum length of a display line, should be positive. Default value is: 80. User property is: lineLength. |
Parameter Details
If true, display all settable properties for each
goal.
- Type: boolean
- Required: No
- User Property: detail
- Default: false
goal:
The name of the goal for which to show help. If unspecified, all
goals will be displayed.
- Type: java.lang.String
- Required: No
- User Property: goal
The number of spaces per indentation level, should be positive.
- Type: int
- Required: No
- User Property: indentSize
- Default: 2
The maximum length of a display line, should be positive.
- Type: int
- Required: No
- User Property: lineLength
- Default: 80


About
HIPI is designed to provide a clean and simple interface for performing efficient and high-throughput image processing within the Apache Hadoop MapReduce framework. HIPI was created by Sean Arietta, Jason Lawrence, Liu Liu, and Chris Sweeney working together at the University of Virginia Computer Graphics Lab. HIPI has been used in a number of projects and even gained some press.
The initial development of HIPI was supported in part by the National Science Foundation through a Cluster Exploratory (CluE) grant IIS-0844416 ("Image Super-Resolution using Trillions of Examples") and with resources generously made available by IBM and Google.
The initial development of HIPI was supported in part by the National Science Foundation through a Cluster Exploratory (CluE) grant IIS-0844416 ("Image Super-Resolution using Trillions of Examples") and with resources generously made available by IBM and Google.
Core Team
| Liu Liu is a former undergraduate student at the University of Virginia. He now works at Facebook and has made numerous contributions to the popular OpenCV library. | Chris Sweeney is a former undergraduate student at the University of Virginia. He is now a graduate student at the University of California at Santa Barbara where his research investigates various topics in computer vision including SLAM systems and 3D scene reconstruction. | ||
| Sean Arietta is former graduate student at the University of Virginia. He is now a PhD student at the University of California at Berkeley. Sean's research focuses on applications of Internet-scale image processing. | Jason Lawrence is associate professor in the Department of Computer Science at the University of Virginia. In addition to large-scale image processing, his research interests include real-time and global illumination rendering algorithms and methods for general appearance capture. | ||
| Zack Verham is a current undergraduate student at the University of Virginia. He will be graduating in May of 2015 and will be entering a Master's program at the University of Virginia with a continued focus in image processing. |


Class 3: Introduction to Statistical Learning Theory
Slides
Class 2: Why do we need causal inference?
Slides
Class 1: Introduction, Causation
Schedule
Everyone wanting to be in the class should:
- Submit the MMM Pre-Semester Survey
- Join the Course Slack
- Start forming a team for Project 1 (you can use the
#teaming
channel in slack to find teammates). Your team should be 2 Econ majors and 2 CS majors. (If you don’t find a full team, we will help form teams at Thursday’s class.)
Slides
Beginning of Semester Survey
Please submit this survey to register for the class:
https://forms.gle/5gmDkR5xnA6xFfst5
(You should do this if you want to take the class, whether or not you are officially enrolled in it now.)
Welcome
Welcome to the website for the joint Economics/Computer Science course, Markets, Mechanisms, and Machines.
More information will be posted here soon. For now, you can get a rough idea what the course will be like by looking at the Spring 2019 version of the course.
Final Projects
You can see the final projects from last year’s class here: https://uvammm.github.io/s19/finalreports/. You’ll have more time for the final project this year than they did, and we have higher expectations for what you’ll be able to do, but several of the projects there are quite


| Vikoflex 7170 General Information
-
| Synonyms: |
ESO; Epoxidized soybean oil |
| Molecular Formula: |
C57H76O18 (approx) |
| Molecular Weight: |
1000 (approx) |
| CAS Registry No.: |
8013-07-8 |
| Chemical Category: |
Epoxides |
| Oxirane Oxygen, wt. %: |
7.0 min |
Usage and Performance Characteristics
-
| Manufacturer: |
Atofina Chemicals, Inc. |
| Outstanding Properties: |
Heat & light stability, low volatility, oil & detergent resistance, low viscosity |
| Used for Polymeric Materials: |
PVC, PVA emulsion, chlorinated rubber, NC |
| Used for Products: |
Floor covering, coated fabrics, wire & cable |
| Extraction, hexane 24 h at 25°C, 50 phr, %: |
2.5 |
Physical Properties
-
| Specific Gravity: |
0.993 (25°C) |
| Aggregate State at 25°C: |
Viscous liquid |
| Tensile Strength, MPa: |
19.08 (50 phr) |
| 100% Modulus, MPa: |
10.93 (50 phr) |
| Clash-Berg Temperature, °C: |
-11 (50 phr) |
| Ultimate Elongation, %: |
377 (50 phr) |
| Volume Resistivity, Ohm cm: |
8E+13 |
Chemical Properties
-
| Acid Number, mg KOH/g: |
0.5 (max) |
Optical Properties
-
| Color, Platinum-Cobalt Scale: |
<150 |
| Refractive Index: |
1.472 (n25D) |
Hazard-Related Data
-
| OSHA Hazard Class: |
Not considered a hazardous substance |
| UN Risk Phrases: |
37/38,43 |
| Eye Irritation (human): |
Slight (rabbits) |
| Flash Point Temperature, °C: |
315 |
| HMIS Personal protection: |
Rubber gloves, eye protection |
| Skin Irritation: |
Slight (rabbits) |
Animal Toxicity
-
| Rabbit Dermal, LD50, mg/kg: |
>19,900 |
| Rat Oral, LD50, mg/kg: |
22,400 |
Plasticizers Database (2nd Electronic Edition) Copyright © 2004 by ChemTec Publishing |


-
Champagne is your favorite summer drink?
-
You are pretty much the loudest person in every room?
-
Scary movies are my favorite?
-
I see myself as disorganized?
-
I see myself as dependable?
-
Black Color Looks Best On You?
-
I typically do not rise before noon?
-
Your family motivates you?
-
Christmas is your favority holiday?
-
Family time with kids is your favorite activity?


WEB SITE
Home
home1
home2
home3
About
Contact
this is a website that is used to display blocks
this is the second block and ther is a lot of paragraphs to study
this is just a beginning to great adventures
this is a sample demonstration of flexbox
click me


My career over the last 16 years has gone from working in a distribution center as an order filler to working in IT for Hallmark Cards. In 2015 I began pursuing an Associates degree in Computer Science. I learned backend languages C++ and C# with some SQL. After graduating in 2017 I joined FreeCodeCamp.com to earn my certificate in Front End Web Development. Currently I am studying Java in addition to growing my skills with C# and .Net Core.
Coding is a creative outlet for me. There is something about coding that when I build something I am creating something meaningful. I have always believed art is created for users to enjoy and consume and to be filled with joy. When I began to learn Front End development I began to see the possibilities to create something meaningful when coding.
Below you will find my personal projects I have worked on and my goals as a developer. Enjoy looking around and I hope to hear from you.
Currently in progress. I began learning Java as a requirment for an opportunity I have at my current job.
Because Java is an Object Oriented language it will be very similar to C++ and C#.
Learning C++, C#, and .Net was a requirement of completing my Associates. In my coursework we created classes, models, views, databases, and controllers for our projects.
After completing my Associates I took the initiative to learn Front End development through FreeCodeCamp.org.
I completed my certification for front end web development in 2018. I am very comfortable in using CSS and Bootstrap
I recently began learning JQuery to add to my skills on the front end.
I am able to create databases and the tables that are needed. I am working on learning on how to query the DB and learning other commands in the database.
Image by Ronny Overhate from Pixabay
With 16 years of corporate experience I have developed a strong business acumen.
Additionally I have:
My goal is to become a Full Stack Developer. Currently I feel very comfortable with Front End development and creating classes on the Backend.


This book has been put on-line as part of the BUILD-A-BOOK Initiative at the Celebration of Women Writers.
Initial text entry and proof-reading of this book were the work of John Mark Ockerbloom and Mary Mark Ockerbloom.
Illustrations may vary somewhat in size, color, and placement from the original.
Original: http://digital.library.upenn.edu/women/williams/rabbit/rabbit.html


Wild-Bruins Sums
by EndPlayFirst Period_1, Minnesota, Zucker 8 (Hunt, Zuccarello), 8:53 (pp). Penalties_Spurgeon, MIN, (hooking), 1:07; Chara, BOS, (hooking), 3:55; Krug, BOS, (slashing), 8:46; Marchand, BOS, (roughing), 11:25; Dumba, MIN, (roughing), 11:25; McAvoy, BOS, (tripping), 12:56.
Second Period_2, Boston, DeBrusk 4 (Ritchie, Chara), 4:14. 3, Minnesota, V.Rask 2 (Spurgeon, Suter), 6:14. 4, Minnesota, Staal 7 (Suter, Zuccarello), 14:26 (pp). 5, Boston, Marchand 16 (Bergeron, Krug), 19:56. Penalties_Chara, BOS, major (high sticking), 12:43; Marchand, BOS, (cross checking), 17:14.
Third Period_6, Minnesota, Fiala 5, 5:19. 7, Boston, Krejci 3 (DeBrusk, Bergeron), 18:05. 8, Boston, Krejci 4 (Bergeron, Krug), 18:53 (pp). Penalties_Bergeron, BOS, (tripping), 0:30; V.Rask, MIN, (holding), 14:39; Kunin, MIN, (tripping), 18:29.
Overtime_9, Boston, Krug 3 (Marchand, Bergeron), 2:41. Penalties_None.
Shots on Goal_Minnesota 15-11-7-3_36. Boston 10-13-15-1_39.
Power-play opportunities_Minnesota 2 of 7; Boston 1 of 3.
Goalies_Minnesota, Stalock 5-3-1 (39 shots-34 saves). Boston, T.Rask 11-2-2 (36-32).
A_17,850 (17,565). T_2:46.
Referees_Steve Kozari, Tim Peel. Linesmen_Devin Berg, Jesse Marquis.


Functions to create and handle sparse arrays and matrix operations. More...
Modules | |
| dense | |
| Returns a dense array from a sparse input. | |
| sparse | |
| Create a sparse array. | |
| sparseConvertTo | |
| Convert an existing sparse array into a different storage format. | |
| sparseGetColdx | |
| Returns reference to the column indices component of the sparse array. | |
| sparseGetInfo | |
| Returns reference to components of the input sparse array. | |
| sparseGetNNZ | |
| Returns the number of non zero elements in the sparse array. | |
| sparseGetRowIdx | |
| Returns reference to the row indices component of the sparse array. | |
| sparseGetStorage | |
| Returns the storage type of a sparse array. | |
| sparseGetValues | |
| Returns reference to the values component of the sparse array. | |
Functions to create and handle sparse arrays and matrix operations.
Sparse array in ArrayFire use the same af::array (or af_array) handle as normal. Internally, this handle is used to maintain a structure of the sparse array (components listed below).
| Description | Data Type |
|---|---|
| Values | T (one of f32, f64, c32, c64) |
| Row Indices | Int (s32) |
| Column Indices | Int (s32) |
| Storage | af::storage |
The value array contains the non-zero elements of the matrix. The af::dtype of the value array is the same as that of the matrix. The size of this array is the same as the number of non-zero elements of the matrix.
The row indices and column indices contain the indices based on af::storage type. These af::array are always of type s32.
The af::storage is used to determin the type of storage to use. Currently AF_STORAGE_CSR and AF_STORAGE_COO are available.
A sparse array can be identied using the af::array::issparse() function. This function will return true for a sparse array and false for a regular af::array.
The valid operations on sparse arrays are af::matmul (sparse-dense). When calling matmul for sparse matrices, the sparse array is required to be the left hand side matrix and can be used with transposing options. The dense matrix on the right hand side cannot be used with any transpose options.
Most functions cannot use sparse arrays and will throw an error with AF_ERR_ARG if a sparse array is given as input.


10
1 All the people of northern Israel went to the city Shechem in order to appoint Rehoboam to be their king. So Rehoboam also went there.
2 Jeroboam son of Nebat, fled to Egypt to escape from King Solomon. But when he heard about the people wanting to appoint Rehoboam to be their king, he returned from Egypt to Israel.
3 So the leaders of the northern tribes summoned Jeroboam, and he went with them to talk to Rehoboam. They said to Rehoboam,
4 "Your father Solomon forced us to work very hard, but if you charge us fewer taxes than we were paying to him, and if you make us work not so much we will serve you faithfully."
5 He replied, "Come back three days from now, and I will give you my answer." So those leaders and Jeroboam left.
6 Then King Rehoboam consulted his older men who had advised his father Solomon while he was still alive. He asked them, "What shall I say to answer these men?"
7 They replied, "If you will be kind to these people and do things that will please them, and if you say kind things to them when you answer them, they will always serve you."
8 But he did not agree with what the older men advised him to do. Instead, he consulted the younger men who had grown up with him, who were now his advisors.
9 He said to them, "What do you say that I should answer the men who are asking me to reduce the work and taxes that my father required from them?"
10 The young men who had grown up with him replied, "Those men have said that your father forced them to work very hard for him , so they want you to reduce the work and taxes that your father required from them. But this is what you should tell them: 'My little finger is thicker than my father's waist.'
11 What we mean is that your father required the people to work hard and pay high taxes. But tell them that you will make those loads heavier. It was as though your father whipped them with leather whips, but you will whip you with scorpions."
12 Three days later, Jeroboam and all the leaders came to King Rehoboam again, as he had instructed them to do.
13 The king ignored the advice of the older men and spoke harshly to the Israelite leaders.
14 He told them what the younger men had advised. He said, "My father put heavy burdens of work and taxes on you, but I will put heavier burdens on you. It was as though he beat you with whips, but I will beat you with scorpions!"
15 So the king did not pay any attention to the people's leaders. All this happened in order that what Yahweh wanted would occur, what he had told the prophet Ahijah about Jeroboam becoming king of the ten tribes out of the twelve.
16 When the Israelite leaders realized that the king did not pay any attention to what they said, they shouted,
"We do not want anything to do with this descendant of King David!
We will not pay attention to what this grandson of Jesse says!

As for this descendant of David, he can look after his family himself!"
So the Israelite leaders returned to their homes.
17 And after that, the only Israelite people whom Rehoboam ruled over were those who lived in the territory of the tribe of Judah, in the countryside and in the cities, towns, and villages.
18 Then King Rehoboam went with Adoniram to talk to the Israelite people. Adoniram was the man who supervised all the men who were forced to work for Rehoboam. But the Israelite people killed him by throwing stones at him. When that happened, King Rehoboam quickly got in his chariot and escaped to Jerusalem.
19 Ever since that time, the people of the northern tribes of Israel have been rebelling against the descendants of King David.


MVA.Rmd
This tutorial illustrates a multivariate statistical analysis workflow for NMR-based metabolic profilig using the metabom8 R package.
Proton (1H) NMR data are available in the nmrdata package (www.github.com/tkimhofer) and constitute standard 1D experiments acquired from murine urine samples. Samples were collected longitudinally with a single collection point before and multiple collection points after bariatric surgery was performed. Data acquisition was performed on a 600 MHz Bruker Avance III spectrometer, equipped with a 5 mm triple resonance (TXI) probe operating at 300 K. Further information on study design, experimental setup and data collection can be found in Jia Li et al.1
# For reproducibility set.seed(153)
Data have been preprocessed as illustrated in Tutorial I. In short, spectral reagions that bear no quantitative or biological information were excised and baseline correction was performed proir to spectral normalisation with probabilistic quotient normalisaion (PQN).
Let’s get started with the analysis:
Pre-processed data are imported with the data
command. The data are saved as a list and the first task is to assign each list element to a variable.
# Load data data(bariatric) # Declare variables Xn<-bariatric$X.pqn # PQN-normalised NMR data matrix dim(Xn) #> [1] 67 56357 ppm<-bariatric$ppm # chemical shift vector in ppm length(ppm) #> [1] 56357 meta<-bariatric$meta # spectrometer metadata dim(meta) #> [1] 67 417 an<-bariatric$an # sample annotation dim(an) #> [1] 67 4 # list all environment varaibales ls() #> [1] "an" "bariatric" "meta" "ppm" "Xn"
The following variables should be in the R workspace after executing the code snippet above:
Let’s start with a visual inspection of the pre-processed NMR spectra using the matspec() function:
The pre-processed specra range from 0.5 to 9.5 ppm, the water signal has been removed and the baseline is fairly flat.
In the first analysis step, data are interrogated using Principal Component Analysis (PCA). PCA is a compression technique that represents the high-dimensional spectrometric data (this relates to the number of spectral variables, here > 56,300) with only a few latent (in the sense of unobserved) components. Each PCA component, referred to as principal component (PC), is a composite of the original variables, formed by weighting and linearly combining the original variables. The weightings (referred to as PCA loadings) are determined to preserve systematic variation trends across samples. Collinear variables, e.g., metabolites that share structural or biological relationships, have similar PC weightings, and different PC’s describe different variation trends.
Typically, PCA allows to become a fairly good overview of variable patterns by looking at the first few PCA components.
In metabom8, a PCA can be calculated with the pca() function. Input arguments are the pre-processed NMR matrix (X=Xn), information on the desired number of principal components (pc=2) and variable centering and scaling parameters. Here the data will autoscaled, this includes mean centering (center=TRUE) and unit variance scaling (scale=“UV”).
# Perform PCA pca_model=pca(X=Xn, pc=2, scale='UV', center=TRUE)
The variable pca.model is an R object that contains different slots containing information about the PCA model - this includes PCA scores (t) and loadings (p) for each of the principal components.
Visualising PCA scores can be achieved with the plotscores() and plotload() functions. The input of this function is the pca model (model=pca.model), further input parameters include axis definition (which principal components are plotted in x/y space, pc=c(1,2)) and a list object with its first element specifying the point colouring variable (an=list([variable])).
In this example, point colour should indicate the treatment (eg. surgical procedure), which is either none (Pre-op), Roux-en-Y gastric bypass (RYGB, a type of bariatic surgery) or sham surgery2. The latter is a control group, included to account for incidential effects induced by the surgical procedure (anesthesia, incision, etc.).
# Plot PCA results: scores of the first two components plotscores(obj=pca_model, pc=c(1,2), an=list(Surgery=an$Class), title='PCA - Scores plot')
The produced scatterplot shows PCA scores of the first two PCs, plotted in x/y space. Each point represents an NMR spectrum (row of the matrix Xn). The percentages in the axis labels describe the amount of variation that is accounted for by the repsective PC, relative to the total amount of variation in the data (this number is also termed R2). The dotted ellipse represents the Hotelling’s T2, this is a statistical measure to identify outlier samples and can be thought of a multivariate generalisation of a confidence interval.
Additional graphics parameters can be passed to the plotscores() function. For example, point shape and text labels are included as list element two and three of an, repsectively. See the following code for an example:
# define scores that should be labelled idx<-which(pca_model@t[,2]>20 & an$Class=='RYGB') # PC 2 scores above 20 and in group RYGB # construct label vector with mouse IDs outliers<-rep('', nrow(an)) outliers[idx]<-an$ID[idx] # Plot PCA scores, colour according to class, point shape according to time of sample collection and label outliers plotscores(obj=pca_model, pc=c(1,2), an=list( Class=an$Class, # point colour Timepoint=an$Timepoint, # point shape ID=outliers), # point label title='PCA - Scores plot')
In NMR-based metabonomics, PCA loadings are visualised as a line plot that resembles an NMR spectrum. In metabom8, this is achieved with the plotload() function. The funtion’s input arguments are the PCA_metabom8 model (mod=pca_model) and the number of the PC to be visualised (eg., pc=1). The code snipped below, the first and second PC loadings are visualised (one at a time), with the latter focussing on the aromatic chemical shift region (6 - 9 ppm).
# Plot PCA loadings plotload(mod=pca_model, pc=1) # 1st principal component plotload(mod=pca_model, pc=2) # 2ndt principal component plotload(mod=pca_model, pc=2, shift=c(6,9)) # 2ndt principal component chemical shift reagion 6-9 ppm
In the loadings plot, the x axis describes the chemical shift of each variable, just like in an ordinary NMR spectrum, the y axis is the covariance of the PCA scores and original spectral variables (indicating the peak magnitude and positive or negative model loadings), and the colour represents the PC loading for each variable normalised to range between zero and one. PCA loadings and scores plot are linked such that peaks coloured towards the red colour spectrum are characteristic for spectra with postive (negative) scores when these point up (down) in the loadings plot.
A scores clustering trend according to surgery type is visible in PCA scores plot. However, PCA is an unsupervised analysis method and is not designed to tease out data patterns related to group effects (eg., sham vs RYGB surgery) or numeric trends related to an outcome variable (eg., recovery time after surgery). Performing PCA with NMR spectra derived from human urine samples typically highlights environmental effects (e.g., diet and drug metabolites) in the first few principal components. In contrast, the murine individuals were housed in a controlled enviroment (with defined diet and day/night cycle), which greately reduces the metabolic variation so that the treatment effects can already be observed in the first two PCA components.
To explicitly model study group effects, sham vs RYGB surgery, we use an extension of a supervised analysis method called Orthogonal-Projections to Latent Structures or also known as Orthogonal Partial Least Squares (O-PLS).3
O-PLS can be seen as a supervised extension of PCA, where the NMR data matrix (usually termed X) is related to an external variable (usually termed Y) that encodes study outcome information (eg. Sham vs RYGB surgery). O-PLS is separating systematic data variation into Y-predictive and Y-orthogonal, creating a single predictive component and one or more orthogonal components. Consequently, only the predictive component is interpreted in relation to Y. The orthogonal component(s) often encode(s) information related to technical matters (eg., analytical batch effects).
The number of O-PLS orthogonal components must be carefully chosen based on the amount of data variation that is related to the oucome variable Y. If the number of components is too low, the model is underfitted and does not accurately represent the data. In contrast, if too many orthogonal components are fitted, the model describes patterns that are specific to only this one data set (eg. instrumental noise) and these patterns are unrelated to the outcome variable. This is termed data overfitting. O-PLS models that underfit or overfit the data can lead to inaccurate interpretations. So how can one estimate the optimal number of components?
Statistical resampling techniques are employed to determine the optimal number of orthogonal components in O-PLS context. In essence, a subset of spectra are used to generate an O-PLS model (training set) and the remaining subset is used to validate this model (valiation set). In regression context (continuous Y), validation means comparing predicted Y values for the validation set with the original Y variable values. The index that summarises the accuracy of the prediction is termed Q^2 and ranges from 1 (perfect prediction) to zero or negative values (inaccurate prediction). A high Q^2 value indicates good model fit. In discriminant context (categorical Y), prediction accuracy is assessed using the area under the receiver operator characteristic curve (AUROC_CV). This index ranges from 1 (perfect prediction) to 0 (exact inverted prediction) and values around 0.5 indicate no predictive capacity at all.
In metabom8, the number of components is automatically determined based on the Q^2 and AUROC_CV in regression or discrimnant context, respectively.
An O-PLS model is calculated with the function olps(). The function’s minimum input arguments are the the NMR data matrix (X=Xn) and the outcome variable(s) of interest (Y=[outcome variable], eg., the surgical procedure). There are a number of other input parameters, such as the statistical validation method to estimate model fit; However, these are not considered at this point and further information can be found in the help section (?opls).
# Exclude pre-op group idx=an$Class!='Pre-op' X=Xn[idx,] Y=an$Class[idx] # Train O-PLS model opls.model=opls(X,Y)
The model summary plot above describes the O-PLS parameters, with each set of bars corresponding to one fitted predictive and the specied number of orthogonal compononents. As you can see, the final model comprises one predictive and one orthogonal components (labelled 1+1). The set of bars on the right-hand side of the plot (slightly transparent) correspond to a model with 1 predictive and 2 orthogonal components (one orthogonal component more than found appropriate). This information is included for comparative purposes and for the evaluation of the automatic stop criteria.
The model summary can also be returned as a table with the following command:
opls.model@summary
| PC_pred | PC_orth | R2X | AUROC | AUROC_CV |
|---|---|---|---|---|
| 1 | 1 | 0.19 | 1 | 1 |
| 1 | 2 | NA | 1 | 1 |
R2X (R2Y) describes the amount of variation that the model describes in the X (Y) variable space. The range of R2X and R2Y is 0-1, with the latter indicating that all variation is explaine by the model.
The distance to the model in X space (DModX) is a dianostic measure to spot model outliers. The variable X refers to the independent variables, in this case the NMR matrix. We can access the DModX by calling the dmodx() function:
distX=dmodx(mod =opls.model, plot=T)
In the plot above each point represents a sample and the dotted horizontal line represents a 95% confidence interval. This threshold is specific for a particular model and varies for different OPLS models. Samples exceeding the confidence line are considered as moderate outliers. In particular if the DModX plot shows any patterns a further investigation should be untertaken. The distX variable in the above code snippet is a dataframe of DModX values which can be used for further instpections.
O-PLS model results are visualised in the scores plot, where the x-axis represents the predictive component and the y-axis an orthogonal component. The function plotscores() can be used for this taks (see section of PCA scores for function input arguments). An additional input argument is whether cross-validated (CV) scores should be plotted or not. CV scores are derived withing the internal model validation procedure and are considered as statistically robust. See the following code for an example:
# Plot OPLS scores plotscores(obj=opls.model, an=list( Surgery=an$Class[idx], # colouring according to surgery type Timepoint=an$Timepoint[idx]), # linetype according to timepoint title='OPLS - Scores plot', # plot title cv.scores = T) # visualise cross-validated scores
The resuling OPLS CV scores plot shows a perfect separation of both surgery types, with all predictive power focussed on the x-axis (that is characteristic for O-PLS, compared to PLS).
The orthogonal component (y-axis) is - in the mathematical sense - unrelated to the outcome variable Y. In some cases, its interpretation can give some insights about the study samples. In the present case, the first orthogonal O-PLS component is associated with effects resulting from spectral normalisation, which was part of the data pre-processing pipeline (not shown here).
The variable influence on the predictive component can be visualised with the plotload() function which plots a single O-PLS model line plot (see PCA section).
The function’s input argument type can be used to derive different visualisations of the model loadings, that is either a statistical reconstruction using covariances or back-scaled loadings. For details on both of these methods see help(plotload) or the original publication by Cloarec et al..4
The O-PLS loadings plot shown above highlights signals that are systematically different between the RYGB and Sham control group. In many cases, it is helpful to compare the O-PLS model loadings with spectra within certain chemical shift regions. The function specload() can be used for this task. From the loadings plot above we can see that the signals within the region of 7.45 - 7.5 ppm has a high model importance, so let’s have a closer look at this:
specload(mod=opls.model, shift=c(7.3,7.45), an=list( facet=an$Class[idx]), type='backscaled', alp = 0.5, title = 'Overlayed Spectra with Backscaled Loadings')
The colour gradient-filled line located in the upper plot area shows the OPLS model loadings (in this case: backscaled method). Plotted below are overlayed NMR spectra where the colour represents group membership. It is easy to see that there are group-related intensity differences for two multiplets centered around 7.365 and 7.425 ppm, with on average lower intensities in the Sham group.
The following section provides the standard pipeline for the identification of metabolites with high OPLS-DA variable importance.
A single compound/metabolite can have different chemical resonances, ie., it can give rise to multilpe signals in the NMR spectrum. A correlation analysis can help identifying signals from structural relationships. In the field of metabolomics, the spectral correlation analysis is termed Statistical Total Correlaion Spectrsocopy (STOCSY).
# define driver peak (the ppm variable where all other spectral variables will be correlated to) driver1=7.834 # perform stocsy stocsy_model=stocsy(Xn, ppm, driver1) # zoom-in different plot regions plotStocsy(stocsy_model, shift=c(7,8)) plotStocsy(stocsy_model, shift=c(3.9, 4)) # observed signals: # multiplet @ 7.56 # multiplet @ 7.65 # doublet @ 7.84 # doublet @ 3.97 ppm
Identified signal patterns can be used to search spectroscopic databases that provide NMR reference data. One popular NMR reference database in the field of metabolic profiling is the *Human Metabolome Database (HMDB)**.
Navigate to the database website (www.hmdb.ca) und use the NMR search utility to find the identity of the compound using the chemical shift pattern extracted from the OPLS-DA loadings plot. Use a chemical shift tollerance of 0.01 ppm to account for small calibration differences.
The assignment of putative identities via database search based on the supervised analysis of NMR spectra is oftenonly a first step in identifying spectral signals. Further (2D NMR and spike-in) experiments are often performed to characterise completele unknown compounds.
This vignette illustrated multivariate statistical analysis of NMR-based metabolic phenotyping data with PCA and O-PLS-DA using the metabom8 package. Once a statistically robust OPLS model was established, information on variable importance was extracted using different model visualisations. STOCSY was performed to identify strucutural correlations of metabolites and this information was used to search putative metabolite identities on a spectral database.
Li, Jia V., et al. (2011) Metabolic surgery profoundly influences gut microbial-host metabolic cross-talk. Gut 60.9, 1214-1223.↩
In a sham surgery an operation is performed but the surgeon omitts the intended therapeutic procedure.↩
Trygg, J., et al. (2002). Orthogonal projections to latent structures (O-PLS). Journal of Chemometrics, 16.3, 119-28.↩
Cloared, O., et al. (2005). Evaluation of the Orthogonal Projection on Latent Structure Model Limitations Caused by Chemical Shift Variability and Improved Visualization of Biomarker Changes in 1H NMR Spectroscopic Metabonomic Studies. Analytical Chemistry. 77.2, 517-26.↩


Functions for Data Import
All of the below functions can be found in the data_import
module of the package.
The below functions can be used to import delimited data files into Numpy or
Matlab database format.
-
import_del
(in_file, force=False, deli='\t', dec_mark='.', out_ext='npz', out_dir='', pad=0, colheadlines=1)[source]
Import a delimited data file into Numpy or Matlab database format. The file
must have at least two data columns that are separated by deli
.
| Parameters: |
- in_file (str) – The file handle of the delimited file that is to be imported.
- force (bool, optional) – If
True , existing output files will be overwritten during
import. Default is False .
- deli (str, optional) – The delimiter used to separate data columns in the delimited file.
Default is tab.
- dec_mark (str, optional) – The decimal mark of the data file. Default is dot.
- out_ext (str, optional) – The file extension (format) of the output file. Default is
npz
for Numpy database format. Alternative is mat for Matlab
database format.
- out_dir (str, optional) – The absolute or relative path to the output directory. Default is the
current working directory.
- pad (positive int) – The numbers of data columns to skip. For
pad = n , the first
n data columns will not be imported.
- colheadlines (int, optional) – The number of lines spanned by the column headers. If several lines are
spanned, the lines will be merged to generate the column keys in the
output dictionary.
|
| Returns: |
- out_file (str) – A handle to the output file that was generated during import.
- import_status (str) – The import status of
in_file . If True , the file was
successfully imported. If False , file import was attempted and
failed. If None , file import was not attempted (most likely
because an output file with the same name already exists).
- out_dict (dict) – The data that was imported from
in_file .
|
-
import_dir
(in_dir, in_ext='txt', recursive=False, force=False, deli='\t', dec_mark='.', out_ext='npz', out_dir='', print_stat=False, pcs=False, colheadlines=1)[source]
Import all delimited data files in a directory into Numpy or Matlab
database format. Optionally, all data files in a directory and all its
child directories can be imported. The method can be applied to regular
delimited files as well as files generated by test rigs made by PCS
Instruments. All files must have at least two data columns that are
separated by deli
.
| Parameters: |
- in_dir (str) – Path to directory for which to import all files with extension
in_ext . If recursive=True , imports are performed for all
files with extension in_ext in the directory tree with parent
in_dir .
- in_ext (str, optional) – File extension of files to import (without dot). Default is
txt .
- recursive (bool, optional) – If
True , all files in in_dir and all its child
directories are imported. Default is False .
- force (bool, optional) – If
True , existing output files will be overwritten during
import. Default is False .
- deli (str, optional) – The delimiter used to separate data columns in the delimited file.
Default is tab.
- dec_mark (str, optional) – The decimal mark of the data file. Default is dot.
- out_ext (str, optional) – The file extension (format) of the output file. Default is
npz
for Numpy database format. Alternative is mat for Matlab
database format.
- out_dir (str, optional) – The path to the output directory where output databases are stored after
import. By default, files are stored in
in_dir if
recursive=False . If recursive=True , files are stored in
the respective child directories of in_dir if out_dir
is not specified.
- print_stat (bool, optional) – If
True , the current import status is printed to the console.
Default is False .
- pcs (bool, optional) – If
True , the delimited files are treated like files that were
generated using an MTM or EHD2 test rig manufactured by PCS Instruments.
- colheadlines (int, optional) – The number of lines spanned by the column headers. If several lines are
spanned, the lines will be merged to generate the column keys in the
output dictionary.
|
| Returns: |
- in_files (ls of strings) – The file handles of all files for which import was attempted.
- out_files (ls of strings) – The file handles of all output files that were generated during the
import process.
- import_status (ls of bools) – The import status of each file in
in_files . If True ,
the file was successfully imported. If False , file import was
attempted and failed. If None , file import was not attempted
(most likely because an output file with the same name already exists).
|
-
import_pcs
(in_file, force=False, out_ext='npz', out_dir='')[source]
Import a delimited data file that was produced by an MTM, ETM or EHD2 test
rig manufactured by PCS Instruments. The method calls the import_del
method to perform a basic import of a delimited text file, and generates
additional output variables that simplify data analysis.
| Parameters: |
- in_file (str) – The file handle of the delimited file that is to be imported.
- force (bool, optional) – If
True , existing output files will be overwritten during
import. Default is False .
- out_ext (str, optional) – The file extension (format) of the output file. Default is
npz
for Numpy database format. Alternative is mat for Matlab
database format.
- out_dir (str, optional) – The absolute or relative path to the output directory. Default is the
current working directory.
|
| Returns: |
- out_file (str) – A handle to the output file that was generated during import.
- import_status (str) – The import status of
in_file . If True , the file was
successfully imported. If False , file import was attempted and
failed. If None , file import was not attempted (most likely
because an output file with the same name already exists).
- out_dict (dict) – The data that was imported from
in_file .
|
-
merge_del
(in_files, out_file=None)[source]
Merge several delimited data files into a single file. The merged
file contains all data from the data files, in the order given in the
in_files
argument.
No checks are performed to ensure that the data files
have a compatible format, for example the same number of data columns.
| Parameters: |
- in_files (list) – File paths to the files to be merged. Files will be merged in order.
- out_file (str, optional) – Path to output file, including file extension. If no path is provided,
a file name is generated based on the input file names.
|
| Returns: | out_file_abs – Absolute path to the merged file.
|
| Return type: | str
|
-
merge_npz
(in_files, accum=None, safe=True)[source]
Merge npz databases by concatenating all databases in in_files
.
Databases are concatenated in the order given in in_files
.
Database keys for which values are to be accumulated can be given as a list
using the accum
argument. For examples, if all databases have the
key time
, then accum=['time']
will produce a continuous
time axis, adding the last time value of the first database to all time
values of the second database (and so on).
| Parameters: |
- in_files (list) – Paths to database files to merge. Files are merged in order.
- accum (list) – Database keys for which values should be accumulated. Values must be
numeric.
- safe (bool) – If True, checks will be performed to ensure that all databases share the
exact same set of keys and that all keys in
accum are in all
databases. An exception (type KeyError) will be raised if not.
|
| Returns: | merged – Merged data.
|
| Return type: | dict
|
-
split_del
(file, deli='\t', ext='txt', cmin=3, hspan=1, outdir=None, force=False)[source]
Split a delimited data file into several separate data files, if the file
contains more than one block of data. Blocks of data are typically
separated by at least one line of column headers. The first data column
of each data block has to be numeric.
This function is meant to be used on data files where different blocks of
data have different numbers of columns or different column headers. After
splitting the data file into individual data files, import methods like
import_del
can be used on the individual files. If all data should
be merged into a single database afterwards, the merge_npz
function
can be used.
| Parameters: |
- file (str) – Path to the data file.
- deli (str, optional) – Delimiter used to separate data columns in
file
- ext (str, optional) – File extension of output files. Default is
txt
- cmin (int, optional) – Minimum number of columns that a line of data needs to have in order to
be classified as data.
- hspan (int, optional) – Maximum number of non-data lines above each data block that should be
written to individual data files (usually equal to number of lines
spanned by the column headers).
- outdir (str, optional) – Path to output directory. Default is current working directory.
- force (bool) – If True, existing output files will be overwritten. Will raise an
exception if file exists and force is False.
|
| Returns: | outfiles – Paths to output files.
|
| Return type: | list
|


&; metabolic tropical OpenUrl thermal temperatures temperate temperature mayflies rate stoneflies CrossRef Fig. rates elevation high low performance stream Science insects Web oxygen sensitivity stress species higher range mid panel) standard SMR aquatic elevations warming Biology, change different study values climate profiles ascending effects response similar streams (right Pörtner, compared critical descending experience greater measured peak MAX body energy Abstract American Climate Huey, consumption elevations. physiological responses sensitive test tolerance Download FREE Global Text Thermal acclimation chamber differences global temperature, variation (left Figs. Huey Kingsolver, bars circles) did limits mass maximum means observed phase phases results square stressful support (i.e. Chown, Comparative Experimental Figure Open Proceedings Sciences, Table curves data-hide-link-title=""> data-icon-position="" determined environmental errors figure increasing insect mayflies. new non-stressful reflect signs stoneflies, tab typically using (,) (A), Brittain, Brown, Shah Vertical View ability analysis broad calculated comparison contrast, control ectotherms. increase latitude lower mayflies, metabolism outside panel populations previous represent showed streams, time traits vulnerability (e.g., Angilletta, Biological Biology Change Ecology, Mountains Naturalist, Rocky Science, Sunday, T-MR Thus, Verberk, a). aerobic arrows b). case curve decline dispersal ecological ectotherms, evidence example, field growth, increases indicated location mayfly measure native organisms peaks predict rise shown. streams. temperature. temperatures, visible warmer water yellow (A, (B) (C) (black (e.g. (genus (see (white ;<;div Andes Deutsch Dillon Ecology Encalada, Evolution, Funk, Ghalambor, Gilman, Gray However, Integrative National Nature, Navas, PEAK Payne Peckarsky, Plecoptera. Royal S). Savage, Schulte, Shah, Smith, Society Stefan, Temperate Terblanche, Values Ward, accounting air approximate average background biological changes conducted consistent consumption) data differ distribution ecology ectotherm ectotherms elevated elevation, elevations, evolutionary exhibited experiencing feeding functional generally highest history interactions latitudes left like line, model. narrow narrower need onset perlid population. rates, rectangles reflects regions relatively right selection special stream. stress. studies study. suggest swimming typical work °C) °C,


Conduct a simulation study (with numsim at least 500) with n=25 and n=100 observations. Generate data from a true model where Y = 0.5 - 1 * X where the residuals are normal with mean zero but the standard deviation depends on the X’s. Let the distribution of the X’s be uniform [0, 2] and the standard deviation of the residuals be equal to \(0.1+X^2\). Repeat the process for a scenario where your residuals are normally distributed with equal variance = 1 for all X’s. Compare the coverage results and shape of the distribution of the slope parameter.
First we generate the data, fit the model, and extract the slope for the unequal variance problem
numsim <- 2000
gen_sim <- function(n) {
x <- runif(n, min = 0, max = 2)
errors <- rnorm(n, 0, sd = 1 + x^2) # variance is not equal
y <- 0.5 - x + errors
return(data.frame(y, x))
}
fit_slope <- function(n) {
df <- gen_sim(n)
mod <- lm(y ~ x, df)
slope <- coef(mod)['x']
conf <- stats::confint(mod)
covered <- (-1 > conf['x', 1]) && (-1 < conf['x', 2])
return(data.frame(slope, covered))
}
Next we do the same assuming equal variances.
gen_sim_equal <- function(n) {
x <- runif(n, min = 0, max = 2)
errors <- rnorm(n, 0, sd = 1) # variance is equal
y <- 0.5 - x + errors
return(data.frame(y,x))
}
fit_slope_equal <- function(n) {
df <- gen_sim_equal(n)
mod <- lm(y ~ x, df)
slope <- coef(mod)['x']
conf <- confint(mod)
covered <- (-1 > conf['x', 1]) && (-1 < conf['x', 2])
return(data.frame(slope, covered))
}
sims <- list(slopes_equal_25, slopes_25, slopes_equal_100, slopes_100)
df <- data.frame('coverage' = numeric(), 'lower' = numeric(),
'upper' = numeric())
for (sim in sims){
b <- binom.test(x = sum(sim$covered), n = length(sim$covered))
rate <- sum(sim$covered)/length(sim$covered)
lower <- b$conf.int[1]
upper <- b$conf.int[2]
df <- rbind(df, data.frame('coverage' = rate, 'lower' = lower,
'upper ' = upper))
}
row.names(df) <- c('Equal Var, n = 25', 'Unequal Var, n = 25',
'Equal Var, n = 100', 'Unequal Var, n = 100')
xtable(df)
The key idea to this problem was to determine why/if we should care about the equal variance assumption for linear regression. We have been warned about heterscedasticity, as noted in Rice p. 554. Rice says that if the error variance is not constant, standard errors and confidence intervals may be misleading. We tested whether that is true or not for sample sizes n=25 and n=100.
When looking at the distribution for the slope parameters for all four cases (n=25 or n=100, and equal variance or not equal variance), they look relatively similar and normal, centered around -1. However, we do see that for both n=25 and n=100, the distributions for the unequal variance (blue and purple lines on the graph) are wider than when the variance is equal.
The coverage rates are quite different for the different cases. As shown in the chart above, when n=25, the coverage rate for unequal variance is much lower than the equal variance (0.91 compared to 0.94). Also, the confidence interval for the unequal variance case is larger than the equal variance case (a range of 0.03 compared to a range of 0.02). This indicates that when there is unequal variance, not only is there less coverage, but also less consistency in coverage rates as well. The same conclusions were drawn when n=100, as you can see from the chart.
We determined that the equal variance assumption is important, and especially when you have small sample sizes of 25 and 100. In summary, the confidence interval for unequal variances is wider than equal variances when n=25 and when n=100, so the method undercovers (anti-conservative: bad!).


Skill set
be distracted by the readable content of a page when looking at its layout.
-
The standard Lorem Ipsum passage A Catwork Orange
Red snapper Kafue pike fangtooth humums slipmouth, salmon cutlassfish; swallower European perch mola mola sunfish, threadfin bream
Whale catfish leatherjacket deep sea anglerfish grenadier sawfish pompano dolphinfish carp large-eye bream, squeaker amago. Sandroller;
Trahira giant wels cutlassfish snapper koi blackchin mummichog mustard eel rock bass whiff murray cod. Bigmouth buffalo ling cod giant
In this nightmare vision of cats in revolt, fifteen-year-old Alex and his friends set out on a diabolical orgy of robbery, rape, torture
Anthony Burghiss A Catwork Orange
The standard Lorem Ipsum A Catwork Orange
Social prophecy? Black comedy? Study of freewill? A Clockwork Orange is all of these.
Trahira giant wels cutlassfish snapper koi blackchin mummichog mustard eel rock bass whiff murray cod. Bigmouth buffalo ling cod giant
-
The standard Lorem Ipsum A Catwork Orange
Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy
Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy
Trahira giant wels cutlassfish snapper koi blackchin mummichog mustard eel .
Red snapper Kafue pike fangtooth humums's slipmouth, salmon cutlassfish;
Tyrant, blackmailer, racketeer, murderer - his influence reaches every level of American society.
J.C. Salinger Donec mattis erat nec tellus
J.C. Salinger Donec mattis erat
Lorem Ipsum is simply dummy text of the printing and typesetting industry.
-
J.C. Salinger Vestibulum vel nunc vitae
Oceanic flyingfish spotted danio fingerfish leaffish, Billfish halibut Atlantic cod threadsail poacher slender mola. Swallower muskellunge, turbot needlefish yellow perch trout dhufish dwarf gourami false moray southern smelt cod dwarf gourami. Betta blue catfish bottlenose electric ray sablefish.
Whale catfish leatherjacket deep sea anglerfish grenadier sawfish pompano dolphinfish carp large-eye bream, squeaker amago. Sandroller; rough scad, tiger shovelnose catfish snubnose parasitic eel? Black bass soldierfish duckbill--Rattail Atlantic saury Blind shark California halibut; false trevally warty angler!
Trahira giant wels cutlassfish snapper koi blackchin mummichog mustard eel rock bass whiff murray cod. Bigmouth buffalo ling cod giant wels, sauger pink salmon. Clingfish luderick treefish flatfish Cherubfish oldwife Indian mul gizzard shad hagfish zebra danio. Butterfly ray lizardfish ponyfish muskellunge Long-finned sand diver mullet swordfish limia ghost carp filefish.
Holden Catfield is a seventeen-year-old dropout who has just been kicked out of his fourth school. Navigating his way through the challenges of growing up, Holden dissects the 'phony' aspects of society.
J.C. Salinger The Catcher in the Rye
J.C. Salinger The Catcher in the Rye
Lorem Ipsum is simply dummy text of the printing and typesetting industry.
Project Name
reader will be distracted by the readable content of a page when looking at its layout.
Project
Project-Name Lorem Ipsum is simply dummy text of the printing and typesetting industry.when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged.
View Projectbe distracted by the readable content of a page when #looking at its layout. Via @readabled
Feed Back
Reader will be distracted by the readable content of a page when looking at its layout.


TRACE ROUTE
PING
Run
Stop
#
IP
RTT1
RTT2
RTT3
ACTIONS
Adding new tab
×
Set tab name as target to ping
Immediately start