I understand that the order in which transformations are performed can sometimes yield different results, and sometimes yield the same result. Your answer raises the very question I still have: "Why do these two different transformations transform f into the same function?"
Rhonda replied with a question like the previous one: Thank you! So the real question is, why do these two different transformations transform f into the same function? The point (1, 1), which is on the original graph, is mapped to different points by the two transformations, but both are on the graph of the same transformed function. They are two different transformations that transform this particular graph into the same graph. I replied, initially just pointing this out: These are not the same transformation. Second, vertical stretch (purple) followed by shift (blue):īoth transformations have the same effect on the graph, but different effects on an individual point. First, horizontal compression (purple) followed by shift (blue): Here are the graphs and the points referred to, showing how the point (1, 1) transforms. These are the same function, but obtained by two different transformations. Here we are combining a compression and a shift (using the format I recommended last time), then expanding into a form that pulls the 3 outside and squares it, changing the horizontal compression to a vertical stretch. Why? Why does basically the same transformation yield different image points for the same preimage? This gives the exact same graph, but now (1, 1) goes to image (-3, 9). The preimage point is (1, 1), and the image is (-3 2/3, 1).Īpplying a vertical stretch of 9 and a shift left 4 units yields y = 9(x + 4)^2. When I change from a horizontal compression to a corresponding vertical stretch, why does the image point change?Īpplying a horizontal compression of 1/3 and a shift left by 4 units yields y = ^2. This led to a different perspective on the issue in a 2014 question: Shifting Images Squaring: are they really different transformations?Īnother function with a similar property is the square. Functions that lack this, or a similar property, will not have this ambiguity. What will he do when he is given a graph and asked to determine the function? Jon has been given two functions to graph, and astutely observed that the results of a vertical stretch and a horizontal compression look essentially alike.
#VERTICAL STRETCH HOW TO#
Ultimately, I would like to know how to tell the difference by merely looking at a graph. However, my textbook makes a distinction for both cases. I'm confused because they both graphically look like they are being horizontally compressed or vertically stretched. How can we tell by looking at a graph if a square root function is being horizontally compressed or vertically stretched?įor example, y = 2 sqrt(x) is being vertically stretched when graphed, but y = sqrt(2x) is being horizontally compressed. We’ll first look at this question from 2009: Square Root Functions and Transformations
This can make it hard to decide what to call it or it can actually make things easier, by letting us choose the easier of two ways. The next thing to look at will be how to determine the transformations when you are given a graph but before we take that challenge in general, we need to see how transformations can interact with particular base functions, resulting in graphs that can be attained in more than one way. Or you could adjust your TextBox to reflect the padding of your Label's by targeting TextBlock with attached properties like TextBlock.LineHeight and TextBlock.LineStackingStrategy="BlockLineHeight" which would take some tinkering to get the exact output you want.The last two posts were about transformations of functions (shift, stretch, reflect) and their effect on a graph, first individually and then in combination. Or swap them for good old TextBlock (which by the way is a "lighter" control and suggested instead unless using Label is actually necessary). So if you you want them to align in your scenario you've got some options such as Whereas Label is a templated control inheriting from ContentControl and has a Padding set by default within it.
The issue this causes is that TextBox renders lines as TextBlock which is a framework element. The immediate reason for your current issue is because you're using Label instead of TextBlock Setting a fixed height for the TextBox corrects the behaviour, but that's not really a good way to solve the problem. I tried setting the LineHeigt, but it only "cuts off" the text: My goal is a TextBox that accepts return but only shows 4 lines of text that is alligned to other lines of text, but I'm having some problems that basically seem to boil down to the question: What is the correct way to get the content of a TextBox to vertically stretch to the available space?
0 kommentar(er)
