text:
If you are familiar with C++, value semantics really should be second nature for you (or at least I hope so). If you are however mainly programming in C#, you may never even have thought about value semantics. Which is a pity. In this post, I’d like to first give a brief overview of value semantics and its implementation in C# and then discuss some guidelines that I have on when to use value semantics in C#. If you want to try any of the examples for yourself, you could use try.dot.net (to run them) or SharpLab (to see what it compiles to).

# Value Semantics in a Nutshell

int x = 5;
int y = x;
x++;

What is the value of y after the last line? Well, obviously it is still 5, whereas x is now 6. This is very different from

List<int> x = new List<int> { 1, 2, 3 };
List<int> y = x;

After the execution of the last line, y will also evaluate to the list 1, 2, 3, 4. In the first example, changing the original variable, x, does not change y, but in the second it seemingly does. This difference is inherently because int (as all the other basic types except for string) has value semantics, whereas almost all other types in C# have reference semantics.

Essentially, the only difference is that variables of a value type hold a value by itself, whereas variables of a reference type hold a reference to a value that lives somewhere else, independently of any references to it. Thus reference types have a notion of identity beyond equality: Two lists can hold the same values, but still be different. Whether to objects of value type are equal only depends on their values.

In C#, the issue of value semantics for types is deeply confounded with its implementation of these semantics – it is just very hard to discuss value semantics in the abstract and still get any mileage from the discussion, hence all of the following blurs this distinction between semantics and implementation. For example, the identity of a reference type object is basically its address in memory – other implementations are conceivable, but I want to talk about C# and its usual implementation specifically.

# The implementation of value semantics

Whenever I try to see what a feature in a language really does, I ask myself how to compile it myself. In fact, I object to the very notion of using features that you could not at least in principle compile manually1. Only if you know what is really happening will you be able to get a feeling for what implications using a particular feature has, both for performance and the meaning of the code you write. With value semantics, you pretty much need this mindset.

Let us take a closer look at what the lines

int x = 5;
int y = x;

actually mean. Whenever you declare a variable in a C# function (as with int x;) you are essentially saying:

Dear compiler, please reserve enough space to hold an int (i.e., a storage location for 4 bytes) right here, local to the current function.2

This means that when you then write int y; you would rightfully expect to get a different 4 byte storage location for an int. The line int y = x; now says:

Copy whatever is in the 4 bytes of the storage location denoted by x to the storage location denoted by y.

In C#, it is not wrong to think of the innocent looking = as a copy-instruction. In a picture:

Similarly then, x++ simply increases the value stored in x by one, which of course does not change y in any way. You could do the same thing with, say, long instead of int and get the same behavior (with the difference that you are now talking about 8 byte storage locations).

How is this different from the second case with Lists? Well, it is not actually all that different! A declaration like List<int> x; does not do more than ask the compiler to reserve enough space for a List<int> variable locally. The problem with this naive thinking is that for the way C# (and all another languages I am aware of) work, you need to know exactly how much local storage will be required by any function before calling it – but a list can grow without bounds3, so how could the compiler figure out how much local storage space the function will need?

It is here where references help: The declaration List<int> x; does not actually reserve local storage for a list, but only for a reference to a list. A reference can be thought of as the address of a point in memory where an object lives. This is not quite the full-story for C#, but good enough4. Luckily, such references have a fixed size (usually either 4 or 8 bytes, depending on the machine). So List<int> x; does not reserve storage space for the value of a list, but for a reference to it: Hence the term reference semantics. An assignment such as List<int> y = x; then does just the same as int y = x; – it copies the contents of the storage location denoted by x to the storage location denoted by y. The only difference is that in this case, the content that is being copied is a reference. In a picture:

In short:

• if a type T has value semantics then a declaration T t; reserves a storage location to store an actual value of type T,
• if a type T has reference semantics then a declaration T t; reserves a storage location to store a reference to a value of type T that lives somewhere else in memory.

## The ref keyword in C#

Now that we have cleared up what value and reference semantics are, we should also briefly talk about the ref keyword in C#, especially so because it will get more and more common with the recent C# 7. The notion of reference as embodied by ref pretty much exactly what you would expect from C++, in case you are familiar with it.

### ref parameters

ref parameters allow to pass a reference (in the precise sense defined above) to any storage location. For example:

void Increment(int y) {
y++;
}

void IncrementRef(ref int y) {
y++;
}

void Test() {
int x = 5;
Increment(x);
// x still has value 5
IncrementRef(ref x);
// x has value 6 now
}

Here, Increment receives a copy of the value stored in x and increments it (only to discard the copy when it returns). IncrementRef on the other hand receives a reference to the storage location x from Test and can act on it, which means that it can change the value in x.

### ref return values and locals

Since C# 7, ref can also be used on return values to return a reference to a storage location. As I have briefly mentioned earlier, local storage locations vanish completely once the function they are local to returns. As such, it does not make sense to return a reference to such a local storage location – it will be invalid by the time the function returns!

ref int GetValue() {
return 5; // invalid! 5 is a value, not a storage location!
}

There are of course plenty of use-cases for ref-returns. One that immediately springs to mind is that of looking for a value in an array with the intention of modifying it. Usually, you would return the index of the value in the array to modifiy it. For example, take this piece of code that makes the first odd number in an array even:

int IndexOfFirstOdd(int[] values) {
for (int i = 0; i < values.Length; i++) {
if (values[i] % 2 == 1) {
return i;
}
}
return -1;
}

void MakeFirstEven(int[] values) {
int oddIndex = IndexOfFirstOdd(values);
if (oddIndex >= 0)
values[oddIndex] *= 2;
}

Instead of returning an index we could also return a reference to the value in the array:

ref int IndexOfFirstOdd(int[] values) {
for (int i = 0; i < values.Length; i++) {
if (values[i] % 2 == 1) {
return ref values[i];
}
}
// assuming values.Length >= 1
return ref values[0];
}

void MakeFirstEven(int[] values) {
// note the ref on both sides
ref int oddNumber = ref IndexOfFirstOdd(values);
if (oddNumber % 2 == 1) {
// this actually changes the value in the array!
oddNumber *= 2;
}
}

Admittedly, this quite a contrived example, especially since we don’t know whether the array even contains an odd number, forcing us to return a default value if none is found (which then forces us to again check whether the value we get by reference is actually odd). What this example should show is that oddNumber in MakeFirstEven is a reference to the storage location within the array, or simply an alias for it.

In short, the ref keyword allows us to create and pass around references to storage locations, such that a value type can be used with limited reference semantics.

## Defining Data Types with Value Semantics in C#

Whereas C++ makes it easy to use every type with both value and reference semantics, C# forces us to make a per-type choice of whether this type should support value semantics. In C#, this distinction is that between using a class (reference semantics) or a struct (value semantics) – again in stark contrast to C++, where the only difference between structs and classes is the default access modifier for members.

As an example, take the following data type definitions in C#:

public struct ValueTuple {
public int x;
public List<int> y;
}

public class Tuple {
public int x;
public List<int> y;
}

Then:

void Test() {
ValueTuple vt1 = new ValueTuple { x = 1, y = new List<int>() };
ValueTuple vt2 = vt1;
vt1.x = 15; // does NOT change vt2.x, it is still 1
// does change vt2.y, since vt2.y references the same object as vt1.y

Tuple t1 = new Tuple { x = 1, y = 2 };
Tuple t2 = t1;
t1.x = 15; // does change t2.x, since t2 and t1 reference the same Tuple object
}

What this shows is that ValueTuple has value semantics5: When declaring ValueTuple vt1;, you reserve a local storage liocation for an int and a reference to List<int>, since that is what makes a ValueTuple. In contrast, Tuple has reference semantics and declaring Tuple t1; reserves a local storage location for a reference to a Tuple that lives somewhere else in memory. Therefore, it makes sense to ask whether t1 == null, because the reference could well not be initialized and point to the invalid memory location at 0. However, it does not make any sense whatsoever to ask whether vt1 == null: A ValueTuple is a not a reference to a some place storing a an int and List<int>.

With ValueTuple vt2 = vt1;, the entire tuple vt1 is copied to vt2. This means that every member is copied, which implies that vt1 and vt2 now both share a reference to a list (the reference was copied but still points to the same place in memory).

### struct-type member fields

Just as local variables of struct types have value semantics, so have member variables. Take a look at the following:

struct S1 { int x; }
struct S2 { S1 t1; int y; }
struct S3 { S2 t2; int z; }

In memory, a variable m of type S2 and a variable n of type S3 look like this:

Note how n of type S3 directly contains a value of type S2:

You can convince yourself of the size of the values of these struct types by using unsafe in C#:

unsafe {
Console.WriteLine(sizeof(S1)); // 4 bytes
Console.WriteLine(sizeof(S2)); // 8 bytes
Console.WriteLine(sizeof(S3)); // 12 bytes
}

(This is not possible for class types; sizeof only takes structs.) This further reinforces that a struct is nothing more than the sum of its parts.

Compare this to a variable k of type C36:

class C1 { int x; }
class C2 { C1 d1; int y; }
class C3 { C2 d2; int z; }

Classes and structs can of course be mixed freely, as in:

class C {
S2 t;
int z;
}

Which then looks like this when used:

## Consequences of using value-semantics

In this section, I would like to show that many of the properties and restrictions of structs are just a consequence of the implementation of value semantics in C#.

### Corollary 1: No cycles between structs

An immediate consequence of what we have learned above is that the following is illegal7:

struct S1 { S1 other; int x; }

whereas this is perfectly fine:

class C1 { C1 other; int x; }

What is the first declaration of structs even supposed to mean? What would be the amount of memory you’d need to reserve for a value of type S1? Hence:

sizeof(S1) = sizeof(int) + sizeof(S1) = 2 * sizeof(int) + sizeof(S1)

The only conclusion we can reasonably draw is that sizeof(S1) is no finite number, illustrating why this cannot work.

### Corollary 2: No inheritance for structs

Consider the following class declarations with inheritance:

class C1 {
int x;
}
class C2 : C1 {
int y;
}

Unsurprisingly, this works:

C1 baseTypeVariable = new C2();

Because C1 is a reference type, the compiler can statically deduce the size of the storage location baseTypeVariable (it simply has the size of a reference). The reference is then set to point to an instance of C2, which is definitely larger than C1 because it contains an additional field. On the other hand, the following is illegal in C#:

struct S1 {
int x;
}
struct S2 : S1 {
int y;
}

If it were legal C#, then users might expect to be able to write something like:

S1 baseTypeVariable = new S2();

The mere declaration S1 baseTypeVariable asks the compiler to allocate enough space for a value of type S1 – and this size is just the size of an int by definition of S1. Assigning a value of type S2 to that variable poses a problem, because S2 values use up more memory. In C++, the moral equivalent of the above actually does work and will simply ignore that the value being assigned is of type S2 and only copy that value’s S1-part. This is known as the slicing problem and is prevented by C# simply by disallowing structs to inherit anything.

### Corollary 3: Boxing

From the last paragraphs, it is evident that whenever a variable of struct type is declared, its runtime type is completely determined to be that struct type and nothing else. For this reason, it is not necessary to store any additional type information with the value. Contrast this to:

string x = "Test";
object y = x; // static type is object, dynamic type string
y.ToString(); // virtual call: should call the method on string, not object.

In C# (and .NET more generally), each and every object is derived from object. Whenever a virtual function is called on an object, it needs to be able to determine its actual dynamic type to be able to call the right method. Hence, values of class types always carry some meta information around that determines their dynamic type and allows to correctly dispatch virtual calls (I glossed over that detail in some of the earlier pictures).

When I said that every object is derived from object, I really meant every: Even value types.

int x = 42;
object y = x; // completely valid
y.ToString(); // virtual call

Such an assigment of a value type object to a storage location with reference semantics (phew, what a mouthful!) must therefore somehow conjure up additional runtime type information. The example above is of course simplified and any compiler worth its salt would take note that y is statically known to contain an int and not bother with a virtual function call. But things get much trickier when calling a function with an object parameter by passing an int value. That function could do literally anything, so including the aforementioned meta data is mandatory.

This problem is solved through boxing: A box is allocated somewhere (usually in long-lived memory8), and the sole purpose of the box is to store the value and its meta data so it can be accessed by a reference. Whenever T is a reference type or interface and y’s type has value semantics, each assignment of the form T x = y; should be expected to cause boxing.

This example should make this clear:

int x = 42;
object a = x;
object b = x;
a == b; // this evaluates to false, because a and b reference different boxes
a.Equals(b); // this evaluates to true, because both boxes hold the value 42

Note at this point that the value of x is copied to the box, because int has value semantics:

int x = 42;
object a = x;
x++;
a.Equals(x); // this evaluates to false, since x is 43, but x contains 42.

I should point out that in this last example, there are two instances of boxing occuring: First for the line object a = x, then again for a.Equals(x), because Equals takes an argument of type object.

### Corollary 4: No default constructors

When you declare a variable in C#, you get the guarantee by the language that this memory does not contain random garbage but is set to zero. For example, the default value for an int is 0, because that’s what you get when you zero out all its bits. Usually, the compiler will stop you from accessing any variables that have not been explicitly initialized and only hold their default value:

int x;
x++; // error! Trying to access uninitialized variable x!

But in one case you routinely access such default-initialized values: Arrays and fields of objects. For example:

int[] x = new int[1];
x[0]++; // perfectly fine!

Zeroing out the memory of an array is comparatively cheap because setting large contiguous regions of memory to a value usually enjoys hardware support. The same zeroing out happens when allocating an array of classes, because each entry in the array will actually be a reference and can be set to null. An array of values of struct types however contains the actual values directly in the array itself. As an example, consider the following struct:

struct Vector2 {
float x;
float y;
}

In memory, this will look something like this (object[] on the left, Vector2[] on the right):

This shows why there can be no default constructor: The runtime does not want to initialize each value of the array. Setting the whole memory of the array to zero sets the bits of the structs to zero; this is the initialization you get. If you were allowed to define a default constructor that does something else, it would be forced to run for each value of the array.

## Common gotchas with structs

There are a few things that you should look out for when using structs because they might at first seem very weird. Here is a list of my favorites:

### Arrays vs. lists of structs

Arrays of structs and lists of structs are superficially very similar, but have one striking difference: Whether you access the elements by reference or by value. As an example, consider this:

var arr = new Vector2[1];
arr[0].x = 1f;
// arr[0] is Vector2 { x = 1, y = 0 }

var list = new List<Vector2>();
list[0].x = 1f; // error! Cannot modify return value.

The array access arr[0] allows us to modify the value in the array. Morally, we can think of the this[int] accessor to be declared as:

ref Vector2 this[int index] { get; set; }

This is not quite how array accessor are defined, because arrays are hardwired into the runtime and C# versions before 7.2 did not have ref returns, but it would have the same semantics. Lists on the other hand have an accessor defined like this:

Vector2 this[int index] { get; set; }

It always returns a copy of the value at the index and that copy is temporary until we copy it (again) into a variable. Hence any modifications to this temporary object will just be discarded anyway, so the language makes them invalid.

### Beware of non-obvious boxing

While we are talking about lists, it is worth pointing out that the standard C# collections often lead to excessive boxing when used without care. Generally, you will want to avoid boxing because it can be quite expensive (it allocates new objects in long lived memory, that is bad enough already). As an example, consider the cost of a call such as

bool IsInList(List<Vector2> list, Vector2 v) {
return list.Contains(v);
}

With our naive implementation of Vector2, this will yield $O(n)$ boxing operations. This is because Contains will call bool Equals(object) for every element of the list to check whether it is equal to the target value. Getting from Vector2 to the object required by bool Equals(object) causes the boxing. You can avoid most of the boxing by making your struct implement IEquatable<T>, but that of course only works if you have access to the struct’s source code. Otherwise, you might want to read this excellent article by Jackson Dunstan on using code generation to deal with such cases. Note that the boxing here does not occur because List<T> is a generic type and somehow causes boxing per se, quite the opposite: Generics are specifically designed to avoid boxing; this is about using generics carelessly.

My general message here is not only to remember to implement IEquatable<T> where necessary, but to watch out for where and how boxing might occur en masse.

### Methods on structs and readonly

Unless explicitly specified as ref, structs are passed to functions by value – i.e., as a copy. This is the whole point of value semantics after all! Yet in one instance, this is not quite true: Methods on structs. Consider this:

struct Counter {
private int _value;
public void Increase() { this._value++; }
public int GetValue() { return _value; }
}

Besides the fact that it is not quite idiomatic to not use a property for _value, this should be an easy struct to understand. Using it like this yields the expected results:

var ctr = new Counter();
ctr.Increase();
ctr.Increase();
ctr.GetValue(); // evaluates to 2

What this shows is that the this parameter of a method is passed to the method by reference, even for structs. This is definitely what you want, trust me. In some cases, however, this leads to unexpected consequences: Enter readonly. In C#, a readonly field means that the storage location that this field denotes cannot change (except when it is dealllocated). For reference types, the storage location will merely hold a reference and so you cannot change the reference, but the value that is referenced can still be modified. For value types on the other hand, the storage location holds the whole value, so you cannot change anything about this value. Example:

class C { public int X; }
struct S { public int X; }

class Example {

public Example() {
s = new S();
c = new C();
}

public void DoThings() {
c.X++; // valid
c = new C(); // error! cannot change readonly field
s.X++; // error! cannot change readonly field
s = new S(); // error! cannot change readonly field
}
}

So what about methods on structs? Adding a method to the example struct above and calling it has unintuitive consequences:

struct S {
public int X;
public void Increase() { X++; }
}

class Example {
public Example() { s = new S(); }
public void DoThings() {
s.Increase(); // increase X by one
Debug.Assert(s.X == 0); // huh!? s.X is in fact 0.
}
}

Yes, this is really what happens. The compiler does everything it can to prevent you from modifying a readonly field. In this case, it even decides to create a copy of s before calling Increase. This is not because the compiler figured out that Increase modifies s, but because it does not try to figure that out and just flatout assumes that every such call will modify the struct. In other words: For structs in readonly storage locations, this is effectively passed by value.

C# 7.2 added the in parameter modifier which may be thought of as readonly ref9 that leads to the same behavior. Interestingly, C# adds the possibility to declare a whole struct as readonly by using readonly struct S { ... } which will prevent these copies; this is again moving a site-by-site decision as in C++ to a type-by-type decision in C#, although they seem to be keeping a door open to change that.

Values vs. references has a long history of debates around it, most of them in the C++ community (just google c++ by value vs. by reference) where the choice comes up basically anytime you want to pass a variable to a function or create an object. In C#, this choice has to be made per type (with the option to locally switch from value semantics to reference semantics by using ref in some special cases), which is why you should be much more considerate about it. Here are some thoughts about when to use structs instead of classes and when not to (take them with a pinch of salt):

## Structs should be small

When you make something a struct, you can be certain that it will be copied around a lot. If you make your struct larger than a few words, then you will likely suffer a performance hit if you do not pass it around by reference. For a detailed benchmark, see Adam Sitnik’s post over here. Note how his post looks at structs that have the size of 5 ints and finds quite a large difference between passing by value (copying) and by reference (no copying). (The usual disclaimer about microbenchmakers and premature optimization apply.)

## Avoid mixing references and values in a struct

You should probably not use a struct if your struct would contain both value and reference type members. For example, imagine that I want to write a Stack with fixed capacity as a value type. The main part of the definition could look something like this:

struct FixedStack<T> {
private T[] _entries;
public int Capacity { get { return _entries.Length; } }
public int Size { get; private set; }

public FixedStack(int capacity) {
_entries = new T[capacity];
Size = 0;
}

public bool Push(in T value) {
if (Size < Capacity) {
_entries[Size++] = value;
return true;
}
return false;
}

public void Pop() { Size = Size == 0 ? 0 : Size - 1; }
public ref readonly T Top() { return ref _entries[Size - 1]; }
}

It sure is small: It only takes a reference to an array and an int to store its current size. There is another problem here, namely that a copy of a FixedStack is not a deep copy, but shallow, leading to absolutely unintuitive behavior:

var s = new FixedStack<int>(5);
s.Push(1);
// s.Size == 1

var s2 = s;
s2.Push(0);
// s2.Size == 2, but s.Size == 1
s.Push(2);
// s2.Top() == 2

Languages such as C++ allow the user to customize how copying is performed, such that you can always make a deep copy, but this comes with lots of problems of its own and inevitably leads to move semantics (which I fear even less people understand properly, although it is really not all that difficult). C# does not, so you have to design around it.

There are of course examples where mixing value and reference types in a struct is OK, for example when your struct is readonly and does not allow to modify the referenced object10. An obvious example would be a struct like ReadonlySpan that describes a slice of memory that can only be read, but not written to.

##### Another example

As a side note, this point is the reason why I felt the need to write this post. A colleague suggested to define the following struct:

struct EntryCollection {
public Dictionary<int, string> Values;
}

I objected to this definition for two reasons: First, this violates the principle of not mixing values and references. Second and more importantly, this is not all that obvious in this case. While it is intuitive that function pointers by their very nature have value semantics, C#’s delegates are not function pointers. A delegate can represent multiple functions; this is known as a multicast delegate. It is backed by an invocation list that contains the functions to be called. I guess that most people who hear “list” and would infer “reference type”. But no, Action<int, string> has value semantics. If you do not have this on your mind all the time, you will use this struct incorrectly and probably spend the better part of a day debugging why your callbacks are not called every time you add a value to the dictionary.

In my colleagues defense, this struct was a private nested struct (and has since been changed to a class, which was then changed to be public).

## Consider structs for cache-friendly arrays

Among the top reasons why you would use an array is because you determined that using a class is not fast enough. As we have seen before, an array of struct values really holds all of the structs, not just references to them. This makes traversals of these arrays much faster, because you do not need to dereference the references (which will most likely cause a cache miss) to get to the actual values. To get the full story, click here and let Jackson Dunstan explain it to you.

## Consider structs to avoid allocations for short-lived objects

Creating an object of a class-type causes an allocation somewhere in long-lived memory. The object thus created will have to be tracked by the garbage collector so it can destroy when it has become inaccessible, i.e. there are no accessible references to it left. All of this has a certain cost at runtime that you can avoid by using structs instead: They will usually be allocated in function-local short-lived memory (when used as a local variable inside a regular function at least) and automatically vanish once the function returns, making them much cheaper. Again, Adam Sitnik has a nice write-up with benchmarks.

To seriously benefit from this you of course then need to keep track of all kinds of boxing that may occur.

## Have a good reason to use a struct

When you are using a struct instead of a class, ask yourself why you are doing it. Just saying “this is a small class, so I should make it a struct” is probably not good enough a reason. There are certainly cases where the only natural choice will be a struct: If int did not have value semantics, we’d all be scratching our heads. I do not want to discourage anyone from using structs (I love value semantics!), but please know what you are getting everyone into and remember that there is probably at least one person on your team that does not fully understand value semantics.

1. I am not saying that you need to be able to produce completely correct x86 assembly language and implement the feature in the most efficient way possible, but you should know how to break that feature down into the basic operations your computer is capable of. There can be no magic left.

2. Whether the compiler will actually follow your request is an entirely different story. I am also lying a little bit about local storage here, because using a local variable in a closure or as part of an iterator block will change everything. Technically, value semantics is also completely decoupled from any of its implementations and how that implementation uses memory, so I am confounding to issues here. In practice, value semantics is usually understood to have an implementation that is the same as the one I am talking about here, at least in spirit.

3. This is a blatant lie. The instance of the list has a fixed size and references a growing memory buffer, but the general problem remains.

4. C# should not really be thought of as pointers, because the thing they are referencing could change its location due to the garbage collector moving stuff around. Furthermore, references are not quite as they are in C++: C# references are something of a middle-ground between C++’s references and pointers: They are nullable and reassignable, but have no support for pointer arithmetic. See this interesting write-up by Vladimir Sadov

5. You do not need to introduce a type for value tuples anymore, because C# 7 already ships with those

6. This is true only morally. While structs really consist just of their fields and nothing more, classes have a bit of meta-data attached to them such that you can recover the dynamic type of a variable and do locking etc. There is an awesome blogpost by Adam Sitnik that goes into more detail about this and should definitely be read by everyone.

7. In other languages with value semantics this might still be possible (Haskell, for example, will happily accept this definition). This is therefore a consequence of C#’s implementation of value semantics, not value semantics itself.

8. I am doing my best to avoid the words heap and stack, because I don’t want Eric Lippert to come around and slap me ;) But quite frankly, C# 7.2 will make the stackalloc keyword much more common in code bases and you shouldn’t feel dirty for talking about stack vs. heap. It may still be an implementation detail, but I believe that we should stop pretending that we don’t care about the implementation.

9. Marking a field readonly means two things: You cannot change it and nobody else can. This is a very strong guarantee. Marking a parameter as in gives you something weaker: It only means that you cannot change it, but someone else still might. In fact, consider the following example (which made me feel smart until I noticed it is right in the feature proposal):

class Example {
private int x;
private int y;
private int z;

public void Unintuitive(in int w) {
y = w;
x++; // if called as below, this line changes w
z = w;
}

public void Do() {
x = y = z = 0;
Unintuitive(in x);
}
}

It therefore first seemed to me that in was specifically not named readonly ref, since the meaning of readonly here differs from its meaning on fields. Alas, this is probably not the case because C# has ref readonly return values that allow the same aliasing problems. In the end, in was chosen for its brevity, according to this language design meeting protocol

10. This is one of my main gripes with Go: The inbuilt slices are just such structs with both reference and value members. See my post here.) There is nothing wrong with slices per se: They are great for representing a read-only view on a list or string, but Go does not know anything about read-only/const references.


text:
# What is it called when two problems are similar?

Suppose that there are two problems $P$ and $Q$.

How can I say that "solving $P$ is same thing with solving $Q$"?

For instance, if $P$ is NP-Hard, then we can say "$P$ can be solved in polynomial time iff there exists an algorithm $A$ that solves $Q$ in polynomial time".

There should be a shorter term for this, and I'm sure that is not similar.

Is equivalent the right word?

In complexity theory we prefer, when possible, to use formal definitions. Two problems $P,Q$ are polynomially equivalent if there are polytime functions $f,g$ such that $x \in P$ iff $f(x) \in Q$ and $y \in Q$ iff $g(x) \in P$. This is the usual notion of equivalence in complexity theory.
Sometimes we prefer a coarser notion of equivalence which allows using a problem as an oracle. Two problems $Q,R$ are polynomially equivalent with respect to oracle reductions if $Q \in \mathsf{P}^R$ and $R \in \mathsf{P}^Q$, or in other words, $Q$ can be solved in polynomial time with oracle access to $R$, and $R$ can be solved in polynomial time with oracle access to $Q$. Under this notion, 3SAT and co-3SAT (its complement) are equivalent.

format: plain


text:
## Introduction

Cooling garments have been widely studied in the pursuit of various benefits for human life, particularly in terms of physical properties, such as water evaporativity, phase-transition heat, and radiation transparency1,2,3. Nowadays, despite ordinary textile materials, it was found wearing stockings, knitted as micro-size yarns (~50 μm) were separated far from each other (~400 μm), reduced human body’s temperature (see Fig. 1a,b)4. Even in our inorganically-designed experimental setup, where a thermal metallic body was kept stationary under chemical-equilibrium and windless conditions, 1~4% higher heat release than the unworn was steadily measured. Then, heat release efficiency is experimentally elevated as (1) spacing is widened, (2) yarn diameter is reduced. These facts indicate that endothermic reactions, thermal radiation, or motion-driven flow are unconcerned for the fundamental to cooling effect of the stockings, although they are origins of conventional passive cooling garments1.

The knit fabrics consist of a periodic structure of yarns5, and are formed to be repeated rib-like protrusions when worn tightly (see Fig. 1c). A number of previous researches revealed that ribbed surfaces promote heat transfer in forced-convection internal flow6,7,8,9. This is realized due to rib’s guiding huge amount of cool flow into the vicinity of the surface. On the other hand, Tanda et al. investigated natural convection along ribbed surfaces with optical techniques, and concluded that heat transfer augmentation by adding millimeter-size ribs they prepared was useless in a series of their studies10,11,12,13. Similar issue is micro-finned heat sinks. Their heat transfer coefficients were improved as fin’s height decreased and spacing increased, but some were found to be less than smooth surface’s14,15. In this way, it is uncertain whether ribs enhance heat transfer on natural-convection environments, which are crucial for permanent passive cooling functions. Therefore, as a model system to consider heat transfer phenomena of wearing the stockings, we investigated natural convection along vertical small ribbed surfaces based on fluid-solid conjugate heat transfer analysis.

Any numerical simulation requires the verification and validation to be entitled to quantitative arguments. Thus, we first simulated two examined situations, (1) smooth, and (2) a millimeter-size ribbed surfaces. Through this study, a vertical plate of height H = 175 mm, thickness t = 0.2 mm was arranged in two-dimensional external-flow configuration. With correspondence to our experiments, temperature on the wall surface Tw = 33 °C, and ambient temperature T = 21 °C were decided. The analytical solution of natural convection on a vertical isothermal surface was formulated by Squire and Eckert16, for which local heat transfer coefficient h and thermal boundary layer thickness δ are respectively expressed as,

$$h(y)=0.508{\lambda }^{fluid}{y}^{-1}{\left(\frac{{{\rm{PrRa}}}_{y}}{0.952+{\rm{\Pr }}}\right)}^{1/4},$$
(1)
$$\delta (y)=3.936y{\left(\frac{0.952+{\rm{\Pr }}}{{{\rm{PrRa}}}_{y}}\right)}^{1/4},$$
(2)

where y, $${\lambda }^{fluid}$$, Pr, and Ray are vertical location, thermal conductivity, Prandtl numbers, and Rayleigh numbers of fluid. According to the Eq. (2), thermal boundary layer thickness on the plate was less than 17.1 mm, for which distances between the surface and infinite boundary were prepared to be beyond it. Laminar flow was just considered since the turbulent transition criteria 108 Ray was unsatisfied. As to ribbed conditions, five squared ribs of their edge length e = 5 mm were arranged with a pitch P = 30 mm symmetrically with respect to a center of the plate (Fig. 2a). Rib’s thermal conductivities $${\lambda }^{solid}$$ were $$236.0{\rm{W}}/{\rm{m}}\cdot {\rm{K}}$$ and $$0.057\,{\rm{W}}/{\rm{m}}\cdot {\rm{K}}$$ assuming alminium and fibrous materials respectively. Note the former condition is almost the same with the experiments conducted by Tanda team. (their setup: e = 4.85 mm, H = 175 mm, t = 12 mm, $${T}^{w}-{T}^{\infty }=11\,^\circ {\rm{C}}$$, alminium ribs)11. Figure 2b shows local heat transfer coefficients of our numerical simulations together with the analytical solution and the experimental data. Obviously, the theoretical prediction and our computed values for smooth surfaces accord quite well. Comparison of experiment and simulation in the ribbed case shows quantitative agreement over a broad middle area, thus we have successfully validated the quantitative capability of our method to predict heat transfer coefficients in the area. Further, temperature distributions in Fig. 2c visually resemble the images taken by a schlieren optical technique10,11,12. Compared with forced-convection internal flow on ribbed surfaces8,9, similar pattern of velocity distributions was observed as shown in Fig. 2d,e. In spite of external flow in our situation, outer cooler flow was guided into the vicinity of the surface. This can be explained by the fact natural-convection mainstream was just dragged by surroundings of each rib. On a different note, low-thermal-conductivity ribs promote heat transfer between neighboring ribs for the same reason with the previous studies9,12. Moreover, a remarkable point is that heat transfer coefficient via ribs comes to be largely below smooth surface’s, which implies millimeter-size ribs made of insulative materials work as thermal resistance.

By means of our validated numerical method, we have investigated heat transfer on micro-size ribbed surfaces (e = 50, 500 μm). From the bottom edge of the plate, ribs were periodically arranged with pitch-to-size ratio P/e fixed (P/e = 3, 6, 9). Rib’s thermal conductivity was chosen of $$0.057\,{\rm{W}}/{\rm{m}}\cdot {\rm{K}}$$ which corresponded to our textile insulative materials. Figure 3 exemplifies local heat transfer coefficients in the middle area including several periodic unit cells, because we confirmed the same was true of the entire area. Narrow rib-rib spacing (P/e = 3) induced hot recirculation flow in the whole space sandwiched with neighboring ribs17, which led to uniformization of temperature distributions near the surfaces. Therefore, their heat transfer coefficients were entirely at a low level, particularly among the fluid area. As spacing was widened (P/e = 6, 9), more amount of cool flow was guided onto the surface. Accordingly, direct heat release from surface to fluid was promoted. Such a trend was also reported in the studies of millimeter-order ribs7,12. However, it is noteworthy that all heat releases via ribs was drastically enhanced, and exceed smooth’s despite thermally insulative properties. In addition, as rib’s size was reduced, the heat release via ribs was enhanced, whereas the release between neighboring ribs was suppressed. The latter is reasonable in that the larger ribs can take the faster and cooler natural-convection flow to the surface area. We will later discuss why the former occurs. Here, the effective heat release can be evaluated by average heat transfer coefficient $$\bar{h}$$. Except for the cases hot recirculation flow dominates heat transfer (P/e = 3), average heat transfer coefficients were elevated in the same trend with our sensitivity experiments of the stockings. Further, some of them exceeded the smooth surface’s, which proves the cooling effect emerged. Heat release efficiency increases by ~1%, which is valid level to account for our experimental measurements quantitatively. As a result, we have numerically elucidated that cooling mechanism of the stockings in natural convection along micro-size ribbed surfaces.

This intriguing result is greatly owing to the enhancement of heat release through minuscule ribs. In general, heat transfer phenomena are determined within thermal boundary layers. According to the Eq. (2), thermal boundary layer thickness ranges 5.1 mm to 17.1 mm in the upper 99% area on the plate, which means almost all micro-size ribs are sufficiently smaller than the thickness $$(e\ll \delta )$$. Therefore, addition of such small ribs is regarded as a perturbation with respect to the solution of natural-convection flow on a vertical isothermal surface, whose temperature and temperature gradient profiles are analytically described as16,

$$T(x)={T}^{\infty }+({T}^{w}-{T}^{\infty }){(1-x/\delta )}^{2},$$
(3)
$$\nabla T(x)=-\,2({T}^{w}-{T}^{\infty })(1-x/\delta )/\delta .$$
(4)

Quadratically temperature profile decays to ambient temperature, which means that the closer to the surface horizontal location x is, the steeper temperature gradient becomes. Therefore, smaller ribs are exposed to steeper temperature gradient, which results in the enhancement of heat release via ribs whose thermal conductivity is beyond fluid media, as Fourier’s law suggests a perturbative heat flux relation $$q\propto -{\lambda }^{solid}\nabla T(e)$$. In reality, it also has influence on convective flow around ribs as we argued, not simply proportional to each physical quantity. However, increment of pitch-to-size ratio improves the perturbation condition, and guide more cool flow onto the surface. Consequently, the cooling effect emerges due to their complementary contributions.

Our investigation indicates relative relationship between geometric structure of minuscule ribbed surface and thermal boundary layer plays essential role in the cooling mechanism, which complements conventional theory for heat sink. If size of ribs, or fins, is larger relative to thermal boundary layer of the attached wall $$(\delta \ll e)$$, their own boundary layer is formed on themselves. This is in the scope of the conventional theory, and the basis to promote heat release is to expand the surface area of ribs made of high thermal conductivity materials. On the other hand, relatively small ribs $$(e\ll \delta )$$ are subject to the boundary layer of the wall, whose heat transfer is enhanced as we discussed, that is, by reducing the rib’s size with adequate spacing. Our mechanism is generally applicable to other formations of thermal convective flows which give steep temperature gradients near the surface. Thus, it gives a guideline to design permanent cooling artifacts of other clothes as well as micro devices. Also, minuscule protrusions are often observed in self-organized structures in nature, in a similar fashion, some natural creatures might wear their own cooling garments to maintain life activity18,19,20.

## Methods

### Experiments

The yarns of knitted stocking in our experiments were made of spandex of Roica® BZ (19dtex) covered with Nylon yarns (13dtex). Its thermal conductivity was measured as $$0.057\,{\rm{W}}/{\rm{m}}\cdot {\rm{K}}$$ at 65%RH. Note the order of the thermal conductivity indicates that sufficiently the yarn is thermally insulative as the same with common textile materials. Because stretchable property of the spandex enables stockings to fit to adherend surfaces, ribbed surfaces are formed when they are worn.

In order to measure human body temperature change, four human subjects walked at 5 km/hour under 30 °C and 50%RH environment during 3 minutes. After bare-legs walking, the human subjects took enough rest and their body temperature was confirmed to be recovered, and then walking tests with stockings were conducted. The experimental procedures were done twice per person, then each trial was confirmed to get the same conclusion (Their representatives are shown in Fig. 1a,b). The study protocol was confirmed, and approved by the research ethics committee of Asahi Kasei Corporation because the test procedure in this study does not harm health of human subjects. All experiments were conducted in accordance with the guideline and the standard the research ethics committee established. Each subject agreed with informed consent.

Our experiments to measure heat release were conducted by thermal counter method. As a hot body imitating human legs, a sealed alminium cylindrical shell of 300 mm height, 140 mm diameter, and 5 mm thickness was prepared with a temperature controller to maintain an isothermal condition of 37 °C in the inner thermocouple, which made the surface to be 33 °C in all trials. To evaluate the worn situations, the shell was covered uniformly with the stocking. As laboratory’s environment, the room temperature was regulated to be 21 °C, the wind speed was less than 0.5 m/sec, and humidity is fixed at a constant set value. The radiation emissivity of alminium is relatively low, so that we reduce influence of radiation into heat release as possible. After reach to thermal steady state was carefully confirmed, heat releases were obtained as time-averaged measurement values of the heater’s power consumptions during a fixed period. Note that we have confirmed that the stockings made of the material we used in this study did not give rise to cooling effect on the usual knitting condition $$(P/e \sim 3)$$. Incidentally, our experiment showed the higher heat release as room humidity is set to be higher. The thermal conductivity of yarns increases as humidity increases, because more water is included in the yarn. Such a heat release dependence on thermal conductivity has been also reported in the research of micro heat sink21.

### Simulations

In our fluid-solid conjugate heat transfer analysis, the governing equations were used of the steady compressible Newtonian fluid with the equation of state as the ideal gases in fluid domains, and of the steady heat diffusion in solid domains. Physical properties of fluid were of air at 27 °C. As our simulation software, the finite volume method computational fluid dynamics solver, chtMultiRegionSimpleFoam of the openFOAM package, was used, and thus semi-implicit method for pressure linked equations (SIMPLE) method was used to solve the pressure-velocity-density coupled equations. In usual, computed spaces were equally meshed by 50 μm length squares. As to cases of micro-size ribs, meshes near the plate’s surface were gradually refined to be 6.25 μm length squares to precisely deal with micro-order phenomena. Convective terms in the governing equations were discretized by Total-variation-diminishing (TVD) cubic schemes to describe buoyant convection with the semi-third-order accuracy. Linear algebraic solvers are prepared for each field as, velocity: diagonal incomplete LU (DILU) factorization preconditioned stabilized bi-conjugate gradient (BiCG Stab) method, pressure: diagonal incomplete Cholesky (DIC) factorized generalized geometric-algebraic multigrid (GAMG) preconditioned conjugate gradient (CG) method, temperature: DIC factorized GAMG method. These linear solvers were verified to be in stable convergence in each inner iteration. Global convergences in SIMPLE iterations were attained by cautiously confirming residuals as well as computed values of local heat transfer coefficients. Local heat transfer coefficients of solid domain, heat transfer via ribs, were calculated by using temperature gradient value on the isothermal surface, which are effective estimation in thermal steady state.


text:
# About vector space and subspaces

1. May 17, 2012

### applechu

Hi:
I am a newbie to linear algebra; I have a problem about
vector space and subspaces. How to distinguish these two
subject. what I know from books is subspace is going through
zero, but I still can not figure out what is the difference between
vector space and subspaces, thanks.

2. May 17, 2012

### DonAntonio

Simple: a vector subspace is a vector space in its own, but the particle "sub" indicates that it is a subset of a vector space that

contains it, and they both are vectors spaces wrt the very same operations and, of course, over the same field.

Thus, for example, the set $\,\,\{t(1,0) \,;\,t\in\mathbb{R}\}\,$ is a v. subspace of $\,\mathbb{R}^2\,$, but $\,\mathbb{R}^2\,$ is

not a subspace of $\,\mathbb{R}^3$ is the former as not a subset of the latter.

DonAntonio

3. May 17, 2012

### theorem4.5.9

DonAntonio is correct, but I think his example is confusing.

$\mathbb{R}^2$ is not a subspace of $\mathbb{R}^3$ because the former are vectors with two entries, and the latter are vectors with three entries. They are just different animals altogether, and so cannot be subsets of one or another.

However, in practice we tend to think of $\mathbb{R}^2$ as a subset of $\mathbb{R}^3$ with the tacit understanding that every vector in $\mathbb{R}^2$ gets a zero appended to it.

So $[4,2]\in\mathbb{R^2}$ becomes $[4,2,0]\in\mathbb{R^3}$

With this understanding, $\mathbb{R}^2$ is a subspace of $\mathbb{R}^3$

I add this not to nit pick or be confusing. I add this because this is how most people see $\mathbb{R}^2$ and it's important to make explicit why it is wrong to do so (like in DonAntonio's post) and what we implicitly do in our intuition.

Last edited: May 17, 2012
4. May 17, 2012

### applechu

Thanks a lot

Share this great discussion with others via Reddit, Google+, Twitter, or Facebook


text:
# Find the Vertex f(x)=(x-5)^2

Rewrite the equation in term of and .
Use the vertex form, , to determine the values of , , and .
Find the vertex .
Find the Vertex f(x)=(x-5)^2


text:
# What is the domain of g(x) = 3^(x+3)?

Apr 14, 2017

$\text{D} : \left\{x \in \mathbb{R}\right\}$.

#### Explanation:

Cool thing about this type of function, is that although the function does not touch the $x$-axis, it's domain is not limited.

Thus, we have $\text{D} : \left\{x \in \mathbb{R}\right\}$.

We can check this by graphing the function.
graph{3^(x+3) [-12.063, 3.96, -1.89, 6.12]}

As you can see, along the vertical axis, the $x$-value continues to increase (slowly but surely).

Hope this helps :)


text:
# Question #3e7ef

Jul 28, 2017

work done is zero as the displacement is zero.

#### Explanation:

Everytime an object completes a circle in uniform circular motion, the displacement of the object is zero as it returns to its starting position.And according to formula of work,

$W = F \cdot S$

where $S$ is zero for uniform cicular motion hece work done is zero.

Another reason is that the angular velocity($\omega$), Angular accelaration($\alpha$), centripetal acccelaration and tangential accelaration all are perpendicular to each other.Hence work done is zero as they have no components on each other.

Jul 28, 2017

I agree with the above, but think it can be explained more simply.

#### Explanation:

Imagine you are on a satellite orbiting the Earth, your velocity is a tangent to the orbit, the force causing you to remain in orbit (gravity) is at right angles to the velocity vector. Thus no work is done in the direction of the motion, as your displacement from the Earth is constant.

Work is better defined as

$W = F . s \cos \left(\theta\right)$

which reduces to zero when the angle between force and displacement is $90$ degrees.

If work was done in the direction of travel, your velocity would increase and you would move into a higher orbit.


text:
# Gauss practice (easy)

The earth has a net electric charge. The resulting electric field is, on average, $$150~\mbox{V/m}$$ and it is directed toward the center of the earth. What is the magnitude of the Earth's net charge in Coulombs? You may assume that the charge is uniformly distributed over the Earth's surface and that the earth is a perfect sphere.

• $k=\frac{1}{4\pi \epsilon_{0}}=9\times 10^{9}~\mbox{Nm}^{2}/\mbox{C}^{2}$
• The radius of the earth is $$6370~\mbox{km}$$.
×


text:
# zbMATH — the first resource for mathematics

##### Examples
 Geometry Search for the term Geometry in any field. Queries are case-independent. Funct* Wildcard queries are specified by * (e.g. functions, functorial, etc.). Otherwise the search is exact. "Topological group" Phrases (multi-words) should be set in "straight quotation marks". au: Bourbaki & ti: Algebra Search for author and title. The and-operator & is default and can be omitted. Chebyshev | Tschebyscheff The or-operator | allows to search for Chebyshev or Tschebyscheff. "Quasi* map*" py: 1989 The resulting documents have publication year 1989. so: Eur* J* Mat* Soc* cc: 14 Search for publications in a particular source with a Mathematics Subject Classification code (cc) in 14. "Partial diff* eq*" ! elliptic The not-operator ! eliminates all results containing the word elliptic. dt: b & au: Hilbert The document type is set to books; alternatively: j for journal articles, a for book articles. py: 2000-2015 cc: (94A | 11T) Number ranges are accepted. Terms can be grouped within (parentheses). la: chinese Find documents in a given language. ISO 639-1 language codes can also be used.

##### Operators
 a & b logic and a | b logic or !ab logic not abc* right wildcard "ab c" phrase (ab c) parentheses
##### Fields
 any anywhere an internal document identifier au author, editor ai internal author identifier ti title la language so source ab review, abstract py publication year rv reviewer cc MSC code ut uncontrolled term dt document type (j: journal article; b: book; a: book article)
Symmetric singularity formation in lubrication-type equations for interface motion. (English) Zbl 0856.35002

Fourth-order degenerate diffusion equations arise in a ‘lubrication approximation’ of a thin film or neck driven by surface tension. Numerical studies of the lubrication equation (LE) ${h}_{t}+{\left({h}^{n}{h}_{xxx}\right)}_{x}=0$ with various boundary conditions indicate that singularity formation in which $h\left(x\left(t\right),t\right)\to 0$ occurs for small enough $n$ with ‘anomalous’ or ‘second type’ scaling inconsistent with usual dimensional analysis.

This paper considers locally symmetric or even singularities in the (LE) and in the modified lubrication equation (MLE) ${h}_{t}+{h}^{n}{h}_{xxxx}=0$. Both equations have the property that entropy bounds forbid finite time singularities when $n$ is sufficiently large. Power series expansions for local symmetric similarity solutions are proposed for equation (LE) with $n<1$ and (MLE) for all $n\in ℝ$. In the latter case, special boundary conditions that force singularity formation are required to produce singularities when $n$ is large. Matching conditions at higher order terms in the expansion suggests a simple functional form for the time dependence of the solution.

Computer simulations presented here resolve the self similarity in the onset of the singularity of approximately 30 decades in ${min}_{x}\left(h\left(x,t\right)\right)$. Measurements of the similarity shape and time dependences show excellent agreement with the theoretical prediction.

One striking feature of the solution to (MLE) is a transition from a finite time singularity to an infinite time singularity $n=3/2$. Also both equations (LE) and (MLE) exhibit symmetric singularities for $n<0$ with derivatives of order $k$ vanishing at the singular point for all $2. They also exhibit a blow up in derivatives of order greater than $4-2n$.

##### MSC:
 35A20 Analytic methods, singularities (PDE) 35C20 Asymptotic expansions of solutions of PDE 35K55 Nonlinear parabolic equations 76B45 Capillarity (surface tension) 76M20 Finite difference methods (fluid mechanics)


text:
# Chapter 9 - Quadratic Functions and Equations - 9-1 Quadratic Graphs and Their Properties - Practice and Problem-Solving Exercises - Page 539: 40

Time is 3.1 seconds

#### Work Step by Step

$h = -16t^{2} + 154$ The apple hits the ground so the height equals 0 so we plug in 0 for h and find t $0 = -16t^{2} + 154$ Subtract 154 from both sides $0 - 154 = -16t^{2} + 154 - 154$ $-154 = -16t^{2}$ Divide -16 on both sides $\frac{-154}{-16}= \frac{-16t}{-16}^{2}$ 9.625 = $t^{2}$ We take square root of both sides $\sqrt 9.625 = \sqrt t^{2}$ $\sqrt 9.625$ = 3.1 x 3.1 t= 3.1

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.


text:
GMAT Question of the Day - Daily to your Mailbox; hard ones only

 It is currently 19 Jan 2019, 09:01

### 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 January
PrevNext
SuMoTuWeThFrSa
303112345
6789101112
13141516171819
20212223242526
272829303112
Open Detailed Calendar
• ### FREE Quant Workshop by e-GMAT!

January 20, 2019

January 20, 2019

07:00 AM PST

07:00 AM PST

Get personalized insights on how to achieve your Target Quant Score.
• ### Free GMAT Strategy Webinar

January 19, 2019

January 19, 2019

07:00 AM PST

09:00 AM PST

Aiming to score 760+? Attend this FREE session to learn how to Define your GMAT Strategy, Create your Study Plan and Master the Core Skills to excel on the GMAT.

# In the rectangle above, what is the ratio of (area of shaded region)

Author Message
TAGS:

### Hide Tags

Math Expert
Joined: 02 Sep 2009
Posts: 52294
In the rectangle above, what is the ratio of (area of shaded region)  [#permalink]

### Show Tags

05 Feb 2018, 05:53
00:00

Difficulty:

25% (medium)

Question Stats:

83% (00:51) correct 17% (00:50) wrong based on 62 sessions

### HideShow timer Statistics

In the rectangle above, what is the ratio of (area of shaded region)/(area of unshaded region)

(A) 1:4
(B) 1:2
(C) 1:1
(D) 2:1
(E) 3:1

Attachment:

2018-02-05_1750.png [ 13.04 KiB | Viewed 1496 times ]

_________________
Senior PS Moderator
Joined: 26 Feb 2016
Posts: 3334
Location: India
GPA: 3.12
In the rectangle above, what is the ratio of (area of shaded region)  [#permalink]

### Show Tags

05 Feb 2018, 06:52
2
Attachment:

2018-02-05_1750.png [ 13.9 KiB | Viewed 1140 times ]

In the rectangle above, the triangle with similar base and height will have an equal area.
Hence, Area(Triangle 1) = Area(Triangle 2)
Similarly, Area(Triangle 3) = Area(Triangle 4)

Area(Triangle2) + Area(Triangle3) = Area(Triangle1) + Area(Triangle4)

The ratio of (area of shaded region)/(area of unshaded region) is 1:1(Option C)
_________________

You've got what it takes, but it will take everything you've got

SC Moderator
Joined: 13 Apr 2015
Posts: 1687
Location: India
Concentration: Strategy, General Management
GMAT 1: 200 Q1 V1
GPA: 4
WE: Analyst (Retail)
Re: In the rectangle above, what is the ratio of (area of shaded region)  [#permalink]

### Show Tags

05 Feb 2018, 06:54
Area of unshaded = 1/2 * x * y

Area of shaded = 1/2 * x * a + 1/2 * x * (y - a) = 1/2 * x * y

Attachments

Untitled.png [ 11.86 KiB | Viewed 1133 times ]

Target Test Prep Representative
Affiliations: Target Test Prep
Joined: 04 Mar 2011
Posts: 2830
Re: In the rectangle above, what is the ratio of (area of shaded region)  [#permalink]

### Show Tags

06 Feb 2018, 17:02
Bunuel wrote:

In the rectangle above, what is the ratio of (area of shaded region)/(area of unshaded region)

(A) 1:4
(B) 1:2
(C) 1:1
(D) 2:1
(E) 3:1

Attachment:
2018-02-05_1750.png

We can let the base of the unshaded triangle = the length of rectangle = n.

We can let the height of the unshaded triangle = width of the rectangle = h.

The area of the unshaded region is the area of the unshaded triangle, which is:

1/2 x n x h = nh/2

The area of the shaded region is the difference between the area of the rectangle and the area of the unshaded triangle:

nh - nh/2 = 2nh/2 - nh/2 = nh/2

So the ratio is 1 : 1.

_________________

Jeffery Miller

GMAT Quant Self-Study Course
500+ lessons 3000+ practice problems 800+ HD solutions

Director
Joined: 31 Jul 2017
Posts: 517
Location: Malaysia
GMAT 1: 700 Q50 V33
GPA: 3.95
WE: Consulting (Energy and Utilities)
Re: In the rectangle above, what is the ratio of (area of shaded region)  [#permalink]

### Show Tags

07 Feb 2018, 01:17
Bunuel wrote:

In the rectangle above, what is the ratio of (area of shaded region)/(area of unshaded region)

(A) 1:4
(B) 1:2
(C) 1:1
(D) 2:1
(E) 3:1

Attachment:
2018-02-05_1750.png

Area of Unshaded region = $$\frac{1}{2}*l*b$$
Area of Rectangle = $$l*b$$
$$Ratio = (\frac{Total Area}{Area of Unshaded Region}) - 1$$ = 1
_________________

If my Post helps you in Gaining Knowledge, Help me with KUDOS.. !!

Re: In the rectangle above, what is the ratio of (area of shaded region) &nbs [#permalink] 07 Feb 2018, 01:17
Display posts from previous: Sort by


text:
# How this linear Motor Shaft works?

I am trying to understand how this linear motor works:

You can see a video here for more details. From what I know each permanent magnet consist a North and South poles so for a cylindrical magnet I have half of the magnet which is South and the other half North, so If I understand correctly the are positioned on this way:

 XXXXXXXXXXXXXXXXXX
_______  _______
|   |   ||   |   |
| N | S || N | S |
|___|___||___|___|
..................

Where 'X' is the current going into and '.' is the current getting out. So If I understand correctly I will have opposite forces that cancels each other. Analyzing the current of the top ('X') North poles gives me a force going to the right, but the South pole gives me a force going to the left so I have no force, so, how exactly this linear motor moves?

The design you see is probably an AC linear motor. Such motors are always driven by alternating current, and have several sets of windings driven either in phase quadrature, or a common configuration is three separate phases driven by equispaced phased currents, i.e. proportional to $\cos(\omega\,t)$, $\cos(\omega\,t + 2\pi/3)$ and $\cos(\omega\,t + 4\pi/3)$. The conductors are layered so that the nett flux inside the solenoid varies like:
$$\sum\limits_{n=1}^\infty a_n \cos(n\, k\,z - \omega\,t)$$
where $\omega$ is the angular frequency, $t$ the time, $z$ the distance along the motor's axis and $k$ is the "wavenumber", which is set by the coil design. The number of windings from each of the three phases present at any given axial position is varied to achieve this wavenumber. The coils are also layered such that the fundamental harmonic $a_0$ is as big as it can be relative to the others. So we have a travelling wave field, and the wavenumber $k$ is engineered as described to match the wavelength with the "wavelength" of the periodic variation in magnetisation from the permanent magnets set up with unlike poles back to back. Owing to the travelling wave, the shaft is swept along to keep the relative positions of the permanent magnets and the field constant. So I'm guessing that this a synchronous motor design. It would be driven by a sophisticated controller that would vary the frequency of the field to accelerate the shaft without losing phase lock.