CSC/ECE 517 Spring 2014/ch1a 1a rt - Revision history

Rathoma4 at 00:43, 18 April 2014

2014-04-18T00:43:35Z

← Older revision		Revision as of 00:43, 18 April 2014
Line 1:		Line 1:
	'''Prototype-Based Programming'''		'''Prototype-Based Programming'''

	In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming], ~~inheritance is~~ a way to reuse code of existing objects, or to establish a subtype from an existing object, or both. Class based inheritance required objects to be defined as classes before they are created. In contrast, prototype-based inheritance consists of [http://en.wikipedia.org/wiki/Cloning_(programming) cloning] existing objects which act as prototypes.<ref>http://en.wikipedia.org/wiki/Prototype-based_programming</ref> This programming style is also known as instance-base, prototype-oriented, or class-less programming.		In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming], [http://en.wikipedia.org/wiki/Inheritance_(programming) inheritance] is a way to reuse code of existing objects, or to establish a subtype from an existing object, or both. Class based inheritance required objects to be defined as classes before they are created. In contrast, prototype-based inheritance consists of [http://en.wikipedia.org/wiki/Cloning_(programming) cloning] existing objects which act as prototypes.<ref>http://en.wikipedia.org/wiki/Prototype-based_programming</ref> This programming style is also known as instance-base, prototype-oriented, or class-less programming.

	Previous page on this topic: [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1a_1e_pi CSC/ECE 517 Spring 2013/ch1a 1e pi]		Previous page on this topic: [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1a_1e_pi CSC/ECE 517 Spring 2013/ch1a 1e pi]
Line 34:		Line 34:

	===Delegation===		===Delegation===
	In class inheritance, methods are either defined in child classes or inherited from their parents. Delegation is a feature of prototype-based languages that use pointers to find the correct method or data during runtime. The delegation pointer establishes the link between parent and child methods. This allows child objects to be different in structure from their parents and be modified without affecting the parent.<ref>http://en.wikipedia.org/wiki/Delegation_(programming)</ref>		In class inheritance, methods are either defined in child classes or inherited from their parents. [http://en.wikipedia.org/wiki/Delegation_(programming) Delegation] is a feature of prototype-based languages that use pointers to find the correct method or data during runtime. The delegation pointer establishes the link between parent and child methods. This allows child objects to be different in structure from their parents and be modified without affecting the parent.<ref>http://en.wikipedia.org/wiki/Delegation_(programming)</ref>

	=='''Advantages'''==		=='''Advantages'''==
Line 51:		Line 51:
	===One-of-a-kind object support===		===One-of-a-kind object support===

	Ruby provides a framework that can easily include one-of-a-kind objects with their own behavior. Since each object has named slots, and slots can hold state or behavior, any object can have unique state or behavior. Class-based systems are designed for situations where there are many objects with the same behavior. There is no support for an object to possess its own unique behavior, and it is awkward to create a class that is guaranteed to have only one instance. Ruby suffers from neither of these disadvantages. A unique object can be customized with its own behavior, and a separate "instance" is not needed.<ref>http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop</ref>		[http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby] provides a framework that can easily include one-of-a-kind objects with their own behavior. Since each object has named slots, and slots can hold state or behavior, any object can have unique state or behavior. Class-based systems are designed for situations where there are many objects with the same behavior. There is no support for an object to possess its own unique behavior, and it is awkward to create a class that is guaranteed to have only one instance. Ruby suffers from neither of these disadvantages. A unique object can be customized with its own behavior, and a separate "instance" is not needed.<ref>http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop</ref>

	===Amending objects===		===Amending objects===

Rathoma4 at 00:37, 18 April 2014

2014-04-18T00:37:46Z

← Older revision		Revision as of 00:37, 18 April 2014
Line 68:		Line 68:
	The classical approach offers [http://en.wikipedia.org/wiki/Static_typing#STATIC static typing] where the type of an object is determined at compilation. Since all languages that allow prototype based inheritance are dynamically typed, typically more testing is required to ensure correct behavior and that objects are of the correct type for methods they are called on.<ref>http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop</ref>		The classical approach offers [http://en.wikipedia.org/wiki/Static_typing#STATIC static typing] where the type of an object is determined at compilation. Since all languages that allow prototype based inheritance are dynamically typed, typically more testing is required to ensure correct behavior and that objects are of the correct type for methods they are called on.<ref>http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop</ref>

			===Convention===
	==~~'''Which is the better approach'''(5)~~==		Class base inheritance is more widely used, making programmer unfamiliarity a possible issue. Programmers accustomed to static typing and class inheritance can find prototype-based programming confusing and unpredictable to fix errors.
	~~The classical based method~~ is more ~~traditional and purist compared to the prototype based approach.~~
	~~People~~ used to a ~~conventional OOP style may easily get confused~~. ~~"What do you mean there's only one class called "Thing"?!?" - "How do I extend this final Thing class!?!" - "You are violating OOP principles!!!" - "It's wrong~~ to ~~have all these~~ static ~~functions that act on any kind of object!?!?"~~
	~~It is really the type of software, objects that are interacting with each other~~ and ~~functionality that determine which approach needs to be used.~~
	~~For instance, if the above soldier example were about an army rather than individual or special divisions in the army then the classical~~
	~~approach would have been more appropriate, as there is already a natural existing hierarchy within the army that~~ can ~~be exploited. It would~~
	~~seem vague if different ranks such as lieutenant, corporal, major, general, etc were to be created as objects rather than classes. Also since~~
	~~each of these ranks can have multiple instances of real world objects associated with them, performing almost exactly the same functions, it~~
	~~would be better~~ to ~~create the ranks as classes and then instantiate each soldier as an object of the respective class~~.

	=='''References'''==		=='''References'''==
	<references/>		<references/>
	~~[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Summer_2008/wiki1_8_smr (4)Work by students from previous semesters]~~
	~~[http://javascript.crockford.com/prototypal.html (6)Prototype based inheritance in javascript]~~

Rathoma4 at 00:27, 18 April 2014

2014-04-18T00:27:31Z

@@ Line 53: / Line 53: @@
 Ruby provides a framework that can easily include one-of-a-kind objects with their own behavior. Since each object has named slots, and slots can hold state or behavior, any object can have unique state or behavior. Class-based systems are designed for situations where there are many objects with the same behavior. There is no support for an object to possess its own unique behavior, and it is awkward to create a class that is guaranteed to have only one instance. Ruby suffers from neither of these disadvantages. A unique object can be customized with its own behavior, and a separate "instance" is not needed.<ref>http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop</ref>
-===Elimination of meta-regress(4)===
+===Amending objects===
-No object in a class-based system can be self-sufficient; another object (its class) is needed to express its structure and behavior. On the other hand, in prototype-based systems an object can include its own behavior; no other object is needed to breathe life into it. Prototypes eliminate meta-regress.
+Using prototype-based programming, any object can be treated as a prototype, therefore the object can be extended without having to create a new object. In class-based programming, objects are committed to the functionality provided at instantiation. If the functionality of the class-based object later needs to be extended, a new object that has the desired functionality must instantiated and transfer the state between the two objects.<ref>http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop</ref>
- For example in case of the soldier, a Delta force unit is its own object. It does not require a an airman basic object to define any of its
+==Disadvantages==
-===Transfer of state information on extending the functionality of an object(5)===
+===Prototype based inheritance requires dynamic typing===
-Using prototype-based programming, we are able to treat any object as a prototype and therefore we can extend the object without having to create a new object. In class-based programming, we are committed to the functionality provided by the object at instantiation. If we later need to extend the functionality of the class-based object, we must instantiate a new class-based object that has the desired functionality and transfer state between the two objects.
+===Refactoring===
- Consider the transfer of a private from marine corps to green berets. In the prototype-based solution, we simply extend the marine corps
+===Testing for assurance===
- object to have the functionality of a Green Beret. In a class-based solution, we must instantiate a new Green Beret object and transfer state
+The classical approach offers [http://en.wikipedia.org/wiki/Static_typing#STATIC static typing] where the type of an object is determined at compilation. Since all languages that allow prototype based inheritance are dynamically typed, typically more testing is required to ensure correct behavior and that objects are of the correct type for methods they are called on.<ref>http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop</ref>

Rathoma4 at 22:45, 17 April 2014

2014-04-17T22:45:48Z

← Older revision		Revision as of 22:45, 17 April 2014
Line 42:		Line 42:
	<ref>http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop</ref>		<ref>http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop</ref>

	class ~~Motorcycle~~{}		class Bicycle{}
	class ElectricCar{}		class ElectricCar{}
			Scooter.prototype = Bicycle.new();
	Scooter.prototype = ~~Motorcycle~~.new();
	Scooter.power_source = ElectricCar.power_source;		Scooter.power_source = ElectricCar.power_source;
	//An electric scooter is made from inheriting		//An electric scooter is made from inheriting
	//data from two unrelated classes.		//data from two unrelated classes.

	===~~Using pre-existing modules===~~		===One-of-a-kind object support===

	Prototypes are more concrete than classes. They are examples of objects rather than descriptions of format and initialization. These examples help users to reuse modules by making them easier to understand. A prototype-based system allows the user to examine a typical representative rather than requiring him to make sense out of its description.


	~~===Support for one~~-of-a-kind ~~objects(5)~~===

	Ruby provides a framework that can easily include one-of-a-kind objects with their own behavior. Since each object has named slots, and slots can hold state or behavior, any object can have unique slots or behavior. Class-based systems are designed for situations where there are many objects with the same behavior. There is no linguistic support for an object to possess its own unique behavior, and it is awkward to create a class that is guaranteed to have only one instance. Ruby suffers from neither of these disadvantages. Any object can be customized with its own behavior. A unique object can hold the unique behavior, and a separate "instance" is not needed.

	~~In the above soldier example, navy seals may be trained in marine combat techniques which makes the navy seal object have its own unique~~
	~~behavior. Similarly a private in the army may be trained to handle tanks, (if he were to be in the cavalry division) which makes it unique for~~
	~~the private(army) object. In a class based approach,if private(marine corps) were to be inherited from private(army) and navy seals inherit~~
	~~from private(marine corps) then it would mean that the navy seal would be trained in tanks too, which is not the case here. However in~~
	~~prototype based inheritance training in tanks can remain unique to the marine corps if it is do desired.~~


			Ruby provides a framework that can easily include one-of-a-kind objects with their own behavior. Since each object has named slots, and slots can hold state or behavior, any object can have unique state or behavior. Class-based systems are designed for situations where there are many objects with the same behavior. There is no support for an object to possess its own unique behavior, and it is awkward to create a class that is guaranteed to have only one instance. Ruby suffers from neither of these disadvantages. A unique object can be customized with its own behavior, and a separate "instance" is not needed.<ref>http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop</ref>

	===Elimination of meta-regress(4)===		===Elimination of meta-regress(4)===

Rathoma4 at 22:40, 17 April 2014

2014-04-17T22:40:30Z

← Older revision		Revision as of 22:40, 17 April 2014
Line 1:		Line 1:
	'''Prototype-Based Programming'''		'''Prototype-Based Programming'''

	In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming], inheritance is a way to reuse code of existing objects, or to establish a subtype from an existing object, or both. Class based inheritance required objects to be defined as classes before they are created. In contrast, prototype-based inheritance consists of cloning existing objects which act as prototypes. This programming style is also known as instance-base, prototype-oriented, or class-less programming.		In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming], inheritance is a way to reuse code of existing objects, or to establish a subtype from an existing object, or both. Class based inheritance required objects to be defined as classes before they are created. In contrast, prototype-based inheritance consists of [http://en.wikipedia.org/wiki/Cloning_(programming) cloning] existing objects which act as prototypes.<ref>http://en.wikipedia.org/wiki/Prototype-based_programming</ref> This programming style is also known as instance-base, prototype-oriented, or class-less programming.

	Previous page on this topic: [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1a_1e_pi CSC/ECE 517 Spring 2013/ch1a 1e pi]		Previous page on this topic: [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1a_1e_pi CSC/ECE 517 Spring 2013/ch1a 1e pi]
Line 21:		Line 21:
	class medium Truck inherits Truck {}		class medium Truck inherits Truck {}

	In prototype based programming, a new object can be instantiated by simply creating a copy of/cloning an existing object.		In prototype based programming, a new object can be instantiated by simply creating a copy of/cloning an existing object.<ref>http://en.wikipedia.org/wiki/Cloning_(programming)</ref>

	Prototype based inheritance example:		Prototype based inheritance example:
Line 33:		Line 33:
	Car.model=("Master Deluxe II");		Car.model=("Master Deluxe II");

			===Delegation===
			In class inheritance, methods are either defined in child classes or inherited from their parents. Delegation is a feature of prototype-based languages that use pointers to find the correct method or data during runtime. The delegation pointer establishes the link between parent and child methods. This allows child objects to be different in structure from their parents and be modified without affecting the parent.<ref>http://en.wikipedia.org/wiki/Delegation_(programming)</ref>

			=='''Advantages'''==

	===~~Using Pre Existing modules~~===		===Ease of creating object variety===
			In prototype-based programming, new objects can be quickly cloned and defined in individual lines of code. As well, multiple inheritance is made simple with prototypes compared to class inheritance. Individual data or methods in two unrelated objects can be associated to a child without requiring complete inheritance. This allows for a high density of different prototypes that can be easily maintained.
			<ref>http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop</ref>

	Prototypes are more concrete than classes ~~because they~~ are examples of objects rather than descriptions of format and initialization. These examples ~~may~~ help users to reuse modules by making them easier to understand. A prototype-based system allows the user to examine a typical representative rather than requiring him to make sense out of its description		class Motorcycle{}
			class ElectricCar{}

			Scooter.prototype = Motorcycle.new();
			Scooter.power_source = ElectricCar.power_source;
			//An electric scooter is made from inheriting
			//data from two unrelated classes.

			===Using pre-existing modules===

			Prototypes are more concrete than classes. They are examples of objects rather than descriptions of format and initialization. These examples help users to reuse modules by making them easier to understand. A prototype-based system allows the user to examine a typical representative rather than requiring him to make sense out of its description.


Line 124:		Line 139:
	=='''References'''==		=='''References'''==
	<references/>		<references/>
	~~[http://en.wikipedia.org/wiki/Prototype-based_programming (1)Prototype-based_programming]~~
	~~[http://en.wikipedia.org/wiki/Delegation_(programming) (2)Delegation_(programming)]~~
	~~[http://en.wikipedia.org/wiki/Cloning_(programming) (3)Cloning_(programming)]~~
	[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Summer_2008/wiki1_8_smr (4)Work by students from previous semesters]		[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Summer_2008/wiki1_8_smr (4)Work by students from previous semesters]
	~~[http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop (5)advantages-of-prototype-based-oop-over-class-based-oop]~~
	[http://javascript.crockford.com/prototypal.html (6)Prototype based inheritance in javascript]		[http://javascript.crockford.com/prototypal.html (6)Prototype based inheritance in javascript]

Rathoma4 at 21:50, 17 April 2014

2014-04-17T21:50:54Z

← Older revision		Revision as of 21:50, 17 April 2014
Line 10:		Line 10:

	===Object Creation===		===Object Creation===
	~~While in the case of the~~ classical ~~approach~~, ~~objects need to be instantiated after defining the format of the class~~, ~~in case of prototype based, a new object~~ can ~~be instantiated by simply creating a copy of/cloning an~~ existing ~~object~~. ~~As in~~		In classical inheritance, Objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes, superclasses, or parent classes.

	Classical inheritance example:		Classical inheritance example:
Line 21:		Line 21:
	class medium Truck inherits Truck {}		class medium Truck inherits Truck {}

			In prototype based programming, a new object can be instantiated by simply creating a copy of/cloning an existing object.

	Prototype based inheritance example:		Prototype based inheritance example:
Line 34:		Line 35:


	===Using ~~Preexisting~~ modules~~(5)~~===		===Using Pre Existing modules===

	Prototypes are more concrete than classes because they are examples of objects rather than descriptions of format and initialization. These examples may help users to reuse modules by making them easier to understand. A prototype-based system allows the user to examine a typical representative rather than requiring him to make sense out of its description		Prototypes are more concrete than classes because they are examples of objects rather than descriptions of format and initialization. These examples may help users to reuse modules by making them easier to understand. A prototype-based system allows the user to examine a typical representative rather than requiring him to make sense out of its description

Rathoma4 at 21:22, 17 April 2014

2014-04-17T21:22:07Z

← Older revision		Revision as of 21:22, 17 April 2014
Line 30:		Line 30:
	Car.prototype = Vehicle.new();		Car.prototype = Vehicle.new();
	Car.make =("Chevy");		Car.make =("Chevy");
	Car.~~Model~~=("Master Deluxe II");		Car.model=("Master Deluxe II");

Rathoma4 at 21:21, 17 April 2014

2014-04-17T21:21:52Z

← Older revision		Revision as of 21:21, 17 April 2014
Line 17:		Line 17:
	//properties		//properties
	}		}

	class Car inherits Vehicle {}		class Car inherits Vehicle {}
	class trucks inherits inherits Car {}		class trucks inherits inherits Car {}
Line 29:		Line 28:
	//properties		//properties
	}		}

	Car.prototype = Vehicle.new();		Car.prototype = Vehicle.new();
	Car.make =("Chevy");		Car.make =("Chevy");

Rathoma4: Removed explanation of inheritance types and revised inheritance compare & contrast.

2014-04-17T21:21:29Z

Removed explanation of inheritance types and revised inheritance compare & contrast.

← Older revision		Revision as of 21:21, 17 April 2014
Line 7:		Line 7:
	[https://docs.google.com/a/ncsu.edu/document/d/1PEx2x5F7pJkyfeVRwV8CEDarZKmoXrQyKI1fGgBef00/edit Writeup page.]		[https://docs.google.com/a/ncsu.edu/document/d/1PEx2x5F7pJkyfeVRwV8CEDarZKmoXrQyKI1fGgBef00/edit Writeup page.]

	=='''~~Means of achieving~~ inheritance'''==		=='''Classical Inheritance vs. Prototype based inheritance'''==
	~~===Classical Inheritance===~~
	Objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes, superclasses, or parent classes. The resulting classes are known as derived classes, subclasses, or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

	~~[[File:Inheritance(Classical Inheritance).png\| center]]~~		===Object Creation===
	~~[http://expressionflow.com/2007/04/14/reusing-code-by-inheritance/ Image from Expression Flow]~~



	~~===Prototype Based Inheritance(1)===~~
	A feature of object-oriented programming in which classes are not present and inheritance is performed via a process of [http://en.wikipedia.org/wiki/Cloning_(programming) cloning(3)] existing objects that serve as [http://en.wikipedia.org/wiki/Prototype prototypes] . [http://en.wikipedia.org/wiki/Delegation_(programming) Delegation(2)] is the language feature that supports prototype-based programming.

	~~A simple example of Prototype Based Inheritance could be depicted as~~

	~~[[File:Priority Inheritnce Fig2.jpg\|300px\|center]].~~
	''(For the sake of an example, do not assume any of the military categories mentioned to be a class. They are all objects. For example we will not create an object for Green Berets. Rather Green Berets is itself an object. This has been done to avoid the use of common names for a soldier and then assigning his type to be a private or a green beret or a navy seal, etc)''


	This example shows soldiers belonging to different divisions as different objects. This sort of a relation can be better be represented as a prototype based inheritance than as a class-based one. If the relation used was the classical approach, then a separate class "soldier" would have to be defined as the base class from which the rest of the classes such as delta, green berets and navy seals would have to be defined as children classes. Also these would have been the children classes from which the object itself(probably a real soldier) would have to be instantiated. There is no reason to do so in this case as, each of these, intuitively suit more as an object(real life) than as a passive conceptual class. Besides, the classical approach would bring about a hierarchy among the objects when none exists.


	~~=='''Classical Inheritance v/s Prototype based inheritance'''==~~

	===Object Creation~~(1)~~===
	While in the case of the classical approach, objects need to be instantiated after defining the format of the class, in case of prototype based, a new object can be instantiated by simply creating a copy of/cloning an existing object. As in		While in the case of the classical approach, objects need to be instantiated after defining the format of the class, in case of prototype based, a new object can be instantiated by simply creating a copy of/cloning an existing object. As in

	Classical inheritance example		Classical inheritance example:
	class Vehicle		class Vehicle
	{
	~~//properties~~
	}
	~~class Car inherits Land Vehicle~~
	{
	}
	~~class trucks inherits inherits Car~~
	{
	}
	~~class medium Truck inherits Truck~~
	{		{
	//properties		//properties
	}		}

			class Car inherits Vehicle {}
			class trucks inherits inherits Car {}
			class medium Truck inherits Truck {}


	Prototype based inheritance example		Prototype based inheritance example:

	class ~~Soldier~~		class Vehicle
	{		{
	//properties		//properties
	}		}
	~~Private~~ = ~~Soldier~~.new()
	~~GreenBeret.prototype = Private~~		Car.prototype = Vehicle.new();
	~~GreenBeret~~.~~weapon~~=("~~H&K~~")		Car.make =("Chevy");
	~~GreenBeret~~.~~training~~=("~~x months~~")		Car.Model=("Master Deluxe II");

Rathoma4 at 20:08, 17 April 2014

2014-04-17T20:08:41Z

← Older revision		Revision as of 20:08, 17 April 2014
Line 1:		Line 1:
	'''Prototype-Based Programming'''		'''Prototype-Based Programming'''

	In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming], inheritance is a way to reuse code of existing objects, or to establish a subtype from an existing object, or both. Class based inheritance required objects to be defined as classes before they are created. In contrast, prototype-based inheritance consists of cloning existing objects which act as prototypes. This programming style is also known as instance-base, prototype-oriented, or class-less programming.		In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming], inheritance is a way to reuse code of existing objects, or to establish a subtype from an existing object, or both. Class based inheritance required objects to be defined as classes before they are created. In contrast, prototype-based inheritance consists of cloning existing objects which act as prototypes. This programming style is also known as instance-base, prototype-oriented, or class-less programming.

	Previous page on this topic: [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1a_1e_pi CSC/ECE 517 Spring 2013/ch1a 1e pi]		Previous page on this topic: [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1a_1e_pi CSC/ECE 517 Spring 2013/ch1a 1e pi]

	[https://docs.google.com/a/ncsu.edu/document/d/1PEx2x5F7pJkyfeVRwV8CEDarZKmoXrQyKI1fGgBef00/edit Writeup page.]		[https://docs.google.com/a/ncsu.edu/document/d/1PEx2x5F7pJkyfeVRwV8CEDarZKmoXrQyKI1fGgBef00/edit Writeup page.]