Our team was tasked with developing a product or service that addressed the following problem statement:
From months of research, in home interviews, and ideation, we developed Gylty, a barcode scanning app that provides tips for organizing fridge space, stores metadata relating to each food including purchase time and duration of a food item’s stay within a fridge. Gylty can individually store information for every fridge a user interacts with and take in manual input to register items such as takeout that do not intrinsically have a barcode themselves. Push notifications exist for informing a user when food is going or about to go bad, or else to show that a friend has offered food within a communal fridge as “up for grabs.”
From tracking consumer and industry trends, we brainstormed potential areas for improvement at each step food usage process. We identified a potential opportunity for a physical or digital product that manipulated the fridge environment to optimize the awareness of food items placed inside.
We initially centered our focus on families as they are the group that engage in grocery shopping the most. However, through the process of our interviews and observations, we came to the realization that the biggest source of food waste was not families; rather it was often people just moving into their first apartments or else just starting to grocery shop and don’t have the awareness and information needed to be conscious about their food waste. This led to narrowing our focus to young professionals and college students between the ages 20-27.
We spoke to people within our target age range as well as seasoned chefs who work with people within our target age range. As a result, we gained insights into the habits and attitudes of young adult homeowners towards their kitchens and could better understand how young adults optimize the space. Interviewing the chefs gave us practical insight into the mindset of efficient kitchens and allowed us to identify key areas of improvement.
We took pictures of various college student, graduate student, and young adult refrigerators to understand the thought processes and habits behind their food storage and organization. These pictures were compared with images taken of refrigerators managed by chefs in order to understand the most efficient and food safety conscious organization methods.
We were able to do a comparison between people who had difficulty managing their food waste (our target market), and people who had become adept at doing so through experience (seasoned chefs and busy professionals). This is what helped us realize that the lack of information and awareness is a key driver in food waste, at least, within our target market.
Leftovers, both home cooked and takeout, are a major source of waste. Bulk amounts of food can also easily lead to waste. In addition, optimizing kitchen space while maintaining food safety precautions can be a frustrating balance. Meat is supposed to be kept at the bottom of the fridge to avoid dripping and contaminating other food, but we saw most college fridges did not abide by this convention.
Transparency vs Awareness
This map compared a physical aspect, transparency, with a more enabling, intangible aspect, awareness. These two concepts are similar; in that, they assist the user in knowing what is going on with their food. We decided on these axes because we found that young adults have not yet found the balance between groceries and takeout and pack things into their fridges without thought. As a result, food gets wasted because people overbuy, lose food, or improperly store food. These axes will help us find a solution that increases their knowledge and will hopefully inform behavior.
Affordability vs. Tech Enabled
Given that these are young adults, affordability is a major parameter for our solution. In addition, because we live in a tech enabled world, utilizing technology offers a wider range of applications and ease of access to our users. Therefore, we hoped our solution would optimize both parameters so as to better accommodate our target group.
We began brainstorming by using a method where each group member ideates and sketches 4 new solution concepts in five minutes. After time expires, each paper is passed in a circle to a different team member who either improves the ideas or uses them to spark new ideas in another 5 minute interval. This process repeats until the original paper is back in the creator's hands. From this exercise, we were able to generate about 50 ideas that were then placed into 5 categories using affinity mapping.
Each team member then selected 1-2 ideas to keep from the list. This resulted in 7 final ideas.
We combined the Queue System and Rotating Shelves, since they yielded similar results and mutually enhanced each other. We eliminated LED lighting and mirroring and transparent fridge sides, because it was difficult to conceptualize placement of lighting and mirrors to optimize the fridge viewing experience such that it could fit any refrigerator. Also there is no guarantee that most the kitchen setups are conducive to making this a viable solution. If the sides are blocked, you can’t see the interior regardless of the transparency of the sides.
After discussing the final 4 ideas with people in the target age demographic, we found that they would be much more likely to adopt a digital solution. This led us to choosing to further develop the barcode scanner idea.
The barcode scanner app helps consumers optimize the use of their own food by keeping an active inventory of one’s fridge and providing notifications when food is likely to go bad soon. Once a user has shopped at a partnered grocery store, they can scan all of the newly purchased items using a QR code on the bottom of the receipt. If a user needs to input something manually, they can also scan the item’s barcode itself and manually inputting the expiration date information.
Once a user has scanned or entered in an item into the app, it gives suggestions on where to store it in the fridge based on proper storage practices and what else is currently in the fridge. For example, if a user buys produce and chicken and has a roommate, it suggests a spot where the chicken is below the produce while still keeping enough separation from the roommates stuff to stay organized. All of a user’s food items can be easily seen when the app is opened, and clicking the drop down menu allows the user to find all of the relevant data such as purchase date, expiration date, and where the food came from. Another feature of the app that optimizes food consumption is the ability to put something “Up for Grabs” in a shared fridge. This allows users to offer up their unwanted food items to their friends and coworkers easily, and giving the ability to request a food item in a shared space offers a solution to food stealing.
Prototyping began with a few preliminary sketches, and those were turned into more developed hand drawn concepts that were modeled after apps that our target demographic are familiar with such as Groupme and Snapchat. These were then used to create wireframes of several use cases.


--- layout: default head: title: Quick Tournament #39 - DDraceNetwork menu: |
---This tournament is played on Sunday, 2015-09-13 at 20:00 CEST.
by Skeptar
Difficulty: ★★✰✰✰, Points: 21
6 tees finished (average time: 15:26)
3 teams finished (biggest team: 2)
| 1. | 22:13 | darky & milk | |
| 2. | 22:21 | gB. | FeIs & gB. | Kayumi | |
| 3. | 23:07 | Forris & LanuX |


A KanBan
Username
Profile
Sign Out
Home
About
Contact
本网站需要客户端启用 JavaScript，请启用浏览器的 JavaScript 或使用其他支持 JavaScript 的浏览器。
×
Create New Task
Title
Urgent
Mark this task as urgent
blocked
Mark this task as blocked
Step
Planning
Design
Developing
Testing
Released
Color
default
blue
brown
green
orange
red
yellow
pruple
Person
Tag
Notes
×
Edit Task
Title
Urgent
Mark this task as urgent
blocked
Mark this task as blocked
Color
default
blue
brown
green
orange
red
yellow
pruple
Person
Tag
Notes
Add a new Ticket:
!
filter by user
user1
user2
filter by version
0.1
0.2
0
Queue
In-Progress


You do not have write access to this Tale.
Would you like to create a writeable copy of this Tale that you can run instead?


Hi, my name is Rohan.
I am a student developer, an avid coder and proud Pythonista.
Studying Computer Science, English and Economics.
Goal is to read Computer Science at undergraduate level.


'Jeopardy!' rivalry between James Holzhauer, Emma Boettcher ends in final round of 'Tournament of Champions'
by Stacey BacaThe epic standoff between two "Jeopardy!" fan favorites has ended, and one contestant took home the crown!
Recording-breaking contestant "Jeopardy! James" Holzhauer faced off against Emma Boettcher, a University of Chicago librarian who ended his 32-day winning streak and earned the nickname of "giant slayer."
Spoiler alert: If you don't want to know who won the final round of "Jeopardy! Tournament of Champions" Friday, then stop reading now.
On Friday, Naperville, Illionois native and lifelong Chicago Cubs fan "Jeopardy! James" took home $250,000.
"I think the best part has been fulfilling my childhood dream from when I was a 9 year old watching the show with my beloved Granny," Holzhauer said.
Holzhauer's family held a watch party to root on the "Jeopardy!" giant on Friday.
Despite the loss, Boettcher has kept it all in check throughout the competition, according to her boss.
"She's been incredible humble," said David Bietila, her supervisor. "She still comes in, works hard and is very diligent at her job."
As for Holzhauer, "Jeopardy!" appears to be the launching pad.
"I'll be back on your TVs before long," he said. "Stay tuned."


---
layout: front-en
title: Contact Us
description: Information and help about Atlassian products, SonarSource products, DevOps and Agile | Contact us for the best enterprise solutions
---
If you are already a customer and need help you can open a ticket in our Jira Service Management portal. We will get back to you as soon as possible.
Fill the form and ask us anything you need.Need support?
Contact Us


function length(path|string)
To return or filter on the length of a path, use the length() function.
To return or filter on the length of a string, use the length() function.
Arguments:
MATCH p=(a)-->(b)-->(c) WHERE a.name='Alice' RETURN length(p); MATCH (a) WHERE length(a.name)> 6 RETURN length(a.name)


MOTIV
Authorize
Sign Out
What is your age?
Who is your favorite Artist?
What is your favorite subject?
What is your favorite outdoor activity?
What do you hate the most?
What is your gender?
What do you love?
submit


Le Mans Triumph sells for record price at auction
by Paul LawrenceAn ex-works Triumph TR2 from the 1955 Le Mans 24-Hour race sold for more than a quarter of a million pounds at the Classic Motor Show.
Although the Triumph had a guide price of up to £140,000, it finally sold for £258,750 at the Silverstone Auctions sale at the Birmingham NEC.
The final price represents a new record for the sale of a Triumph TR2.
Registered 'PKV 374', the TR2 was raced in 1955 by Leslie Brooke and Mort Morris-Goodall and finished 19th in the race marked by accident that claimed the lives of 84 people.
The Triumph spent two and a half hours beached on a sand bank at Tetre Rouge, but Brooke managed to finally dig it clear and rejoin the race.
Immediately after the race it was bought by Prince Hussein of Jordan, who owned it for little more than a year.
It then had several owners before being bought in 1972 by Jan Pearce. A long restoration was finally completed and from the year 2000 onwards it competed in various events, including the 2005 Le Mans Legends support race to the 24-hour.
Pearce, one of the early members of the TR Register, died in 2015 and the car was sold by his family.
Nick Whale from Silverstone Auctions said: "To set a world record is a wonderful achievement with the ex-works Le Mans TR2.
"I am so pleased for the family and to see the emotion throughout the room was a moving experience."


Reading configuration files¶
-
odi_config.
cfgparse
(cfg_file, verbose=True)[source]¶ This function reads the
yaml
configuration file that is needed to make theodi_process.py
andodi_scalestack_process.py
functions work. The configuration file must be given the nameconfig.yaml
and be in the same directory as the images that will be processed.Parameters: cfg_file (str) – A string containing the name of the configuration file. Returns: - object_str (str) – Name of the object in the images (eg M53)
- filters (list) – List of filters present in images
- instrument (str) – Name of instrument used
podi
or5odi
- images (list) – List of images that will be processed
- illcor_flag (bool) – If
True
an illumination correction will be applied to the images - skyflat_src (str) – Can be
object
ormaster
. Ifobject
the dark sky flat is created from the images being processed. Ifmaster
the dark sky flat is taken from a master calibration - wcs_flag (bool) – If
True
the a step will be taken to improve the WCS solution on each OTA - reproject_flag (bool) – If
True
all of the OTAs will be reprojected to OTA33 of the first image in the image list. - scale_flag (bool) – If
True
the OTAs will be scaled to the same level before stacking - stack_flag (bool) – If
True
the processed OTAs will be stacked into a final image - align_flag (bool) – If
True
the stacked images will be aligned using pixel shifts computed from the gaia catalog - gaia_flag (bool) – If
True
the gaia catalog will be used as the sources in the fix WCS step - cluster_flag (bool) – If
True
the central regions of a crowded area, such as a globular cluster, are avoided when collecting the gaia sources to fix the WCS - ra_center (float) – If the
cluster_flag
isTrue
, then the centralRa
andDec
of the cluster, or area that is to be avoided must be given in the configuration file. - dec_center (float) – If the
cluster_flag
isTrue
, then the centralRa
andDec
of the cluster, or area that is to be avoided must be given in the configuration file. - min_radius (float) – If the
cluster_flag
isTrue
, then a minimum radius in arcminutes, relative tora_center
anddec_center
, must be given in the configuration file.
-
odi_config.
photcfgparse
(cfg_file)[source]¶ This function reads the
yaml
configuration file that is needed to make theodi_phot_process.py
function work. The configuration file must be given the namephot_config.yaml
and be in the same directory as the images that will be processed.Parameters: cfg_file (str) – A string containing the name of the configuration file. Returns: - object_str (str) – Name of the object in the images (eg M53)
- filters (list) – List of filters present in images
- instrument (str) – Name of instrument used
podi
or5odi
- images (list) – List of images that will be processed
- new_extension (str) – The new extension that will be given to the images resulting from
odi_phot_process.py
- remove_tpv_flag (bool) – If
True
header cards withTPV
will be removed from the stacked images previously produced byodi_process.py
- trim_image_flag (bool) – If
True
the stacked images previously produced byodi_process.py
will be trimmed. - wcs_flag (bool) – If
True
the a step will be taken to improve the WCS on the stacked images previously produced byodi_process.py
- trim_image_flag (bool) – The sections to trim from the stacked images.
- airmasses (list) – The airmasses of the images in the order they will be processed.


India, U.S. joint exercise focusses on disaster response
by Special CorrespondentSoldiers of U.S. marine and U.S. navy conducted a joint exercise with Indian soldiers in the area of humanitarian assistance and disaster response on Wednesday at Kakinada in East Godavari district.
The exercise included planning as well as field training that simulated moving a humanitarian assistance/disaster relief force from ship to shore.
Speaking on the occasion, Rear Admiral Suraj Berry, Eastern Fleet Commander, said: “This exercise is aimed at improving the capacity of both India and the United States to face the challenges of humanitarian crisis during natural calamities like cyclone.”
“We are here because both the U.S. and India are willing to help each other in building their capacities to deal with crisis,” said Lt. Col. Dana Demer, Special Purpose Marine Air Ground Task Force Commander. He said both the countries were well equipped for humanitarian assistance and disaster response. This was part of the ‘Tiger Triumph’ that began in Vizag on November 13 and will conclude at Kakinada on Thursday.


Provides feedback to the user to show that the app is performing a search:
* It changes the color and the message of the speech button
* It synthesizes a voice message
Provides feedback to the user to show that the app is listening:
* It changes the color and the message of the speech button
* It synthesizes a voice message
Provides feedback to the user to show that the app is listening:
* It changes the color and the message of the speech button
* It synthesizes a voice message
Provides feedback to the user to show that the app is listening:
* It changes the color and the message of the speech button
* It synthesizes a voice message
Provides feedback to the user to show that the app is performing a search:
* It changes the color and the message of the speech button
* It synthesizes a voice message
Provides feedback to the user to show that the app is performing a search:
* It changes the color and the message of the speech button
* It synthesizes a voice message
Parses the grammar into Java objects and converts them to a regular expression
that it used in the other methods to validate phrases and obtain their semantics.


| CotsBots A Platform for Distributed Mobile Robotics Last updated 29 Jan. 2003 |
Each robot is small (5"x2.5"x3") and costs approximately $200 each (in quantity 50). Each is equipped with on-board processing and wireless radio communication (through the Mica Mote). Currently, sensing boards associated with the TinyOS/NEST project, including a board equipped with light, temperature, buzzer/microphone, 2-axis magnetometer and accelerometer, are available commercially. A common bus allows for the design and addition of robot-oriented sensor boards (for odometry, obstacle avoidance, mapping, etc.). A MotorBoard has been designed to interface boards developed through the NEST project to an off-the-shelf RC toy car. All parts are commercially available and require only minor modifications to build the robot.
The CotsBots platform consists of both a hardware and a software component. This lesson describes a very simple example of using the software. For more information, please see the CotsBotsSpecifications in the contrib/cotsbots/doc directory.
Note that this description is based on Tutorial, Lesson 1. Apologies if it looks the same.
Let's look at a concrete example: the simple test program "Figure8" found in contrib.cotsbots.apps.Figure8. This application will run the robot in a figure8-like pattern.
Figure8 consists of two components: a module, called "Figure8M.nc", and a configuration, called "Figure8C.nc". Remember that all applications require a single top-level configuration, which is typically named after the application itself. In this case Figure8.nc is the configuration for the Figure8 application and the source file that the NesC compiler uses to generate the executable for the mote. Figure8M.nc provides the implementation of the Figure8 application. As you might guess, Figure8C.nc is used to wire the Figure8M.nc module to other components that the Figure8 application requires.
The reason for the distinction between modules and configurations is to allow a system designer to quickly "snap together" applications. For example, a designer could provide a configuration that simply wires together one or more modules, none of which she actually designed. Likewise, another developer can provide a new set of "library" modules that can be used in a range of applications. A concrete example of this is when Figure8C.nc is re-used in the TestMotorBoard application.
Let's look first at the module Figure8M.nc:
Figure8M.nc
module Figure8M { provides interface StdControl; provides interface Figure8Calibration; uses { interface Robot; interface Clock; interface Leds; } } // Continued below... |
The first part of the code states that this is a module called Figure8M. Figure8M provides two interfaces: StdControl and Figure8Calibration. It uses three interfaces: Robot, Clock, and Leds.
The idea of providing and requiring interfaces should be familiar to anyone who has programmed in an object-oriented language such as Java. First consider the clause "provides interface StdControl". This means that Figure8M implements the StdControl interface. StdControl is a common interface used to initialize and start TinyOS components. If we look at tos/interfaces/StdControl.nc:
StdControl.nc
interface StdControl { command result_t init(); command result_t start(); command result_t stop(); } |
We see that StdControl defines three commands, init(), start(), and stop(). init() is called when a component is first initialized, and start() when it is started, that is, actually executed for the first time. stop() is called when the component is stopped, for example, in order to power off the device that it is controlling. init() can be called multiple times, but will never be called after either start() or stop are called. Specifically, the valid call patterns of StdControl are init* (start | stop)* All three of these commands have "deep" semantics; calling init() on a component will make it call init() on all of its subcomponents. A good example is the component controlling the mote radio: init() is called when the component is initialized, start() is called to enable power to the radio, and stop() to shut off power. Because the radio power is only needed when communicating, start() and stop() may be called multiple times to power on or power off the radio.
A command is just a function that may be defined in an interface. If an interface defines a command, then any component that provides that interface must implement that function. In the case of Figure8M, then, we expect this module to implement the init(), start(), and stop() commands, which it does as we will see below.
Likewise, if an interface defines a command, then any component that uses that interface may call the function. Figure8M uses three interfaces, Robot, Clock, and Leds. (The code for these can be found in tos/interfaces.) For example, Robot.nc defines a bunch of commands like setSpeed(speed), setTurn(turn), and so forth, which set the speed and turning angle of the robot. Because Figure8M uses the Robot interface, it can invoke any of these commands. (Keep in mind, however, that Robot is just an interface: it specifies no implementation. We will see later how the configuration, Figure8C.nc, is used to wire Figure8M's use of the Robot interface to a concrete implementation of that interface.)
Let's look at the rest of Figure8M.nc to see how this all fits together:
Figure8M.nc, continued
implementation { uint8_t ticks; uint8_t TurnRight; uint8_t TurnStraight1; uint8_t TurnLeft; uint8_t TurnStraight2; uint8_t Speed; command result_t StdControl.init() { /* Set default constants -- could store on EEPROM for Mica*/ Speed = 70; TurnRight = 3; TurnStraight1 = 8; TurnLeft = 11; TurnStraight2 = 16; ticks = 0; call Robot.init(); return SUCCESS; } /* Start timer to fire once/sec */ command result_t StdControl.start() { call Clock.setRate(TOS_I8PS, TOS_S8PS); call Robot.setSpeedTurnDirection(Speed, STRAIGHT, FORWARD); return SUCCESS; } /* Stop timer and reset ticks, speed, direction and turn */ command result_t StdControl.stop() { call Clock.setRate(TOS_I0PS, TOS_S0PS); ticks = 0; call Robot.setSpeedTurnDirection(OFF,STRAIGHT,FORWARD); return SUCCESS; } /* Determine if I should turn */ event result_t Clock.fire() { ticks++; if (ticks == 1) call Robot.setSpeedTurnDirection(Speed, STRAIGHT, FORWARD); else if (ticks == TurnRight) call Robot.setSpeedTurnDirection(Speed, RIGHT, FORWARD); else if (ticks == TurnStraight1) call Robot.setSpeedTurnDirection(Speed, STRAIGHT, FORWARD); else if (ticks == TurnLeft) call Robot.setSpeedTurnDirection(Speed, LEFT, FORWARD); else if (ticks == TurnStraight2) { call Robot.setSpeedTurnDirection(Speed, STRAIGHT, FORWARD); ticks = 0; } return SUCCESS; } // Continued below... |
This is simple enough. As we see the Figure8M module implements the StdControl.init(), StdControl.start(), and StdControl.stop() commands, since it provides the StdControl interface. It also implements the Clock.fire() event, which is necessary since BlinkM uses the Clock interface. Several variables are also declared for use throughout the module.
init() simply initializes the internal state of the module and initializes the Robot sub-module. start() invokes Clock.setRate() to set the clock rate to 8 ticks per second and uses Robot.setSpeedTurnDirection() to initialize the state of the robot. stop() sets the clock rate to zero ticks per second, which is equivalent to disabling the clock and stops the robot as well. Each time fire() is invoked, the ticks variable is compared with the times at which we would like to to turn and the robot state is set appropriately. Voila!
If you look at the application code, you will notice that the implementation of the Figure8Calibration interface in Figure8M as well. Because the Figure8 component is open-loop (i.e. there is no feedback on what the robot's current position is -- everything is based on time only), it is often necessary to calibrate the Figure8 -- setting the proper speed and turn times. Because the Figure8Calibration interface is not actually used in Figure8.nc, we will not concern ourselves with it here.
Now let's look at Figure8C.nc, the configuration for this application:
Figure8C.nc
configuration Figure8C { provides interface StdControl; provides interface Figure8Calibration; } implementation { components Figure8M, RobotC, ClockC, LedsC; StdControl = Figure8M.StdControl; Figure8Calibration = Figure8M.Figure8Calibration; Figure8M.Robot -> RobotC; Figure8M.Clock -> ClockC; Figure8M.Leds -> LedsC; } |
The first thing to notice is that the syntax of a configuration is slightly different, in that it doesn't contain any code. The first four lines,
configuration Figure8C { provides interface StdControl; provides interface Figure8Calibration; }simply state that this is a configuration called Figure8C. In this case, our configuration also provides the StdControl and Figure8Calibration interfaces. This is important, because it allows a separate application (such as TestMotorBoard) to use the Figure8C.StdControl interface without knowing the components underneath it. This is important to keep in mind: a configuration can require and provide interfaces!
The "components" line specifies the set of components that this configuration references, in this case Figure8M, RobotC, ClockC, and LedsC. In many ways this line is redundant since it's obvious from the rest of the file which components are referenced by the configuration. The components line is included only for completeness, but is required by the NesC compiler.
The lines
StdControl = Figure8M.StdControl; Figure8Calibration = Figure8M.Figure8Calibration;are used to essentially "pass through" these interfaces from their respective implementations in Figure8M.
Figure8M.Robot -> RobotC; Figure8M.Clock -> ClockC; Figure8M.Leds -> LedsC;are used to bind the use of the Robot, Clock, and Leds interfaces in Figure8M to their respective implementations.
There are two confusing things about these lines. First of all, the Clock on the left side of the arrow is referring to the interface called Clock (tos/interfaces/Clock.nc), while the ClockC on the right side of the arrow is refering to the implementation module called ClockC, found in tos/system/Clock.nc. Remember that the arrow always binds interfaces (on the left) to implementations (on the right). ClockC is a mnemonic for "clock component".
The second confusing point is that the line
Figure8M.Clock -> ClockC;is really shorthand for
Figure8M.Clock -> ClockC.Clock;That is, because Figure8M is using the interface Clock.nc, we are trying to bind it to an implementation (in the module ClockC.nc) of the same interface. If no interface name is given on the right side of the arrow, the NesC compiler tries to bind to the same interface as on the left side of the arrow.
If you are in the TinyOS source tree, compiling the Figure8 application is as simple as typing
make micain the contrib/cotsbots/apps/Figure8 directory. Of course this doesn't tell you anything about how the NesC compiler is invoked.
Now that we've compiled the application it's time to program the mote and run it. To download your program into the mote, place the mote board (or mote and sensor stack) into the bay on the programming board.
Plug the 32-pin connector into the parallel port of a computer configured with the TOS tools, using a standard DB32 parallel port cable.
Type: make install mica. If you get the error:
uisp -dprog=dapa --erase pulse An error has occurred during the AVR initialization. * Target status: Vendor Code = 0xff, Part Family = 0xff, Part Number = 0xff Probably the wiring is incorrect or target might be `damaged'. make: *** [install] Error 2check whether the power is on. You can also get this error message if the mote is low on batteries (if you are using batteries), or if the wrong version of the uisp programming utility is installed (be sure to use the version in the NEST distribution).
If you are using an IBM ThinkPad, it may be necessary to tell the tools to use a different parallel port. You can do this by adding the line
HOST = THINKPADbefore the include statement in contrib/cotsbots/apps/Figure8/Makefile.
If the installation is successful you should see something like the following:
compiling Figure8 to a mica binary ncc -board=micasb -o build/mica/main.exe -Os -target=mica -Wall -Wshadow -DDEF_TOS_AM_GROUP=0x7d -finline-limit=200 -fnesc-cfile=build/mica/app.c Figure8.nc -lm avr-objcopy --output-target=srec build/mica/main.exe build/mica/main.srec compiled Figure8 to build/mica/main.srec installing mica binary uisp -dprog=dapa --erase pulse Atmel AVR ATmega128 is found. Erasing device ... pulse Reinitializing device Atmel AVR ATmega128 is found. sleep 1 uisp -dprog=dapa --upload if=build/mica/main.srec pulse Atmel AVR ATmega128 is found. Uploading: flash sleep 1 uisp -dprog=dapa --verify if=build/mica/main.srec pulse Atmel AVR ATmega128 is found. Verifying: flash
You can now test the program by unplugging the mote from the programming board, attaching it to the CotsBots robot as shown below, and turning on the power switch for both the robot and the Mica.
| Mica mote attached to the CotsBots Platform | Power Switch for the CotsBots |
Typing make clean in the Figure8 directory will clean up the compiled binary files.
This tutorial has just scratched the surface of NesC's syntax and CotsBots features. Please see the CotsBots Specifications in contrib/cotsbots/doc to get a more thorough introduction to CotsBots. Have fun!


2016-2017 League Rules
League Philosophy:
- This is a gentleman's league that has zero tolerance for any
aggressive play or
behaviour that would increase the chances of injury to any player or
official.
Ground Rules (Updated 2010/OCT/30):
- no slapshots (i.e. windup above the
knee results in
a whistle, face-off in offending team's zone)
- no checking or "aggressive"
body contact,
play the puck at all times
- 3 minor penalties results in expulsion from the game, and
a 1 game
suspension (double minor = 2 penalties)
- Misconduct: results in 10 minute penalty
-
Game
Misconduct: expulsion from game, 1st offence = 1 game suspension, 2nd = 2 games +
review - Abuse of
Official: Game Misconduct, 2 game suspension, league review
- 1 major penalty results
in expulsion from
game, minimum 1 game suspension, league review
- continued undesirable behaviour
(except bad
goaltending) may result in expulsion from the league
- 1st Offensive player in crease:
face-off outside
blueline & warning
- Subsequent Offensive player in crease: Goaltender interference
penalty
-
no red line when invoking 2-line pass rule
- unlimited line changes at whistle when
teams are at even
strength (see rule 14 !!)
- shorthanded team may only change on the fly
- the puck
drops 15sec
after a stoppage in play, ready or not
- all face-offs to be at the nearest dot
-
puck off
crossbar and out of play, face-off at nearest dot to origin of shot
- penalties result
in a face-off in
the defensive zone of penalized team
- high stick on puck is immediate whistle,
face-off in offending
team's defensive zone (no penalty)
- no TV timeouts after icings. (see rule 14 !!)
-
STOP TIME in
the last 2 minutes of a game (if within 2 goals)
- Time Keepers please give Pink/Yellow
Game Sheets to
Captains, White Game Sheet to Statistician
Tie-Breaker Rules
- Wins: Most total wins among the tied teams.
- -Head-to-Head Record: Most points
in games against
each other among the tied teams.
- -Goal Differential: Using the total goals scored
during the regular
season, the greater positive differential between goals for and against among the
tied
teams.
- -Most Goals For: Using the total goals scored during the regular season, the greater
number of goals for among the tied teams.
- -Least Goals Against: Using the total goals
scored during the regular season, the fewer number of goals against among the tied
teams.
Playoff tiebreakers
- Most wins playoffs
- Head to head playoffs
- Goal differential playoffs
-
Most goals
playoffs
- Lowest goals against playoffs
- most points regular season
- most
wins regular
season
- goal differential regular season
- Coin flip.
Spares:
- spares may only be called if fewer than 10 regular players
are available.
- maximum of 2 spares, must be same caliber as missing regular players, 10 players
max.
- spares must be registered prior to Dec 15th
- Captains have a list of 28 or so players that have been pre identified and only
those
league players can spare.
|
|


Google LLC is multinational technology company that specializes in internet-related service and products such as: search engine, cloud computing, software and hardware. It is considered one of the Big 5 technology companies. It was founded in 1998 by Larry Page and Sergey Brin. Google became famous for its search engine and is also the world's most visited website. It's because of the following things:


Current Progress:
All problems and subproblems are solved through the webpage
Below is the video showing the output
Click here to go to the live webpage solver
All problems and subproblems are solved through the webpage
Below is the video showing the output
Click here to go to the live webpage solver


Premium & Local Materials
Our trombones use the shiniest brass which is sourced locally. This will increase the longevity of your purchase.
Fast Shipping
We make sure you receive your trombone as soon as we have finished making it. We also provide free returns if you are not satisfied.
Quality Assurance
For every purchase you make, we will ensure there are no damages or faults and we will check and test the pitch of your instrument.
Tenor Trombone
$600
- Lorem, ipsum.
- Nemo, minus!
- Vitae, possimus.
- Et, atque!
Bass Trombone
$900
- Lorem, ipsum.
- Aut, repellat.
- Incidunt, magni.
- Fugit, voluptatibus.
Valve Trombone
$1200
- Lorem, ipsum.
- Reiciendis, aspernatur.
- Officia, reprehenderit.
- Modi, commodi?
Want to know more about us?
Contact us!


The library has been tested using Agda 2.6.1 and <IP_ADDRESS>.
Highlights
-
Regular expressions which work over both arbitrary types and
String
s. -
Instance declarations for
IsDecEquivalence
andIsDecTotalOrder
over various data types. -
Bindings for Haskell’s
System.Environment
andSystem.Exit
.
Bug-fixes
-
Added the version number to the official library name, i.e. name is now
standard-library-1.5
rather thanstandard-library
, allowing other libraries to require a specific version as a dependency. See the library management docs for more details. -
In
Data.List.Relation.Unary.All.Properties
: fixed the type of the proofmap-id
which was incorrectly abstracted over unused module parameters. -
In
Data.List.Relation.Binary.Subset.(Propositional/Setoid).Properties
: fixed the fixity of the reasoning combinators in so that they compose properly. -
In
Relation.Binary.Construct.Closure.Reflexive
: the example moduleMaybe
was accidentally exposed publicly. It has been made private. -
In
Relation.Binary.Morphism.Structures
: fixed bug whereIsRelIsomorphism
did not publicly re-export the contents ofIsRelMonomorphism
. -
In
Relation.Binary.Bundles
: the binary relation_≉_
exposed by records now has the correct infix precedence.
Non-backwards compatible changes
-
The internal build utilities package
lib.cabal
has been renamedagda-stdlib-utils.cabal
to avoid potential conflict or confusion. Please note that the package is not intended for external use. -
The modules
Algebra.Construct.Zero
andAlgebra.Module.Construct.Zero
are now level-polymorphic, each taking two implicit level parameters. - The definition of
_⊖_
inData.Integer.Base
has changed. Previously it was defined inductively as:_⊖_ : ℕ → ℕ → ℤ m ⊖ ℕ.zero = + m ℕ.zero ⊖ ℕ.suc n = -[1+ n ] ℕ.suc m ⊖ ℕ.suc n = m ⊖ n
which meant that it had to recursively evaluate its unary arguments. The definition has been changed as follows to use operations on
ℕ
that are backed by builtin operations, greatly improving its performance:_⊖_ : ℕ → ℕ → ℤ m ⊖ n with m ℕ.<ᵇ n ... | true = - + (n ℕ.∸ m) ... | false = + (m ℕ.∸ n)
-
The proofs
↭⇒∼bag
and∼bag⇒↭
have been moved fromData.List.Relation.Binary.Permutation.Setoid.Properties
toData.List.Relation.Binary.BagAndSetEquality
as their current location were causing cyclic import dependencies. -
In
Data.String
, orders onString
now use propositional equality as the notion of equivalence on characters rather than the equivalent, but less inference-friendly, variant defined by conversion of characters to natural numbers. This is in line with our effort to deprecate this badly-behaved equivalence relation on characters. -
In
Data.Vec.Relation.Unary.AllPairs
: generalised the types ofhead
,tail
,uncons
so that the vector talked about does not need to be cons-headed. - Cleaned up
IO
to make it more friendly:- Renamed
_>>=_
and_>>_
tobind
andseq
respectively to free up the names fordo
-notation friendly combinators. - Introduced
Colist
andList
modules for the varioussequence
andmapM
functions. This breaks code that relied on theColist
-specific function being exported as part ofIO
. ⊤
-returning functions (such asputStrLn
) have been made level polymorphic. This may force you to add more type or level annotations to your programs.
- Renamed
Deprecated modules
-
The inner module
TransitiveClosure
inInduction.WellFounded
has been deprecated. You should instead use the standard definition of transitive closure and the accompanying proof of well-foundness defined inRelation.Binary.Construct.Closure.Transitive
. -
The module
Relation.Binary.OrderMorphism
has been deprecated, as the new(Homo/Mono/Iso)morphism
infrastructure inAlgebra.Morphism.Structures
is now complete. The new definitions are parameterised by raw bundles instead of bundles meaning they are much more flexible to work with. -
All modules in the folder
Algebra.Operations
have been deprecated, as their design a) was inconsistent, with some of the modules parameterised over the raw bundle and some over the stanard bundle b) prevented definitions from being neatly inherited by super-bundles.These problems have been fixed with a redesign: definitions of the operations can be found in
Algebra.Definitions.(RawMagma/RawMonoid/RawSemiring)
and their properties can be found inAlgebra.Properties.(Magma/Semigroup/Monoid/CommutativeMonoid/Semiring).(Sum/Mult/Exp)
. The latter also export the definition, and so most users will only need to import the latter.
Deprecated names
- The immediate contents of
Algebra.Morphism
have been deprecated, as the new(Homo/Mono/Iso)morphism
infrastructure inAlgebra.Morphism.Structures
is now complete. The new definitions are parameterised by raw bundles instead of bundles meaning they are much more flexible to work with. The replacements are as following:IsSemigroupMorphism ↦ IsSemigroupHomomorphism IsMonoidMorphism ↦ IsMonoidHomomorphism IsCommutativeMonoidMorphism ↦ IsMonoidHomomorphism IsIdempotentCommutativeMonoidMorphism ↦ IsMonoidHomomorphism IsGroupMorphism ↦ IsGroupHomomorphism IsAbelianGroupMorphism ↦ IsGroupHomomorphism
-
In
Data.Char.Properties
, deprecated all of the_≈_
-related content: this relation is equivalent to propositional equality but has worse inference. - In
Data.Fin.Properties
:inject+-raise-splitAt ↦ join-splitAt
-
In
Data.Integer
, theshow
function has been deprecated. Please useshow
fromData.Integer.Show
instead. - In
Data.Integer.Properties
:neg-mono-<-> ↦ neg-mono-< neg-mono-≤-≥ ↦ neg-mono-≤ *-monoʳ-≤-non-neg ↦ *-monoʳ-≤-nonNeg *-monoˡ-≤-non-neg ↦ *-monoˡ-≤-nonNeg *-cancelˡ-<-non-neg ↦ *-cancelˡ-<-nonNeg *-cancelʳ-<-non-neg ↦ *-cancelʳ-<-nonNeg
- In
Data.List.Relation.Binary.Subset.Propositional.Properties
:mono ↦ Any-resp-⊆ map-mono ↦ map⁺ concat-mono ↦ concat⁺ >>=-mono ↦ >>=⁺ _⊛-mono_ ↦ ⊛⁺ _⊗-mono_ ↦ ⊗⁺ any-mono ↦ any⁺ map-with-∈-mono ↦ map-with-∈⁺ filter⁺ ↦ filter-⊆
- In
Data.List.Relation.Binary.Subset.Setoid.Properties
:filter⁺ ↦ filter-⊆
-
In
Data.Rational
, theshow
function has been deprecated. Please useshow
fromData.Rational.Show
instead. - In
Relation.Binary.Construct.Closure.Reflexive
:Refl ↦ ReflClosure
- In
Relation.Binary.Construct.Closure.Transitive
:Plus′ ↦ TransClosure
New modules
- Generic definitions over algebraic structures (divisibility, multiplication etc.):
Algebra.Definitions.RawMagma Algebra.Definitions.RawMonoid Algebra.Definitions.RawSemiring
- Properties of generic definitions over algebraic structures (divisibility, multiplication etc.):
Algebra.Properties.Magma.Divisibility Algebra.Properties.Semigroup.Divisibility Algebra.Properties.CommutativeSemigroup.Divisibility Algebra.Properties.Monoid.Sum Algebra.Properties.Monoid.Mult Algebra.Properties.Monoid.Divisibility Algebra.Properties.CommutativeMonoid.Sum Algebra.Properties.CommutativeMonoid.Mult Algebra.Properties.Semiring.Divisibility Algebra.Properties.Semiring.Exp Algebra.Properties.Semiring.Exp.TCOptimised Algebra.Properties.Semiring.Mult Algebra.Properties.Semiring.Mult.TCOptimised Algebra.Properties.CommutativeSemiring.Exp Algebra.Properties.CommutativeSemiring.Exp.TCOptimised
- Properties of monomorphisms over lattice structures:
Algebra.Morphism.LatticeMonomorphism
- Various modules containing
instance
declarations forIsDecEquivalence
andIsDecTotalOrder
records:Data.Bool.Instances Data.Char.Instances Data.Fin.Instances Data.Float.Instances Data.Integer.Instances Data.List.Instances Data.Nat.Instances Data.Nat.Binary.Instances Data.Product.Instances Data.Rational.Instances Data.Sign.Instances Data.String.Instances Data.Sum.Instances Data.These.Instances Data.Unit.Instances Data.Unit.Polymorphic.Instances Data.Vec.Instances Data.Word.Instances Reflection.Instances
- Various modules for converting numeric data to
String
s:Data.Fin.Show Data.Integer.Show Data.Rational.Show
- Permutations over finite sets represented as a list of transpositions:
Data.Fin.Permutation.Transposition.List
- Heterogeneous relation characterising a list as an infix segment of another:
Data.List.Relation.Binary.Infix.Heterogeneous Data.List.Relation.Binary.Infix.Heterogeneous.Properties
and added
Properties
file for the homogeneous variants of (pre/in/suf)fix:Data.List.Relation.Binary.Prefix.Homogeneous.Properties Data.List.Relation.Binary.Infix.Homogeneous.Properties Data.List.Relation.Binary.Suffix.Homogeneous.Properties
- Properties of lists with decidably unique elements:
Data.List.Relation.Unary.Unique.DecSetoid Data.List.Relation.Unary.Unique.DecSetoid.Properties Data.List.Relation.Unary.Unique.DecPropositional Data.List.Relation.Unary.Unique.DecPropositional.Properties
- New ternary relation for two lists that are appended to form a third list:
Data.List.Relation.Ternary.Appending Data.List.Relation.Ternary.Appending.Properties Data.List.Relation.Ternary.Appending.Propositional Data.List.Relation.Ternary.Appending.Propositional.Properties Data.List.Relation.Ternary.Appending.Setoid Data.List.Relation.Ternary.Appending.Setoid.Properties
- Solvers for rationals:
Data.Rational.Solver Data.Rational.Unnormalised.Solver
- Setoid equality over vectors:
Data.Vec.Functional.Relation.Binary.Equality.Setoid
- Bindings for Haskell’s
System.Environment
:System.Environment System.Environment.Primitive
- Bindings for Haskell’s
System.Exit
:System.Exit System.Exit.Primitive
-
Added
Reflection.Traversal
for generic de Bruijn-aware traversals of reflected terms. -
Added
Reflection.DeBruijn
with weakening, strengthening and free variable operations on reflected terms. -
Added
Relation.Binary.TypeClasses
for type classes to be used with instance search. This module re-exports_≟_
fromIsDecEquivalence
and_≤?_
fromIsDecTotalOrder
where the principal argument has been made into an instance argument. This enables automatic resolution if the corresponding moduleData.*.Instances
(orReflection.Instances
) is imported as well. For example, ifRelation.Binary.TypeClasses
,Data.Nat.Instances
, andData.Bool.Instances
have been imported, thentrue ≟ true
has typeDec (true ≡ true)
, while0 ≟ 1
has typeDec (0 ≡ 1)
. More examples can be found inREADME.Relation.Binary.TypeClasses
. - Added various constructions for morphisms over binary relations:
Relation.Binary.Morphism.Construct.Composition Relation.Binary.Morphism.Construct.Constant Relation.Binary.Morphism.Construct.Identity
- New modules formalising regular expressions:
Text.Regex Text.Regex.Base Text.Regex.Derivative.Brzozowski Text.Regex.Properties.Core Text.Regex.Properties Text.Regex.Search Text.Regex.SmartConstructors Text.Regex.String Text.Regex.String.Unsafe
Other minor additions
-
All bundles in
Algebra.Bundles
now re-export the binary relation_≉_
from the underlyingSetoid
. - Added new records to
Algebra.Bundles
:CommutativeMagma c ℓ : Set (suc (c ⊔ ℓ)) RawNearSemiring c ℓ : Set (suc (c ⊔ ℓ)) RawLattice c ℓ : Set (suc (c ⊔ ℓ)) CancellativeCommutativeSemiring c ℓ : Set (suc (c ⊔ ℓ))
- Added new definitions to
Algebra.Definitions
:AlmostLeftCancellative e _•_ = ¬ x ≈ e → (x • y) ≈ (x • z) → y ≈ z AlmostRightCancellative e _•_ = ¬ x ≈ e → (y • x) ≈ (z • x) → y ≈ z AlmostCancellative e _•_ = AlmostLeftCancellative e _•_ × AlmostRightCancellative e _•_
- Added new records to
Algebra.Morphism.Structures
:IsNearSemiringHomomorphism (⟦_⟧ : A → B) : Set (a ⊔ ℓ₁ ⊔ ℓ₂) IsNearSemiringMonomorphism (⟦_⟧ : A → B) : Set (a ⊔ ℓ₁ ⊔ ℓ₂) IsNearSemiringIsomorphism (⟦_⟧ : A → B) : Set (a ⊔ b ⊔ ℓ₁ ⊔ ℓ₂) IsSemiringHomomorphism (⟦_⟧ : A → B) : Set (a ⊔ ℓ₁ ⊔ ℓ₂) IsSemiringMonomorphism (⟦_⟧ : A → B) : Set (a ⊔ ℓ₁ ⊔ ℓ₂) IsSemiringIsomorphism (⟦_⟧ : A → B) : Set (a ⊔ b ⊔ ℓ₁ ⊔ ℓ₂) IsLatticeHomomorphism (⟦_⟧ : A → B) : Set (a ⊔ ℓ₁ ⊔ ℓ₂) IsLatticeMonomorphism (⟦_⟧ : A → B) : Set (a ⊔ ℓ₁ ⊔ ℓ₂) IsLatticeIsomorphism (⟦_⟧ : A → B) : Set (a ⊔ b ⊔ ℓ₁ ⊔ ℓ₂)
- Added new definitions to
Algebra.Structures
:IsCommutativeMagma (• : Op₂ A) : Set (a ⊔ ℓ) IsCancellativeCommutativeSemiring (+ * : Op₂ A) (0# 1# : A) : Set (a ⊔ ℓ)
- Added new proofs to
Codata.Delay.Properties
:⇓-unique : (d⇓₁ : d ⇓) (d⇓₂ : d ⇓) → d⇓₁ ≡ d⇓₂ bind̅₁ : bind d f ⇓ → d ⇓ bind̅₂ : (bind⇓ : bind d f ⇓) → f (extract (bind̅₁ bind⇓)) ⇓ extract-bind-⇓ : (d⇓ : d ⇓) (f⇓ : f (extract d⇓) ⇓) → extract (bind-⇓ d⇓ f⇓) ≡ extract f⇓ extract-bind̅₂-bind⇓ : (bind⇓ : bind d f ⇓) → extract (bind̅₂ d bind⇓) ≡ extract bind⇓ bind⇓-length : (bind⇓ : bind d f ⇓) (d⇓ : d ⇓) (f⇓ : f (extract d⇓) ⇓) → toℕ (length-⇓ bind⇓) ≡ toℕ (length-⇓ d⇓) ℕ.+ toℕ (length-⇓ f⇓)
- Added new definition to
Data.Char.Base
:_≉_ : Rel Char zero _≤_ : Rel Char zero
- Added proofs to
Data.Char.Properties
:≉⇒≢ : x ≉ y → x ≢ y <-trans : Transitive _<_ <-asym : Asymmetric _<_ <-cmp : Trichotomous _≡_ _<_ _≤?_ : Decidable _≤_ ≤-reflexive : _≡_ ⇒ _≤_ ≤-trans : Transitive _≤_ ≤-antisym : Antisymmetric _≡_ _≤_ ≤-isPreorder : IsPreorder _≡_ _≤_ ≤-isPartialOrder : IsPartialOrder _≡_ _≤_ ≤-isDecPartialOrder : IsDecPartialOrder _≡_ _≤_ ≤-preorder : Preorder _ _ _ ≤-poset : Poset _ _ _ ≤-decPoset : DecPoset _ _ _
- Added new function to
Data.Fin
:join : Fin m ⊎ Fin n → Fin (m ℕ.+ n)
- Added new properties to
Data.Fin.Properties
:splitAt-join : splitAt m (join m n i) ≡ i +↔⊎ : Fin (m ℕ.+ n) ↔ (Fin m ⊎ Fin n) Fin0↔⊥ : Fin 0 ↔ ⊥
- Added new relations, functions and proofs to
Data.Fin.Permutation
:_≈_ : Rel (Permutation m n) 0ℓ lift₀ : Permutation m n → Permutation (suc m) (suc n) lift₀-remove : π ⟨$⟩ʳ 0F ≡ 0F → ∀ i → lift₀ (remove 0F π) ≈ π lift₀-id : lift₀ id ⟨$⟩ʳ i ≡ i lift₀-comp : lift₀ π ∘ₚ lift₀ ρ ≈ lift₀ (π ∘ₚ ρ) lift₀-cong : π ≈ ρ → lift₀ π ≈ lift₀ ρ lift₀-transpose : transpose (suc i) (suc j)≈ lift₀ (transpose i j)
- Added new proofs in
Data.Integer.Properties
:[1+m]⊖[1+n]≡m⊖n : suc m ⊖ suc n ≡ m ⊖ n ⊖-≤ : m ≤ n → m ⊖ n ≡ - + (n ∸ m) -m+n≡n⊖m : - (+ m) + + n ≡ n ⊖ m m-n≡m⊖n : + m + (- + n) ≡ m ⊖ n ≤∧≢⇒< : x ≤ y → x ≢ y → x < y ≤∧≮⇒≡ : x ≤ y → x ≮ y → x ≡ y positive⁻¹ : Positive n → n > 0ℤ nonNegative⁻¹ : NonNegative n → n ≥ 0ℤ negative⁻¹ : Negative n → n < 0ℤ nonPositive⁻¹ : NonPositive q → q ≤ 0ℤ negative<positive : Negative m → Positive n → m < n neg-mono-< : -_ Preserves _<_ ⟶ _>_ neg-mono-≤ : -_ Preserves _≤_ ⟶ _≥_ neg-cancel-< : - m < - n → m > n neg-cancel-≤ : - m ≤ - n → m ≥ n +∣n∣≡n⊎+∣n∣≡-n : + ∣ n ∣ ≡ n ⊎ + ∣ n ∣ ≡ - n ∣m⊝n∣≤m⊔n : ∣ m ⊖ n ∣ ℕ.≤ m ℕ.⊔ n ∣m+n∣≤∣m∣+∣n∣ : ∣ m + n ∣ ℕ.≤ ∣ m ∣ ℕ.+ ∣ n ∣ ∣m-n∣≤∣m∣+∣n∣ : ∣ m - n ∣ ℕ.≤ ∣ m ∣ ℕ.+ ∣ n ∣ *-cancelˡ-≤-neg : -[1+ m ] * n ≤ -[1+ m ] * o → n ≥ o *-cancelʳ-≤-neg : n * -[1+ m ] ≤ o * -[1+ m ] → n ≥ o *-monoˡ-≤-nonPos : NonPositive m → (m *_) Preserves _≤_ ⟶ _≥_ *-monoʳ-≤-nonPos : ∀ m → NonPositive m → (_* m) Preserves _≤_ ⟶ _≥_ *-monoˡ-≤-neg : (-[1+ m ] *_) Preserves _≤_ ⟶ _≥_ *-monoʳ-≤-neg : (_* -[1+ m ]) Preserves _≤_ ⟶ _≥_ *-monoˡ-<-neg : (-[1+ n ] *_) Preserves _<_ ⟶ _>_ *-monoʳ-<-neg : (_* -[1+ n ]) Preserves _<_ ⟶ _>_ *-cancelˡ-<-neg : -[1+ n ] * i < -[1+ n ] * j → i > j *-cancelˡ-<-nonPos : NonPositive n → n * i < n * j → i > j *-cancelʳ-<-neg : i * -[1+ n ] < j * -[1+ n ] → i > j *-cancelʳ-<-nonPos : NonPositive n → i * n < j * n → i > j ∣m*n∣≡∣m∣*∣n∣ : ∣ m * n ∣ ≡ ∣ m ∣ ℕ.* ∣ n ∣ +-*-commutativeSemiring : CommutativeSemiring 0ℓ 0ℓ mono-≤-distrib-⊓ : f Preserves _≤_ ⟶ _≤_ → f (m ⊓ n) ≡ f m ⊓ f n mono-<-distrib-⊓ : f Preserves _<_ ⟶ _<_ → f (m ⊓ n) ≡ f m ⊓ f n mono-≤-distrib-⊔ : f Preserves _≤_ ⟶ _≤_ → f (m ⊔ n) ≡ f m ⊔ f n mono-<-distrib-⊔ : f Preserves _<_ ⟶ _<_ → f (m ⊔ n) ≡ f m ⊔ f n antimono-≤-distrib-⊔ : f Preserves _≤_ ⟶ _≥_ → f (m ⊔ n) ≡ f m ⊓ f n antimono-<-distrib-⊔ : f Preserves _<_ ⟶ _>_ → f (m ⊔ n) ≡ f m ⊓ f n antimono-≤-distrib-⊓ : f Preserves _≤_ ⟶ _≥_ → f (m ⊓ n) ≡ f m ⊔ f n antimono-<-distrib-⊓ : f Preserves _<_ ⟶ _>_ → f (m ⊓ n) ≡ f m ⊔ f n *-distribˡ-⊓-nonNeg : + m * (n ⊓ o) ≡ (+ m * n) ⊓ (+ m * o) *-distribʳ-⊓-nonNeg : (n ⊓ o) * + m ≡ (n * + m) ⊓ (o * + m) *-distribˡ-⊔-nonNeg : + m * (n ⊔ o) ≡ (+ m * n) ⊔ (+ m * o) *-distribʳ-⊔-nonNeg : (n ⊔ o) * + m ≡ (n * + m) ⊔ (o * + m) *-distribˡ-⊓-nonPos : NonPositive m → m * (n ⊓ o) ≡ (m * n) ⊔ (m * o) *-distribʳ-⊓-nonPos : NonPositive m → (n ⊓ o) * m ≡ (n * m) ⊔ (o * m) *-distribˡ-⊔-nonPos : NonPositive m → m * (n ⊔ o) ≡ (m * n) ⊓ (m * o) *-distribʳ-⊔-nonPos : NonPositive m → (n ⊔ o) * m ≡ (n * m) ⊓ (o * m) ⊓-absorbs-⊔ : _⊓_ Absorbs _⊔_ ⊔-absorbs-⊓ : _⊔_ Absorbs _⊓_ ⊔-⊓-absorptive : Absorptive _⊔_ _⊓_ ⊓-⊔-absorptive : Absorptive _⊓_ _⊔_ ⊓-isMagma : IsMagma _⊓_ ⊓-isSemigroup : IsSemigroup _⊓_ ⊓-isBand : IsBand _⊓_ ⊓-isCommutativeSemigroup : IsCommutativeSemigroup _⊓_ ⊓-isSemilattice : IsSemilattice _⊓_ ⊓-isSelectiveMagma : IsSelectiveMagma _⊓_ ⊔-isMagma : IsMagma _⊔_ ⊔-isSemigroup : IsSemigroup _⊔_ ⊔-isBand : IsBand _⊔_ ⊔-isCommutativeSemigroup : IsCommutativeSemigroup _⊔_ ⊔-isSemilattice : IsSemilattice _⊔_ ⊔-isSelectiveMagma : IsSelectiveMagma _⊔_ ⊔-⊓-isLattice : IsLattice _⊔_ _⊓_ ⊓-⊔-isLattice : IsLattice _⊓_ _⊔_ ⊓-magma : Magma _ _ ⊓-semigroup : Semigroup _ _ ⊓-band : Band _ _ ⊓-commutativeSemigroup : CommutativeSemigroup _ _ ⊓-semilattice : Semilattice _ _ ⊓-selectiveMagma : SelectiveMagma _ _ ⊔-magma : Magma _ _ ⊔-semigroup : Semigroup _ _ ⊔-band : Band _ _ ⊔-commutativeSemigroup : CommutativeSemigroup _ _ ⊔-semilattice : Semilattice _ _ ⊔-selectiveMagma : SelectiveMagma _ _ ⊔-⊓-lattice : Lattice _ _ ⊓-⊔-lattice : Lattice _ _
- Added new functions to
Data.List.Base
:linesBy : Decidable P → List A → List (List A) unsnoc : List A → Maybe (List A × A)
- Added new relations in
Data.List.Relation.Binary.Subset.(Propositional/Setoid)
:xs ⊇ ys = ys ⊆ xs xs ⊉ ys = ¬ xs ⊇ ys
- Added new proofs in
Data.List.Relation.Binary.Subset.Setoid.Properties
:⊆-respʳ-≋ : _⊆_ Respectsʳ _≋_ ⊆-respˡ-≋ : _⊆_ Respectsˡ _≋_ ⊆-reflexive-↭ : _↭_ ⇒ _⊆_ ⊆-respʳ-↭ : _⊆_ Respectsʳ _↭_ ⊆-respˡ-↭ : _⊆_ Respectsˡ _↭_ ⊆-↭-isPreorder : IsPreorder _↭_ _⊆_ ⊆-↭-preorder : Preorder _ _ _ Any-resp-⊆ : P Respects _≈_ → (Any P) Respects _⊆_ All-resp-⊇ : P Respects _≈_ → (All P) Respects _⊇_ xs⊆xs++ys : xs ⊆ xs ++ ys xs⊆ys++xs : xs ⊆ ys ++ xs ++⁺ʳ : xs ⊆ ys → zs ++ xs ⊆ zs ++ ys ++⁺ˡ : xs ⊆ ys → xs ++ zs ⊆ ys ++ zs ++⁺ : ws ⊆ xs → ys ⊆ zs → ws ++ ys ⊆ xs ++ zs filter⁺′ : P ⋐ Q → xs ⊆ ys → filter P? xs ⊆ filter Q? ys
- Added new proofs in
Data.List.Relation.Binary.Subset.Propositional.Properties
:⊆-reflexive-↭ : _↭_ ⇒ _⊆_ ⊆-respʳ-↭ : _⊆_ Respectsʳ _↭_ ⊆-respˡ-↭ : _⊆_ Respectsˡ _↭_ ⊆-↭-isPreorder : IsPreorder _↭_ _⊆_ ⊆-↭-preorder : Preorder _ _ _ Any-resp-⊆ : (Any P) Respects _⊆_ All-resp-⊇ : (All P) Respects _⊇_ Sublist⇒Subset : xs ⊑ ys → xs ⊆ ys xs⊆xs++ys : xs ⊆ xs ++ ys xs⊆ys++xs : xs ⊆ ys ++ xs ++⁺ʳ : xs ⊆ ys → zs ++ xs ⊆ zs ++ ys ++⁺ˡ : xs ⊆ ys → xs ++ zs ⊆ ys ++ zs filter⁺′ : P ⋐ Q → xs ⊆ ys → filter P? xs ⊆ filter Q? ys
- Added new properties to
Data.List.Properties
:concat-++ : concat xss ++ concat yss ≡ concat (xss ++ yss) concat-concat : concat ∘ map concat ≗ concat ∘ concat concat-[-] : concat ∘ map [_] ≗ id
- Added new relations to
Data.List.Relation.Binary.Sublist.(Setoid/Propositional)
:xs ⊂ ys = xs ⊆ ys × ¬ (xs ≋ ys) xs ⊃ ys = ys ⊂ xs xs ⊄ ys = ¬ (xs ⊂ ys) xs ⊅ ys = ¬ (xs ⊃ ys)
- Added new proof to
Data.List.Relation.Binary.Permutation.Propositional.Properties
:++↭ʳ++ : xs ++ ys ↭ xs ʳ++ ys
- Added new proof to
Data.List.Relation.Binary.Permutation.Setoi.Properties
:++↭ʳ++ : xs ++ ys ↭ xs ʳ++ ys
- Added new proofs to
Data.List.Extrema
:min-mono-⊆ : ⊥₁ ≤ ⊥₂ → xs ⊇ ys → min ⊥₁ xs ≤ min ⊥₂ ys max-mono-⊆ : ⊥₁ ≤ ⊥₂ → xs ⊆ ys → max ⊥₁ xs ≤ max ⊥₂ ys
- Added new operator to
Data.List.Membership.DecSetoid
:_∉?_ : Decidable _∉_
- Added new proofs to
Data.List.Relation.Unary.Any.Properties
:lookup-index : (p : Any P xs) → P (lookup xs (index p)) applyDownFrom⁺ : P (f i) → i < n → Any P (applyDownFrom f n) applyDownFrom⁻ : Any P (applyDownFrom f n) → ∃ λ i → i < n × P (f i)
- Added new proofs to
Data.List.Membership.Setoid.Properties
:∈-applyDownFrom⁺ : i < n → f i ∈ applyDownFrom f n ∈-applyDownFrom⁻ : v ∈ applyDownFrom f n → ∃ λ i → i < n × v ≈ f i
- Added new proofs to
Data.List.Membership.Propositional.Properties
:∈-applyDownFrom⁺ : i < n → f i ∈ applyDownFrom f n ∈-applyDownFrom⁻ : v ∈ applyDownFrom f n → ∃ λ i → i < n × v ≡ f i ∈-upTo⁺ : i < n → i ∈ upTo n ∈-upTo⁻ : i ∈ upTo n → i < n ∈-downFrom⁺ : i < n → i ∈ downFrom n ∈-downFrom⁻ : i ∈ downFrom n → i < n
- Added new proofs to
Data.List.Relation.Binary.Lex.Strict
:≤-isDecPartialOrder : IsStrictTotalOrder _≈_ _≺_ → IsDecPartialOrder _≋_ _≤_ ≤-decPoset : StrictTotalOrder a ℓ₁ ℓ₂ → DecPoset _ _ _
- Added new function to
Data.List.Relation.Binary.Prefix.Heterogeneous
:_++ᵖ_ : Prefix R as bs → ∀ suf → Prefix R as (bs ++ suf)
- Added new function to
Data.List.Relation.Binary.Suffix.Heterogeneous
:_++ˢ_ : ∀ pre → Suffix R as bs → Suffix R as (pre ++ bs)
- Added new function to
Data.Maybe.Base
:when : Bool → A → Maybe A
- Added new definition to
Data.Nat.Base
:_≤ᵇ_ : (m n : ℕ) → Bool
- Added new proofs to
Data.Nat.Properties
:≤∧≮⇒≡ : m ≤ n → m ≮ n → m ≡ n ≤ᵇ⇒≤ : T (m ≤ᵇ n) → m ≤ n ≤⇒≤ᵇ : m ≤ n → T (m ≤ᵇ n) <ᵇ-reflects-< : Reflects (m < n) (m <ᵇ n) ≤ᵇ-reflects-≤ : Reflects (m ≤ n) (m ≤ᵇ n) *-distribˡ-⊔ : _*_ DistributesOverˡ _⊔_ *-distribʳ-⊔ : _*_ DistributesOverʳ _⊔_ *-distrib-⊔ : _*_ DistributesOver _⊔_ *-distribˡ-⊓ : _*_ DistributesOverˡ _⊓_ *-distribʳ-⊓ : _*_ DistributesOverʳ _⊓_ *-distrib-⊓ : _*_ DistributesOver _⊓_
- Added new function to
Data.Nat.Show
:readMaybe : (base : ℕ) → {base≤16 : True (base ≤? 16)} → String → Maybe ℕ
- Added new functions and relation to
Data.String.Base
:linesBy : Decidable P → String → List String lines : String → List String _≤_ : Rel String zero
- Added new proofs to
Data.Sign.Properties
:s*opposite[s]≡- : s * opposite s ≡ - opposite[s]*s≡- : opposite s * s ≡ -
- Added new operation to
Data.Sum.Base
:reduce : A ⊎ A → A
- Added new proofs to
Data.String.Properties
:≤-isDecPartialOrder-≈ : IsDecPartialOrder _≈_ _≤_ ≤-decPoset-≈ : DecPoset _ _ _
- Added new functions to
Data.Tree.AVL
:foldr : (∀ {k} → Val k → A → A) → A → Tree V → A size : Tree V → ℕ intersectionWith : (∀ {k} → Val k → Wal k → Xal k) → Tree V → Tree W → Tree X intersection : Tree V → Tree V → Tree V intersectionsWith : (∀ {k} → Val k → Val k → Val k) → List (Tree V) → Tree V intersections : List (Tree V) → Tree V
- Added new functions to
Data.Tree.AVL.Indexed
:foldr : (∀ {k} → Val k → A → A) → A → Tree V l u h → A size : Tree V → ℕ
- Added new functions to
Data.Tree.AVL.IndexedMap
module:foldr : (∀ {k} → Value k → A → A) → A → Map → A size : Map → ℕ
- Added new functions to
Data.Tree.AVL.Map
:foldr : (Key → V → A → A) → A → Map V → A size : Map V → ℕ intersectionWith : (V → W → X) → Map V → Map W → Map X intersection : Map V → Map V → Map V intersectionsWith : (V → V → V) → List (Map V) → Map V intersections : List (Map V) → Map V
- Added new functions to
Data.Tree.AVL.Sets
:foldr : (A → B → B) → B → ⟨Set⟩ → B size : ⟨Set⟩ → ℕ union : ⟨Set⟩ → ⟨Set⟩ → ⟨Set⟩ unions : List ⟨Set⟩ → ⟨Set⟩ intersection : ⟨Set⟩ → ⟨Set⟩ → ⟨Set⟩ intersections : List ⟨Set⟩ → ⟨Set⟩
- Add new properties to
Data.Vec.Properties
:take-distr-zipWith : take m (zipWith f u v) ≡ zipWith f (take m u) (take m v) take-distr-map : take m (map f v) ≡ map f (take m v) drop-distr-zipWith : drop m (zipWith f u v) ≡ zipWith f (drop m u) (drop m v) drop-distr-map : drop m (map f v) ≡ map f (drop m v) take-drop-id : take m v ++ drop m v ≡ v zipWith-replicate : zipWith _⊕_ (replicate x) (replicate y) ≡ replicate (x ⊕ y)
-
Added infix declarations to
∃-syntax
and∄-syntax
toData.Product
. - Added new definitions to
Function.Bundles
:record Func : Set _ _⟶_ : Set a → Set b → Set _ mk⟶ : (A → B) → A ⟶ B
- Added new proofs to
Function.Construct.Composition
:function : Func R S → Func S T → Func R T _∘-⟶_ : (A ⟶ B) → (B ⟶ C) → (A ⟶ C)
- Added new proofs to
Function.Construct.Identity
:function : Func S S id-⟶ : A ⟶ A
- Added new function
Reflection.TypeChecking.Format
:errorPartFmt : (fmt : String) → Printf (lexer fmt) (List ErrorPart)
- Added new proofs to
Relation.Binary.Construct.Closure.Transitive
:reflexive : Reflexive _∼_ → Reflexive _∼⁺_ symmetric : Symmetric _∼_ → Symmetric _∼⁺_ transitive : Transitive _∼⁺_ wellFounded : WellFounded _∼_ → WellFounded _∼⁺_
- Added new proof to
Relation.Binary.PropositionalEquality
:resp : (P : Pred A ℓ) → P Respects _≡_
- Added new proof to
Relation.Nullary.Reflects
:fromEquivalence : (T b → P) → (P → T b) → Reflects P b


Initial Event Cohort
People having any of the following:
with continuous observation of at least
days prior and days after event index date,
and limit initial events to: per person.
For people matching the Primary Events, include:
Limit cohort of initial events to: per person.
Limit qualifying cohort to: per person.