text:
# Concepts as door-opening robots

I’m at CppCon this week. It’s great. You should be here too. (If you are — come say hello in person! I hope you’re having fun so far.)

# A simpler SUBSUMES() macro

In our previous installment, I called the following (not-yet-valid C++2a) idiom a “poor man’s version” of member concepts:

# A use-case for member concepts and/or template concept parameters

I continue, very slowly, to work on my CppCon 2018 session “Concepts As She Is Spoke.” A while back, someone on the C++ Slack channel asked whether it was possible to have either “template concept parameters” or “member concepts” — that is, either

# Data race when catching by non-const reference

People say “always catch exceptions by const reference,” which I think is good advice. I’ve worked on at least one codebase that catches by non-const reference, presumably just because it’s shorter to type. This has never caused any problem for them in practice, as far as I know. But in theory, it’s a bad idea, because in C++ it is possible to construct a program where two different catch-blocks, executing concurrently, actually reference the exact same exception object. In that situation, any mutation to the exception object will cause a data race. The easiest way to prevent the race is to prevent mutation: to catch by const reference!

# Homeworlds: The Yellowbird Mistake, Part II

Following up on my previous post titled “The Yellowbird Mistake”…

# Homeworlds: The Yellowbird Mistake

This post is about Binary Homeworlds, the “space chess” game invented by John Cooper and popularized by (among others) Andy Looney. You can play Homeworlds online at SuperDuperGames. Sadly a full rules explanation is out of scope for this blog post, but maybe sometime. In this post I just want to talk about a specific tactical error that (sigh) I keep making.

# Constrained forwarding references considered sketchy as frick

I’ll just leave this here.

# The big problems for C++11 SFINAE

So I’ve finally started working on slides for my CppCon 2018 talk “Concepts As She Is Spoke.” (To see the original work to whose title this is an allusion, click through.) I intended to make it as bland and tutorial in nature as I can, but my natural tendency to find the hard problems keeps interfering. Let me take the 25 slides I just wrote and turn them into a blog post, so that I can qualmlessly delete these slides and start over.

# The Mysteries of London

Lately I’ve been reading George W. M. ReynoldsThe Mysteries of London (serialized 1844–1845). Or, mostly, speed-reading; it gives the general impression that the author was paid by the column-inch, and it’s not worth too much of one’s full attention. But every so often there’s a gem that makes the exercise pay off.

# make_range and reversed

A simple force multiplier that should be in every C++11-and-later programmer’s toolbox:

template<class It>
struct iterator_range {
It begin_, end_;
constexpr It begin() const noexcept { return begin_; }
constexpr It end() const noexcept { return end_; }
}; ...

# Stopping the cascade of errors

In 2016, Andrzej Krzemieński pointed out that static_assert is great and all, but it doesn’t stop the cascade of error messages from something like this:

# C++ doesn’t know how to do customization points that aren’t operators

If you’re a C++ programmer and you want to customize the behavior of your class for a certain operation, you’ll have one of two experiences:

# Exploring C++ types with puts(__PRETTY_FUNCTION__)

Today on Slack I noticed that some people still don’t know this one, so it should be shared more widely.

# mutable and “trivially fooable”

Pop quiz, hotshot.

struct M {
M() = default;
M(M&);
M(const M&) = default;
};

Is M trivially move-constructible? …

# The Auto macro

I’ve been talking about this one since 2014. The contents of “Auto.h” fit comfortably on a single slide:

# The FORCE_CONSTEXPR macro

#define FORCE_CONSTEXPR(expr) [&]() \
{ constexpr auto x = (expr); return x; }()


text:
# Three warnings with six lines of code

Using the tufte-book class, I get three different warnings just with these six lines of code:

\documentclass{tufte-book}
\usepackage{lipsum}
\begin{document}
\marginnote{Foo}
\lipsum[1-5]
\end{document}

The warnings I get are

LaTeX Warning: Marginpar on page 1 moved.

Package bibentry Warning: You have used \nobibliography* without a following \bibliography.

Underfull \vbox (badness 10000) has occurred while \output is active

This isn't the first time I've had issues with this class, and I'm very tempted to just give up on it.

Is there an easy way to silence those warnings or should I move on?

• Warnings are not necessarily a problem, if the output looks good then you can safely ignore the errors. Of course you should try to fix warnings if you can, but if you cannot fix them then most of the time the resulting pdf will be fine. – Marijn May 18 at 21:54
• (1) The marginpar warning is because the marginpar is prior to the start of the paragraph. It's moved to align it with the first line of the paragraph. (2) If you're not going to use a bibliography, then use the nobib document class option to suppress the warning (and disable the built-in bibliography code). (3) This will vary based on the actual content of your document. Adding more or less text will likely resolve this. – godbyk May 18 at 22:47
• @godbyk Thanks for the help, I got rid of the second warning but haven't been successful with the other two. (1) Then how do I get a marginnote that is aligned with the first line of a paragraph? I tried putting some text before the marginnote, e.g. Foo\marginnote{Bar} Baz, but the warning is still there. (3) I get this warning every time a new page is outputted. What's wrong with the length of the \lipsum[1-5] text, why should I need to add or remove any text? – noibe May 19 at 12:53
• Using the code from this post seems to solve the (3) warning. – noibe May 19 at 13:16

format: plain


text:
Profil  |   Publiczne video (0)  |   Prywatne video (0)  |   Ulubione (0)  |   Przyjaciele (0)

## dl92q0b1 - profil

Video użytkownika oglądano 0 razy
Profil uzytkownika oglądano 476 razy
Użytkownik obejrzał 0 video
Użytkownik ma 0 przyjaciół

Zarejestruj się lub Zaloguj aby dodać dl92q0b1 do przyjaciół.
 Ostatnie logowanie: 2706 dni temu Zarejestrował się: 2706 dni temu Imię / Nick: dl92q0b1 Slomer Wiek: 41 Płeć: K O sobie: kuchnie na wymiar warszawa How to make simple Barcodes Popular Stand out Uk concert party Ultrahaptics grasp expanded an original expertise that will allows abusers for concrete experiences since out of sight 3 dimensions victims soaring taking part in above ground. Virtalent corresponds businessperson also matters with academe apprentices which exert yourself tenuously to accomplish any amount of on-going missions otherwise one-off sees into the future. Each of our Netting spider isn't arbitrary; we establish with all the Alexa crest thousands and still have been alive utilizing the hyperlink as of those puts to get a wider reach associated with summons,” Lopin shouted. On the 41 seek also fabrication firm inside Dow Jones Grease along with Gab Makers Pointer, 15 group received outside juice tricks cause the stashes away assessments with regard to them. Portia receives gleaned the most effective purposes as of every one of the sports center, wellness middles plus checkup tidiness she's ever endured the enjoyment to operate with and it has made all the mull over to Generate anywhere the girl "say ""i do""" your ex cherishes with the woman interest pro placing health insurance and wellness. Discover ways to check out, reach helpers next chat with hit and miss nations while using the for the most part talked-about portable memorandum software. The search engines Influence is often a ritual allowing clients for making messages or calls from your range apart from his or her cellphone otherwise landline. The centrifical pry open produced because of the casino person in charge transferring a circular lane piece of legislation near caway your own gets brazen toward the baseball which usually can easily impinge on the balance involving your own case for the duration of the golf swing. In the course of a good vertical swing action this kind of centrifical constrain is it being spawned other cheerful over the crate along with calvess through the grate engendering much less influence on your own hand down in exchange leans muscle making it possible for your current stalk to be other sure. Individual crash remains identified using the numerals 0 via 9 next the opposite with manifolds involving 10 via 00 on the way to 99. After you cylinder both dice at the same time, people engender lots connecting 0 plus 99. The much more play-off a polyhedron bear, the far more around it's got to get, so this means dice having a multitude of looks toward never get too. I afford the introduction involving precisely how toward change RGB/ARGB reflection for you to 8 attack colour pallette likeness next to lessening the overall volume of tints in the direction of 256 for anyone who is gazing headed for put into action that yourself. In the event you simply want to engender less important PNG the way you are seen in a jiffy, that put on view how we be capable of employ this aspect with your possess Espresso cipher with the JDeli Capuccino Icon documents. If a perception surrounds 256 color or perhaps take away, followed by 256 influence colour scheme diagram brings into being lossless answers; Save for if a perception limits a many colorations next the shade color scheme should be picked in a fashion that optimizes meant for coloration that will am real most popular to be able to come up with a good end result so as to lives visually tolerable. So, we eased on the difficulty connected with crank out a arbitrary variety linking $1$ and also $5$. In their normal method an individual create a dress scattering over $1,10$ with $\frac115=\colorred2.2$ chucks, wearing normal. What's transpiring the following is we suppose we have been opting an actual numeral commencing $0,10)$, and we'll after that heave out the portion portion of this specific existent digit. The reckonings with $a,b)$ transpire look after an eye on our own uncertainty within the frank amount were make starting pass away spool. To generate the whole really total, we may should turn round the pack in evermore, Nevertheless we will not want the complete really integer. The program code are available in usuals connected with 10, and you will engender a brand new put in any spot, involuntarily helping to make the older solidified dormant. Strona WWW: http://www.twojemeblenawymiar.pl/

## Komentarze

 Dodaj komentarz
Brak komentarzy


text:
It’s all very well designing your future but now you need to actually engineer it by testing and building. An obvious place to start is with your CV or résumé, because that’s where most people get going. How can you create a bug-free CV, résumé or completed application form? How can you support applications with a strong personal statement or covering letter? These documents are crucial part of your future so how can you debug them? 🐛

## 7.1 What you will learn

By the end of this chapter you will be able to

1. Structure and style the content of your CV and résumé appropriately
2. Articulate your story7 as evidenced by your experience, projects and education etc
3. Identify and fix bugs in CV’s by:
• Constructively criticising other people’s CVs
• Asking for, listening to, and acting on constructive criticism of your own CV
4. Quantify and provide convincing evidence for any claims you make you on your CV
5. Identify gaps is your CV and how you might begin to fill them

## 7.2 Beware of the black hole

Before we get started, let’s consider some advice from software engineer Gayle Laakmann McDowell. Gayle is an experienced software engineer who has worked at some of the biggest technology employers in the world: Apple, Microsoft and Google. She has also authored a cracking series of books on technology careers, particularly Cracking the Coding Interview which we’ll discusses in chapter 10. Gayle refers to the employer “black hole” described in figure 7.2.

If you’re applying to big employers, you’ll need to create a CV that is good enough to stand out before it disappears over the event horizon and into an employers black hole, see section 8.4.8. Your CV or résumé needs to be good enough to persuade an employer to invite you to an interview. You can start with an employer-agnostic CV but you may need to come back and revisit the issues in this chapter once you have identified some target employers, so that you can customise and tailor your CV and written applications.

## 7.3 The CV is dead, long live the CV!

Résumés and CV’s have reigned supreme in kingdom of employment and recruitment for many years but their demise has often been predicted, see figure 7.3.

While it is true that some employers don’t accept CVs or favour online application forms or digital profiles, it is still worth writing a CV because:

• Your CV provides a record for you of relevant things you’ve done
• Your CV enables you to get your story straight, What’s your story, coding glory? see section 2.2.3
• Your CV forces you to articulate who you are and what you want, see chapter 2
• Some employers will still ask you for one, see section 7.7.6 and figure 7.3
• Your CV helps you script and practice your “lines” for interviews, see chapter 10

Even if an employer never asks you for your CV, you’ll frequently want to use the content of your CV in applications and interviews. So this chapter looks at how you can debug your written applications, whatever the mechanism is for submitting them.

You can of course augment your CV with various public digital profiles such as LinkedIn, Github etc. A public digital profile can help employers find you, see section 8.3.2.

Wherever you’re putting information about yourself for potential employers, on a CV, Résumé, LinkedIn profile the same principles apply. See the checklist in section 7.9 and for specific advice on LinkedIn see:

## 7.4 It’s not bug, it’s a feature!

It’s an age old trope in Computer Science that engineers use to cover their mistakes, passing off their accidental bugs as deliberate features of their work, see 7.4.

“It’s not a bug, it’s a feature…” —A. Hacker

Nobody likes buggy software, but unfortunately we routinely have to tolerate badly-designed, low quality, bug-ridden software in our everyday lives.

In contrast, buggy CVs are rarely tolerated, they will usually end up in the bin. Even a tiny defect, like an innocent typo, can be fetal fatal. Most employers (particularly large and well known ones) have to triage hundreds or even thousands of CV’s for any given vacancy. This means the person reading your CV is as likely to be looking for reasons to REJECT your CV, than ACCEPT it, because that’s a sensible strategy for shortlisting from a huge pool of candidates. A buggy CV, application and covering letter could ruin your chances of being invited to an interview, see chapter 10.

Like writing software, the challenging part of writing a CV isn’t the creation but in the debugging and subsequent re-writing. Can you identify and fix the bugs before they are fatal?

⚠ Coding Caution ⚠

If you ask three people what they think of your CV, you will get three different and probably contradictory opinions. CV’s are very subjective and very personal. The advice in this chapter is based on common sense, experience and ongoing conversations with employers. What makes a good CV will depend on the personal preferences and prejudices of your reader. So, this chapter just describes some general debugging guidelines, rather than rigid rules.

It is good practice to triangulate responses from your readers. For example, if three different people point out the same bug in your CV you can be confident that it is a bug that needs fixing.

While referring to this guide, remember that:

• The main purpose of your CV is to get an interview, not a job. Your CV should catch attention and provide talking points for an interview
• Your CV will be assessed in seconds, rather than minutes so brevity really is key
• Bullet points with verbs first (see section 7.7.4) will:
• avoid long sections of flowery prose which the reader will very probably skip anyway. Instead, you can use your beautiful prose on your covering letters or personal statements, see section 7.10

You’re not trying to tell your whole life story from section 2.2.3 but to distill the essentials into several short stories which can be summarised into a handful of bullets or sentences. It’s a bit like the blurb or synopsis on the back of novel, can you entice the reader into wanting to find out more (by inviting you to an interview)?

## 7.5 Is it a bug or a feature?

Wherever criticism of your CV comes from, don’t take it personally - it is probably one of the first you have written. Think of your current CV as an alpha or beta version that you continuously test, release and redeploy. There are many chances to debug and improve your CV during your study but before potential employers read it. The aim of this chapter is to help you improve your CV, whatever stage you are at. Employers often grumble that Computer Science graduates lack written communication skills. Written applications and CV’s are a common example of this.

1. EDUCATION: Is your year of graduation, degree program, University and expected (or achieved) degree classification clear? Have you mentioned things you are studying now, not just courses you have finished? See section 7.6.2
2. STYLE: Does it look good, decent layout, appropriate use of LaTeX or Word or whatever? Are there any spelling mistakes, typos and grammar? Don’t just rely on a spellchecker, some typos can only be spitted spotted by a human reader see section 7.7.7
3. LENGTH: Does it fit comfortably on (ideally) one page (for a Résumé) or two pages (for a CV)? See section 7.7.3
4. STRUCTURE: Is the structure sensible? Is it in reverse chronological order? Most important (usually recent) things first? Not too many sections or anything missing? See section 7.6
5. VERBS FIRST: Have you talked about what you have actually done using prominent verbs, rather than just what you think you know? Avoid long sections of prose, see section 7.7.4
6. RESULTS: Have you also demonstrated and quantified the outcomes of your actions where possible, see Context, Action, Result & Evidence (C.A.R.E.) in section 7.7.2
7. SEE ALSO: This is just a quick checklist, see the longer CV checklist in section 7.9

How you structure your CV will depend on who you are and what your story is. Recruiters at Google suggest four or five sections, that follow a header section. Before we look at those, lets look at some general points about CVs, watch the videos shown in Figure 7.5.

As Jonathan Black, director of the careers service at the University of Oxford has pointed out, a key part of your story that you want to communicate in your CV is that you :

1. take responsibility
2. achieve things
3. are nice to have around

How can you demonstrate this? Watch the short video in Figure 7.6.

Quantifying and providing evidence for any claims you make will make your CV much more convincing. This can turn meaningless assertions described in figure 7.6 into meaningful evidence. So for example:

* Achieved excellent results

…is a bit vague, what were the results exactly, can you measure them somehow? Or at least describe them?

* Worked in a team

So you worked in a team? Worked is vague. What was your role and contribution exactly? How long did the project last? How many people were on your team? What was the result of your action? What’s the story, coding glory?

The first thing in your CV is the header, a simple section giving your name, email, phone number and any links shown in the CV in figure 7.7 for Alan Turing. That’s it!

1. 🎓 Education: the formal stuff, see section 7.6.2
2. 💰 Experience: paid work, see section 7.6.3
3. 💪 Projects: personal, school, social, side or University projects see section 7.6.4
4. 🏆 Leadership and awards: see section 7.6.5
5. Optional: but don’t call it that, see section 7.6.6

Let’s look at each of these sections in turn:

Unless you have significant amount of experience, the EDUCATION section of your CV is likely to be the first real section, after the header. Your education section needs to strike a balance between:

• Describing in enough detail what you’ve studied and any projects you’ve completed at University as part of your formal education
• Keeping it short and sweet by avoiding getting bogged down in tedious details

You’ve invested a significant amount of time and money in getting your degree. At this stage, your degree justifies more description than a terse one line BSc Computer Science. You’ll need to:

• say more than Pen Tester and Rick Urshion, who haven’t said enough about their University education
• say less than Mike Rokernel, who has given way too much information on his degree.

You don’t need to name every single module and give a mark for each. Neither do you need to give your result to FOUR or FIVE significant figures: 71.587%9. Two significant figures will do just fine: 72% (first class). You might like to pick out relevant modules, or the ones you enjoyed most. Employers like Google encourage applicants to emphasise courses on data structures and algorithms, but you’ll need to tailor your description to the role and be brief. On a one page CV, you might only have two or three lines to describe your higher education. 🎓

Experience is where you can talk about any paid or voluntary work experience you have. For paid work call it EXPERIENCE rather than WORK EXPERIENCE as the latter can imply work shadowing, see section 5.3. Work shadowing is valuable, but paid work is even better so you should make it clear if your experience was paid or not. Don’t discount the value of casual labour, such as working in retail or hospitality, these demonstrate your work ethic and ability to deal with customers, often under pressure. You are more than just a techie too, so anywhere you’ve worked in a team is experience worth mentioning, even if that team was just two people. Two people is still a team.

If you don’t have much experience, don’t worry, there are plenty of opportunities to get some. For details, see chapter 5 experiencing your future.

Are you experienced? Whatever it is, make sure you add it to your experience section. 💰

The PROJECTS section of your CV is a where you can describe all other things you get up to. These might include:

• personal side projects
• social responsibility projects
• open source projects
• entrepreneurial projects
• University projects (although these might fit better in your Education section)

Your projects will most likely be unpaid because paid work tends to fit better under the heading experience, see section 7.6.3. Perhaps you’ve completed some courses outside of your education such as a massive open online course (MOOC) or similar. Hackathons and competitions, fit well here too. You don’t need to have won any prizes or awards, although be sure to mention them if you have. Participating in hackathons and competitions clearly shows the reader that you enjoy learning new things. Demonstrating an appetite for new knowledge and skills will make your application stand out. If you’re looking for some inspiration for side projects, the codecrafters-io/build-your-own-x repository is a good starting point. Building and creating new things is a great way to understand them, just ask Richard Feynman shown in figure 7.9. What you cannot create you do not understand. One way of doing this is with open source projects which we describe in section 5.3.3.

Any longer projects you’ve done at University are worth mentioning. Your projects are important because they differentiate you from everyone else in your year group. Try to be more descriptive than this:

* First year team project

or perhaps

* Second year team project

or even just

* Final year project

By themselves, those project names are pretty opaque. They are OK for giving the context of your story but don’t give the reader much else to go on. What was the story (the context, action, result and evidence (CARE) we described in section 7.7.2) of those projects? How many people were in your team? How long did you collaborate for? What did you build? What was it called? What did it do? What roles and responsibilities did you have in the team? Was their conflict in the team? How did you resolve it? How did you motivate the free-riders in the team to contribute? This is all excellent CV fodder, see 7.10

It’s often better to describe what YOU did before you describe what the software, hardware or project did. Your reader is much more likely to be interested in the former than the latter. Let’s imagine you’ve developed a piece of software called WidgetWasher. You might describe it like this:

* WidgetWasher is a web service that washes widgets
* Makes use of an HTTP API and secret keys
* Tested WidgetWasher on a range of different operating systems
* Collaborated with one other contributor over two days
* Designed and implemented an API

Instead, you could reverse the order to change the emphasis like this:

* Designed and implemented an API
* Collaborated with one other contributor over two days
* Tested WidgetWasher on a range of different operating systems
* Makes use of an HTTP API and secret keys
* WidgetWasher is a web service that washes widgets

The latter has all the same information, but by reversing the order, you’ve emphasised what you did, rather than what the software did. 💪

If you can demonstrate leadership, you may want to dedicate a whole separate section for it. If you have experience of tutoring or mentoring other students, perhaps younger ones, make sure you highlight it as leadership. Teaching is a different kind of leadership to running a small business or captaining a sports team, but it is leadership nonetheless.

A leadership section is also a good place to add any prizes you’ve won. If you’ve been granted any interesting awards or honours be sure to mention them. You’ll typically need a bit more than:

* Awarded the Poppleton University scholarship for excellence

Congratulations, but how many people were awarded that prize? How many applicants or entrants were there and what percentage were successful? Was it a regional, national or global award? How frequently is the award given? It is unlikely that your reader will have heard of the award unless it is widely known. So if you’re going to mention awards, give the context where you can so the reader can understand what the prize was for. 🏆

If you have anything else you want to highlight besides your education, experience, projects and leadership and awards you may still have room for one more optional extras section. Try to come up with a better name than Miscellaneous, Extracurricular or Other highlights, which sound like dumping grounds for the leftovers. You might decide to have a dedicated skills section but see section 7.6.7.

You may opt to have a hobbies and interests section which can add a bit of colour to what can otherwise become quite a dull list of facts. However, it is debatable how many (if any) hobbies and interests you should list on your CV. For a one-pager you’re usually pushed for space and looking for things to edit out (rather than add in), so if you’re going to list hobbies, I’d stick to those that are relevant to the job or those that demonstrate particular transferrable or soft skills. Organising or participating in team sports is a good example of a relevant hobby as it provides evidence of your teamwork, commitment, reliability etc, see figure 7.11. Other collaborative activities outside of sport will also demonstrate your communication skills.

The fact that you enjoy swimming, reading, football, cooking and hiking is a vague and pretty boring, making it unlikely to be a factor in the decision to invite you to interview. There’s nothing wrong with these pastimes but there’s not much point mentioning them on your CV unless you have, for example:

• coached a swimming team
• trained as a mountain leader
• organised, hosted and participated in a book club
• regularly participated in or organised competitive sports matches (for example)

In this case, the way you have engaged with your hobbies demonstrates your communication and leadership skills. So in this context, your hobbies are worth talking about if you have any space left. However, if they are just hobbies that enable you to amuse yourself, you should probably leave them out as they are unlikely to be of interest to an employer. Sure, they add colour to your CV, but you’ve probably got more interesting and important things to say about who you are.

Of course, you might get lucky and your interviewer could be intrigued (or even share) your esoteric passion for Quidditch (say), but you can’t rely on it. So, I reckon if you’re going to mention hobbies and interests at all then …

• pick the unusual hobbies that make you unique
• describe the interests that add some colour and personality to your CV
• be specific, e.g. reading japanese novels from 20th century might sound more interesting than just reading
• highlight any actions you’ve taken, see chapter 18

… or just leave them out altogether. That option is up to you.❓

You may be tempted to dedicate a whole section on your CV to skills, particularly the technical ones. Maybe it makes you feel good listing them all in one place like a stamp collection. If you’re going to have a skills section, keep it short. Why? Let’s imagine, that like Rick Urshion, you include Python in a long list skills, with its own dedicated section. There are at least five problems with Rick’s not so skilful approach:

1. No Context to give the reader an idea of where he’s developed or used his Python skills. Was it during his education, as a part of his work experience or his personal projects? We don’t know because he doesn’t say.
2. No Actions to demonstrate what he’s done with his Python skills. So Rick claims he knows Python. So what? What did use them for? We don’t know because he hasn’t told us.
3. No Results given for what the outcome of using the skills was. Did he save his employers some money? Did he make something more efficient? Did he learn some methodology? We will never know.
4. No Evidence to support his claims. Perhaps he DOES have Python skills, perhaps he DOESN’T. Is he telling lies and peddling fake news (see section 8.4.4)? It’s difficult to tell.
5. No C.A.R.E. There’s no story told for that skill, see figure 7.12. This makes for a very dull and boring read. Yawn. NEXT! 🥱

So, this doesn’t mean Rick shouldn’t mention his Python skills. Where he can, he needs to give us the context, action, result and evidence (C.A.R.E.) of his story described in section 7.7.2. This will make his Python story much more convincing and interesting to read. Showing a bit of C.A.R.E. will improve his chances of being invited to interview.

This applies to soft skills too, not just hard technical skills. Best to mention the context in which you’ve used any skills you mention on your CV. So, if you’re going to have a skill section:

• keep it short (one or two lines maybe) but personally I’d avoid dedicating a whole section to it
• stick to your strongest and most relevant skills that you are comfortable to answer questions on in your interview, rather than an exhaustive encyclopædic inventory
• avoid listing mass marketed office products of Microsoft (e.g. Word etc) as a skill, they are not generally very interesting skill because almost everyone has them. They won’t set you apart much from your competition, so don’t waste valuable space talking about office unless you’ve done something interesting with them, like some advanced integration with other software. Cloud services can be a slightly different matter, see section 11.4.1.

If you’re a computer scientist, you also have demonstrable meta skills like the ability to learn things quickly. You can also think logically and critically, reason, problem solve, analyse, generalise, decompose and abstract - often to tight deadlines. These computational thinking skills are future-proof and will last longer than whatever technology happens to be fashionable right now. Employers are often more interested in these meta capabilities and your potential than in any specific technical skills you may or may not have.

## 7.7 Birds eye view

Having looked at the sections you’re likely to have, we’ll take a birds eye view of your whole CV. The issues in this section apply to the whole of your CV, rather than individual sections.

Making your CV look good can take ages, but a well presented CV will stand out. While its worth making an effort to style carefully and consistently, you need to be be wary of the huge time sink of typography.

Whatever your typographical style is, portable document format (*.pdf) is the safest way to deliver it. It’s called portable for a reason. While Microsoft Word is fine for editing, it is difficult to ensure that a Word document doesn’t get mangled by transmission via the web, email or even Microsoft’s own products like Teams! PDF is much safer, you can be more confident that it will work well on a range of different operating systems and devices. Try opening a Word document on any smartphone or tablet and you’ll see what I mean. It helps if you can give the file a descriptive name so ada_lovelace.pdf is a better filename than my_cv.pdf, especially if its being read by a human and not a robot. 🤖

It’s fine to author your CV in Microsoft Word, but you’ll want to save it as a PDF to make it more platform independent. LaTeX and overleaf can be used to create professional PDFs and there are plenty of good templates. See Getting started with LaTeX (LaTeX4year1) if you’ve not used LaTeX before, or you need to refresh your memory.

### 7.7.2 What’s your story, coding glory?

One way to structure descriptions of items within each section of your CV is to use Context, Action, Result and Evidence (C.A.R.E.) to tell your stories. What’s your story, coding glory? The C.A.R.E. method can also be useful for structuring answers to interview questions, especially if you get nervous. So for example, rather than just listing Python as a skill, you could tell the reader more about the context in which you’ve used python, what you actually did with it and what the result was. You really need to spell it out.

• CONTEXT: So you’ve used Python, but in what context? As part of your education? For a personal project? As a volunteer? In a competition? All of the above?
• ACTION: What did you do with Python? Did you use some particular library? Did you integrate or model something? What verbs can you use to describe these actions, see chapter 18
• RESULT: What was the result and how can you measure it? You picked up some new skills? What was the impact? Perhaps you made something that was inefficient and awkward into something better, cheaper or faster? Some things are hard to measure but you should quantify results where you can.
• EVIDENCE: Where evidence exists, you should highlight it. That could be a quantification, for example describing a result in numbers (see as measured by below) or it might be certification described in chapter 12. If you’re talking about software, point to a copy online if you can, but beware of plagiarism if you publish university coursework on github. Nothing says “I can build software …” quite like “ … and here’s one I made earlier”.

You don’t have to stick rigidly to the order C.A.R.E. as long as they appear somewhere. For example, recruiters at Google (see figure 7.5) advise candidates to describe their experience and projects using this simple pattern:

* Accomplished [X], as measured by [Y], by doing [Z]

Where accomplished is Result, measured by is Evidence and doing is the Action. So instead of just saying:

* Generated reports for end users

You could say:

* Generated daily reconciliation report for team by automating workflow of 8 different tasks

The latter is better because it is more specific, captures the result (accomplishment), by giving evidence (8 different tasks) and talks about the actions (the doing part). Choose the verbs you use carefully, see chapter 18 for examples.

How long should your CV be? Many people start with a two page CV, which is a sensible starting point shown in figure 7.14. It is also advisable to create a one page Résumé.

At this stage in your career you should be able to fit everything on to one page. However, it can be challenging and time consuming squeezing it all on, see figure 7.15.

It takes more time to write less. Writing a one page résumé is a valuable exercise, because it forces you to distill and edit out any filler or fluff, which you sometimes find on two page undergraduate or graduate CVs. It is much better to have a strong one-page résumé than a weaker two-page CV that is padded out with filler to make up the space, as described in the video in figure 7.14. Adding more features (pages and content) to your CV doesn’t necessarily make it better. Sometimes adding more features to your CV will make it worse, as shown in figure 7.16.

If you’re struggling to fit all the information onto a one page résumé, revisit each section and item carefully. Is there anything you can drop? Can you save a wasteful word here, or a lazy line there? Check for any spurious line breaks because every pixel counts. Don’t throw your two page CV away, it is still a good store of stuff you might want to add to customised one-page résumés.

A simple but effective technique for emphasising what you have done, rather than just what you know, is to start the description of it with a verb. Employers don’t just want to know what you know, but what you have actually done. So, for example, instead of saying e.g.

* In my second year CS29328 software engineering module I used Java, Eclipse and JUnit to test and build an open source Massively Multiplayer Online Role-Playing Game (MMORPG)

you could say:

* Built and tested a large open-source codebase using Eclipse, Ant, JUnit and Jenkins”

followed by:

* Added and deployed new features to a Massively Multiplayer Online Role-Playing Game (MMORPG) in Java

The latter examples get to the point much quicker and avoid the problem of using I, me, my... too much which can sound self-centred and egotistical. Although your CV is all about you so it is natural to have a few personal pronouns in there, too many can look clumsy and give the wrong impression. Choose the verbs you use carefully, see chapter 18 for examples.

### 7.7.6 Robot proofing your CV

It’s a good idea get feedback from as many different sources as you can on your CV. By sources I don’t just mean humans, but also robots. Larger employers will use automated Application Tracking Systems (ATS) to log and trace your application. These “résumé robots” (if you like) are unlikely to have arms and legs like the one in figure 7.18, but they will be looking for keywords and standard headings in your CV. You can get automated feedback from a range of different automated systems, though it is a good idea to remove any personal information like phone numbers and emails before using these free services. You might also want to check what the services privacy policy says about what they do with your personal data. Résumé robots include:

Besides providing feedback on the content of your CV, using these systems can help address issues such as the use of tables or layout which may cause problems for some systems. For example, some systems ignore the second column of a two-column CV because they can’t parse the PostScript reliably to identify columns. Some things to check with automated CV screens:

• Have you used standard headings for the sections? Non-standard sections maybe ignored or misunderstood
• Have you used appropriate verbs to describe your actions?
• Is your layout and design robot friendly? Sometimes tables and two column layouts can get horribly mangled, see what happens to tables and columns in an applicant tracking system

### 7.7.7 Spellchecking

Bots, grammar and spell checkers will improve your CV but you can’t rely on automated help completely. The résumé robots described in section 7.7.6 will just encode the biases and prejudices of whoever wrote their algorithms. Spellcheckers can’t be relied on completely either, as shown in the poem below:

Eye halve a spelling checker
It came with my pea sea
It plainly marques four my revue
Miss steaks eye kin knot sea

Eye strike a key and type a word
And weight for it to say
Weather eye am wrong oar write
It shows me strait a weigh

As soon as a mist ache is maid
It nose bee fore two long
And eye can put the error rite
Its rare lea ever wrong

Eye have run this poem threw it
Its letter perfect awl the weigh
My chequer told me sew

---Anon

While automation can help improve your writing, ultimately there is no substitute for people (you know: actual humans) reading your CV, and the more people that read it the better. This could be potential employers, your critical friends shown in figure 7.19 or just reading it out loud to yourself described in section 4.5.1.

You might be tempted to put your referees details on your résumé. Don’t bother because;

• references waste valuable space. You can say much more interesting things about yourself than who you referees are
• references aren’t needed in the early stages of a job application anyway. Employers typically ask for your referees much later, when you’ve been offered or are about to be offered the job
• references disclose personal information. Do you really want to be giving personal details out to anyone that reads your CV? It could easily be misused.

It’s not even worth saying references available on request - that just wastes space as well and is implied information on every CV anyway.

## 7.8 Breakpoints

Let’s pause here. Insert a breakpoint in your code and slowly step through it so we can examine the current values of your variables and parameters.

* PAUSE ⏸
* RESUME ▶

## 7.9 Checklist: Big Bad Bugs

Here is a quick check-list for debugging your CV before you send it off to an employer:

1. ✅ Does it fit comfortably on exactly one page (résumé) or two pages (CV)? Definitely not one-and-a-half pages or more than two? See section 7.7.3
2. ✅ Does the style look good? Is it easy on the eye? Is there adequate whitespace, not too much (gappy) or too little (cramped)? See section 7.7.1
3. ✅ Is your year of graduation, degree program, University and expected (or achieved) overall degree classification clear? See section 7.6.2
4. ✅ Have you eaten your own dogfood (woof), see section 4.5.1? Is everything relevant? e.g. no swimming certificates from ten years ago?
5. ✅ Have you spell-checked using both automatic and manual (proof-reading) techniques? See section 7.7.7.
6. ✅ Have you got a second opinion from a “résumé robot”? Is it robot proof? See section 7.7.6 🤖
7. ✅ Have you shown you C.A.R.E? Are the Contexts, Actions, Results and Evidence described in section 7.6.7 clear? Have you added context using relevant hyperlinks that an interested reader can click on? See section 7.7.5
8. ✅ Is it in reverse chronological order with the most recent things first? Can your timeline be easily scanned, with all dates clearly aligned for easy reading? See Neil Pointer as an example with a clear timeline using right-aligned dates.
9. ✅ Have you avoided using too many personal pronouns? I, me, my ... everywhere? See section 7.7.4
10. ✅ Have you made it clear what you have actually done using prominent verbs? See chapter 18
11. ✅ Have you given sufficient information on your education without going into too much detail? Have you mentioned courses you are studying now (and next semester)? See section 7.6.2
12. ✅ Have you quantified and evidenced the claims you have made where you can? See section 7.6
13. ✅ Is it balanced, including both technical and non-technical (softer) skills? See section 5.3.5
14. ✅ Does it have a good, clear structure? Not too many headings, around five sections for a one-pager see section 7.6.1?
15. ✅ Have you clearly distinguished between paid, unpaid and voluntary experience? Have you done the same for your projects, see section 7.6.4? Have you included all of the relevant experience that you can fit on including casual work, see section 5.3.5?
16. ✅ Has your CV been reviewed by other people? Do a CV swap with a critical friend (see figure 7.19) and score each others CV’s using this rubric. This is a bit like pair programming. According to Linus’s law “given enough eyeballs all bugs are shallow” so the more people who give you feedback the better
17. ✅ Have you reviewed other people’s CV’s? This will put you in the shoes of an employer or recruiter, thereby helping you to write a better CV yourself. See the examples in chapter 15. Who would you want to interview and why?

## 7.10 Covering letters & personal statements

Applications and CV’s are often accompanied by covering letters or include some kind of personal statement. Whereas a lot of your CV is essentially a bulleted list of facts and statements, a covering letter or personal statement gives you a chance to really demonstrate your fluent written communication skills in clear prose. If you’re going to have a personal statement or profile on your CV keep it short, unlike Mike Rokernel who waffles on for ages without providing any evidence. Usually this kind of information is better in your covering letter.

Let’s say you’re applying for a widget engineering position at widget.com. There are three things you need to cover in this order:

1. Why them? Why are you applying to widget.com
2. Why that role? Employees of widget.com have many roles and responsibilities but what is it about widget engineering (say) that attracts you?
3. Why you? Why should widget.com employ you? What skills and experience make you stand out from all the other candidate widget engineerings? What are your Unique Selling Points (USPs)? Say why you would be good for them (not why widget.com would be good for you and your career).

You can see some examples of answers to these questions at:

### 7.10.1 Does anyone actually READ covering letters?

Some employers will read your covering letter very carefully, others less so. It is not always clear which employers will bother and which won’t.

Even if nobody reads your covering letter, it is still worth writing one because formulating answers to the three basic questions in section 7.10 will force you to rehearse standard interview questions.

Think of your covering letter as practicing some of the lines of your elevator pitch.

## 7.11 Debugging summary

Too long, didn’t read (TL;DR)? Here’s a summary:

In this chapter we have looked at how to debug your CV. If you fix the bugs we’ve described here, before an employer sees your CV, you’ll stand a much better chance of getting an interview. The checklist above in section 7.9 is a good place to start.


text:
# About the values of the $\Gamma$ function

The $\Gamma$ function is defined by

$$\Gamma(z)=\int_{0}^{+\infty}t^{z-1}e^{-t}dt$$

where $z$ is a complex number.

We know that if $z$ is real then the values of $\Gamma$ are also real. I am interested in the case where $z$ is complex and the values of $\Gamma$ are real. In particular where $0<Re(z)<1$.

Is this case possible?

-

Here's a picture of the contours for $\Im(\Gamma(z))=0$. As you can see, pure real values of the gamma function, and indeed most analytic functions in the complex plane, are quite common off the real line.

-
Is there some simple function that describes these contours? –  nbubis Dec 30 '12 at 9:31
@ Mario Carneiro : So, my case is possible. Can you indicate to me a reference about this. For your claim: "most analytic functions in the complex plane, are quite common off the real line". –  ZE1 Dec 30 '12 at 9:39
i don't understand can you please explain what is the contour is? –  Koushik Dec 30 '12 at 10:01


text:
# One Categorical Variable

## 2018/03/26

### Frequency Distributions

What is your perception of your own body? Do you feel that you are overweight, underweight, or about right?

A random sample of 1,200 U.S. college students were asked this question as part of a larger survey. The following table shows part of the responses:

Table 1: Body Image
Student Body_Image
student 25 overweight
student 27 underweight

The information we would be interested in finding are:

• What percentage of the samples students fall into each category?
• How are the students divided across the three body image categories? Are they equally divided? If not, do the percentages follow some other kind of pattern?

There is no way that we can answer these questions by looking at the raw data, which are in the form of a long list of 1,200 responses, and thus not very useful. However, both these questions will be easily answered once we summarize and look at the distribution of the variable Body Image (i.e., once we summarize how often each of the categories occurs).

In order to summarize the distribution of a categorical variable, we first create a table of the different values (categories) the variable takes, how many times each value occurs (count) and, more importantly, how often each value occurs (by converting the counts to percentages); this table is called a frequency distribution. Here is the frequency distribution for our example:

Category <- c("About right", "Overweight", "Underweight", "$\\textbf{Total}$")

Count <- c(855, 235, 110, "$n=1200$")

Percent <- c("$\\left(\\frac{855}{1200}\\right)*100=71.3%$",
"$\\left(\\frac{235}{1200}\\right)*100=19.63%$",
"$\\left(\\frac{110}{1200}\\right)*100=9.2%$",
"$100\\%$")
dt <- data.frame(Category, Count, Percent,
stringsAsFactors = F)

kable(dt, "html", caption = "Body Image Distribution") %>%
kable_styling(
bootstrap_options = c(
"striped")
)
Table 2: Body Image Distribution
Category Count Percent
About right 855 $$\left(\frac{855}{1200}\right)*100=71.3%$$
Overweight 235 $$\left(\frac{235}{1200}\right)*100=19.63%$$
Underweight 110 $$\left(\frac{110}{1200}\right)*100=9.2%$$
$$\textbf{Total}$$ $$n=1200$$ $$100\%$$

In order to visualize the numerical summaries we’ve obtained, we need a graphical display. There are two simple graphical displays for visualizing the distribution of categorical data:

1. The pie chart
pie_dt <- dt[1:3,1:2]
pie_dt$Count <- as.integer(pie_dt$Count)
library(plotly)
p <- plot_ly(pie_dt, labels = Category,
values = Count, type = "pie") %>%
layout(title = 'Pie Chart of Body Image')
# api_create(p, filename = "r-pie-body-image")
1. The Bar Chart
library(ggplot2)
g <- ggplot(pie_dt, aes(x = Category,
Count,
fill=Category)) +
geom_col() +
theme_bw()
p <- ggplotly(g)
# api_create(p, filename = "r-barchart-body-image")

### Pictograms

1. While both the pie chart and the bar chart help us visualize the distribution of a categorical variable, the pie chart emphasizes how the different categories relate to the whole, and the bar chart emphasizes how the different categories compare with each other.

2. A variation on the pie chart and bar chart that is very commonly used in the media is the pictogram. Here are two examples:

Source: USA Today Snapshots and the Impulse Research for Northern Confidential Bathroom survey

Source: Market Facts for the Association of Dressings and Sauces

This graph is aimed at advertisers deciding where to spend their budgets, and clearly suggests that Time magazine attracts by far the largest amount of advertising spending. Are the differences really as dramatic as the graph suggests? If we look carefully at the numbers above the pens, we find that advertisers spend in Time only $$\4,433,879 / \2,698,386 = 1.64$$ times more than in Newsweek, and only $$\4,433,879 / \1,537,617 = 2.88$$ times more than in U.S. News. By looking at the pictogram, however, we get the impression that Time is much further ahead. Why? In order to magnify the picture without distorting it, we must increase both its height and width. As a result, the area of Time’s pen is 1.64 * 1.64 = 2.7 times larger than the Newsweek pen, and 2.88 * 2.88 = 8.3 times larger than the U.S. News pen. Our eyes capture the area of the pens rather than only the height, and so we are misled to think that Time is a bigger winner than it really is. ***

The same survey that asked 1,200 U.S. college students about their body perception also asked the following question:

“With whom do you find it easiest to make friends?” (opposite sex, same sex or no difference).

Below is a snapshot of how the first 25 men and women answered the question: “With whom do you find it easiest to make friends?”

library(downloader)
url <- "https://lagunita.stanford.edu/assets/courseware/v1/6c69fdf1ef819cd13c1d53a0b3481435/asset-v1:OLI+ProbStat+Open_Jan2017+type@asset+block/friends.RData"
filename <- basename(url)
str(friends)
## 'data.frame':    1200 obs. of  1 variable:
##  $Friends: Factor w/ 3 levels "No difference",..: 1 1 1 1 1 1 1 1 1 1 ... head(friends, 25) ## Friends ## 1 No difference ## 2 No difference ## 3 No difference ## 4 No difference ## 5 No difference ## 6 No difference ## 7 No difference ## 8 No difference ## 9 No difference ## 10 No difference ## 11 No difference ## 12 No difference ## 13 No difference ## 14 No difference ## 15 No difference ## 16 No difference ## 17 No difference ## 18 No difference ## 19 No difference ## 20 No difference ## 21 No difference ## 22 No difference ## 23 No difference ## 24 No difference ## 25 No difference library(dplyr) t <- summary(friends$Friends)
str(t)
##  Named int [1:3] 602 434 164
##  - attr(*, "names")= chr [1:3] "No difference" "Opposite sex" "Same sex"

Summary table of the data

prop <- prop.table(t); prop
## No difference  Opposite sex      Same sex
##     0.5016667     0.3616667     0.1366667
writeLines("\n")
percent=prop.table(t)*100; percent
## No difference  Opposite sex      Same sex
##      50.16667      36.16667      13.66667
writeLines("\n")
#modify our percent table so that each value is rounded to one decimal place.
pf <- round(percent,1); pf
## No difference  Opposite sex      Same sex
##          50.2          36.2          13.7
df <- data.frame(rbind(t,pf))
rownames(df) <- 1:nrow(df)
df[2,] <- paste(df[2,], "%", sep = ""); df
##   No.difference Opposite.sex Same.sex
## 1           602          434      164
## 2         50.2%        36.2%    13.7%
df %>%
kable("html") %>%
kable_styling( c("striped", "hover"))
No.difference Opposite.sex Same.sex
602 434 164
50.2% 36.2% 13.7%

Next we will create a label that will include the category name and the percent as the labels for each section of the pie chart. R defaults to alphabetical order for tables and graphic creation so if you create your own labels list the names accordingly.

lbl = paste(c("No difference","Opposite sex","Same sex"),pf,"%",sep=" ");lbl
## [1] "No difference 50.2 %" "Opposite sex 36.2 %"  "Same sex 13.7 %"
pie(t, label=lbl)

dftut <- data.frame(values = as.numeric(df[1,]),
taxonomies = colnames(df))
dftut
##   values    taxonomies
## 1    602 No.difference
## 2    434  Opposite.sex
## 3    164      Same.sex
g <- ggplot(dftut,aes(x=taxonomies,
y=values,
fill=taxonomies) ) +
geom_col(width = 1) +
coord_polar()
g

p <- plot_ly(dftut,
labels = dftut$taxonomies, values = dftut$values, type="pie",
text=dftut\$taxonomies) %>%
layout(title = "Friends pie chart")
# api_create(p, filename = "r-friends-pie-chart")

If you were to pick one of the 1,200 surveyed students at random, he/she would most likely find it easier to make friends with which of the same or opposite sex.


text:
# Read and output CSV content OO PHP

Okay, I am wanting to expand my armoury within PHP, so I've been researching OO PHP. With my researched knowledge I went on to create a quick script that reads a CSV file and outputs the results.

CSV Class:

class CSV {

private $file; public function __construct($filename, $mode) {$this->file = fopen($filename,$mode);
return $this->file; } public function endFile() { return feof($this->file);
}

public function getCSV($mode) { return fgetcsv($this->file, $mode); } public function close() { fclose($this->file);
}
}

The test file:

require('class.csv.php');

$csv = new CSV('postcodes.csv', 'r'); while(!$csv->endFile()) {

$postcode =$csv->getCSV(1024);
echo $postcode[0] . "<br />"; }$csv->close();

I am just wondering if there are... or what are the improvements I could make in regards to the OO approach. This is purely a script for me to put the knowledge i've learnt together. I'm not another 'following the crowd person' who creates every script in an OO approach because they 'can'.

I understand it is a short script but I am wanting to make sure I have the correct approach before moving forward.

While I think this is a very solid foundation, I think you could expand this to make it easier to use.

The first thing which caught my eye was the possibility to make a file handle open longer than necessary. You have already implemented the functionality, but to have the handle closed before the script is terminated is a responsibility of the developer. I would add a __destruct() magic method which checks if the file handle has been closed when the object is out of scope.

public function __destruct() {
if(is_resource($this->handle)) { // Property name changed, see next.$this->close();
}
}

The next thing is to provide a default $mode. As this class would mainly be used to read the file you could easily set a default value. As of now your code does not utilize any other functionality provided by the different file handle modes, so this should not change anything, other than making your class easier to use. public function __construct($filename, $mode = 'r') {...  While we are at the constructor I would also rename your property $this->file into $this->handle and save the opened file name in a separate property. This is to write better error messages. private$file;
private $handle; public function __construct($file, $mode = 'r') { if(!is_string($file)) {
throw new InvalidArgumentException('Parameter $file must be a string. Provided type: ' . gettype($file));
}

if(!is_file($file) || !is_readable($file)) {
throw new RuntimeException('The provided file could not be opened for reading. File: ' . $file); }$this->file   = $file;$this->handle = fopen($file,$mode);
}

I would also write some error checking. The most obvious place something bad could happen is when opening the file handle. If you first make sure the file actually exists and throw a well written exception if not, you will save yourself some time when errors occur.

The next place I think could use some error checking is when you are reading a line using fgetcsv() in method getCSV(). If an error occurs it returns false, but the current state of the code is completely unaware this may have happened. A simple check to see if it returned false and then throw an exception would suffice.

public function getCSV($mode) {$value = fgetcsv($this->handle,$mode);

if($value === false) { throw new RuntimeException('Encountered an error while reading CSV file: ' .$this->file);
}

return $value; }  Misc (naming) I feel like the name of the class is somewhat misleading. If I only look at the like name I might also get the impression I can save values into the specified file. Consider changing the name to reflect its exact behavior. I would consider something like ReadCSV sufficient. I also think this is true for the method getCSV(). Do I read the entire file or just one line? It can be hard to determine just by looking at the name. I would rename it to readLine(). This name also skips the CSV part, as the class name states its associated with a csv file, so it should not come as a surprise. I also have a little trouble understanding your argument $mode in the method getCSV(). If you look at the documentation for fgetcsv() it has more than one optional parameters, but none named $mode. Consider changing this to the same names, as this would make it easier to understand for other developers (or yourself in six months) who knows the method signature or looks at the documentation. You should also consider writing documentation using the DocBlock feature. This can help reduce confusion when argument names are ambiguous and provide a short description of the behavior of the method as well as which exceptions it can throw. Additional You could also write methods for reading the entire file. A method that looks something like the following could be useful. public function readAll() {$array = [];

while(($columns = fgetcsv($this->handle)) !== false) {

$rows = count($columns);

for($i = 0;$i <= $rows;$i++) {
$array[] =$columns[$i]; } } return$array;
}

Hope this helps. Please keep in mind none of this code has been tested.

Happy coding!

• Thank you very much for this! I did use DockBlock within the script on my local machine. I just didn't copy it across to the example - apologies. Now you have mentioned a lot of these they seem such simple mistakes but I guess that's part of the learning curve. Thanks again! – Jacob Hallas Jun 2 '15 at 18:57
• I wouldn't think of them as mistakes, but as improvements. As I said I think this is a solid foundation to improve on :D – AnotherGuy Jun 2 '15 at 20:34


text:
# Max-flow min-cut theorem

In computer science and optimization theory, the max-flow min-cut theorem states that in a flow network, the maximum amount of flow passing from the source to the sink is equal to the total weight of the edges in a minimum cut, i.e., the smallest total weight of the edges which if removed would disconnect the source from the sink.

This is a special case of the duality theorem for linear programs and can be used to derive Menger's theorem and the Kőnig–Egerváry theorem.[1]

## Definitions and statement

The theorem equates two quantities: the maximum flow through a network, and the minimum capacity of a cut of the network. To state the theorem, each of these notions must first be defined.

### Network

A network consists of

• a finite directed graph N = (V, E), where V denotes the finite set of vertices and EV×V is the set of directed edges;
• a source sV and a sink tV;
• a capacity function, which is a mapping ${\displaystyle c:E\to \mathbb {R} ^{+}}$  denoted by cuv or c(u, v) for (u,v) ∈ E. It represents the maximum amount of flow that can pass through an edge.

### Flows

A flow through a network is a mapping ${\displaystyle f:E\to \mathbb {R} ^{+}}$  denoted by ${\displaystyle f_{uv}}$  or ${\displaystyle f(u,v)}$ , subject to the following two constraints:

1. Capacity Constraint: For every edge ${\displaystyle (u,v)\in E}$ , ${\displaystyle f_{uv}\leq c_{uv}.}$
2. Conservation of Flows: For each vertex ${\displaystyle v}$  apart from ${\displaystyle s}$  and ${\displaystyle t}$  (i.e. the source and sink, respectively), the following equality holds:
${\displaystyle \sum \nolimits _{\{u:(u,v)\in E\}}f_{uv}=\sum \nolimits _{\{w:(v,w)\in E\}}f_{vw}.}$

A flow can be visualized as a physical flow of a fluid through the network, following the direction of each edge. The capacity constraint then says that the volume flowing through each edge per unit time is less than or equal to the maximum capacity of the edge, and the conservation constraint says that the amount that flows into each vertex equals the amount flowing out of each vertex, apart from the source and sink vertices.

The value of a flow is defined by

${\displaystyle |f|=\sum \nolimits _{\{v:(s,v)\in E\}}f_{sv}=\sum \nolimits _{\{v:(v,t)\in E\}}f_{vt},}$

where as above ${\displaystyle s}$  is the source and ${\displaystyle t}$  is the sink of the network. In the fluid analogy, it represents the amount of fluid entering the network at the source. Because of the conservation axiom for flows, this is the same as the amount of flow leaving the network at the sink.

The maximum flow problem asks for the largest flow on a given network.

Maximum Flow Problem. Maximize ${\displaystyle |f|}$ , that is, to route as much flow as possible from ${\displaystyle s}$  to ${\displaystyle t}$ .

### Cuts

The other half of the max-flow min-cut theorem refers to a different aspect of a network: the collection of cuts. An s-t cut C = (S, T) is a partition of V such that sS and tT. That is, an s-t cut is a division of the vertices of the network into two parts, with the source in one part and the sink in the other. The cut-set ${\displaystyle X_{C}}$  of a cut C is the set of edges that connect the source part of the cut to the sink part:

${\displaystyle X_{C}:=\{(u,v)\in E\ :\ u\in S,v\in T\}=(S\times T)\cap E.}$

Thus, if all the edges in the cut-set of C are removed, then no positive flow is possible, because there is no path in the resulting graph from the source to the sink.

The capacity of an s-t cut is the sum of the capacities of the edges in its cut-set,

${\displaystyle c(S,T)=\sum \nolimits _{(u,v)\in X_{C}}c_{uv}=\sum \nolimits _{(i,j)\in E}c_{ij}d_{ij},}$

where ${\displaystyle d_{ij}=1}$  if ${\displaystyle i\in S}$  and ${\displaystyle j\in T}$ , ${\displaystyle 0}$  otherwise.

There are typically many cuts in a graph, but cuts with smaller weights are often more difficult to find.

Minimum s-t Cut Problem. Minimize c(S, T), that is, determine S and T such that the capacity of the s-t cut is minimal.

### Main theorem

In the above situation, one can prove that the value of any flow through a network is less than or equal to the capacity of any s-t cut, and that furthermore a flow with maximal value and a cut with minimal capacity exist. The main theorem links the maximum flow value with the minimum cut capacity of the network.

Max-flow min-cut theorem. The maximum value of an s-t flow is equal to the minimum capacity over all s-t cuts.

## Example

A maximal flow in a network. Each edge is labeled with f/c, where f is the flow over the edge and c is the edge's capacity. The flow value is 5. There are several minimal s-t cuts with capacity 5; one is S={s,p} and T={o, q, r, t}.

The figure on the right shows a flow in a network. The numerical annotation on each arrow, in the form f/c, indicates the flow (f) and the capacity (c) of the arrow. The flows emanating from the source total five (2+3=5), as do the flows into the sink (2+3=5), establishing that the flow's value is 5.

One s-t cut with value 5 is given by S={s,p} and T={o, q, r, t}. The capacities of the edges that cross this cut are 3 and 2, giving a cut capacity of 3+2=5. (The arrow from o to p is not considered, as it points from T back to S.)

The value of the flow is equal to the capacity of the cut, showing that the flow is a maximal flow and the cut is a minimal cut.

Note that the flow through each of the two arrows that connect S to T is at full capacity; this is always the case: a minimal cut represents a 'bottleneck' of the system.

## Linear program formulation

The max-flow problem and min-cut problem can be formulated as two primal-dual linear programs.[2]

Max-flow (Primal)

Min-cut (Dual)

variables

${\displaystyle f_{uv}}$  ${\displaystyle \forall (u,v)\in E}$  [a variable per edge]

${\displaystyle d_{uv}}$  ${\displaystyle \forall (u,v)\in E}$  [a variable per edge]

${\displaystyle z_{v}}$  ${\displaystyle \forall v\in V\setminus \{s,t\}}$  [a variable per non-terminal node]

objective

maximize ${\displaystyle \sum \nolimits _{v:(s,v)\in E}f_{sv}}$

[max total flow from source]

minimize ${\displaystyle \sum \nolimits _{(u,v)\in E}c_{uv}d_{uv}}$

[min total capacity of edges in cut]

constraints

subject to

{\displaystyle {\begin{aligned}f_{uv}&\leq c_{uv}&&\forall (u,v)\in E\\\sum _{u}f_{uv}-\sum _{w}f_{vw}&=0&&v\in V\setminus \{s,t\}\end{aligned}}}

[a constraint per edge and a constraint per non-terminal node]

subject to

{\displaystyle {\begin{aligned}d_{uv}-z_{u}+z_{v}&\geq 0&&\forall (u,v)\in E,u\neq s,v\neq t\\d_{sv}+z_{v}&\geq 1&&\forall (s,v)\in E,v\neq t\\d_{ut}-z_{u}&\geq 0&&\forall (u,t)\in E,u\neq s\\d_{st}&\geq 1&&{\text{if }}(s,t)\in E\end{aligned}}}

[a constraint per edge]

sign constraints {\displaystyle {\begin{aligned}f_{uv}&\geq 0&&\forall (u,v)\in E\\\end{aligned}}}  {\displaystyle {\begin{aligned}d_{uv}&\geq 0&&\forall (u,v)\in E\\z_{v}&\in \mathbb {R} &&\forall v\in V\setminus \{s,t\}\end{aligned}}}

The max-flow LP is straightforward. The dual LP is obtained using the algorithm described in dual linear program. The resulting LP requires some explanation. The interpretation of the variables in the min-cut LP is:

${\displaystyle d_{uv}={\begin{cases}1,&{\text{if }}u\in S{\text{ and }}v\in T{\text{ (the edge }}uv{\text{ is in the cut) }}\\0,&{\text{otherwise}}\end{cases}}}$
${\displaystyle z_{v}={\begin{cases}1,&{\text{if }}v\in S\\0,&{\text{otherwise}}\end{cases}}}$

The minimization objective sums the capacity over all the edges that are contained in the cut.

The constraints guarantee that the variables indeed represent a legal cut:[3]

• The constraints ${\displaystyle d_{uv}-z_{u}+z_{v}\geq 0}$  (equivalent to ${\displaystyle d_{uv}\geq z_{u}-z_{v}}$ ) guarantee that, for non-terminal nodes u,v, if u is in S and v is in T, then the edge (u,v) is counted in the cut (${\displaystyle d_{uv}\geq 1}$ ).
• The constraints ${\displaystyle d_{sv}+z_{v}\geq 1}$  (equivalent to ${\displaystyle d_{sv}\geq 1-z_{v}}$ ) guarantee that, if v is in T, then the edge (s,v) is counted in the cut (since s is by definition in S).
• The constraints ${\displaystyle d_{ut}-z_{u}\geq 0}$  (equivalent to ${\displaystyle d_{ut}\geq z_{u}}$ ) guarantee that, if u is in S, then the edge (u,t) is counted in the cut (since t is by definition in T).

Note that, since this is a minimization problem, we do not have to guarantee that an edge is not in the cut - we only have to guarantee that each edge that should be in the cut, is summed in the objective function.

The equality in the max-flow min-cut theorem follows from the strong duality theorem in linear programming, which states that if the primal program has an optimal solution, x*, then the dual program also has an optimal solution, y*, such that the optimal values formed by the two solutions are equal.

## Application

### Cederbaum's maximum flow theorem

The maximum flow problem can be formulated as the maximization of the electrical current through a network composed of nonlinear resistive elements.[4] In this formulation, the limit of the current Iin between the input terminals of the electrical network as the input voltage Vin approaches ${\displaystyle \infty }$ , is equal to the weight of the minimum-weight cut set.

${\displaystyle \lim _{V_{\text{in}}\to \infty }(I_{in})=\min _{X_{C}}\sum _{(u,v)\in X_{C}}c_{uv}}$

### Generalized max-flow min-cut theorem

In addition to edge capacity, consider there is capacity at each vertex, that is, a mapping ${\displaystyle c:V\to \mathbb {R} ^{+}}$  denoted by c(v), such that the flow f has to satisfy not only the capacity constraint and the conservation of flows, but also the vertex capacity constraint

${\displaystyle \forall v\in V\setminus \{s,t\}:\qquad \sum \nolimits _{\{u\in V\mid (u,v)\in E\}}f_{uv}\leq c(v).}$

In other words, the amount of flow passing through a vertex cannot exceed its capacity. Define an s-t cut to be the set of vertices and edges such that for any path from s to t, the path contains a member of the cut. In this case, the capacity of the cut is the sum the capacity of each edge and vertex in it.

In this new definition, the generalized max-flow min-cut theorem states that the maximum value of an s-t flow is equal to the minimum capacity of an s-t cut in the new sense.

### Menger's theorem

In the undirected edge-disjoint paths problem, we are given an undirected graph G = (V, E) and two vertices s and t, and we have to find the maximum number of edge-disjoint s-t paths in G.

The Menger's theorem states that the maximum number of edge-disjoint s-t paths in an undirected graph is equal to the minimum number of edges in an s-t cut-set.

### Project selection problem

A network formulation of the project selection problem with the optimal solution

In the project selection problem, there are n projects and m machines. Each project pi yields revenue r(pi) and each machine qj costs c(qj) to purchase. Each project requires a number of machines and each machine can be shared by several projects. The problem is to determine which projects and machines should be selected and purchased respectively, so that the profit is maximized.

Let P be the set of projects not selected and Q be the set of machines purchased, then the problem can be formulated as,

${\displaystyle \max\{g\}=\sum _{i}r(p_{i})-\sum _{p_{i}\in P}r(p_{i})-\sum _{q_{j}\in Q}c(q_{j}).}$

Since the first term does not depend on the choice of P and Q, this maximization problem can be formulated as a minimization problem instead, that is,

${\displaystyle \min\{g'\}=\sum _{p_{i}\in P}r(p_{i})+\sum _{q_{j}\in Q}c(q_{j}).}$

The above minimization problem can then be formulated as a minimum-cut problem by constructing a network, where the source is connected to the projects with capacity r(pi), and the sink is connected by the machines with capacity c(qj). An edge (pi, qj) with infinite capacity is added if project pi requires machine qj. The s-t cut-set represents the projects and machines in P and Q respectively. By the max-flow min-cut theorem, one can solve the problem as a maximum flow problem.

The figure on the right gives a network formulation of the following project selection problem:

Project r(pi)

Machine c(qj)

1 100 200

Project 1 requires machines 1 and 2.

2 200 100

Project 2 requires machine 2.

3 150 50

Project 3 requires machine 3.

The minimum capacity of an s-t cut is 250 and the sum of the revenue of each project is 450; therefore the maximum profit g is 450 − 250 = 200, by selecting projects p2 and p3.

The idea here is to 'flow' each project's profits through the 'pipes' of its machines. If we cannot fill the pipe from a machine, the machine's return is less than its cost, and the min cut algorithm will find it cheaper to cut the project's profit edge instead of the machine's cost edge.

### Image segmentation problem

Each black node denotes a pixel.

In the image segmentation problem, there are n pixels. Each pixel i can be assigned a foreground value  fi or a background value bi. There is a penalty of pij if pixels i, j are adjacent and have different assignments. The problem is to assign pixels to foreground or background such that the sum of their values minus the penalties is maximum.

Let P be the set of pixels assigned to foreground and Q be the set of points assigned to background, then the problem can be formulated as,

${\displaystyle \max\{g\}=\sum _{i\in P}f_{i}+\sum _{i\in Q}b_{i}-\sum _{i\in P,j\in Q\lor j\in P,i\in Q}p_{ij}.}$

This maximization problem can be formulated as a minimization problem instead, that is,

${\displaystyle \min\{g'\}=\sum _{i\in P,j\in Q\lor j\in P,i\in Q}p_{ij}.}$

The above minimization problem can be formulated as a minimum-cut problem by constructing a network where the source (orange node) is connected to all the pixels with capacity  fi, and the sink (purple node) is connected by all the pixels with capacity bi. Two edges (i, j) and (j, i) with pij capacity are added between two adjacent pixels. The s-t cut-set then represents the pixels assigned to the foreground in P and pixels assigned to background in Q.

## History

An account of the discovery of the theorem was given by Ford and Fulkerson in 1962:[5]

"Determining a maximal steady state flow from one point to another in a network subject to capacity limitations on arcs ... was posed to the authors in the spring of 1955 by T.E. Harris, who, in conjunction with General F. S. Ross (Ret.) had formulated a simplified model of railway traffic flow, and pinpointed this particular problem as the central one suggested by the model. It was not long after this until the main result, Theorem 5.1, which we call the max-flow min-cut theorem, was conjectured and established.[6] A number of proofs have since appeared."[7][8][9]

## Proof

Let G = (V, E) be a network (directed graph) with s and t being the source and the sink of G respectively.

Consider the flow f computed for G by Ford–Fulkerson algorithm. In the residual graph (Gf ) obtained for G (after the final flow assignment by Ford–Fulkerson algorithm), define two subsets of vertices as follows:

1. A: the set of vertices reachable from s in Gf
2. Ac: the set of remaining vertices i.e. V − A

Claim. value( f ) = c(A, Ac), where the capacity of an s-t cut is defined by

${\displaystyle c(S,T)=\sum \nolimits _{(u,v)\in S\times T}c_{uv}}$ .

Now, we know, ${\displaystyle value(f)=f_{out}(A)-f_{in}(A)}$  for any subset of vertices, A. Therefore, for value( f ) = c(A, Ac) we need:

• All outgoing edges from the cut must be fully saturated.
• All incoming edges to the cut must have zero flow.

To prove the above claim we consider two cases:

• In G, there exists an outgoing edge ${\displaystyle (x,y),x\in A,y\in A^{c}}$  such that it is not saturated, i.e., f (x, y) < cxy. This implies, that there exists a forward edge from x to y in Gf, therefore there exists a path from s to y in Gf, which is a contradiction. Hence, any outgoing edge (x, y) is fully saturated.
• In G, there exists an incoming edge ${\displaystyle (y,x),x\in A,y\in A^{c}}$  such that it carries some non-zero flow, i.e., f (y, x) > 0. This implies, that there exists a backward edge from x to y in Gf, therefore there exists a path from s to y in Gf, which is again a contradiction. Hence, any incoming edge (y, x) must have zero flow.

Both of the above statements prove that the capacity of cut obtained in the above described manner is equal to the flow obtained in the network. Also, the flow was obtained by Ford-Fulkerson algorithm, so it is the max-flow of the network as well.

Also, since any flow in the network is always less than or equal to capacity of every cut possible in a network, the above described cut is also the min-cut which obtains the max-flow.

A corollary from this proof is that the maximum flow through any set of edges in a cut of a graph is equal to the minimum capacity of all previous cuts.


text:
# stepinfo

Rise time, settling time, and other step-response characteristics

## Syntax

``S = stepinfo(sys)``
``S = stepinfo(y,t)``
``S = stepinfo(y,t,yfinal)``
``S = stepinfo(y,t,yfinal,yinit)``
``S = stepinfo(___,'SettlingTimeThreshold',ST)``
``S = stepinfo(___,'RiseTimeLimits',RT)``

## Description

`stepinfo` lets you compute step-response characteristics for a dynamic system model or for an array of step-response data. For a step response y(t), `stepinfo` computes characteristics relative to yinit and yfinal, where yinit is the initial offset, that is, the value before the step is applied, and yfinal is the steady-state value of the response. These values depend on the syntax you use.

• For a dynamic system model `sys`, `stepinfo` uses yinit = 0 and yfinal = steady-state value.

• For an array of step-response data `[y,t]`, `stepinfo` uses yinit = 0 and yfinal = last sample value of `y`, unless you explicitly specify these values.

For more information on how `stepinfo` computes the step-response characteristics, see Algorithms.

The following figure illustrates some of the characteristics `stepinfo` computes for a step response. For this response, assume that y(t) = 0 for t < 0, so yinit = 0.

example

````S = stepinfo(sys)` computes the step-response characteristics for a dynamic system model `sys`. This syntax uses yinit = 0 and yfinal = steady-state value for computing the characteristics that depend on these values.```
````S = stepinfo(y,t)` computes step-response characteristics from an array of step-response data `y` and a corresponding time vector `t`. For SISO system responses, `y` is a vector with the same number of entries as `t`. For MIMO response data, `y` is an array containing the responses of each I/O channel. This syntax uses yinit = 0 and the last value in `y` (or the last value in each channel's corresponding response data) as yfinal.```

example

````S = stepinfo(y,t,yfinal)` computes step-response characteristics relative to the steady-state value `yfinal`. This syntax is useful when you know that the expected steady-state system response differs from the last value in `y` for reasons such as measurement noise. This syntax uses yinit = 0.For SISO responses, `t` and `y` are vectors with the same length `NS`. For systems with `NU` inputs and `NY` outputs, you can specify `y` as an `NS`-by-`NY`-by-`NU` array (see `step`) and `yfinal` as an `NY`-by-`NU` array. `stepinfo` then returns a `NY`-by-`NU` structure array `S` of response characteristics corresponding to each I/O pair.```

example

````S = stepinfo(y,t,yfinal,yinit)` computes step-response characteristics relative to the response initial value `yinit`. This syntax is useful when your `y` data has an initial offset; that is, `y` is nonzero before the step occurs.For SISO responses, `t` and `y` are vectors with the same length `NS`. For systems with `NU` inputs and `NY` outputs, you can specify `y` as an `NS`-by-`NY`-by-`NU` array and `yinit` as an `NY`-by-`NU` array. `stepinfo` then returns a `NY`-by-`NU` structure array `S` of response characteristics corresponding to each I/O pair.```

example

````S = stepinfo(___,'SettlingTimeThreshold',ST)` lets you specify the threshold `ST` used in the definition of settling and transient times. The default value is `ST = 0.02` (2%). You can use this syntax with any of the previous input-argument combinations. ```

example

````S = stepinfo(___,'RiseTimeLimits',RT)` lets you specify the lower and upper thresholds used in the definition of rise time. By default, the rise time is the time the response takes to rise from 10% to 90% of the way from the initial value to the steady-state value (```RT = [0.1 0.9]```). The upper threshold `RT(2)` is also used to calculate `SettlingMin` and `SettlingMax`. These values are the minimum and maximum values of the response occurring after the response reaches the upper threshold. You can use this syntax with any of the previous input-argument combinations. ```

## Examples

collapse all

Compute step-response characteristics, such as rise time, settling time, and overshoot, for a dynamic system model. For this example, use a continuous-time transfer function:

`$sys=\frac{{s}^{2}+5s+5}{{s}^{4}+1.65{s}^{3}+5{s}^{2}+6.5s+2}$`

Create the transfer function and examine its step response.

```sys = tf([1 5 5],[1 1.65 5 6.5 2]); step(sys)```

The plot shows that the response rises in a few seconds, and then rings down to a steady-state value of about 2.5. Compute the characteristics of this response using `stepinfo`.

`S = stepinfo(sys)`
```S = struct with fields: RiseTime: 3.8456 TransientTime: 27.9762 SettlingTime: 27.9762 SettlingMin: 2.0689 SettlingMax: 2.6873 Overshoot: 7.4915 Undershoot: 0 Peak: 2.6873 PeakTime: 8.0530 ```

Here, the function uses ${\mathit{y}}_{\mathrm{init}}$= 0 to compute characteristics for the dynamic system model `sys`.

By default, the settling time is the time it takes for the error to stay below 2% of $|{\mathit{y}}_{\mathrm{init}}-{\mathit{y}}_{\mathit{final}}|$. The result `S.SettlingTime` shows that for `sys`, this condition occurs after about 28 seconds. The default definition of rise time is the time it takes for the response to go from 10% to 90% of the way from ${\mathit{y}}_{\mathrm{init}}$= 0 to ${\mathit{y}}_{\mathrm{final}}$. `S.RiseTime` shows that for `sys`, this rise occurs in less than 4 seconds. The maximum overshoot is returned in `S.Overshoot`. For this system, the peak value `S.Peak`, which occurs at the time `S.PeakTime`, overshoots by about 7.5% of the steady-state value.

For a MIMO system, `stepinfo` returns a structure array in which each entry contains the response characteristics of the corresponding I/O channel of the system. For this example, use a two-output, two-input discrete-time system. Compute the step-response characteristics.

```A = [0.68 -0.34; 0.34 0.68]; B = [0.18 -0.05; 0.04 0.11]; C = [0 -1.53; -1.12 -1.10]; D = [0 0; 0.06 -0.37]; sys = ss(A,B,C,D,0.2); S = stepinfo(sys)```
```S=2×2 struct array with fields: RiseTime TransientTime SettlingTime SettlingMin SettlingMax Overshoot Undershoot Peak PeakTime ```

Access the response characteristics for a particular I/0 channel by indexing into `S`. For instance, examine the response characteristics for the response from the first input to the second output of `sys`, corresponding to `S(2,1)`.

`S(2,1)`
```ans = struct with fields: RiseTime: 0.4000 TransientTime: 2.8000 SettlingTime: 3 SettlingMin: -0.6724 SettlingMax: -0.5188 Overshoot: 24.6476 Undershoot: 11.1224 Peak: 0.6724 PeakTime: 1 ```

To access a particular value, use dot notation. For instance, extract the rise time of the (2,1) channel.

`rt21 = S(2,1).RiseTime`
```rt21 = 0.4000 ```

You can use `SettlingTimeThreshold` and `RiseTimeThreshold` to change the default percentage for settling and rise times, respectively, as described in the Algorithms section. For this example, use the system given by:

`$\mathit{sys}=\frac{{\mathit{s}}^{2}+5\mathit{s}+5}{{\mathit{s}}^{4}+1.65{\mathit{s}}^{3}+6.5\mathit{s}+2}$`

Create the transfer function.

`sys = tf([1 5 5],[1 1.65 5 6.5 2]);`

Compute the time it takes for the error in the response of `sys` to stay below 0.5% of the gap $|{\mathit{y}}_{\mathrm{final}}-{\mathit{y}}_{\mathrm{init}}|$. To do so, set `SettlingTimeThreshold` to 0.5%, or 0.005.

```S1 = stepinfo(sys,'SettlingTimeThreshold',0.005); st1 = S1.SettlingTime```
```st1 = 46.1325 ```

Compute the time it takes the response of `sys` to rise from 5% to 95% of the way from ${\mathit{y}}_{\mathrm{init}}$ to ${\mathit{y}}_{\mathrm{final}}$. To do so, set `RiseTimeThreshold` to a vector containing those bounds.

```S2 = stepinfo(sys,'RiseTimeThreshold',[0.05 0.95]); rt2 = S2.RiseTime```
```rt2 = 4.1690 ```

You can define percentages for both settling time and rise time in the same computation.

`S3 = stepinfo(sys,'SettlingTimeThreshold',0.005,'RiseTimeThreshold',[0.05 0.95])`
```S3 = struct with fields: RiseTime: 4.1690 TransientTime: 46.1325 SettlingTime: 46.1325 SettlingMin: 2.0689 SettlingMax: 2.6873 Overshoot: 7.4915 Undershoot: 0 Peak: 2.6873 PeakTime: 8.0530 ```

You can extract step-response characteristics from step-response data even if you do not have a model of your system. For instance, suppose you have measured the response of your system to a step input and saved the resulting response data in a vector `y` of response values at the times stored in another vector `t`. Load the response data and examine it.

```load StepInfoData t y plot(t,y)```

Compute step-response characteristics from this response data using `stepinfo`. If you do not specify the steady-state response value `yfinal`, then `stepinfo` assumes that the last value in the response vector `y` is the steady-state response. Because the data has some noise, the last value in `y` is likely not the true steady-state response value. When you know what the steady-state value should be, you can provide it to `stepinfo`. For this example, suppose that the steady-state response is 2.4.

`S1 = stepinfo(y,t,2.4)`
```S1 = struct with fields: RiseTime: 1.2897 TransientTime: 19.6478 SettlingTime: 19.6439 SettlingMin: 2.0219 SettlingMax: 3.3302 Overshoot: 38.7575 Undershoot: 0 Peak: 3.3302 PeakTime: 3.4000 ```

Because of the noise in the data, the default definition of the settling time is too stringent, resulting in an arbitrary value of almost 20 seconds. To allow for the noise, increase the settling-time threshold from the default 2% to 5%.

`S2 = stepinfo(y,t,2.4,'SettlingTimeThreshold',0.05)`
```S2 = struct with fields: RiseTime: 1.2897 TransientTime: 10.4201 SettlingTime: 10.4149 SettlingMin: 2.0219 SettlingMax: 3.3302 Overshoot: 38.7575 Undershoot: 0 Peak: 3.3302 PeakTime: 3.4000 ```

Settling time and transient time are equal when the peak error ${\mathit{e}}_{\mathrm{max}}$ is equal to the gap $|{\mathit{y}}_{\mathrm{final}}-{\mathit{y}}_{\mathrm{init}}|$ (see Algorithms), which is the case for models with no undershoot or feedthrough and with less than 100% overshoot. They tend to differ for models with feedthrough, zeros at the origin, unstable zeros (undershoot), or large overshoot.

Consider the following models.

```s = tf('s'); sys1 = 1+tf(1,[1 1]); % feedthrough sys2 = tf([1 0],[1 1]); % zero at the origin sys3 = tf([-3 1],[1 2 1]); % non-minimum phase with undershoot sys4 = (s/0.5 + 1)/(s^2 + 0.2*s + 1); % large overshoot step(sys1,sys2,sys3,sys4) grid on legend('Feedthrough','Zero at origin','Non-minimum phase with undershoot','Large overshoot')```

Compute the step-response characteristics.

`S1 = stepinfo(sys1)`
```S1 = struct with fields: RiseTime: 1.6095 TransientTime: 3.9121 SettlingTime: 3.2190 SettlingMin: 1.8005 SettlingMax: 2.0000 Overshoot: 0 Undershoot: 0 Peak: 2.0000 PeakTime: 10.5458 ```
`S2 = stepinfo(sys2)`
```S2 = struct with fields: RiseTime: 0 TransientTime: 3.9121 SettlingTime: NaN SettlingMin: 2.6303e-05 SettlingMax: 1 Overshoot: Inf Undershoot: 0 Peak: 1 PeakTime: 0 ```
`S3 = stepinfo(sys3)`
```S3 = struct with fields: RiseTime: 2.9198 TransientTime: 6.5839 SettlingTime: 7.3229 SettlingMin: 0.9004 SettlingMax: 0.9991 Overshoot: 0 Undershoot: 88.9466 Peak: 0.9991 PeakTime: 10.7900 ```
`S4 = stepinfo(sys4)`
```S4 = struct with fields: RiseTime: 0.3896 TransientTime: 40.3317 SettlingTime: 46.5052 SettlingMin: -0.2796 SettlingMax: 2.7571 Overshoot: 175.7137 Undershoot: 27.9629 Peak: 2.7571 PeakTime: 1.8850 ```

Examine the plots and characteristics. For these models, the settling time and transient time differ because the peak error exceeds the gap between the initial and the final value. For models such as `sys2`, the settling time is returned as `NaN` because the steady-state value is zero.

In this example, you compute the step-response characteristics from step-response data that has an initial offset. This means that the value of the response data is nonzero before the step occurs.

Load the step-response data and examine the plot.

```load stepDataOffset.mat plot(stepOffset.Time,stepOffset.Data)```

If you do not specify `yfinal` and `yinit`, then `stepinfo` assumes that `yfinal` is the last value in the response vector `y` and `yinit` is zero. When you know what the steady-state and initial values are, you can provide them to `stepinfo`. Here, the steady state of the response `yfinal` is 0.9 and the initial offset `yinit` is 0.2.

Compute step-response characteristics from this response data.

`S = stepinfo(stepOffset.Data,stepOffset.Time,0.9,0.2)`
```S = struct with fields: RiseTime: 0.0084 TransientTime: 1.0662 SettlingTime: 1.0662 SettlingMin: 0.8461 SettlingMax: 1.0878 Overshoot: 26.8259 Undershoot: 0.0429 Peak: 0.8878 PeakTime: 1.0225 ```

Here, the peak value of this response is 0.8878 because `stepinfo` measures the maximum deviation from `yinit`.

## Input Arguments

collapse all

Dynamic system, specified as a SISO or MIMO dynamic system model. Dynamic systems that you can use include:

• Continuous-time or discrete-time numeric LTI models, such as `tf`, `zpk`, or `ss` models.

• Generalized or uncertain LTI models such as `genss` or `uss` (Robust Control Toolbox) models. (Using uncertain models requires Robust Control Toolbox™ software.) For generalized models, `stepinfo` computes the step-response characteristics using the current value of tunable blocks and the nominal value of uncertain blocks.

• Identified LTI models, such as `idtf` (System Identification Toolbox), `idss` (System Identification Toolbox), or `idproc` (System Identification Toolbox) models. (Using identified models requires System Identification Toolbox™ software.)

Step-response data, specified as one of the following:

• For SISO response data, a vector of length `Ns`, where `Ns` is the number of samples in the response data

• For MIMO response data, an `Ns`-by-`Ny`-by-`Nu` array, where `Ny` is the number of system outputs and `Nu` is the number of system inputs

Time vector corresponding to the response data in `y`, specified as a vector of length `Ns`.

Steady-state value, specified as a scalar or an array.

• For SISO response data, specify a scalar value.

• For MIMO response data, specify an `Ny`-by-`Nu` array, where each entry provides the steady-state response value for the corresponding system channel.

If you do not provide `yfinal`, then `stepinfo` uses the last value in the corresponding channel of `y` as the steady-state response value.

This argument is only supported when you provide step-response data as an input. For a dynamic system model `sys` as an input, `stepinfo` uses yfinal = steady-state value to compute the characteristics that depend on this value.

Value of `y` before the step occurs, specified as a scalar or an array.

• For SISO response data, specify a scalar value.

• For MIMO response data, specify an `Ny`-by-`Nu` array, where each entry provides the response initial value for the corresponding system channel.

If you do not provide `yinit`, then `stepinfo` uses zero as the response initial value.

The response y(0) at t = 0 is equal to yinit for systems without feedthrough. However, the two quantities differ in the presence of feedthrough because of the discontinuity at t = 0.

For example, the following figure shows the step response of a system with feedthrough `sys = tf([-1 0.2 1],[1 0.7 1])`.

Here, yinit is zero and the feedthrough value is –1.

This argument is only supported when you provide step-response data as an input. For a dynamic system model `sys` as an input, `stepinfo` uses yinit = 0 to compute the characteristics that depend on this value.

Threshold for defining settling and transient times, specified as a scalar value between 0 and 1. To change the default settling and transient time definitions (see Algorithms), set `ST` to a different value. For instance, to measure when the error falls below 5%, set `ST` to 0.05.

Threshold for defining rise time, specified as a 2-element row vector of nondescending values between 0 and 1. To change the default rise time definition (see Algorithms), set `RT` to a different value. For instance, to define the rise time as the time it takes for the response to rise from 5% to 95% from the initial value to the steady-state value, set `RT` to `[0.05 0.95]`.

## Output Arguments

collapse all

Step-response characteristics, returned as a structure containing the fields:

• `RiseTime`

• `TransientTime`

• `SettlingTime`

• `SettlingMin`

• `SettlingMax`

• `Overshoot`

• `Undershoot`

• `Peak`

• `PeakTime`

For more information on how `stepinfo` defines these characteristics, see Algorithms.

For MIMO models or responses data, `S` is a structure array in which each entry contains the step-response characteristics of the corresponding I/O channel. For instance, if you provide a 3-input, 3-output model or an array of response data, then `S(2,3)` contains the characteristics of the response from the third input to the second output. For an example, see Step-Response Characteristics of MIMO System.

If `sys` is unstable, then all step-response characteristics are `NaN`, except for `Peak` and `PeakTime`, which are `Inf`.

## Algorithms

For a step response y(t), `stepinfo` computes characteristics relative to yinit and yfinal. For a dynamic system model `sys`, `stepinfo` uses yinit = 0 and yfinal = steady-state value.

This table shows how `stepinfo` computes each characteristic.

Step-Response CharacteristicDescription
`RiseTime`Time it takes for the response to rise from 10% to 90% of the way from yinit to yfinal
`TransientTime`

The first time T such that the error |y(t) – yfinal| ≤ SettlingTimeThreshold × emax for tT, where emax is the maximum error |y(t) – yfinal| for t ≥ 0.

By default, SettlingTimeThreshold = 0.02 (2% of the peak error). Transient time measures how quickly the transient dynamics die off.

`SettlingTime`

The first time T such that the error |y(t) – yfinal| ≤ SettlingTimeThreshold × |yfinalyinit| for tT.

By default, `SettlingTime` measures the time it takes for the error to stay below 2% of |yfinalyinit|.

`SettlingMin`Minimum value of y(t) once the response has risen
`SettlingMax`Maximum value of y(t) once the response has risen
`Overshoot`Percentage overshoot. Relative to the normalized response ynorm(t) = (y(t) – yinit)/(yfinalyinit), the overshoot is the larger of zero and 100 × max(ynorm(t) – 1).
`Undershoot`Percentage undershoot. Relative to the normalized response ynorm(t), the undershoot is the smaller of zero and –100 × max(ynorm(t) – 1).
`Peak`Peak value of |y(t) – yinit|
`PeakTime`Time at which the peak value occurs

## Version History

Introduced in R2006a

expand all

Behavior changed in R2021b