text:
# The blue mystery and the Raman effect

An elementary school level physics question: Why is the sky blue? You may answer that the sunlight gets scattered by the air-molecules and according to Rayleigh scattering theory, the blue light gets scattered the most (the scattering intensity proportional to $1/\lambda^4$, implying that it’s high for small wavelength $\lambda$ such as the blue light).

Now the immediate question comes: Why does sea look blue too?

Many school text-books explain in a simple and obvious way: Since the sky is blue, it’s reflection makes river or sea appear blue.

Though seems pretty convincing, the answer is incorrect and this week Tuesday Prof. Chandrabhas Narayan of JNCASR gave a beautiful lecture on Raman effect and how it becomes responsible for the blueness of sea.

He showed a few slides where all water resources don’t appear blue even though they are well-exposed under the sky. He explained in the following way. The Rayleigh scattering is an elastic scattering, where light just get deflected after confronting a molecule, but doesn’t change its wavelength. But there could be inelastic scattering processes due to vibrational modes of a molecules.

In an elastic scattering (Rayleigh one) an electron of a certain energy level inside an atom or a molecule absorbs energy from the incident photon and jumps to a higher energy state (called the virtual level) for a while and then emits the photon of the same energy (hence same wavelength too), and goes back to its original energy state.

However, in an inelastic scattering process, the electron can absorb the energy from a photon and then after reaching the virtual level it may decide to sit on one of its vibrational excited energy level by emitting a light with lower energy (hence higher wavelength). Such an emission line is known as the Stokes lines and the whole scattering process is known as the Raman Effect, discovered by C. V. Raman in 1928, who was a Palit Professor in Calcutta (His discovery helped him to get the Nobel prize very shortly, in 1930.).

The emission can go in the opposite direction as well (vibration level $\rightarrow$ virtual level $\rightarrow$ ground state of the atom/molecule ) and then the lines are called anti-Stokes lines.

Due to this Raman effect the water molecules in sea scatter the white sunlight to wavelengths that mostly fall in the blue regime of light spectra and hence sea appears blue.

Chandrabhas gave a long introduction (entertaining and answering several questions from the audience) of the Raman effect and its special importance in comparison to other spectroscopic measurements.

He said that it’s not necessary that sea or any water resource has to be blue in color (e.g. it can be turquoise) and the color depends on the depth of water as well.

He also mentioned that though Raman effect is very weak (out of $10^9$ photons, 1 photon participate in Raman scattering), a newly developed experimental probe called the Surface Enhance Raman Spectroscopy (SERS) can be very useful to characterize nanostructures and for biological fingerprint such as in DNAs and proteins. At the end Chandrabhas mentioned the controversies related to the real discoverers of this effect (e.g. Russians never liked to call it Raman effect, rather they preferred to say Mandelstam effect) and also the credit might have gone to Krishnan, one of Raman’s PhD student.

Prof. Chandrabhas’ talk can be found here.

Now may not be referred as a quiz question, but can you help the child to quench her curiosity?

## 9 thoughts on “The blue mystery and the Raman effect”

1. Thanks Shila. Can you attempt to answer the question asked in the xkcd cartoon above?

2. violet rays scatters most…and the sky is violet also to a little extent but may be as the next spectra is ultraviolet it effects on it..or may be our sense perception…!!
well,I don’t know very well..I just guessed it..:D
do you know???

• Well, I personally think the issue is still debatable. There are two existing and widely-believed answers.

1. The violet part of the sunlight are mostly absorbed at high atmosphere.
2. Our eyes have three cone cells in the retina: red, green, and blue, which are responsible for color vision. Now red and green cells can sense most of the part of the light spectrum, whereas the blue one is limited in the blue regime. Though all three cones response to the color, altogether violet and indigo becomes less sensitive due to the smaller intensities of the response of the cone cells in that
regime of the spectrum. So overall blue predominates.

However, I would prefer to remain still skeptical since we can clearly distinguish the ‘violet’ in a rainbow.

Maybe if we someday talk about how the 3D glasses work (one glass blue and the other red), it may help us to understand more about our vision.

3. I had asked the question to D.S. why sky is blue and not violet??
He said above reasons and also said that sun generates electromagnetic waves within the range of visible light just according to the graph you showed(i.e. describing how our eyes are sensitive to colours) and green is generated mostly(somehow like as it is sensitive to our eyes too) and violet is least generated wave..!!
so that’s another reason why there isn’t much violet in atmosphere..!!
he asked me another question that why hills seem blue from a distance whether they are green due to trees on it..
I said due to scattering of light this happens,he said I pointed out it correctly but still there is more story..:p cause scattering can’t change colour,is it??

4. Clap my hands! Thank you for such valuable information. I need to explain Raman and I think they way that you have explaine it is one of the best that I have found. So, thank you for sharing it.
Best

• Hi, Ana. It’s great to see that it helped you. Let me know if you want me to write on some cool physics stuff in future. 🙂

5. Updates : Well, the post was made by myself on February 2013. Later Veritasium and MinutePhysics have uploaded in May ’13 and Nov ’14 explaining why sky doesn’t appear violet to us. Both talked about the sun’s spectra which has a very little violet contribution compared to blue wavelength. MinutePhysics goes to a more generic explanation in terms of the chromaticity diagram (which also connects to the perception of colors by human eyes, check : http://bit.ly/1qXCkxX) and sun as a hot object (almost a black body) is restricted to a particular color zone in the chromaticity diagram, where depending on varying temperature in the sun, we receive radiations ranging from red to blue (note blue is hotter than red, which is just the Wein’s displacement law), and there again violet part is very insignificant.

You can check out the videos here : https://www.youtube.com/watch?v=ro2MmmdARrs (Veritasium) , https://www.youtube.com/watch?v=R5P6O0pDyMU (MinutePhysics).


text:
It is currently 19 Nov 2017, 13:22

### GMAT Club Daily Prep

#### Thank you for using the timer - this advanced tool can estimate your performance and suggest more practice questions. We have subscribed you to Daily Prep Questions via email.

Customized
for You

we will pick new questions that match your level based on your Timer History

Track

every week, we’ll send you an estimated GMAT score based on your performance

Practice
Pays

we will pick new questions that match your level based on your Timer History

# Events & Promotions

###### Events & Promotions in June
Open Detailed Calendar

### Show Tags

14 Oct 2017, 22:05
00:00

Difficulty:

25% (medium)

Question Stats:

83% (01:20) correct 18% (02:02) wrong based on 40 sessions

### HideShow timer Statistics

A man spends $48 to buy 6 hamburgers and 8 colas for his office workers. The next day, he buys 5 hamburgers and 4 colas and spends$32. Assuming the prices of hamburgers and colas remain constant, what is the price of one hamburger and one cola?

A. $6 B.$7
C. $8 D.$9
E. $10 [Reveal] Spoiler: OA _________________ When everything seems to be going against you, remember that the airplane takes off against the wind, not with it. - Henry Ford The Moment You Think About Giving Up, Think Of The Reason Why You Held On So Long +1 Kudos if you find this post helpful Kudos [?]: 1004 [0], given: 80 Director Joined: 25 Feb 2013 Posts: 555 Kudos [?]: 248 [0], given: 34 Location: India Schools: Mannheim"19 (S) GPA: 3.82 A man spends$48 to buy 6 hamburgers and 8 colas [#permalink]

### Show Tags

14 Oct 2017, 22:11
Skywalker18 wrote:
A man spends $48 to buy 6 hamburgers and 8 colas for his office workers. The next day, he buys 5 hamburgers and 4 colas and spends$32. Assuming the prices of hamburgers and colas remain constant, what is the price of one hamburger and one cola?

A. $6 B.$7
C. $8 D.$9
E. $10 let price of one hamburger be $$x$$ and that of cola be $$y$$ $$6x+8y=48 =>3x+4y=24$$ ----------(1) $$5x+4y=32$$ ----------(2) Subtract equation 1 from 2 to get $$2x=8$$ or $$x=4$$ substitute the value of $$x$$ in any equation to get $$y=3$$ Hence $$x+y=4+3=7$$ Option B Kudos [?]: 248 [0], given: 34 A man spends$48 to buy 6 hamburgers and 8 colas   [#permalink] 14 Oct 2017, 22:11
Display posts from previous: Sort by

format: plain


text:
### Trusted by thousands of candidates each year

#### Study Notes & Video Lessons

AnalystPrep's FRM part 1 study notes and video lessons summarize each chapter of the GARP Books with question examples to facilitate the assimilation of the hardest risk management concepts.

#### Question Bank

AnalystPrep's FRM Part I exam-style question banks only include high-quality questions that replicate the difficulty of the exam you’re studying for.

#### Printable Mock Exams

Challenge yourself with our PDF FRM Part 1 practice exams designed to mimic what you are going to face at the end of your marathon.

### AnalystPrep's Study Materials for the FRM Part 1 Exam

Each FRM preparation package comes with an FRM part 1 question bank that contains over 1,250 practice questions tailored to teach you all of the rudimentary aspects of financial risk management. To succeed, you will need to solve numerous quantitative practice questions on subjects such as the Hypothesis Testing and the Black-Scholes-Merton model to ensure you are able to do the necessary calculation when comes exam time.

You can also create an unlimited number of quizzes to test your understanding of one or more books at the same time.

Moreover, FRM part 1 mock exams that replicate the level of difficulty of the actual exam are included in each FRM package. These mock exams will give you the ability to test yourself using the same weights as given by GARP.

To be sure you are prepared for every concept, read AnalystPrep’s FRM part 1 books summaries. These study notes will speed up the learning process so you can focus on the important aspect of your preparation – practice questions.

For busy candidates, you can also watch our FRM part 1 video lessons. Our lead instructor, Prof. James Forjan, PhD, has created one video for each chapter of the GARP official books. Every video is approximately 20 minutes long and includes many examples similar to the questions you will have to solve in your FRM Part 1 exam.

# Study Materials Content

The first part of the exam is broken down into four different general topics, and are all assigned different percentages that factor into your overall grade:

Foundations of Risk Management (20%)
Quantitative Analysis (20%)
Financial Markets and Products (30%)
Valuation and Risk Models (30%)

Part 1 of the FRM exam will challenge you on 100 multiple choice questions and is always offered in the morning of either of the two available dates. Pass rates for the first part of the exam average around 50%.

There are several key terms that should be emphasized throughout your study plan for part 1 of the exam:

Modern Portfolio Theory (MPT)
Arbitrage Pricing Theory – APT
Monte Carlo Simulation
Value at Risk – VaR
Volatility
Black-Scholes Model
Generalized AutoRegressive Conditional Heteroskedasticity (GARCH) Process
Delta Hedging

These terms, theories, and processes will be the most prevalent topics you will come across while taking the test. AnalystPrep’s FRM part 1 question bank makes sure that you are familiar with their definition, that you can break down the concepts, that you can retain any equations related to the topic to memorize, and that you are able to give the right examples.

## Pricing

Our FRM® packages start as low as $129 with a one exam Practice package. Our Learn + Practice packages include study notes and video lessons for an extra$70.

###### / year
• FRM Part 1 Question Bank
• FRM Part 1 Printable Mock Exams
• Performance Tools

### Testimonials

“Thanks to your program I passed the first level of the CFA exam, as I got my results today. You guys are the best. I actually finished the exam with 45 minutes left in [the morning session] and 15 minutes left in [the afternoon session]… I couldn’t even finish with more than 10 minutes left in the AnalystPrep mock exams so your exams had the requisite difficulty level for the actual CFA exam.”

###### James B.

“I loved the up-to-date study materials and Question bank. If you wish to increase your chances of CFA Exam success on your first attempt, I strongly recommend AnalystPrep.”

###### Jose Gary

“Before I came across this website, I thought I could not manage to take the CFA paper alongside my busy schedule at work. But with the up-to-date study material, there is little to worry about. The Premium package is cheaper and the questions are well answered and explained. The question bank has a wide range of examinable questions extracted from across the whole syllabus. Thank you so much for helping me pass my first CFA papers.”

###### Brian Masibo

Good Day!

I cleared FRM -I (May-2018) with 1.1.1.1. Thanks a lot to AnalystPrep and your support.

Regards,

@AnalystPrep provided me with the necessary volume of questions to insure I went into test day having in-depth knowledge of every topic I would see on the exams.”

###### Justin T.

“Great study materials and exam-standard questions. In addition, their customer service is excellent. I couldn’t have found a better CFA study partner.”

###### Joshua Brown

“I bought their frm part 1 package and passed the exam. Their customer support answered all of my questions when I had problems with what was written in the curriculum. I’m planning to use them also for the frm part 2 exam and CFA level 1.”

###### Zubair Jatoi

“I bought the FRM premium subscription about 2 weeks ago. Very good learning tool. I contacted support a few times for technical questions and Michael was very helpful.”


text:
# Arriving at a wrong output impedance for a BJT Emitter Follower Configuration Circuit

We've to calculate output impedance of the circuit (figure 1). Although i understood the textbook solution (figure 2, figure 3), I took a different approach and arrived at a wrong answer.

step 1: I shorted the input voltage sources. (since, Zout is being calculated)
step 2: since there is no power anywhere in circuit, Ib will definitely be 0.
step 3: the dependent source is opened. (since, Ib = 0)
step 4: also RB is shorted by the source
step 5: thus, when seen b/w emitter terminal and ground, βre and RE are parallel but equation 8.42 says otherwise!

please point where the mistake was in my approach.

• Why would you say "since there is no power anywhere in the circuit"? – Dwayne Reid Mar 29 '19 at 19:14
• Input voltage is shorted and that's the only external power applied to the circuit.. so Ib has to be zero, no? – Mohit Singh Chahar Mar 29 '19 at 19:16
• No. Current flows (conventional flow) from Vcc through Rb, through the E-B junction, through Re, to Ground. In other words, the transistor has base bias. The amount of bias current depends on the value of the resistors. – Dwayne Reid Mar 29 '19 at 19:18
• The small-signal emitter voltage is not zero, so how can Ib be zero? – Spehro Pefhany Mar 29 '19 at 19:20
• @SpehroPefhany: You may be right in that I am confusing small signal analysis with large signal. Been way too many decades since I last touched this stuff. That's why I keep my old textbooks handy. – Dwayne Reid Mar 29 '19 at 21:14

To be able to see the difference try to analysis these two circuits.

The first one is CE amplifier

And for this circuit

$$\Z_{OUT} = \frac{V_X}{I_X} = R_C\$$

because $$\I_B = 0A\$$

But for the emitter follower, we have a different situation:

And $$\ I_B\$$ is not equal to $$\0A\$$ despite the fact that the Vin = 0

For this circuit $$\I_B = -\frac{V_X}{r_{\pi}}\$$

And $$\Z_{OUT} = \frac{V_X}{I_X}\$$

Let us try to find the $$\Z_{OUT}\$$ for the equivalent circuit:

I hope that you see that $$\R_E\$$ is in parallel with the resistance seen from the emitter terminal into the BJT.

And our test current is

$$I_X = I_B + \beta I_B + I_{RE}$$

But if we ignore $$\R_E\$$ resistance for a moment we can find the transistor resistance seen from the emitter looking into BJT.

$$I_X = I_B + \beta I_B = I_B(\beta +1)$$

Additional we know that $$\I_B = \frac{V_X}{r_\pi}\$$

we can write

$$I_X = I_B(\beta +1)= \frac{V_X}{r_\pi}(\beta +1) = \frac{V_X (\beta +1)}{r_\pi}$$

$$\frac{I_X}{V_X} =\frac{\beta +1}{r_\pi}$$

And finally

$$Z_{OUT} = \frac{V_X}{I_X} = \frac{r_\pi}{\beta +1}||R_E$$

and because

$$r_\pi = (\beta +1)re$$

we have

$$Z_{OUT} = re||R_E$$


text:
### Negative Resistance

This tutorial is going to cover the topic of negative resistance. At first, it might seem like a strange idea that you could have a current flowing in the opposite direction of an applied voltage; but, hopefully by the end of this tutorial you will have a better intuitive understanding of what a negative resistance really is, and how to build a negative resistor out of common circuit components.

### What is a Negative Resistance?

Our first step is to try to develop an intuitive notion of what a negative resistance is, and how it would behave in a circuit. The definition of resistance is governed by simple a relationship called Ohm’s Law.

$$R=\frac{V}{I}$$

We can see by looking at this equation, that to create a negative resistance we would need to create a circuit component which develops a negative voltage whenever a positive current is passed through it (assuming passive sign convention). However, rather than thinking about it in terms of mathematics, a simpler way to understand the idea of negative resistance is to consider the resistance of two resistors in series.

From a basic understanding of circuits, we know that the values of resistors add in series. Therefore, if we had a resistor with a positive value of 11 Ohms in series with a resistor with a negative value of -4 Ohms, the equivalent resistance in series comes out to 11 + (-4) = 7 Ohms. In other words, we can think of a negative resistor as a device we can put in series with another resistor to decrease its value.

### Creating a Negative Resistor Using a CCVS

Now that we have an idea of what we are trying to achieve, we can start our quest to create a negative resistor returning to Ohm’s Law and rearranging.

$$R=\frac{V}{I} \Rightarrow V=RI$$

Looking at this equation, we notice that it looks very similar to the equation governing the operation of a current-controlled voltage source (CCVS). In the equation below, $V_{CCVS}$ is the voltage output of the CCVS, $I_c$ is the controlling current, and $r_c$ is the “gain parameter” with units of Ohms—hint, hint!

$$V_{CCVS}=r_c I_c$$

If we make the assumption that the control current $( I_c )$ is flowing into the positive terminal of the CCVS, we can easily calculate the resistance $( R_{CCVS} )$ of the CCVS by once again using Ohm’s Law.

$$R_{CCVS}=\frac{V_{CCVS}}{I_c} = R_c$$

This leads us to the solution that the resistance of a current-controlled voltage source, whose control current is measured at the positive terminal, is simply equal to the gain parameter $( r_c )$ of the CCVS. By utilizing this fact, we can easily create a negative resistor simply by using a CCVS with a negative gain parameter. An example of this method can be seen in the figure below. Here we implement a resistance of -4 Ohms using the CCVS method.

### Creating a Negative Resistor Using a VCVS

At this point, some readers might be wondering “why go any further?” Unfortunately, a current-controlled voltage source isn’t a very practical real world circuit component. In fact, many circuit simulation programs (such as LTspice) don’t even include CCVS models! We can, however, overcome this limitation by using a component which is more readily at our disposal: a voltage-controlled voltage source (VCVS).

By looking at the equation governing the operation of a VCVS, we can see that it looks identical to the equation of a voltage amplifier. In the equation below, $V_{out}$ is the voltage output of the VCVS, $V_{sense}$ is the controlling voltage (i.e., the input voltage to an amplifier), and $G$ is the gain parameter (which is a unitless ratio).

$$V_{out}=G V_{sense}$$

With the help of Ohm’s Law (last time, I promise!), we find that we can make the VCVS mimic a CCVS through the use of a sensing resistor $( R_{sense} )$ in series with the VCVS to measure current. The current flowing through $R_{sense}$ will create a voltage which is proportional to the current, and can then be picked up by $V_{sense}$. The proposed setup can be seen in the figure below.

While the above setup gives us a structure that can be used to create a negative resistor, we continue our analysis by developing a set of analytical equations describing this circuit’s operation. The voltage developed across the sense resistor is written below.

$$V_{sense} = I_{sense} R_{sense}$$

We can now take the equation governing the VCVS, make the following substitutions and regroupings, and make the equation look like the equation governing the CCVS.

$$V_{out}=G V_{sense} = G (I_{sense} R_{sense}) = (G R_{sense}) I_{sense}$$

Here we see that $(G R_{sense})$ takes the place of $r_c$ from the CCVS equation. Also, we know from the previous section that $r_c$ is the resistance of the CCVS negative resistor circuit. However, to find the total resistance $R_{total}$ of VCVS circuit we are building, we need to take into account the added resistance of the current sensing resistor $(R_{sense})$.

$$R_{total} = R_{sense}+r_c$$

Making the substitution $r_c = (G R_{sense})$, we obtain:

$$R_{total}= R_{sense}+G R_{sense} = R_{sense}(1+G)$$

From this equation, we can solve for the gain parameter of the VCVS that we would need to create any desired resistance in our circuit.

$$G = \frac{R_{total}}{R_{sense}} – 1$$

Using the set of equations we have developed, we now have the tools to create a negative resistor of any value by using only a VCVS along with a sensing resistor. As an example, we now create a negative resistor with a value of -4 Ohms. By arbitrarily choosing $R_{sense} = 2 \: Ohms$, we can calculate the required gain parameter of the VCVS by using the previous equation.

$$G= \frac{R_{total}}{R_{sense}} – 1 = \frac{-4}{2} – 1 = -3$$

The completed example circuit can be seen below.

### Creating a Negative Resistor Using Real Components

Now that we have created a theoretical circuit describing a negative resistor, our final step is to create a practical implementation using real world components. To reiterate from the previous section, a VCVS is nothing more than a voltage amplifier with differential input and differential output. To simplify the circuit design, we will make the assumption that one of the terminals of our negative resistor will always be connected to ground. This assumption allows us to use a voltage amplifier which has differential inputs, but only a single ended output. I’ve attached a schematic for an inverting amplifier like this as a reference in the figure below.

The gain of this amplifier is set by the ratio of resistors $R_f$ and $R_1$.

$$G=-\frac{R_f}{R_1}$$

Therefore the input-output relationship of this amplifier is governed by the following equation.

$$V_{out}=-\frac{R_f}{R_1}(V_{in+}-V_{in-})$$

The similarity to the equation governing the VCVS $(V_{out}=G V_{sense})$ is easy to see if we make the following substitutions.

$$G = -\frac{R_f}{R_1}$$

$$V_{sense} = V_{in+}-V_{in-}$$

This allows us to directly substitute for the VCVS in the negative resistor circuit with our differential amplifier circuit. We can solve for the required ratio of $R_f$ to $R_1$ by using the equation used to calculate the required gain of the VCVS in the previous section. The equation is repeated below.

$$G=\frac{R_{total}}{R_{sense}} – 1$$

$$-\frac{R_f}{R_1}=\frac{R_{total}}{R_{sense}} – 1$$

$$\frac{R_f}{R_1}=-\left( \frac{R_{total}}{R_{sense}} – 1 \right)$$

By directly replacing the VCVS from the previous section with the circuit above, we obtain the final schematic for the negative resistor seen below.

We find the overall resistance of the circuit by substituting the gain equation of the differential amplifier circuit into the equation for calculating $R_{total}$ of the VCVS circuit developed in previous section.

$$R_{total} = R_{sense}(1+G) = R_{sense}\left(1+ -\frac{R_f}{R_1} \right)$$

### Example Problem

To make sure that everything discussed is correct and checks out, we will work out a single example problem and simulate it.

Example: Create a negative resistor with a value of -4 Ohms. Use $R_{sense}=2\: Ohms$, and keep both $10\: kOhms \leq R_1 \leq 1\: kOhms$ and $10\: kOhms \leq R_f \leq 1\: kOhms$. Using Spice, calculate the equivalent series resistance of the negative resistor in series with an 11 Ohm resistor, using a 5 V DC voltage source as the test voltage. The total equivalent resistance should be equal to 11 – 4 = 7 Ohms.

We start by calculating the required gain of the amplifier.

$$G = \frac{R_{total}}{R_{sense}} – 1$$

$$G = \frac{-4}{2} – 1 = -3$$

Now that we know the gain, we can calculate the values of $R_1$ and $R_f$ to set the gain of the differential amplifier circuit. To make our calculations easy, we will choose $R_1 = 10\: kOhms$.

$$G=-\frac{R_f}{R_1}$$

$$-3=-\frac{R_f}{10,000}$$

$$R_f = 3 \times 10,000 = 30,000\: Ohms$$

Now that we have the values of all the components, we can plug them into our circuit. Here is what we get!

To verify our results, we run the simulation and everything checks out. Because the differential amplifier has a finite input resistance, this will slightly affect the operation of our circuit. We can take this into account while we are designing our circuit; but, I will leave that as an exercise for the reader (don’t you always love it when textbooks do that).

### Summary

As a summary, I will outline our thought process, the steps we took, and the final result so that we can collect our thoughts.

1. We notice that a current-controlled voltage source has a similar equation to a resistor.
2. We realize that we can create any value of resistor (both positive and negative) if we use the current flowing into the positive terminal of the CCVS as the sensing current, and choose a suitable gain parameter value.
3. We can mimic the CCVS using a voltage-controlled voltage source if we use a current sensing resistor.
4. We can implement a VCVS by using a differential amplifier.
5. By substituting the VCVS for the differential amplifier, we obtain a practical method to implement a negative resistor.

The negative resistor circuit can be seen below

The resistance of the circuit is given by the following equation.

$$R_{total} = R_{sense}\left( 1-\frac{R_f}{R_1} \right)$$


text:
# 3D Translation using only distance and angles

So I'm starting to foray into 3D game programming, but I've hit something of a snag.

I have an object I want to move around. It should always move either forward or backward relative to its local Z axis, and otherwise change directions by changing its local X and Y rotations.

Now doing this in 2D is no problem. When I only consider the X-Z plane, the following code works fine:

m_Position.x -= (float)sin(m_Rotation.y * Pi / 180) * Speed;
m_Position.z -= (float)cos(m_Rotation.y * Pi / 180) * Speed;

And when only considering the Y-Z plane, the following works fine:

m_Position.y += (float)sin(m_Rotation.x * Pi / 180) * Speed;
m_Position.z -= (float)cos(m_Rotation.x * Pi / 180) * Speed;

But when combining the two, they don't work. Now I didn't expect them to work just straight up stuck together like that, since the Z value is getting conflicting signals. But I'm not sure where to go from here.

I've read a bit about matrix math, and that seems the way to go, but the tutorials I have found are either difficult to follow, or they focus on rotating a point around the origin (or translating if you already have a translation vector, which is the thing I'm looking for). The clearest one I've found is this, but I'm not sure how to adapt the rotate-around-origin matrix math to the move-in-direction-of-angle matrix math.

My extremely rudimentary understanding of matrix math would suggest that translations Ta and Tb along angles A and B, if A is a rotation around the Y axis and B around the X axis, would be represented as:

Xa = x*sinA + y*0 + z*0 + w*0
Ya = x*0 + y*1 + z*0 + w*0
Za = x*0 + y*0 + z*cosA + w*0
Wa = x*0 + y*0 + z*0 + w*1

Xb = x*1 + y*0 + z*0 + w*0
Yb = x*0 + y*sinB + z*0 + w*0
Zb = x*0 + y*0 + z*cosB + w*0
Wb = x*0 + y*0 + z*0 + w*1

But I don't know whether that's right, and what I have to do with them. Multiply them together? Add the resulting vectors? Am I even close?

Can someone point me in the direction of good resources for learning this sort of thing?

EDIT: Just to be clear, I have the object's current (X,Y,Z) and its (Roll, Yaw, Pitch). I want it to move in from the former in the direction defined by the latter. I know I can use OpenGL to do this transformation on a purely visual level by just rotating first and then translating, but I need to have access to the new (X,Y,Z) for things like collision detection, indexing, etc.

EDIT 2: I've created the following code after finding this, but I'm not 100% sure if it's correct, since there are also issues with my visual rotations at the moment. It seems to work, at least superficially. Thoughts?

float X = (float)sin(m_Rotation.y * Pi / 180) * (float)cos(m_Rotation.x * Pi / 180);
float Y = (float)sin(-m_Rotation.x * Pi / 180);
float Z = (float)cos(m_Rotation.y * Pi / 180) * (float)cos(m_Rotation.x * Pi / 180);

Basically you have to:

1. Create a rotation matrix from Yaw/Pitch and Roll
2. Multiply your local direction vector (z-axis) by that matrix and multiply the resulting vector by speed, that is the translation

I added a code example. There are 2 convenience classes that do most of the ugly work: vector and matrix. Scroll directly down to main, to see the implementation of 1) 2) and 3)

#include <cmath>
#include <cassert>
#include <cstdio>

#define NEARLY_EQUAL_EPS_F( a, b, eps )     (fabsf( (a)-(b) ) < (eps))
#define ASSERT_VECTOR( v )                  (assert( NEARLY_EQUAL_EPS_F(0.0f, (v)[3], 1.e-7)))
#define FLOAT_FORMATOR                      "%10.6f"

namespace demo
{
class vector
{
public:
vector() {}
explicit vector( const float _v[4] )                    { v[0]=_v[0]; v[1]=_v[1]; v[2]=_v[2]; v[3]=_v[3]; }
vector( const vector &_v )                              { v[0]=_v[0]; v[1]=_v[1]; v[2]=_v[2]; v[3]=_v[3]; }
vector( float _x, float _y, float _z, float _w )        { v[0]=_x; v[1]=_y; v[2]=_z; v[3]=_w; }

float           &operator[]( int i )                    { return v[i]; }
const float     &operator[]( int i ) const              { return v[i]; }

// useful for glVertex3fv, glNormal3fv
const float*    data_ptr() const                        { return v; }
vector          operator+(const vector &b ) const       { ASSERT_VECTOR( b ); return vector( v[0]+b[0], v[1]+b[1], v[2]+b[2], v[3]+b[3] ); }
// scale vector
vector          operator*( float scale ) const          { return vector( v[0]*scale, v[1]*scale, v[2]*scale, v[3]*scale ); }

private:
float v[4];
};

class matrix
{
public:
matrix() {}

vector&                 operator[]( int i )             { return cols[i]; }
const vector&           operator[]( int i ) const       { return cols[i]; }

const float*            data_ptr() const                { return cols[0].data_ptr(); }
matrix&                 rotateY( float a );
matrix&                 rotateX( float a );
matrix&                 rotateZ( float a );

// return an identity matrix
static matrix           identity();
// create a rotation matrix around y-axis
static matrix           rotate_y( float a )             { return matrix::identity().rotateY( a ); }
// create a rotation matrix around y-axis
static matrix           rotate_x( float a )             { return matrix::identity().rotateX( a ); }
// create a rotation matrix around y-axis
static matrix           rotate_z( float a )             { return matrix::identity().rotateZ( a ); }

private:
vector cols[4];
};

inline
matrix
matrix::identity()
{
matrix m;
m[0] = vector( 1.0f, 0.0f, 0.0f, 0.0f );
m[1] = vector( 0.0f, 1.0f, 0.0f, 0.0f );
m[2] = vector( 0.0f, 0.0f, 1.0f, 0.0f );
m[3] = vector( 0.0f, 0.0f, 0.0f, 1.0f );
return m;
}

inline
matrix&
matrix::rotateY( float a )
{
cols[0][0] = cos(a);    cols[0][1] = 0.0f;  cols[0][2] = -sin(a);   cols[0][3] = 0.0f;
cols[1][0] = 0.0f;      cols[1][1] = 1.0f;  cols[1][2] = 0.0f;      cols[1][3] = 0.0f;
cols[2][0] = sin(a);    cols[2][1] = 0.0f;  cols[2][2] = cos(a);    cols[2][3] = 0.0f;
cols[3][0] =            cols[3][1] =        cols[3][2] = 0.0f;      cols[3][3] = 1.0f;
return *this;
}

inline
matrix&
matrix::rotateX( float a )
{
cols[0][0] = 1.0f;      cols[0][1] = 0.0f;      cols[0][2] = 0.0f;     cols[0][3] = 0.0f;
cols[1][0] = 0.0f;      cols[1][1] = cos(a);    cols[1][2] = sin(a);   cols[1][3] = 0.0f;
cols[2][0] = 0.0f;      cols[2][1] = -sin(a);   cols[2][2] = cos(a);   cols[2][3] = 0.0f;
cols[3][0] =            cols[3][1] =            cols[3][2] = 0.0f;     cols[3][3] = 1.0f;
return *this;
}

inline
matrix&
matrix::rotateZ( float a )
{
cols[0][0] = cos(a);    cols[0][1] = sin(a);    cols[0][2] = 0.0f;      cols[0][3] = 0.0f;
cols[1][0] = -sin(a);   cols[1][1] = cos(a);    cols[1][2] = 0.0f;      cols[1][3] = 0.0f;
cols[2][0] = 0.0f;      cols[2][1] = 0.0f;      cols[2][2] = 1.0f;      cols[2][3] = 0.0f;
cols[3][0] =            cols[3][1] =            cols[3][2] = 0.0f;      cols[3][3] = 1.0f;
return *this;
}
// matrix-matrix multiplication
inline
matrix operator*( const matrix &a, const matrix &b )
{
matrix result;

register unsigned int r;
register unsigned int c;

for( r = 0; r < 4; ++r )
{
for( c = 0; c < 4; ++c )
{
result[c][r] = a[0][r] * b[c][0] +
a[1][r] * b[c][1] +
a[2][r] * b[c][2] +
a[3][r] * b[c][3];
}
}
return result;
}

// matrix-vector multiplication
inline
vector operator*( const matrix &m, const vector &v )
{
vector ret;
ret[0] = v[0] * m[0][0] + v[1] * m[1][0] + v[2] * m[2][0] + v[3] * m[3][0];
ret[1] = v[0] * m[0][1] + v[1] * m[1][1] + v[2] * m[2][1] + v[3] * m[3][1];
ret[2] = v[0] * m[0][2] + v[1] * m[1][2] + v[2] * m[2][2] + v[3] * m[3][2];
ret[3] = v[0] * m[0][3] + v[1] * m[1][3] + v[2] * m[2][3] + v[3] * m[3][3];
return ret;
}

inline void DumpVectorf( FILE *file, const char *msg, const vector &p )  { fprintf( file, "%-15s: "FLOAT_FORMATOR" "FLOAT_FORMATOR" "FLOAT_FORMATOR" "FLOAT_FORMATOR"\n", msg, p[0], p[1], p[2], p[3] ); fflush( file ); }

inline void DumpMatrixf( FILE *file, const char *msg, const matrix &m )
{
fprintf( file, "%-15s:\n", msg );
fprintf( file, "  row0: "FLOAT_FORMATOR" "FLOAT_FORMATOR" "FLOAT_FORMATOR" "FLOAT_FORMATOR"\n", m[0][0], m[1][0], m[2][0], m[3][0] );
fprintf( file, "  row1: "FLOAT_FORMATOR" "FLOAT_FORMATOR" "FLOAT_FORMATOR" "FLOAT_FORMATOR"\n", m[0][1], m[1][1], m[2][1], m[3][1] );
fprintf( file, "  row2: "FLOAT_FORMATOR" "FLOAT_FORMATOR" "FLOAT_FORMATOR" "FLOAT_FORMATOR"\n", m[0][2], m[1][2], m[2][2], m[3][2] );
fprintf( file, "  row3: "FLOAT_FORMATOR" "FLOAT_FORMATOR" "FLOAT_FORMATOR" "FLOAT_FORMATOR"\n", m[0][3], m[1][3], m[2][3], m[3][3] );
fflush( file );
}
}

using namespace demo;

int main()
{
vector m_Rotation(1.0f, 0.5f, 0.0f, 0.0f);
vector m_Position(2.0f, 3.0f, 0.0f, 1.0f);
float speed = 3.0f;

// 1) first calculate the rotation matrix from m_Rotation
// !Mind the rotation order, here we use X, Y, Z, if you use a different one, reshuffle this
// We create 3 matrices, each one for a rotation around 1 of the axes,
// then we multiply them to find the final rotation matrix
matrix rot = matrix::rotate_x(m_Rotation[0]) * matrix::rotate_y(m_Rotation[1]) * matrix::rotate_z(m_Rotation[2]);
DumpMatrixf(stdout, "matrix rot", rot);

DumpVectorf(stdout, "position start", m_Position);

// 2) now calculate the translation vector by multiplying the local-space walking direction with that matrix to find the world-space walking direction
// I assume here your nomal walking direction in object space is {0, 0, -1} change it if you use a different one
vector translation = rot * vector(0.0f, 0.0f, -1.0f, 0.0f);
// multiply it with the "Speed"
translation = translation * speed;
DumpVectorf(stdout, "translation", translation);

// 3) add the final translation to the position
m_Position = m_Position + translation;
DumpVectorf(stdout, "position final", m_Position);

return 0;
}

The output of the example:

matrix rot     :
row0:   0.877583   0.000000   0.479426   0.000000
row1:   0.403423   0.540302  -0.738460   0.000000
row2:  -0.259035   0.841471   0.474160   0.000000
row3:   0.000000   0.000000   0.000000   1.000000
position start :   2.000000   3.000000   0.000000   1.000000
translation    :  -1.438277   2.215381  -1.422480   0.000000
position final :   0.561723   5.215381  -1.422480   1.000000

Basically, it should move in whatever direction the camera is looking.

Assuming you have a view matrix representing the inverted position/orientation of the camera, You already have this direction without needing to calculate it.

Matrix myNewMatrix = view.Invert();

float3 directionToMovePlayer = new float3(-myNewMatrix.m31, -myNewMatrix.m32, -myNewMatrix.m33);

• 31, 32, 33 (3rd row) are for DirectX matrices, OpenGL would use 13, 23, 33 (3rd column) – Steve H Mar 14 '12 at 12:52
• Sorry, I didn't think that through - while the current code does have the object moving wherever the camera is looking, I intend to add other objects that move around independently of the camera according to the same system. I also need to know their XYZ coordinates, in order to calculate how far they are from other objects, collisions, etc. – GarrickW Mar 14 '12 at 13:06
• @Steve H for OpenGL it is the other way around, the translation is m[3][0], m[3][1] and m[3][2], the left number is the column, the right number is the row, that is why it is called column-major form. Look at my answer here, there is also code that shows how to easily verify it. – Maik Semder Mar 14 '12 at 17:26
• Thanks, thats good to know. I don't do alot of OpenGL. I wasn't conveying the translation vector to the OP, I was conveying the Z Basis Vector which is the negate of the camera's viewing direction. Which is the 3rd column. If I follow your lead there it is m[2][0], m[2][1], m[2][2]. My point was that he doesn't have to do what you describe in the 1st & 2nd step on your answer because that resulting vector is already inherent in the camera's view matrix. Since the camera is oriented in the direction he wants to go, that direction vector is one of the view matrix's basis vectors, but inverted. – Steve H Mar 14 '12 at 21:39
• But since the OP seems to be also interested in a more generic tool to move objects around that may not be tied to the camera's direction, your whole answer is certainly best for that. – Steve H Mar 14 '12 at 21:47


text:
CoreUnfold.lhs 44.4 KB
Newer Older
 simonpj@microsoft.com committed Dec 11, 2009 1 %  Simon Marlow committed Oct 11, 2006 2 % (c) The University of Glasgow 2006  simonpj committed Jun 08, 1999 3 4 % (c) The AQUA Project, Glasgow University, 1994-1998 %  Simon Marlow committed Oct 11, 2006 5 6  Core-syntax unfoldings  simonpj committed Jun 08, 1999 7 8 9 10 11 12 13 14 15 16 17 18  Unfoldings (which can travel across module boundaries) are in Core syntax (namely @CoreExpr@s). The type @Unfolding@ sits above'' simply-Core-expressions unfoldings, capturing higher-level'' things we know about a binding, usually things that the simplifier found out (e.g., it's a literal''). In the corner of a @CoreUnfolding@ unfolding, you will find, unsurprisingly, a Core expression. \begin{code} module CoreUnfold (  simonpj committed Mar 27, 2000 19  Unfolding, UnfoldingGuidance, -- Abstract types  simonpj committed Jun 08, 1999 20   simonpj@microsoft.com committed Oct 29, 2009 21 22 23 24  noUnfolding, mkImplicitUnfolding, mkTopUnfolding, mkUnfolding, mkCoreUnfolding, mkInlineRule, mkWwInlineRule, mkCompulsoryUnfolding, mkDFunUnfolding,  simonpj committed Jun 08, 1999 25   simonpj@microsoft.com committed Apr 03, 2009 26 27  interestingArg, ArgSummary(..),  simonpj committed Jun 08, 1999 28  couldBeSmallEnoughToInline,  simonmar committed Aug 12, 2005 29  certainlyWillInline, smallEnoughToInline,  simonpj committed Jun 08, 1999 30   simonpj@microsoft.com committed Apr 03, 2009 31  callSiteInline, CallCtxt(..),  simonpj@microsoft.com committed Dec 04, 2007 32   simonpj@microsoft.com committed Oct 29, 2009 33 34  exprIsConApp_maybe  simonpj committed Jun 08, 1999 35 36  ) where  simonpj@microsoft.com committed Oct 29, 2009 37 38 #include "HsVersions.h"  Simon Marlow committed Oct 11, 2006 39 40 import StaticFlags import DynFlags  simonpj committed Jun 08, 1999 41 import CoreSyn  simonpj@microsoft.com committed May 04, 2006 42 import PprCore () -- Instances  Simon Marlow committed Oct 11, 2006 43 import OccurAnal  simonpj@microsoft.com committed Oct 29, 2009 44 import CoreSubst hiding( substTy )  simonpj@microsoft.com committed Oct 30, 2009 45 import CoreFVs ( exprFreeVars )  Simon Marlow committed Oct 11, 2006 46 47 48 import CoreUtils import Id import DataCon  simonpj@microsoft.com committed Oct 29, 2009 49 import TyCon  Simon Marlow committed Oct 11, 2006 50 51 52 import Literal import PrimOp import IdInfo  simonpj@microsoft.com committed Oct 29, 2009 53 54 55 56 import BasicTypes ( Arity ) import TcType ( tcSplitDFunTy ) import Type import Coercion  Simon Marlow committed Oct 11, 2006 57 import PrelNames  simonpj@microsoft.com committed Oct 30, 2009 58 import VarEnv ( mkInScopeSet )  simonpj committed Jun 08, 1999 59 import Bag  simonpj@microsoft.com committed Oct 29, 2009 60 import Util  simonmar committed Oct 12, 2000 61 import FastTypes  Ian Lynagh committed Mar 29, 2008 62 import FastString  simonpj committed Jun 08, 1999 63 import Outputable  simonmar committed Sep 06, 1999 64   simonpj committed Jun 08, 1999 65 66 \end{code}  simonpj committed Mar 27, 2000 67   simonpj committed Jun 08, 1999 68 69 %************************************************************************ %* *  simonpj committed Mar 27, 2000 70 \subsection{Making unfoldings}  simonpj committed Jun 08, 1999 71 72 73 74 %* * %************************************************************************ \begin{code}  simonpj@microsoft.com committed Dec 11, 2009 75 76 77 mkTopUnfolding :: Bool -> CoreExpr -> Unfolding mkTopUnfolding is_bottoming expr = mkUnfolding True {- Top level -} is_bottoming expr  simonpj committed Nov 01, 1999 78   simonpj@microsoft.com committed Sep 10, 2008 79 80 mkImplicitUnfolding :: CoreExpr -> Unfolding -- For implicit Ids, do a tiny bit of optimising first  simonpj@microsoft.com committed Dec 11, 2009 81 mkImplicitUnfolding expr = mkTopUnfolding False (simpleOptExpr expr)  Simon Marlow committed Dec 16, 2008 82   simonpj@microsoft.com committed Oct 29, 2009 83 84 85 86 87 -- Note [Top-level flag on inline rules] -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- Slight hack: note that mk_inline_rules conservatively sets the -- top-level flag to True. It gets set more accurately by the simplifier -- Simplify.simplUnfolding.  simonpj@microsoft.com committed Mar 18, 2009 88   simonpj@microsoft.com committed Dec 11, 2009 89 90 mkUnfolding :: Bool -> Bool -> CoreExpr -> Unfolding mkUnfolding top_lvl is_bottoming expr  simonpj@microsoft.com committed Dec 02, 2009 91 92 93 94 95 96 97 98 99  = CoreUnfolding { uf_tmpl = occurAnalyseExpr expr, uf_src = InlineRhs, uf_arity = arity, uf_is_top = top_lvl, uf_is_value = exprIsHNF expr, uf_is_conlike = exprIsConLike expr, uf_expandable = exprIsExpandable expr, uf_is_cheap = is_cheap, uf_guidance = guidance }  simonpj@microsoft.com committed Oct 29, 2009 100  where  simonpj@microsoft.com committed Dec 02, 2009 101  is_cheap = exprIsCheap expr  simonpj@microsoft.com committed Dec 11, 2009 102 103  (arity, guidance) = calcUnfoldingGuidance is_cheap (top_lvl && is_bottoming) opt_UF_CreationThreshold expr  simonpj committed Mar 23, 2000 104 105 106  -- Sometimes during simplification, there's a large let-bound thing -- which has been substituted, and so is now dead; so 'expr' contains -- two copies of the thing while the occurrence-analysed expression doesn't  simonpj@microsoft.com committed Nov 19, 2009 107  -- Nevertheless, we *don't* occ-analyse before computing the size because the  simonpj committed Mar 23, 2000 108 109 110  -- size computation bales out after a while, whereas occurrence analysis does not. -- -- This can occasionally mean that the guidance is very pessimistic;  simonpj@microsoft.com committed Nov 19, 2009 111 112  -- it gets fixed up next round. And it should be rare, because large -- let-bound things that are dead are usually caught by preInlineUnconditionally  simonpj committed Jun 22, 1999 113   simonpj@microsoft.com committed Dec 02, 2009 114 115 mkCoreUnfolding :: Bool -> UnfoldingSource -> CoreExpr -> Arity -> UnfoldingGuidance -> Unfolding  simonpj@microsoft.com committed Oct 29, 2009 116 -- Occurrence-analyses the expression before capturing it  simonpj@microsoft.com committed Dec 02, 2009 117 mkCoreUnfolding top_lvl src expr arity guidance  simonpj@microsoft.com committed Oct 29, 2009 118  = CoreUnfolding { uf_tmpl = occurAnalyseExpr expr,  simonpj@microsoft.com committed Dec 02, 2009 119  uf_src = src,  simonpj@microsoft.com committed Oct 29, 2009 120 121  uf_arity = arity, uf_is_top = top_lvl,  122 123 124  uf_is_value = exprIsHNF expr, uf_is_conlike = exprIsConLike expr, uf_is_cheap = exprIsCheap expr,  simonpj@microsoft.com committed Oct 29, 2009 125 126 127 128 129  uf_expandable = exprIsExpandable expr, uf_guidance = guidance } mkDFunUnfolding :: DataCon -> [Id] -> Unfolding mkDFunUnfolding con ops = DFunUnfolding con (map Var ops)  Simon Marlow committed Dec 16, 2008 130   simonpj@microsoft.com committed Nov 05, 2009 131 132 mkWwInlineRule :: Id -> CoreExpr -> Arity -> Unfolding mkWwInlineRule id expr arity  simonpj@microsoft.com committed Dec 02, 2009 133 134 135  = mkCoreUnfolding True (InlineWrapper id) (simpleOptExpr expr) arity (UnfWhen unSaturatedOk boringCxtNotOk)  simonpj@microsoft.com committed Nov 05, 2009 136   twanvl committed Jan 25, 2008 137 mkCompulsoryUnfolding :: CoreExpr -> Unfolding  simonpj@microsoft.com committed Nov 05, 2009 138 mkCompulsoryUnfolding expr -- Used for things that absolutely must be unfolded  simonpj@microsoft.com committed Dec 02, 2009 139 140 141  = mkCoreUnfolding True InlineCompulsory expr 0 -- Arity of unfolding doesn't matter (UnfWhen unSaturatedOk boringCxtOk)  simonpj@microsoft.com committed Nov 05, 2009 142   simonpj@microsoft.com committed Dec 02, 2009 143 144 145 mkInlineRule :: Bool -> CoreExpr -> Arity -> Unfolding mkInlineRule unsat_ok expr arity = mkCoreUnfolding True InlineRule -- Note [Top-level flag on inline rules]  simonpj@microsoft.com committed Nov 05, 2009 146  expr' arity  simonpj@microsoft.com committed Dec 02, 2009 147  (UnfWhen unsat_ok boring_ok)  simonpj@microsoft.com committed Nov 05, 2009 148 149  where expr' = simpleOptExpr expr  simonpj@microsoft.com committed Dec 02, 2009 150  boring_ok = case calcUnfoldingGuidance True -- Treat as cheap  simonpj@microsoft.com committed Dec 11, 2009 151  False -- But not bottoming  simonpj@microsoft.com committed Dec 02, 2009 152 153 154 155  (arity+1) expr' of (_, UnfWhen _ boring_ok) -> boring_ok _other -> boringCxtNotOk -- See Note [INLINE for small functions]  simonpj committed Mar 27, 2000 156 \end{code}  simonpj committed Nov 01, 1999 157   simonpj committed Jul 14, 1999 158   simonpj committed Mar 27, 2000 159 160 161 162 163 %************************************************************************ %* * \subsection{The UnfoldingGuidance type} %* * %************************************************************************  simonpj committed Jun 08, 1999 164 165 166  \begin{code} calcUnfoldingGuidance  simonpj@microsoft.com committed Dec 02, 2009 167 168  :: Bool -- True <=> the rhs is cheap, or we want to treat it -- as cheap (INLINE things)  simonpj@microsoft.com committed Dec 11, 2009 169 170  -> Bool -- True <=> this is a top-level unfolding for a -- diverging function; don't inline this  simonpj@microsoft.com committed Dec 02, 2009 171 172  -> Int -- Bomb out if size gets bigger than this -> CoreExpr -- Expression to look at  simonpj@microsoft.com committed Oct 29, 2009 173  -> (Arity, UnfoldingGuidance)  simonpj@microsoft.com committed Dec 11, 2009 174 calcUnfoldingGuidance expr_is_cheap top_bot bOMB_OUT_SIZE expr  simonpj@microsoft.com committed Dec 02, 2009 175  = case collectBinders expr of { (bndrs, body) ->  simonpj committed Nov 01, 1999 176  let  simonpj@microsoft.com committed Dec 02, 2009 177 178 179 180 181 182 183 184 185 186  val_bndrs = filter isId bndrs n_val_bndrs = length val_bndrs guidance = case (sizeExpr (iUnbox bOMB_OUT_SIZE) val_bndrs body) of TooBig -> UnfNever SizeIs size cased_bndrs scrut_discount | uncondInline n_val_bndrs (iBox size) && expr_is_cheap -> UnfWhen needSaturated boringCxtOk  simonpj@microsoft.com committed Dec 11, 2009 187 188 189  | top_bot -- See Note [Do not inline top-level bottoming functions] -> UnfNever  simonpj@microsoft.com committed Dec 02, 2009 190 191 192 193 194 195 196 197  | otherwise -> UnfIfGoodArgs { ug_args = map (discount cased_bndrs) val_bndrs , ug_size = iBox size , ug_res = iBox scrut_discount } discount cbs bndr = foldlBag (\acc (b',n) -> if bndr==b' then acc+n else acc) 0 cbs  simonpj committed Nov 01, 1999 198  in  simonpj@microsoft.com committed Dec 02, 2009 199  (n_val_bndrs, guidance) }  simonpj committed Jun 08, 1999 200 201 \end{code}  simonpj@microsoft.com committed Apr 03, 2009 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 Note [Computing the size of an expression] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The basic idea of sizeExpr is obvious enough: count nodes. But getting the heuristics right has taken a long time. Here's the basic strategy: * Variables, literals: 0 (Exception for string literals, see litSize.) * Function applications (f e1 .. en): 1 + #value args * Constructor applications: 1, regardless of #args * Let(rec): 1 + size of components * Note, cast: 0 Examples Size Term -------------- 0 42# 0 x  simonpj@microsoft.com committed Nov 19, 2009 224  0 True  simonpj@microsoft.com committed Apr 03, 2009 225 226 227 228 229 230 231 232  2 f x 1 Just x 4 f (g x) Notice that 'x' counts 0, while (f x) counts 2. That's deliberate: there's a function call to account for. Notice also that constructor applications are very cheap, because exposing them to a caller is so valuable.  simonpj@microsoft.com committed Dec 11, 2009 233 234 235 236 237 238 239 240 241  Note [Do not inline top-level bottoming functions] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The FloatOut pass has gone to some trouble to float out calls to 'error' and similar friends. See Note [Bottoming floats] in SetLevels. Do not re-inline them! But we *do* still inline if they are very small (the uncondInline stuff).  simonpj@microsoft.com committed Oct 29, 2009 242 243 244 245 Note [Unconditional inlining] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ We inline *unconditionally* if inlined thing is smaller (using sizeExpr) than the thing it's replacing. Notice that  simonpj@microsoft.com committed Apr 03, 2009 246 247 248 249 250 251  (f x) --> (g 3) -- YES, unconditionally (f x) --> x : [] -- YES, *even though* there are two -- arguments to the cons x --> g 3 -- NO x --> Just v -- NO  simonpj@microsoft.com committed Oct 29, 2009 252 253 254 255 256 257 258 259 260 261 262 263 It's very important not to unconditionally replace a variable by a non-atomic term. \begin{code} uncondInline :: Arity -> Int -> Bool -- Inline unconditionally if there no size increase -- Size of call is arity (+1 for the function) -- See Note [Unconditional inlining] uncondInline arity size | arity == 0 = size == 0 | otherwise = size <= arity + 1 \end{code}  simonpj@microsoft.com committed Apr 03, 2009 264 265   simonpj committed Jun 08, 1999 266 \begin{code}  Isaac Dupree committed Jan 17, 2008 267 sizeExpr :: FastInt -- Bomb out if it gets bigger than this  simonpj committed Jun 08, 1999 268 269 270 271 272  -> [Id] -- Arguments; we're interested in which of these -- get case'd -> CoreExpr -> ExprSize  simonpj@microsoft.com committed Apr 03, 2009 273 274 -- Note [Computing the size of an expression]  simonmar committed Oct 12, 2000 275 sizeExpr bOMB_OUT_SIZE top_args expr  simonpj committed Jun 08, 1999 276 277  = size_up expr where  simonpj@microsoft.com committed Oct 29, 2009 278 279  size_up (Cast e _) = size_up e size_up (Note _ e) = size_up e  simonpj@microsoft.com committed Apr 03, 2009 280 281  size_up (Type _) = sizeZero -- Types cost nothing size_up (Lit lit) = sizeN (litSize lit)  simonpj@microsoft.com committed Oct 29, 2009 282  size_up (Var f) = size_up_call f [] -- Make sure we get constructor  simonpj@microsoft.com committed Apr 03, 2009 283  -- discounts even on nullary constructors  Simon Marlow committed Dec 16, 2008 284   twanvl committed Jan 25, 2008 285  size_up (App fun (Type _)) = size_up fun  simonpj@microsoft.com committed Dec 14, 2009 286 287  size_up (App fun arg) = size_up arg addSizeNSD size_up_app fun [arg]  simonpj committed Jun 08, 1999 288   simonpj committed Mar 23, 2000 289  size_up (Lam b e) | isId b = lamScrutDiscount (size_up e addSizeN 1)  simonpj committed Jun 08, 1999 290 291 292  | otherwise = size_up e size_up (Let (NonRec binder rhs) body)  simonpj@microsoft.com committed Dec 14, 2009 293 294  = size_up rhs addSizeNSD size_up body addSizeN  simonpj committed Jun 22, 1999 295 296 297  (if isUnLiftedType (idType binder) then 0 else 1) -- For the allocation -- If the binder has an unlifted type there is no allocation  simonpj committed Jun 08, 1999 298 299  size_up (Let (Rec pairs) body)  simonpj@microsoft.com committed Dec 14, 2009 300 301 302  = foldr (addSizeNSD . size_up . snd) (size_up body addSizeN length pairs) -- (length pairs) for the allocation pairs  simonpj committed Jun 08, 1999 303   simonpj committed Sep 30, 2004 304  size_up (Case (Var v) _ _ alts)  simonpj committed Aug 01, 2000 305  | v elem top_args -- We are scrutinising an argument variable  simonpj@microsoft.com committed Dec 14, 2009 306  = alts_size (foldr1 addAltSize alt_sizes)  simonpj@microsoft.com committed Apr 03, 2009 307  (foldr1 maxSize alt_sizes)  simonpj committed Mar 23, 2000 308 309 310 311 312 313  -- Good to inline if an arg is scrutinised, because -- that may eliminate allocation in the caller -- And it eliminates the case itself where alt_sizes = map size_up_alt alts  simonpj committed Aug 01, 2000 314 315  -- alts_size tries to compute a good discount for -- the case when we are scrutinising an argument variable  simonpj@microsoft.com committed Dec 14, 2009 316 317 318  alts_size (SizeIs tot tot_disc tot_scrut) -- Size of all alternatives (SizeIs max _ _) -- Size of biggest alternative = SizeIs tot (unitBag (v, iBox (_ILIT(2) +# tot -# max)) unionBags tot_disc) tot_scrut  simonpj committed Mar 23, 2000 319  -- If the variable is known, we produce a discount that  simonpj@microsoft.com committed Apr 03, 2009 320  -- will take us back to 'max', the size of the largest alternative  simonpj committed Mar 23, 2000 321  -- The 1+ is a little discount for reduced allocation in the caller  simonpj@microsoft.com committed Apr 03, 2009 322 323 324 325  -- -- Notice though, that we return tot_disc, the total discount from -- all branches. I think that's right.  simonpj committed Mar 23, 2000 326 327  alts_size tot_size _ = tot_size  simonpj@microsoft.com committed Dec 14, 2009 328 329  size_up (Case e _ _ alts) = size_up e addSizeNSD foldr (addAltSize . size_up_alt) sizeZero alts  simonpj committed Mar 23, 2000 330 331 332 333 334  -- We don't charge for the case itself -- It's a strict thing, and the price of the call -- is paid by scrut. Also consider -- case f x of DEFAULT -> e -- This is just ';'! Don't charge for it.  simonpj@microsoft.com committed Dec 02, 2009 335 336  -- -- Moreover, we charge one per alternative.  simonpj committed Jun 08, 1999 337 338  ------------  simonpj@microsoft.com committed Apr 03, 2009 339 340 341  -- size_up_app is used when there's ONE OR MORE value args size_up_app (App fun arg) args | isTypeArg arg = size_up_app fun args  simonpj@microsoft.com committed Dec 14, 2009 342 343  | otherwise = size_up arg addSizeNSD size_up_app fun (arg:args)  simonpj@microsoft.com committed Oct 29, 2009 344  size_up_app (Var fun) args = size_up_call fun args  simonpj@microsoft.com committed Apr 03, 2009 345 346 347  size_up_app other args = size_up other addSizeN length args ------------  simonpj@microsoft.com committed Oct 29, 2009 348 349  size_up_call :: Id -> [CoreExpr] -> ExprSize size_up_call fun val_args  simonpj@microsoft.com committed Apr 03, 2009 350 351  = case idDetails fun of FCallId _ -> sizeN opt_UF_DearOp  simonpj@microsoft.com committed Oct 29, 2009 352 353 354 355  DataConWorkId dc -> conSize dc (length val_args) PrimOpId op -> primOpSize op (length val_args) ClassOpId _ -> classOpSize top_args val_args _ -> funSize top_args fun (length val_args)  simonpj committed Jun 08, 1999 356 357  ------------  simonpj@microsoft.com committed Nov 19, 2009 358  size_up_alt (_con, _bndrs, rhs) = size_up rhs addSizeN 1  simonpj committed Sep 07, 2000 359 360  -- Don't charge for args, so that wrappers look cheap -- (See comments about wrappers with Case)  simonpj@microsoft.com committed Nov 19, 2009 361 362 363 364  -- -- IMPORATANT: *do* charge 1 for the alternative, else we -- find that giant case nests are treated as practically free -- A good example is Foreign.C.Error.errrnoToIOError  simonpj committed Jun 08, 1999 365 366 367 368  ------------ -- These addSize things have to be here because -- I don't want to give them bOMB_OUT_SIZE as an argument  simonpj committed Oct 03, 2001 369 370  addSizeN TooBig _ = TooBig addSizeN (SizeIs n xs d) m = mkSizeIs bOMB_OUT_SIZE (n +# iUnbox m) xs d  simonpj committed Jun 08, 1999 371   simonpj@microsoft.com committed Dec 14, 2009 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387  -- addAltSize is used to add the sizes of case alternatives addAltSize TooBig _ = TooBig addAltSize _ TooBig = TooBig addAltSize (SizeIs n1 xs d1) (SizeIs n2 ys d2) = mkSizeIs bOMB_OUT_SIZE (n1 +# n2) (xs unionBags ys) (d1 +# d2) -- Note [addAltSize result discounts] -- This variant ignores the result discount from its LEFT argument -- It's used when the second argument isn't part of the result addSizeNSD TooBig _ = TooBig addSizeNSD _ TooBig = TooBig addSizeNSD (SizeIs n1 xs _) (SizeIs n2 ys d2) = mkSizeIs bOMB_OUT_SIZE (n1 +# n2) (xs unionBags ys) d2 -- Ignore d1  simonpj committed Jun 08, 1999 388 389 390 \end{code} \begin{code}  simonpj@microsoft.com committed Apr 03, 2009 391 392 393 394 395 396 397 398 399 400 401 -- | Finds a nominal size of a string literal. litSize :: Literal -> Int -- Used by CoreUnfold.sizeExpr litSize (MachStr str) = 1 + ((lengthFS str + 3) div 4) -- If size could be 0 then @f "x"@ might be too small -- [Sept03: make literal strings a bit bigger to avoid fruitless -- duplication of little strings] litSize _other = 0 -- Must match size of nullary constructors -- Key point: if x |-> 4, then x must inline unconditionally -- (eg via case binding)  simonpj@microsoft.com committed Oct 29, 2009 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 classOpSize :: [Id] -> [CoreExpr] -> ExprSize -- See Note [Conlike is interesting] classOpSize _ [] = sizeZero classOpSize top_args (arg1 : other_args) = SizeIs (iUnbox size) arg_discount (_ILIT(0)) where size = 2 + length other_args -- If the class op is scrutinising a lambda bound dictionary then -- give it a discount, to encourage the inlining of this function -- The actual discount is rather arbitrarily chosen arg_discount = case arg1 of Var dict | dict elem top_args -> unitBag (dict, opt_UF_DictDiscount) _other -> emptyBag  simonpj@microsoft.com committed Apr 03, 2009 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 funSize :: [Id] -> Id -> Int -> ExprSize -- Size for functions that are not constructors or primops -- Note [Function applications] funSize top_args fun n_val_args | fun hasKey buildIdKey = buildSize | fun hasKey augmentIdKey = augmentSize | otherwise = SizeIs (iUnbox size) arg_discount (iUnbox res_discount) where some_val_args = n_val_args > 0 arg_discount | some_val_args && fun elem top_args = unitBag (fun, opt_UF_FunAppDiscount) | otherwise = emptyBag -- If the function is an argument and is applied -- to some values, give it an arg-discount res_discount | idArity fun > n_val_args = opt_UF_FunAppDiscount | otherwise = 0 -- If the function is partially applied, show a result discount size | some_val_args = 1 + n_val_args | otherwise = 0 -- The 1+ is for the function itself -- Add 1 for each non-trivial arg; -- the allocation cost, as in let(rec) conSize :: DataCon -> Int -> ExprSize conSize dc n_val_args  simonpj@microsoft.com committed Nov 19, 2009 447  | n_val_args == 0 = SizeIs (_ILIT(0)) emptyBag (_ILIT(1)) -- Like variables  simonpj@microsoft.com committed Apr 03, 2009 448 449 450 451  | isUnboxedTupleCon dc = SizeIs (_ILIT(0)) emptyBag (iUnbox n_val_args +# _ILIT(1)) | otherwise = SizeIs (_ILIT(1)) emptyBag (iUnbox n_val_args +# _ILIT(1)) -- Treat a constructors application as size 1, regardless of how -- many arguments it has; we are keen to expose them  simonpj committed Mar 23, 2000 452  -- (and we charge separately for their args). We can't treat  simonpj@microsoft.com committed Apr 03, 2009 453  -- them as size zero, else we find that (Just x) has size 0,  simonpj committed Mar 23, 2000 454  -- which is the same as a lone variable; and hence 'v' will  simonpj@microsoft.com committed Apr 03, 2009 455  -- always be replaced by (Just x), where v is bound to Just x.  simonpj committed Sep 26, 2001 456 457 458 459 460  -- -- However, unboxed tuples count as size zero -- I found occasions where we had -- f x y z = case op# x y z of { s -> (# s, () #) } -- and f wasn't getting inlined  simonpj committed Mar 23, 2000 461   twanvl committed Jan 25, 2008 462 primOpSize :: PrimOp -> Int -> ExprSize  simonpj@microsoft.com committed Apr 03, 2009 463 primOpSize op n_val_args  simonpj committed Mar 23, 2000 464  | not (primOpIsDupable op) = sizeN opt_UF_DearOp  simonpj@microsoft.com committed Apr 03, 2009 465  | not (primOpOutOfLine op) = sizeN 1  simonpj committed Dec 07, 2000 466  -- Be very keen to inline simple primops.  simonpj committed Sep 26, 2001 467 468 469 470 471 472 473 474  -- We give a discount of 1 for each arg so that (op# x y z) costs 2. -- We can't make it cost 1, else we'll inline let v = (op# x y z) -- at every use of v, which is excessive. -- -- A good example is: -- let x = +# p q in C {x} -- Even though x get's an occurrence of 'many', its RHS looks cheap, -- and there's a good chance it'll get inlined back into C's RHS. Urgh!  simonpj@microsoft.com committed Apr 03, 2009 475 476 477  | otherwise = sizeN n_val_args  simonpj committed Jun 08, 1999 478   twanvl committed Jan 25, 2008 479 buildSize :: ExprSize  simonpj@microsoft.com committed Apr 03, 2009 480 buildSize = SizeIs (_ILIT(0)) emptyBag (_ILIT(4))  simonpj committed Jun 08, 1999 481 482 483 484  -- We really want to inline applications of build -- build t (\cn -> e) should cost only the cost of e (because build will be inlined later) -- Indeed, we should add a result_discount becuause build is -- very like a constructor. We don't bother to check that the  simonpj committed Jun 22, 1999 485  -- build is saturated (it usually is). The "-2" discounts for the \c n,  simonpj committed Jun 08, 1999 486  -- The "4" is rather arbitrary.  simonpj committed Jun 22, 1999 487   twanvl committed Jan 25, 2008 488 augmentSize :: ExprSize  simonpj@microsoft.com committed Apr 03, 2009 489 augmentSize = SizeIs (_ILIT(0)) emptyBag (_ILIT(4))  simonpj committed Jun 22, 1999 490 491  -- Ditto (augment t (\cn -> e) ys) should cost only the cost of -- e plus ys. The -2 accounts for the \cn  twanvl committed Jan 25, 2008 492   simonpj committed Mar 23, 2000 493 -- When we return a lambda, give a discount if it's used (applied)  twanvl committed Jan 25, 2008 494 lamScrutDiscount :: ExprSize -> ExprSize  simonpj@microsoft.com committed Apr 03, 2009 495 lamScrutDiscount (SizeIs n vs _) = SizeIs n vs (iUnbox opt_UF_FunAppDiscount)  twanvl committed Jan 25, 2008 496 lamScrutDiscount TooBig = TooBig  simonpj committed Jun 08, 1999 497 498 \end{code}  simonpj@microsoft.com committed Dec 14, 2009 499 500 501 502 503 504 505 506 507 Note [addAltSize result discounts] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ When adding the size of alternatives, we *add* the result discounts too, rather than take the *maximum*. For a multi-branch case, this gives a discount for each branch that returns a constructor, making us keener to inline. I did try using 'max' instead, but it makes nofib 'rewrite' and 'puzzle' allocate significantly more, and didn't make binary sizes shrink significantly either.  simonpj@microsoft.com committed Oct 29, 2009 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 Note [Discounts and thresholds] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Constants for discounts and thesholds are defined in main/StaticFlags, all of form opt_UF_xxxx. They are: opt_UF_CreationThreshold (45) At a definition site, if the unfolding is bigger than this, we may discard it altogether opt_UF_UseThreshold (6) At a call site, if the unfolding, less discounts, is smaller than this, then it's small enough inline opt_UF_KeennessFactor (1.5) Factor by which the discounts are multiplied before subtracting from size opt_UF_DictDiscount (1) The discount for each occurrence of a dictionary argument as an argument of a class method. Should be pretty small else big functions may get inlined opt_UF_FunAppDiscount (6) Discount for a function argument that is applied. Quite large, because if we inline we avoid the higher-order call. opt_UF_DearOp (4) The size of a foreign call or not-dupable PrimOp  simonpj committed Jun 08, 1999 537   simonpj@microsoft.com committed Apr 03, 2009 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 Note [Function applications] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In a function application (f a b) - If 'f' is an argument to the function being analysed, and there's at least one value arg, record a FunAppDiscount for f - If the application if a PAP (arity > 2 in this example) record a *result* discount (because inlining with "extra" args in the call may mean that we now get a saturated application) Code for manipulating sizes \begin{code} data ExprSize = TooBig | SizeIs FastInt -- Size found (Bag (Id,Int)) -- Arguments cased herein, and discount for each such FastInt -- Size to subtract if result is scrutinised -- by a case expression instance Outputable ExprSize where ppr TooBig = ptext (sLit "TooBig") ppr (SizeIs a _ c) = brackets (int (iBox a) <+> int (iBox c)) -- subtract the discount before deciding whether to bale out. eg. we -- want to inline a large constructor application into a selector: -- tup = (a_1, ..., a_99) -- x = case tup of ... -- mkSizeIs :: FastInt -> FastInt -> Bag (Id, Int) -> FastInt -> ExprSize mkSizeIs max n xs d | (n -# d) ># max = TooBig | otherwise = SizeIs n xs d maxSize :: ExprSize -> ExprSize -> ExprSize maxSize TooBig _ = TooBig maxSize _ TooBig = TooBig maxSize s1@(SizeIs n1 _ _) s2@(SizeIs n2 _ _) | n1 ># n2 = s1 | otherwise = s2  simonpj@microsoft.com committed Dec 02, 2009 578 sizeZero :: ExprSize  simonpj@microsoft.com committed Apr 03, 2009 579 580 581 582 583 584 585 sizeN :: Int -> ExprSize sizeZero = SizeIs (_ILIT(0)) emptyBag (_ILIT(0)) sizeN n = SizeIs (iUnbox n) emptyBag (_ILIT(0)) \end{code}  simonpj committed Jun 08, 1999 586 587 588 589 590 591 %************************************************************************ %* * \subsection[considerUnfolding]{Given all the info, do (not) do the unfolding} %* * %************************************************************************  simonpj@microsoft.com committed Oct 29, 2009 592 593 594 595 We use 'couldBeSmallEnoughToInline' to avoid exporting inlinings that we couldn't possibly use'' on the other side. Can be overridden w/ flaggery. Just the same as smallEnoughToInline, except that it has no actual arguments.  simonpj committed Jun 08, 1999 596 597  \begin{code}  simonpj committed Mar 23, 2000 598 couldBeSmallEnoughToInline :: Int -> CoreExpr -> Bool  simonpj@microsoft.com committed Oct 29, 2009 599 couldBeSmallEnoughToInline threshold rhs  simonpj@microsoft.com committed Dec 11, 2009 600  = case calcUnfoldingGuidance False False threshold rhs of  simonpj@microsoft.com committed Dec 02, 2009 601 602  (_, UnfNever) -> False _ -> True  simonmar committed Aug 12, 2005 603   simonpj@microsoft.com committed Oct 29, 2009 604 ----------------  simonmar committed Aug 12, 2005 605 smallEnoughToInline :: Unfolding -> Bool  simonpj@microsoft.com committed Dec 02, 2009 606 smallEnoughToInline (CoreUnfolding {uf_guidance = UnfIfGoodArgs {ug_size = size}})  simonmar committed Aug 12, 2005 607  = size <= opt_UF_UseThreshold  twanvl committed Jan 25, 2008 608 smallEnoughToInline _  simonmar committed Aug 12, 2005 609  = False  simonpj@microsoft.com committed Oct 29, 2009 610 611 612 613 614 615  ---------------- certainlyWillInline :: Unfolding -> Bool -- Sees if the unfolding is pretty certain to inline certainlyWillInline (CoreUnfolding { uf_is_cheap = is_cheap, uf_arity = n_vals, uf_guidance = guidance }) = case guidance of  simonpj@microsoft.com committed Dec 02, 2009 616 617 618  UnfNever -> False UnfWhen {} -> True UnfIfGoodArgs { ug_size = size}  simonpj@microsoft.com committed Oct 29, 2009 619 620 621 622  -> is_cheap && size - (n_vals +1) <= opt_UF_UseThreshold certainlyWillInline _ = False  simonpj committed Jun 08, 1999 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 \end{code} %************************************************************************ %* * \subsection{callSiteInline} %* * %************************************************************************ This is the key function. It decides whether to inline a variable at a call site callSiteInline is used at call sites, so it is a bit more generous. It's a very important function that embodies lots of heuristics. A non-WHNF can be inlined if it doesn't occur inside a lambda, and occurs exactly once or occurs once in each branch of a case and is small If the thing is in WHNF, there's no danger of duplicating work, so we can inline if it occurs once, or is small  simonpj committed Mar 23, 2000 642 NOTE: we don't want to inline top-level functions that always diverge.  Simon Marlow committed Feb 01, 2008 643 It just makes the code bigger. Tt turns out that the convenient way to prevent  simonpj committed Mar 23, 2000 644 645 646 them inlining is to give them a NOINLINE pragma, which we do in StrictAnal.addStrictnessInfoToTopId  simonpj committed Jun 08, 1999 647 \begin{code}  sewardj committed Oct 12, 2000 648 callSiteInline :: DynFlags  simonpj committed Jun 08, 1999 649  -> Id -- The Id  simonpj@microsoft.com committed Dec 02, 2009 650  -> Unfolding -- Its unfolding (if active)  simonpj@microsoft.com committed Dec 04, 2007 651  -> Bool -- True if there are are no arguments at all (incl type args)  simonpj@microsoft.com committed Apr 03, 2009 652  -> [ArgSummary] -- One for each value arg; True if it is interesting  simonpj@microsoft.com committed Feb 07, 2008 653  -> CallCtxt -- True <=> continuation is interesting  simonpj committed Jun 08, 1999 654 655 656  -> Maybe CoreExpr -- Unfolding, if any  simonpj@microsoft.com committed Apr 03, 2009 657 658 659 660 661 instance Outputable ArgSummary where ppr TrivArg = ptext (sLit "TrivArg") ppr NonTrivArg = ptext (sLit "NonTrivArg") ppr ValueArg = ptext (sLit "ValueArg")  simonpj@microsoft.com committed Feb 07, 2008 662 data CallCtxt = BoringCtxt  simonpj@microsoft.com committed Dec 04, 2007 663   simonpj@microsoft.com committed Nov 05, 2009 664 665 666 667 668 669 670  | ArgCtxt -- We are somewhere in the argument of a function Bool -- True <=> we're somewhere in the RHS of function with rules -- False <=> we *are* the argument of a function with non-zero -- arg discount -- OR -- we *are* the RHS of a let Note [RHS of lets] -- In both cases, be a little keener to inline  simonpj@microsoft.com committed Feb 07, 2008 671   simonpj@microsoft.com committed Oct 28, 2008 672 673 674 675  | ValAppCtxt -- We're applied to at least one value arg -- This arises when we have ((f x |> co) y) -- Then the (f x) has argument 'x' but in a ValAppCtxt  simonpj@microsoft.com committed Feb 07, 2008 676 677 678 679  | CaseCtxt -- We're the scrutinee of a case -- that decomposes its scrutinee instance Outputable CallCtxt where  simonpj@microsoft.com committed Nov 05, 2009 680 681 682 683  ppr BoringCtxt = ptext (sLit "BoringCtxt") ppr (ArgCtxt rules) = ptext (sLit "ArgCtxt") <+> ppr rules ppr CaseCtxt = ptext (sLit "CaseCtxt") ppr ValAppCtxt = ptext (sLit "ValAppCtxt")  simonpj@microsoft.com committed Dec 04, 2007 684   simonpj@microsoft.com committed Dec 02, 2009 685 686 callSiteInline dflags id unfolding lone_variable arg_infos cont_info = case unfolding of {  simonpj@microsoft.com committed Oct 29, 2009 687 688 689 690 691 692 693  NoUnfolding -> Nothing ; OtherCon _ -> Nothing ; DFunUnfolding {} -> Nothing ; -- Never unfold a DFun CoreUnfolding { uf_tmpl = unf_template, uf_is_top = is_top, uf_is_value = is_value, uf_is_cheap = is_cheap, uf_arity = uf_arity, uf_guidance = guidance } -> -- uf_arity will typically be equal to (idArity id), -- but may be less for InlineRules  simonpj committed Jun 08, 1999 694  let  simonpj@microsoft.com committed Dec 02, 2009 695 696  n_val_args = length arg_infos saturated = n_val_args >= uf_arity  simonpj@microsoft.com committed Nov 19, 2009 697   simonpj committed Jun 08, 1999 698 699 700  result | yes_or_no = Just unf_template | otherwise = Nothing  simonpj@microsoft.com committed Oct 29, 2009 701 702 703 704 705 706 707 708 709 710  interesting_args = any nonTriv arg_infos -- NB: (any nonTriv arg_infos) looks at the -- over-saturated args too which is "wrong"; -- but if over-saturated we inline anyway. -- some_benefit is used when the RHS is small enough -- and the call has enough (or too many) value -- arguments (ie n_val_args >= arity). But there must -- be *something* interesting about some argument, or the -- result context, to make it worth inlining  simonpj@microsoft.com committed Dec 02, 2009 711 712 713 714 715 716  some_benefit | not saturated = interesting_args -- Under-saturated -- Note [Unsaturated applications] | n_val_args > uf_arity = True -- Over-saturated | otherwise = interesting_args -- Saturated || interesting_saturated_call  simonpj@microsoft.com committed Oct 29, 2009 717 718 719 720 721 722 723 724  interesting_saturated_call = case cont_info of BoringCtxt -> not is_top && uf_arity > 0 -- Note [Nested functions] CaseCtxt -> not (lone_variable && is_value) -- Note [Lone variables] ArgCtxt {} -> uf_arity > 0 -- Note [Inlining in ArgCtxt] ValAppCtxt -> True -- Note [Cast then apply]  simonpj@microsoft.com committed Dec 02, 2009 725  (yes_or_no, extra_doc)  simonpj committed Jun 08, 1999 726  = case guidance of  simonpj@microsoft.com committed Dec 02, 2009 727 728 729 730 731 732  UnfNever -> (False, empty) UnfWhen unsat_ok boring_ok -> ( (unsat_ok || saturated) && (boring_ok || some_benefit) , empty ) -- For the boring_ok part see Note [INLINE for small functions]  simonpj@microsoft.com committed Oct 29, 2009 733   simonpj@microsoft.com committed Dec 02, 2009 734 735 736  UnfIfGoodArgs { ug_args = arg_discounts, ug_res = res_discount, ug_size = size } -> ( is_cheap && some_benefit && small_enough , (text "discounted size =" <+> int discounted_size) )  simonpj@microsoft.com committed Oct 29, 2009 737  where  simonpj@microsoft.com committed Dec 02, 2009 738 739  discounted_size = size - discount small_enough = discounted_size <= opt_UF_UseThreshold  simonpj@microsoft.com committed Oct 29, 2009 740 741  discount = computeDiscount uf_arity arg_discounts res_discount arg_infos cont_info  simonpj committed Nov 01, 1999 742   simonpj committed Jun 08, 1999 743  in  simonmar committed Oct 17, 2000 744  if dopt Opt_D_dump_inlinings dflags then  simonpj@microsoft.com committed Jan 13, 2009 745  pprTrace ("Considering inlining: " ++ showSDoc (ppr id))  simonpj@microsoft.com committed Dec 02, 2009 746 747  (vcat [text "arg infos" <+> ppr arg_infos, text "uf arity" <+> ppr uf_arity,  simonpj@microsoft.com committed Jan 13, 2009 748  text "interesting continuation" <+> ppr cont_info,  simonpj@microsoft.com committed Dec 02, 2009 749  text "some_benefit" <+> ppr some_benefit,  simonpj@microsoft.com committed Jan 13, 2009 750  text "is value:" <+> ppr is_value,  simonpj@microsoft.com committed Mar 18, 2009 751  text "is cheap:" <+> ppr is_cheap,  simonpj@microsoft.com committed Jan 13, 2009 752  text "guidance" <+> ppr guidance,  simonpj@microsoft.com committed Dec 02, 2009 753  extra_doc,  simonpj@microsoft.com committed Jan 13, 2009 754  text "ANSWER =" <+> if yes_or_no then text "YES" else text "NO"])  simonpj committed Jun 08, 1999 755 756 757 758  result else result }  simonpj@microsoft.com committed Dec 04, 2007 759 760 \end{code}  simonpj@microsoft.com committed Nov 05, 2009 761 762 763 764 765 766 767 768 769 Note [RHS of lets] ~~~~~~~~~~~~~~~~~~ Be a tiny bit keener to inline in the RHS of a let, because that might lead to good thing later f y = (y,y,y) g y = let x = f y in ...(case x of (a,b,c) -> ...) ... We'd inline 'f' if the call was in a case context, and it kind-of-is, only we can't see it. So we treat the RHS of a let as not-totally-boring.  simonpj@microsoft.com committed Oct 29, 2009 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 Note [Unsaturated applications] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ When a call is not saturated, we *still* inline if one of the arguments has interesting structure. That's sometimes very important. A good example is the Ord instance for Bool in Base: Rec { $fOrdBool =GHC.Classes.D:Ord @ Bool ...$cmin_ajX $cmin_ajX [Occ=LoopBreaker] :: Bool -> Bool -> Bool$cmin_ajX = GHC.Classes.$dmmin @ Bool$fOrdBool } But the defn of GHC.Classes.$dmmin is:$dmmin :: forall a. GHC.Classes.Ord a => a -> a -> a {- Arity: 3, HasNoCafRefs, Strictness: SLL, Unfolding: (\ @ a $dOrd :: GHC.Classes.Ord a x :: a y :: a -> case @ a GHC.Classes.<= @ a$dOrd x y of wild { GHC.Bool.False -> y GHC.Bool.True -> x }) -} We *really* want to inline $dmmin, even though it has arity 3, in order to unravel the recursion. Note [INLINE for small functions] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Consider {-# INLINE f #-} f x = Just x g y = f y Then f's RHS is no larger than its LHS, so we should inline it into even the most boring context. (We do so if there is no INLINE  simonpj@microsoft.com committed Dec 02, 2009 805 pragma!)  simonpj@microsoft.com committed Oct 29, 2009 806 807   simonpj@microsoft.com committed Apr 03, 2009 808 809 810 811 812 813 814 815 816 817 818 Note [Things to watch] ~~~~~~~~~~~~~~~~~~~~~~ * { y = I# 3; x = y cast co; ...case (x cast co) of ... } Assume x is exported, so not inlined unconditionally. Then we want x to inline unconditionally; no reason for it not to, and doing so avoids an indirection. * { x = I# 3; ....f x.... } Make sure that x does not inline unconditionally! Lest we get extra allocation.  simonpj@microsoft.com committed Oct 29, 2009 819 820 821 Note [Inlining an InlineRule] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ An InlineRules is used for  simonpj@microsoft.com committed Dec 02, 2009 822  (a) programmer INLINE pragmas  simonpj@microsoft.com committed Oct 29, 2009 823 824 825 826 827 828 829 830 831 832 833  (b) inlinings from worker/wrapper For (a) the RHS may be large, and our contract is that we *only* inline when the function is applied to all the arguments on the LHS of the source-code defn. (The uf_arity in the rule.) However for worker/wrapper it may be worth inlining even if the arity is not satisfied (as we do in the CoreUnfolding case) so we don't require saturation.  simonpj@microsoft.com committed Dec 04, 2007 834 835 836 837 838 839 840 841 842 843 844 845 Note [Nested functions] ~~~~~~~~~~~~~~~~~~~~~~~ If a function has a nested defn we also record some-benefit, on the grounds that we are often able to eliminate the binding, and hence the allocation, for the function altogether; this is good for join points. But this only makes sense for *functions*; inlining a constructor doesn't help allocation unless the result is scrutinised. UNLESS the constructor occurs just once, albeit possibly in multiple case branches. Then inlining it doesn't increase allocation, but it does increase the chance that the constructor won't be allocated at all in the branches that don't use it.  simonpj@microsoft.com committed Oct 28, 2008 846 847 848 849 850 851 852 853 854 855 Note [Cast then apply] ~~~~~~~~~~~~~~~~~~~~~~ Consider myIndex = __inline_me ( (/\a. ) |> co ) co :: (forall a. a -> a) ~ (forall a. T a) ... /\a.\x. case ((myIndex a) |> sym co) x of { ... } ... We need to inline myIndex to unravel this; but the actual call (myIndex a) has no value arguments. The ValAppCtxt gives it enough incentive to inline.  856 857 Note [Inlining in ArgCtxt] ~~~~~~~~~~~~~~~~~~~~~~~~~~  simonpj@microsoft.com committed Oct 29, 2009 858 The condition (arity > 0) here is very important, because otherwise  859 860 861 862 863 864 865 866 867 868 we end up inlining top-level stuff into useless places; eg x = I# 3# f = \y. g x This can make a very big difference: it adds 16% to nofib 'integer' allocs, and 20% to 'power'. At one stage I replaced this condition by 'True' (leading to the above slow-down). The motivation was test eyeball/inline1.hs; but that seems to work ok now.  simonpj@microsoft.com committed Nov 05, 2009 869 870 871 872 873 NOTE: arguably, we should inline in ArgCtxt only if the result of the call is at least CONLIKE. At least for the cases where we use ArgCtxt for the RHS of a 'let', we only profit from the inlining if we get a CONLIKE thing (modulo lets).  simonpj@microsoft.com committed Dec 04, 2007 874 Note [Lone variables]  simonpj@microsoft.com committed Jan 02, 2009 875 ~~~~~~~~~~~~~~~~~~~~~  simonpj@microsoft.com committed Dec 04, 2007 876 877 878 The "lone-variable" case is important. I spent ages messing about with unsatisfactory varaints, but this is nice. The idea is that if a variable appears all alone  simonpj@microsoft.com committed Oct 29, 2009 879 880 881 882  as an arg of lazy fn, or rhs BoringCtxt as scrutinee of a case CaseCtxt as arg of a fn ArgCtxt  simonpj@microsoft.com committed Dec 04, 2007 883 884 AND it is bound to a value  simonpj@microsoft.com committed Oct 29, 2009 885   simonpj@microsoft.com committed Dec 04, 2007 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 then we should not inline it (unless there is some other reason, e.g. is is the sole occurrence). That is what is happening at the use of 'lone_variable' in 'interesting_saturated_call'. Why? At least in the case-scrutinee situation, turning let x = (a,b) in case x of y -> ... into let x = (a,b) in case (a,b) of y -> ... and thence to let x = (a,b) in let y = (a,b) in ... is bad if the binding for x will remain. Another example: I discovered that strings were getting inlined straight back into applications of 'error' because the latter is strict. s = "foo" f = \x -> ...(error s)... Fundamentally such contexts should not encourage inlining because the context can see'' the unfolding of the variable (e.g. case or a RULE) so there's no gain. If the thing is bound to a value. However, watch out: * Consider this: foo = _inline_ (\n. [n]) bar = _inline_ (foo 20) baz = \n. case bar of { (m:_) -> m + n } Here we really want to inline 'bar' so that we can inline 'foo' and the whole thing unravels as it should obviously do. This is important: in the NDP project, 'bar' generates a closure data structure rather than a list.  simonpj@microsoft.com committed Oct 29, 2009 919 920 921 922 923  So the non-inlining of lone_variables should only apply if the unfolding is regarded as cheap; because that is when exprIsConApp_maybe looks through the unfolding. Hence the "&& is_cheap" in the InlineRule branch.  simonpj@microsoft.com committed Dec 04, 2007 924 925 926 927 928 929 930 931 932 933 934  * Even a type application or coercion isn't a lone variable. Consider case$fMonadST @ RealWorld of { :DMonad a b c -> c } We had better inline that sucker! The case won't see through it. For now, I'm treating treating a variable applied to types in a *lazy* context "lone". The motivating example was f = /\a. \x. BIG g = /\a. \y. h (f a) There's no advantage in inlining f here, and perhaps a significant disadvantage. Hence some_val_args in the Stop case  simonpj committed Jun 08, 1999 935   simonpj@microsoft.com committed Dec 04, 2007 936 \begin{code}  simonpj@microsoft.com committed Apr 03, 2009 937 938 computeDiscount :: Int -> [Int] -> Int -> [ArgSummary] -> CallCtxt -> Int computeDiscount n_vals_wanted arg_discounts res_discount arg_infos cont_info  simonpj committed Jun 08, 1999 939 940  -- We multiple the raw discounts (args_discount and result_discount) -- ty opt_UnfoldingKeenessFactor because the former have to do with  simonmar committed Mar 31, 2005 941 942  -- *size* whereas the discounts imply that there's some extra -- *efficiency* to be gained (e.g. beta reductions, case reductions)  simonpj committed Jun 08, 1999 943 944  -- by inlining.  simonpj@microsoft.com committed Apr 03, 2009 945 946 947 948 949 950 951 952 953  = 1 -- Discount of 1 because the result replaces the call -- so we count 1 for the function itself + length (take n_vals_wanted arg_infos) -- Discount of (un-scaled) 1 for each arg supplied, -- because the result replaces the call + round (opt_UF_KeenessFactor * fromIntegral (arg_discount + res_discount'))  simonpj committed Jun 08, 1999 954 955 956  where arg_discount = sum (zipWith mk_arg_discount arg_discounts arg_infos)  simonpj@microsoft.com committed Apr 03, 2009 957 958 959 960 961 962 963 964 965  mk_arg_discount _ TrivArg = 0 mk_arg_discount _ NonTrivArg = 1 mk_arg_discount discount ValueArg = discount res_discount' = case cont_info of BoringCtxt -> 0 CaseCtxt -> res_discount _other -> 4 min res_discount -- res_discount can be very large when a function returns  simonpj@microsoft.com committed Nov 05, 2009 966  -- constructors; but we only want to invoke that large discount  simonpj@microsoft.com committed Apr 03, 2009 967 968 969 970  -- when there's a case continuation. -- Otherwise we, rather arbitrarily, threshold it. Yuk. -- But we want to aovid inlining large functions that return -- constructors into contexts that are simply "interesting"  simonpj committed Jun 08, 1999 971 \end{code}  simonpj@microsoft.com committed Sep 10, 2008 972   simonpj@microsoft.com committed Apr 03, 2009 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 %************************************************************************ %* * Interesting arguments %* * %************************************************************************ Note [Interesting arguments] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ An argument is interesting if it deserves a discount for unfoldings with a discount in that argument position. The idea is to avoid unfolding a function that is applied only to variables that have no unfolding (i.e. they are probably lambda bound): f x y z There is little point in inlining f here. Generally, *values* (like (C a b) and (\x.e)) deserve discounts. But we must look through lets, eg (let x = e in C a b), because the let will float, exposing the value, if we inline. That makes it different to exprIsHNF. Before 2009 we said it was interesting if the argument had *any* structure at all; i.e. (hasSomeUnfolding v). But does too much inlining; see Trac #3016. But we don't regard (f x y) as interesting, unless f is unsaturated. If it's saturated and f hasn't inlined, then it's probably not going to now!  simonpj@microsoft.com committed Oct 29, 2009 999 1000 1001 1002 1003 Note [Conlike is interesting] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Consider f d = ...((*) d x y)... ... f (df d')...  1004 where df is con-like. Then we'd really like to inline 'f' so that the  simonpj@microsoft.com committed Oct 29, 2009 1005 1006 1007 1008 rule for (*) (df d) can fire. To do this a) we give a discount for being an argument of a class-op (eg (*) d) b) we say that a con-like argument (eg (df d)) is interesting  simonpj@microsoft.com committed Apr 03, 2009 1009 1010 1011 1012 \begin{code} data ArgSummary = TrivArg -- Nothing interesting | NonTrivArg -- Arg has structure | ValueArg -- Arg is a con-app or PAP  simonpj@microsoft.com committed Oct 29, 2009 1013  -- ..or con-like. Note [Conlike is interesting]  simonpj@microsoft.com committed Apr 03, 2009 1014 1015 1016 1017 1018 1019 1020 1021  interestingArg :: CoreExpr -> ArgSummary -- See Note [Interesting arguments] interestingArg e = go e 0 where -- n is # value args to which the expression is applied go (Lit {}) _ = ValueArg go (Var v) n  simonpj@microsoft.com committed Oct 29, 2009 1022 1023  | isConLikeId v = ValueArg -- Experimenting with 'conlike' rather that -- data constructors here  simonpj@microsoft.com committed Apr 03, 2009 1024 1025  | idArity v > n = ValueArg -- Catches (eg) primops with arity but no unfolding | n > 0 = NonTrivArg -- Saturated or unknown call  rl@cse.unsw.edu.au committed Nov 04, 2009 1026  | conlike_unfolding = ValueArg -- n==0; look for an interesting unfolding  1027  -- See Note [Conlike is interesting]  simonpj@microsoft.com committed Apr 03, 2009 1028 1029  | otherwise = TrivArg -- n==0, no useful unfolding where  rl@cse.unsw.edu.au committed Nov 04, 2009 1030  conlike_unfolding = isConLikeUnfolding (idUnfolding v)  simonpj@microsoft.com committed Apr 03, 2009 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048  go (Type _) _ = TrivArg go (App fn (Type _)) n = go fn n go (App fn _) n = go fn (n+1) go (Note _ a) n = go a n go (Cast e _) n = go e n go (Lam v e) n | isTyVar v = go e n | n>0 = go e (n-1) | otherwise = ValueArg go (Let _ e) n = case go e n of { ValueArg -> ValueArg; _ -> NonTrivArg } go (Case {}) _ = NonTrivArg nonTriv :: ArgSummary -> Bool nonTriv TrivArg = False nonTriv _ = True \end{code}  Simon Marlow committed Dec 16, 2008 1049 1050 %************************************************************************ %* *  simonpj@microsoft.com committed Oct 29, 2009 1051  exprIsConApp_maybe  Simon Marlow committed Dec 16, 2008 1052 1053 1054 %* * %************************************************************************  simonpj@microsoft.com committed Oct 29, 2009 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 Note [exprIsConApp_maybe] ~~~~~~~~~~~~~~~~~~~~~~~~~ exprIsConApp_maybe is a very important function. There are two principal uses: * case e of { .... } * cls_op e, where cls_op is a class operation In both cases you want to know if e is of form (C e1..en) where C is a data constructor. However e might not *look* as if  Simon Marlow committed Dec 16, 2008 1066 1067  \begin{code}  simonpj@microsoft.com committed Oct 29, 2009 1068 1069 1070 -- | Returns @Just (dc, [t1..tk], [x1..xn])@ if the argument expression is -- a *saturated* constructor application of the form @dc t1..tk x1 .. xn@, -- where t1..tk are the *universally-qantified* type args of 'dc'  simonpj@microsoft.com committed Dec 02, 2009 1071 exprIsConApp_maybe :: IdUnfoldingFun -> CoreExpr -> Maybe (DataCon, [Type], [CoreExpr])  simonpj@microsoft.com committed Oct 29, 2009 1072   simonpj@microsoft.com committed Dec 02, 2009 1073 1074 exprIsConApp_maybe id_unf (Note _ expr) = exprIsConApp_maybe id_unf expr  simonpj@microsoft.com committed Oct 29, 2009 1075 1076 1077 1078 1079 1080  -- We ignore all notes. For example, -- case _scc_ "foo" (C a b) of -- C a b -> e -- should be optimised away, but it will be only if we look -- through the SCC note.  simonpj@microsoft.com committed Dec 02, 2009 1081 exprIsConApp_maybe id_unf (Cast expr co)  simonpj@microsoft.com committed Oct 29, 2009 1082 1083 1084 1085 1086 1087 1088  = -- Here we do the KPush reduction rule as described in the FC paper -- The transformation applies iff we have -- (C e1 ... en) cast co -- where co :: (T t1 .. tn) ~ to_ty -- The left-hand one must be a T, because exprIsConApp returned True -- but the right-hand one might not be. (Though it usually will.)  simonpj@microsoft.com committed Dec 02, 2009 1089  case exprIsConApp_maybe id_unf expr of {  simonpj@microsoft.com committed Oct 29, 2009 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140  Nothing -> Nothing ; Just (dc, _dc_univ_args, dc_args) -> let (_from_ty, to_ty) = coercionKind co dc_tc = dataConTyCon dc in case splitTyConApp_maybe to_ty of { Nothing -> Nothing ; Just (to_tc, to_tc_arg_tys) | dc_tc /= to_tc -> Nothing -- These two Nothing cases are possible; we might see -- (C x y) cast (g :: T a ~ S [a]), -- where S is a type function. In fact, exprIsConApp -- will probably not be called in such circumstances, -- but there't nothing wrong with it | otherwise -> let tc_arity = tyConArity dc_tc dc_univ_tyvars = dataConUnivTyVars dc dc_ex_tyvars = dataConExTyVars dc arg_tys = dataConRepArgTys dc dc_eqs :: [(Type,Type)] -- All equalities from the DataCon dc_eqs = [(mkTyVarTy tv, ty) | (tv,ty) <- dataConEqSpec dc] ++ [getEqPredTys eq_pred | eq_pred <- dataConEqTheta dc] (ex_args, rest1) = splitAtList dc_ex_tyvars dc_args (co_args, val_args) = splitAtList dc_eqs rest1 -- Make the "theta" from Fig 3 of the paper gammas = decomposeCo tc_arity co theta = zipOpenTvSubst (dc_univ_tyvars ++ dc_ex_tyvars) (gammas ++ stripTypeArgs ex_args) -- Cast the existential coercion arguments cast_co (ty1, ty2) (Type co) = Type $mkSymCoercion (substTy theta ty1) mkTransCoercion co mkTransCoercion (substTy theta ty2) cast_co _ other_arg = pprPanic "cast_co" (ppr other_arg) new_co_args = zipWith cast_co dc_eqs co_args -- Cast the value arguments (which include dictionaries) new_val_args = zipWith cast_arg arg_tys val_args cast_arg arg_ty arg = mkCoerce (substTy theta arg_ty) arg in #ifdef DEBUG let dump_doc = vcat [ppr dc, ppr dc_univ_tyvars, ppr dc_ex_tyvars, ppr arg_tys, ppr dc_args, ppr _dc_univ_args, ppr ex_args, ppr val_args]  simonpj@microsoft.com committed Oct 30, 2009 1141 1142  in ASSERT2( coreEqType _from_ty (mkTyConApp dc_tc _dc_univ_args), dump_doc )  simonpj@microsoft.com committed Oct 29, 2009 1143 1144 1145 1146 1147 1148 1149  ASSERT2( all isTypeArg (ex_args ++ co_args), dump_doc ) ASSERT2( equalLength val_args arg_tys, dump_doc ) #endif Just (dc, to_tc_arg_tys, ex_args ++ new_co_args ++ new_val_args) }}  simonpj@microsoft.com committed Dec 02, 2009 1150 exprIsConApp_maybe id_unf expr  simonpj@microsoft.com committed Oct 29, 2009 1151  = analyse expr []  Simon Marlow committed Dec 16, 2008 1152  where  simonpj@microsoft.com committed Oct 29, 2009 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176  analyse (App fun arg) args = analyse fun (arg:args) analyse fun@(Lam {}) args = beta fun [] args analyse (Var fun) args | Just con <- isDataConWorkId_maybe fun , is_saturated , let (univ_ty_args, rest_args) = splitAtList (dataConUnivTyVars con) args = Just (con, stripTypeArgs univ_ty_args, rest_args) -- Look through dictionary functions; see Note [Unfolding DFuns] | DFunUnfolding con ops <- unfolding , is_saturated , let (dfun_tvs, _cls, dfun_res_tys) = tcSplitDFunTy (idType fun) subst = zipOpenTvSubst dfun_tvs (stripTypeArgs (takeList dfun_tvs args)) = Just (con, substTys subst dfun_res_tys, [mkApps op args | op <- ops]) -- Look through unfoldings, but only cheap ones, because -- we are effectively duplicating the unfolding | CoreUnfolding { uf_expandable = expand_me, uf_tmpl = rhs } <- unfolding , expand_me = -- pprTrace "expanding" (ppr fun$$ppr rhs)$ analyse rhs args where is_saturated = count isValArg args == idArity fun  simonpj@microsoft.com committed Dec 02, 2009 1177  unfolding = id_unf fun -- Does not look through loop breakers  simonpj@microsoft.com committed Nov 19, 2009 1178 1179  -- ToDo: we *may* look through variables that are NOINLINE -- in this phase, and that is really not right  simonpj@microsoft.com committed Oct 29, 2009 1180 1181 1182  analyse _ _ = Nothing  simonpj@microsoft.com committed Oct 30, 2009 1183 1184 1185  ----------- in_scope = mkInScopeSet (exprFreeVars expr)  simonpj@microsoft.com committed Oct 29, 2009 1186 1187 1188 1189 1190 1191 1192 1193 1194  ----------- beta (Lam v body) pairs (arg : args) | isTypeArg arg = beta body ((v,arg):pairs) args beta (Lam {}) _ _ -- Un-saturated, or not a type lambda = Nothing beta fun pairs args  simonpj@microsoft.com committed Oct 30, 2009 1195  = case analyse (substExpr subst fun) args of  simonpj@microsoft.com committed Oct 29, 2009 1196 1197 1198 1199 1200  Nothing -> -- pprTrace "Bale out! exprIsConApp_maybe" doc $Nothing Just ans -> -- pprTrace "Woo-hoo! exprIsConApp_maybe" doc$ Just ans where  simonpj@microsoft.com committed Oct 30, 2009 1201  subst = mkOpenSubst in_scope pairs  simonpj@microsoft.com committed Oct 29, 2009 1202 1203 1204 1205 1206


text:
## Trigonometry 7th Edition

Published by Cengage Learning

# Chapter 1 - Section 1.4 - Introduction to Identities - 1.4 Problem Set - Page 41: 59

#### Answer

$m$ (slope) = $3$

#### Work Step by Step

The slope can be calculated with the formula $m = (y_2 - y_1)/(x_2 - x_1)$. Our points are $(0,0)$ and $(1,3)$, $p_1$ and $p_2$ respectively. Subbing in our given values leaves $m = (3 - 0)/(1 -0)$, which gives us $m = 3$.

After you claim an answer you’ll have 24 hours to send in a draft. An editor will review the submission and either publish your submission or provide feedback.