Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2015

2015-10-26T18:57:20Z

Achandr9: /* Writing Assignment 2 */

==Writing Assignment 1==
*[[CSC/ECE 517 Spring 2015/ch1a 17 WL]]
*[[CSC/ECE 517 Spring 2015/ch1a 5 ZX]]
*[[CSC/ECE 517 Spring 2015/ch1a 6 TZ]]
*[[CSC/ECE 517 Spring 2015/ch1a 4 RW]]
*[[CSC/ECE 517 Spring 2015/ch1a 7 SA]]
*[[CSC/ECE 517 Spring 2015/ch1a 9 RA]]
*[[CSC/ECE 517 Spring 2015/ch1a 14 RI]]
*[[CSC/ECE 517 Spring 2015/ch1a 1 DZ]]
*[[CSC/ECE 517 Spring 2015/ch1a 20 HA]]
*[[CSC/ECE 517 Spring 2015/ch1a 3 RF]]
*[[CSC/ECE 517 Spring 2015/ch1a 12 LS]]
*[[CSC/ECE 517 Spring 2015/ch1a 13 MA]]
*[[CSC/ECE 517 Spring 2015/ch1a 2 WA]]
*[[CSC/ECE 517 Spring 2015/ch1b 21 QW]]
*[[CSC/ECE 517 Spring 2015/ch1b 23 MS]]
*[[CSC/ECE 517 Spring 2015/ch1b 10 GL]]
*[[CSC/ECE 517 Spring 2015/ch1b 27 VC]]
*[[CSC/ECE 517 Spring 2015/ch1b 22 SF]]
*[[CSC/ECE 517 Spring 2015/ch1b 15 SH]]
*[[CSC/ECE 517 Spring 2015/ch1b 18 AS]]

==Writing Assignment 2==
*[[CSC/ECE 517 Spring 2015/oss E1502 wwj]]
*[[CSC/ECE 517 Fall 2014/oss E1508 MRS]]
*[[CSC/ECE 517 Spring 2015/oss E1504 IMV]]
*[[CSC/ECE 517 Spring 2015/oss E1505 xzl]]
*[[CSC/ECE 517 Spring 2015/oss E1509 lds]]
*[[CSC/ECE 517 Spring 2015/oss E1510 FLP]]
*[[CSC/ECE 517 Spring 2015/oss E1506 SYZ]]
*[[CSC/ECE 517 Spring 2015/oss S1504 AAC]]
*[[CSC/ECE 517 Spring 2015/oss E1507 DG]]
*[[CSC/ECE 517 Spring 2015/oss M1502 GVJ]]
*[[CSC/ECE 517 Spring 2015/oss M1503 EDT]]
*[[CSC/ECE 517 Spring 2015/oss E1503 RSA]]
*[[CSC/ECE 517 Spring 2015/oss E1501 YWS]]
*[[CSC/ECE 517 Spring 2015/oss S1501 OA]]

==Final Project Design Document==

*[[CSC/ECE 517 Spring 2015 E1526 MPRI]]
*[[CSC/ECE 517 Spring 2015 S1503 LWJZ]]
*[[CSC/ECE 517 Spring 2015 S1524 FSZZ]]
*[[CSC/ECE 517 Spring 2015 M1503 EDTS]]
*[[CSC/ECE 517 Spring 2015 E1529 GLDS]]
*[[CSC/ECE 517 Spring 2015 E1525 TIAA]]
*[[CSC/ECE 517 Spring 2015 E1522 Visualization]]
*[[CSC/ECE 517 Spring 2015 E1527 SWAR]]

==Final Project Report==
*[[CSC/ECE 517 Spring 2015 E1526]]

CSC/ECE 517 Spring 2015/oss S1501 test

2015-10-26T18:57:02Z

Achandr9: Created page with "test"

test

CSC/ECE 517 Spring 2015

2015-10-26T18:56:54Z

Achandr9: /* Writing Assignment 2 */

==Writing Assignment 1==
*[[CSC/ECE 517 Spring 2015/ch1a 17 WL]]
*[[CSC/ECE 517 Spring 2015/ch1a 5 ZX]]
*[[CSC/ECE 517 Spring 2015/ch1a 6 TZ]]
*[[CSC/ECE 517 Spring 2015/ch1a 4 RW]]
*[[CSC/ECE 517 Spring 2015/ch1a 7 SA]]
*[[CSC/ECE 517 Spring 2015/ch1a 9 RA]]
*[[CSC/ECE 517 Spring 2015/ch1a 14 RI]]
*[[CSC/ECE 517 Spring 2015/ch1a 1 DZ]]
*[[CSC/ECE 517 Spring 2015/ch1a 20 HA]]
*[[CSC/ECE 517 Spring 2015/ch1a 3 RF]]
*[[CSC/ECE 517 Spring 2015/ch1a 12 LS]]
*[[CSC/ECE 517 Spring 2015/ch1a 13 MA]]
*[[CSC/ECE 517 Spring 2015/ch1a 2 WA]]
*[[CSC/ECE 517 Spring 2015/ch1b 21 QW]]
*[[CSC/ECE 517 Spring 2015/ch1b 23 MS]]
*[[CSC/ECE 517 Spring 2015/ch1b 10 GL]]
*[[CSC/ECE 517 Spring 2015/ch1b 27 VC]]
*[[CSC/ECE 517 Spring 2015/ch1b 22 SF]]
*[[CSC/ECE 517 Spring 2015/ch1b 15 SH]]
*[[CSC/ECE 517 Spring 2015/ch1b 18 AS]]

==Writing Assignment 2==
*[[CSC/ECE 517 Spring 2015/oss E1502 wwj]]
*[[CSC/ECE 517 Fall 2014/oss E1508 MRS]]
*[[CSC/ECE 517 Spring 2015/oss E1504 IMV]]
*[[CSC/ECE 517 Spring 2015/oss E1505 xzl]]
*[[CSC/ECE 517 Spring 2015/oss E1509 lds]]
*[[CSC/ECE 517 Spring 2015/oss E1510 FLP]]
*[[CSC/ECE 517 Spring 2015/oss E1506 SYZ]]
*[[CSC/ECE 517 Spring 2015/oss S1504 AAC]]
*[[CSC/ECE 517 Spring 2015/oss E1507 DG]]
*[[CSC/ECE 517 Spring 2015/oss M1502 GVJ]]
*[[CSC/ECE 517 Spring 2015/oss M1503 EDT]]
*[[CSC/ECE 517 Spring 2015/oss E1503 RSA]]
*[[CSC/ECE 517 Spring 2015/oss E1501 YWS]]
*[[CSC/ECE 517 Spring 2015/oss S1501 OA]]
*[[CSC/ECE 517 Spring 2015/oss S1501 test]]

==Final Project Design Document==

*[[CSC/ECE 517 Spring 2015 E1526 MPRI]]
*[[CSC/ECE 517 Spring 2015 S1503 LWJZ]]
*[[CSC/ECE 517 Spring 2015 S1524 FSZZ]]
*[[CSC/ECE 517 Spring 2015 M1503 EDTS]]
*[[CSC/ECE 517 Spring 2015 E1529 GLDS]]
*[[CSC/ECE 517 Spring 2015 E1525 TIAA]]
*[[CSC/ECE 517 Spring 2015 E1522 Visualization]]
*[[CSC/ECE 517 Spring 2015 E1527 SWAR]]

==Final Project Report==
*[[CSC/ECE 517 Spring 2015 E1526]]

CSC/ECE 517 Spring 2015 M1503 EDTS

2015-04-01T05:37:54Z

Achandr9: /* Sender */

Extending Developer Tools for Servo
__TOC__
=='''Introduction'''==
===Rust===
Rust is a general purpose, [http://en.wikipedia.org/wiki/Programming_paradigm#Multi-paradigm multi-paradigm], compiled programming language developed by [http://en.wikipedia.org/wiki/Mozilla Mozilla] Research. It is designed to be a "safe, concurrent, practical language", supporting [http://en.wikipedia.org/wiki/Purely_functional pure-functional], [http://en.wikipedia.org/wiki/Actor_model concurrent-actor], [http://en.wikipedia.org/wiki/Procedural_programming imperative-procedural], and object-oriented styles.<ref>http://en.wikipedia.org/wiki/Rust_%28programming_language%29</ref> Being a modern systems programming language focusing on safety and speed, it accomplishes these goals by being memory safe without using garbage collection.<ref>http://doc.rust-lang.org/nightly/intro.html</ref>

===Servo===
Servo is an experimental project to build a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs. With Servo, we are rethinking the browser at every level of the technology stack — from input parsing to page layout to graphics rendering — to optimize for power efficiency and maximum parallelism.
Servo builds on top of Rust to provide a secure and reliable foundation. Memory safety at the core of the platform ensures a high degree of assurance in the browser’s trusted computing base. Rust’s lightweight task mechanism also promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation.<ref>https://www.mozilla.org/en-US/research/projects/</ref>

=='''Background'''==
===Remote Developer Tools===

Firefox supports remote developer tools - ie. communicating with an arbitrary server that implements a protocol for exposing information about web content. You can use the [https://developer.mozilla.org/en-US/docs/Tools Firefox developer tools] on your desktop to debug Web sites and Web apps running in other browsers or runtimes. The other browser might be on the same device as the tools themselves or on a different device, such as a phone connected over USB.

Servo implements a very basic developer tools server that currently supports executing JS remotely and investigating the DOM tree in the document inspector. We want to expand these capabilities by completing previous work that enables remote logging from web content, and add new capabilities to log HTTP requests and responses to allow for easier debugging of network-related problems in Servo.<ref>https://github.com/servo/servo/wiki/More-developer-tools-student-project</ref>

=='''Project Description'''==
=='''Requirement Analysis'''==
=='''Implementation'''==
=='''Architecture'''==

===enum===
Enums are datatypes with several alternate representations. A simple enum defines one or more constants with the same data type. In Rust, an enum can have complex variants though, like a struct. For example, consider an enum 'Shape' with variants 'Circle' and 'Triangle' each of which is a struct.

enum Shape {
Circle { center: Point, radius: f64 },
Triangle{ vert1: Point, vert2: Point, vert3: Point }
}

A variable of type Shape can be resolved to its appropriate variant by using a 'match'.

fn area(sh: Shape) -> f64 {
match sh {
Circle(_, size) => f64::consts::PI * size * size,
Rectangle(Point { x, y }, Point { x: x2, y: y2 }) => (x2 - x) * (y2 - y)
}
}

The Servo Developers Tools project has a 'DevtoolsControlMsg' enum which is used to instruct the devtools server to update its known actors/state according to changes in the browser. The current project requires the addition of two new variants to the 'DevtoolsControlMsg' enum, namely 'HTTRequest' and 'HTTResponse'.

===Sender<DevtoolsControlMsg>===

In Rust, a pipe is used for communication between tasks. A pipe is simply a pair of endpoints: one for sending messages and another for receiving messages(Sender and Receiver). The simplest way to create a pipe is to use the channel function to create a (Sender, Receiver) pair. In Rust parlance, a sender is a sending endpoint of a pipe, and a receiver is the receiving endpoint. A simple channel can be created as follows:
let (tx, rx) = channel();
spawn(proc() {
tx.send(10i);
});
assert_eq!(rx.recv(), 10i);
In this project, whenever a HTTPRequest or a HTTPResponse is received, we are going to send a new message using a 'Sender' object that could send variants of the type 'DevtoolsControlMsg'. This 'Sender<DevtoolsControlMsg>' objects sends the messages at appropriate times in the HTTPLoader function.

===NetworkEventActor===

=='''Design Patterns'''==
===Actor Model===
The actor model in computer science is a mathematical model of concurrent computation that treats "actors" as the universal primitives of concurrent computation: in response to a message that it receives, an actor can make local decisions, create more actors, send more messages, and determine how to respond to the next message received.

The Actor model adopts the philosophy that everything is an actor. This is similar to the everything is an object philosophy used by some object-oriented programming languages, but differs in that object-oriented software is typically executed sequentially, while the Actor model is inherently concurrent.

An actor is a computational entity that, in response to a message it receives, can concurrently:
*send a finite number of messages to other actors;
*create a finite number of new actors;
*designate the behavior to be used for the next message it receives.

=='''UML Diagrams'''==
=='''Proposed Test Cases'''==

=='''Reference'''==
<references/>

CSC/ECE 517 Spring 2015 M1503 EDTS

2015-04-01T05:08:41Z

Achandr9: /* Architecture */

Extending Developer Tools for Servo
__TOC__
=='''Introduction'''==
===Rust===
Rust is a general purpose, [http://en.wikipedia.org/wiki/Programming_paradigm#Multi-paradigm multi-paradigm], compiled programming language developed by [http://en.wikipedia.org/wiki/Mozilla Mozilla] Research. It is designed to be a "safe, concurrent, practical language", supporting [http://en.wikipedia.org/wiki/Purely_functional pure-functional], [http://en.wikipedia.org/wiki/Actor_model concurrent-actor], [http://en.wikipedia.org/wiki/Procedural_programming imperative-procedural], and object-oriented styles.<ref>http://en.wikipedia.org/wiki/Rust_%28programming_language%29</ref> Being a modern systems programming language focusing on safety and speed, it accomplishes these goals by being memory safe without using garbage collection.<ref>http://doc.rust-lang.org/nightly/intro.html</ref>

===Servo===
Servo is an experimental project to build a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs. With Servo, we are rethinking the browser at every level of the technology stack — from input parsing to page layout to graphics rendering — to optimize for power efficiency and maximum parallelism.
Servo builds on top of Rust to provide a secure and reliable foundation. Memory safety at the core of the platform ensures a high degree of assurance in the browser’s trusted computing base. Rust’s lightweight task mechanism also promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation.<ref>https://www.mozilla.org/en-US/research/projects/</ref>

=='''Background'''==
===Remote Developer Tools===

Firefox supports remote developer tools - ie. communicating with an arbitrary server that implements a protocol for exposing information about web content. You can use the [https://developer.mozilla.org/en-US/docs/Tools Firefox developer tools] on your desktop to debug Web sites and Web apps running in other browsers or runtimes. The other browser might be on the same device as the tools themselves or on a different device, such as a phone connected over USB.

Servo implements a very basic developer tools server that currently supports executing JS remotely and investigating the DOM tree in the document inspector. We want to expand these capabilities by completing previous work that enables remote logging from web content, and add new capabilities to log HTTP requests and responses to allow for easier debugging of network-related problems in Servo.<ref>https://github.com/servo/servo/wiki/More-developer-tools-student-project</ref>

=='''Project Description'''==
=='''Requirement Analysis'''==
=='''Implementation'''==
=='''Architecture'''==

===enum===
Enums are datatypes with several alternate representations. A simple enum defines one or more constants with the same data type. In Rust, an enum can have complex variants though, like a struct. For example, consider an enum 'Shape' with variants 'Circle' and 'Triangle' each of which is a struct.

enum Shape {
Circle { center: Point, radius: f64 },
Triangle{ vert1: Point, vert2: Point, vert3: Point }
}

A variable of type Shape can be resolved to its appropriate variant by using a 'match'.

fn area(sh: Shape) -> f64 {
match sh {
Circle(_, size) => f64::consts::PI * size * size,
Rectangle(Point { x, y }, Point { x: x2, y: y2 }) => (x2 - x) * (y2 - y)
}
}

The Servo Developers Tools project has a 'DevtoolsControlMsg' enum which is used to instruct the devtools server to update its known actors/state according to changes in the browser. The current project requires the addition of two new variants to the 'DevtoolsControlMsg' enum, namely 'HTTRequest' and 'HTTResponse'.

===Sender<DevtoolsControlMsg>===

===NetworkEventActor===

=='''Design Patterns'''==
===Actor Model===
The actor model in computer science is a mathematical model of concurrent computation that treats "actors" as the universal primitives of concurrent computation: in response to a message that it receives, an actor can make local decisions, create more actors, send more messages, and determine how to respond to the next message received.

The Actor model adopts the philosophy that everything is an actor. This is similar to the everything is an object philosophy used by some object-oriented programming languages, but differs in that object-oriented software is typically executed sequentially, while the Actor model is inherently concurrent.

An actor is a computational entity that, in response to a message it receives, can concurrently:
*send a finite number of messages to other actors;
*create a finite number of new actors;
*designate the behavior to be used for the next message it receives.

=='''UML Diagrams'''==
=='''Proposed Test Cases'''==

=='''Reference'''==
<references/>

CSC/ECE 517 Spring 2015/oss S1504 AAC

2015-03-21T20:53:03Z

Achandr9: /* Searching geonames */

==About Sahana==
[http://eden.sahanafoundation.org/ Sahana Eden] is an Open Source Humanitarian Platform which can be used to provide solutions for Disaster Management, Development, and Environmental Management sectors. Being open source, it is easily customisable, extensible and free. It is supported by the [http://sahanafoundation.org/ Sahana Software Foundation]. Sahana Eden was first developed in Sri Lanka as a response to the Indian Ocean Tsunami in 2005. The code for the Sahana Eden project is hosted at [https://github.com/flavour/eden Github] and it is published under the [http://en.wikipedia.org/wiki/MIT_License MIT License]. The demo version of Sahana Eden can be found [http://demo.eden.sahanafoundation.org/eden/ here].

Eden is a flexible humanitarian platform with a rich feature set which can be rapidly customized to adapt to existing processes and integrate with existing systems to provide effective solutions for critical humanitarian needs management either prior to or during a crisis. Sahana Eden contains a number of different modules like 'Organization Registry', 'Project Tracking', 'Human Resources', 'Inventory', 'Assets', 'Assessments', 'Scenarios & Events', 'Mapping', 'Messaging' which can be configured to provide a wide range of functionality. We are contributing to Sahana Eden as a part of our Object-Oriented Design and Development's Open-Source Software (OSS) Project. In this Wiki Page, we would be explaining the goals of our project and how we implemented them.

==Goals of the project==
==Implementation==
===Searching Internal database===
<pre>
#Get vars from url
user_str = get_vars["name_startsWith"]
callback_func = request.vars["callback"]
atable = db.gis_location
query = atable.name.lower().like(user_str + '%')
rows = db(query).select(atable.id,
atable.level,
atable.name,
atable.lat,
atable.lon
)
results = []
count = 0
for row in rows:
count += 1
result = {}

#Convert the level colum into the ADM codes geonames returns
#fcode = row["gis_location.level"]
level = row["gis_location.level"]
if level=="L0": #Country
fcode = "PCL" #Zoom 5
elif level=="L1": #State/Province
fcode = "ADM1"
elif level=="L2": #County/District
fcode = "ADM2"
elif level=="L3": #Village/Suburb
fcode = "ADM3"
else: #City/Town/Village
fcode = "ADM4"

result = {"id" : row["gis_location.id"],
"fcode" : fcode,
"name" : row["gis_location.name"],
"lat" : row["gis_location.lat"],
"lng" : row["gis_location.lon"]}
results.append(result)
</pre>

===Searching geonames===

If the initial search for the user query on the internal 'Locations' table, then a search is done on [http://www.geonames.org/ Geonames] as a fallback. This fallback search is implemented within the 'gis' controller using 'urllib2' an extensible Python module for opening URLs. The base URL for the Geonames search is http://ws.geonames.org/searchJSON?. The searchJSON action expects the Geonames username, the prefix of the location names to be searched, number of rows in the JSON result, etc. as parameters. The following code performs the HTTP GET request and loads the JSON response in a dictionary.

<pre>
username = settings.get_gis_geonames_username()
maxrows = "20"
lang = "en"
charset = "UTF8"
nameStartsWith = user_str
geonames_base_url = "http://ws.geonames.org/searchJSON?"
url = "%susername=%s&maxRows=%s&lang=%s&charset=%s&name_startsWith=%s" % (geonames_base_url,username,maxrows,lang,charset,nameStartsWith)
response = urllib2.urlopen(url)
dictResponse = json.loads(response.read().decode(response.info().getparam('charset') or 'utf-8'))
response.close()
</pre>

The JSON object in the response has two keys 'totalResultsCount' and 'geonames'. The object corresponding to the 'geonames' key is an array of the Geonames search results, each of which is a dictionary in itself. Of all the Keys present in a single result dictionary, the relevant ones are 'id', 'fcode', 'name', 'lat' and 'lng'. The relevant keys are extracted and a new dictionary is created for each search result. The array of new dictionaries is then returned as a response. The following code performs the decoding of the JSON object, creating new dictionary objects with the relevant keys and then collecting them as a single array.

<pre>
results = []
if dictResponse["totalResultsCount"] != 0:
geonamesResults = dictResponse["geonames"]
for geonamesResult in geonamesResults:
result = {}
result = {"id" : int(geonamesResult["geonameId"]), "fcode" : str(geonamesResult["fcode"]),
"name" : str(geonamesResult["name"]),"lat" : float(geonamesResult["lat"]),
"lng" : float(geonamesResult["lng"])}
results.append(result)
</pre>

CSC/ECE 517 Spring 2015/oss S1504 AAC

2015-03-21T20:52:39Z

Achandr9: /* Searching geonames */

CSC/ECE 517 Spring 2015/oss S1504 AAC

2015-03-21T20:00:56Z

Achandr9: /* About Sahana */

CSC/ECE 517 Spring 2015/ch1a 9 RA

2015-02-16T16:48:00Z

Achandr9: /* Introduction */

Lazy Enumerators

=='''Introduction'''==
In [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29#Ruby_1.8 Ruby 1.8] and [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29#Ruby_1.9 Ruby 1.9] the problem with enumeration that generate infinite sequences is that we have to write special, non-greedy, versions of methods. But, if you’re using [http://en.wikipedia.org/wiki/Ruby_(programming_language)#Ruby_2.0 Ruby 2.0] or later, you have this support built in. When you call lazy a lot happens inside of Ruby to give you just the values you need, Ruby automatically creates and uses many different types of internal Ruby objects.

If you call lazy Enumerator on any Ruby Enumerator, you get back an instance of class [http://www.ruby-doc.org/core-2.0.0/Enumerator/Lazy.html Enumerator::Lazy]. Many basic class like Array and Hash has lazy method through Enumerator class.<ref>http://www.amazon.com/Programming-Ruby-1-9-2-0-Programmers/dp/1937785491</ref>'lazy' version of some methods such as map and select never returns an array. Instead, they yield the transformed/filtered elements one by one. So you can use them for -
*Huge data which cannot be processed at a time,
*Data stream which you want to process in real-time,
*Infinite list, which has no end.

__TOC__

=='''How a lazy enumerator works'''==
A lazy enumerator in Ruby works as both a data consumer and a data producer. To understand how it’s done, we have to understand what an Enumerator::Generator and an Enumerator::Yielder is.

A simple way of creating an enumerable series of data in Ruby is to create an array. However if we want more flexibility in handling each element of the series while generating it, we can do so by using an Enumerator::Generator.Consider the example below to create an Enumerator:

<pre>
even_natural_numbers = Enumerator.new do |yielder|
number = 0
loop do
number += 2
yielder.yield number
end
end
</pre>

Here a block with an yielder is passed to the constructor of the enumerator. Every time the next method of the enumerator is called, the block is executed till the point the yielder is called in the line “yielder.yield number”. The control is passed to the yielder and returned back to the enumerator generator block when the “next” method is called on the enumerator again.

[[File:Enumerator-constructor.png‎]]

To understand how the block is executed on each call of “next”, the above code can be modified as follows:
<pre>

even_natural_numbers = Enumerator.new do |yielder|
number = 0
loop do
number += 2
yielder.yield number
puts "continuing loop"
end
end

puts even_natural_numbers.next
puts even_natural_numbers.next

Output:
2
continuing loop
4

</pre>

On the first “next” call to ‘even_natural_numbers’, the value of number is 2 and it’s passed to the yielder. During the second “next” call, the execution of the generator block continues from the line ‘puts “continuing loop”’ and the blocks yields again with the value 4.

Printing the above even_natural_numbers object gives the output:
#<Enumerator: #<Enumerator::Generator:0x007fbb040b2e28>:each>

This shows that the enumerator object is created with a reference to an internal object called Enumerator::Generator and the “each” method is setup to call that generator.

In the above example, the enumerator acts as a lazy generator i.e. generating new numbers of the series only on demand. By cascading multiple such lazy enumerators, each enumerator can be made to act as a data generator as well as a consumer. Consider an example where the first 10 even numbers which are also multiples of 5 are to be generated:

If the “select” method is used on the enumerator “even_natural_numbers” as follows, an infinite loop is produced:

<pre>
puts even_natural_numbers.select {|v| v%5==0}.first(10)
</pre>

The reason behind the infinite loop is that the “select” method tries to iterate over the entire collection and doesn't pass the control to the next method in line unless the collection is exhausted which, in an infinite collection, never happens. Hence it’s necessary to define a lazy version of the select method to do something useful with the infinite range that’s being lazily generated.<ref>http://www.michaelharrison.ws/weblog/?p=163</ref> The code given below adds a lazy version of the “select” method to the existing “Enumerator” class:

<pre>
class Enumerator
def lazy_select(&block)
Enumerator.new do |yielder|
self.each do |val|
yielder.yield(val) if block.call(val)
end
end
end
end
</pre>

The lazy_select method creates an enumerator which yields to the next method in line on selecting each value that satisfies the condition in the block. Using the lazy_select method on even_natural_numbers won't give an infinite loop anymore.

<pre>
puts even_natural_numbers.lazy_select {|v| v%5==0}.first(5)
</pre>

The above line of code gives the output as:
10
20
30
40
50

The flow of numbers in the above chain of lazy methods can be illustrated as below:
[[File:Lazy-select.png‎]]

=='''Differences '''==
If you try to iterate over an infinite range in Enumerator then it will run into an endless loop while with Enumerator::Lazy you can avoid endless loop and get just the value you need.

<pre>

> range = 1..Float::INFINITY
> range.collect { |n| n**2}.first(10) #endless loop

</pre>

but with lazy,

<pre>

> range = 1..Float::INFINITY
> range.lazy.collect { |n| n**2}.first(10)
=> [1, 4, 9, 16, 25, 36, 49, 64, 81, 100]

</pre>

Enumerator::Lazy acts just like the original, but it re-implements methods such as select and map so that they can work with infinite sequences. The lazy versions of the various methods do not return arrays of data. Instead, it returns a new enumerator that includes its own special processing—below example of map method returns an enumerator.<ref>http://patshaughnessy.net/2013/4/3/ruby-2-0-works-hard-so-you-can-be-lazy</ref>

<pre>

> range = 1..100
> range.map{|n| n**2}.take(10) #returns array
=> [1, 4, 9, 16, 25, 36, 49, 64, 81, 100]

</pre>

[[File:Enumerator map.png ]]

but with lazy,

<pre>

> range.lazy.map{|n| n**2}.take(10) #returns enumerator
=>#<Enumerator::Lazy:#<Enumerator::Lazy:#<Enumerator::Lazy:1..100>:map>:take(10)>

</pre>

=='''Examples '''==

===Example 1===
Enumerator::lazy manipulate infinite lists wisely. Below example shows without '.lazy', map tries to evaluate an array till last value and then gives first 10 values So, it takes much longer time to evaluate. But, with '.Lazy' method instead of evaluating full length array it evaluates only first 10 values. Thus, it gives answer much quicker than without '.Lazy' method.

<pre>

require 'date'
require ‘benchmark’
Benchmark.bm(8) do |x|
x.report("Non Lazy :") do
puts (Date.new(2015)..Date.new(9999)).select{|d| d.day == 13 and d.friday?}.first(10)
end
x.report("Lazy :") do
puts (Date.new(2015)..Date.new(9999)).lazy.select{|d| d.day == 13 and d.friday?}.first(10)
end
end

</pre>

===Example 2===

This example give you idea of using lazy enumeration in file read example and comparing with non lazy enumeration way,

<pre>

require 'benchmark'
fileName = "C:\\sample.txt"
Benchmark.bm(8) do |x|
x.report("Non Lazy :") do
50.times { File.readlines(fileName).detect { |line| line =~ /110216/i} }
end
x.report("Lazy :") do
50.times { File.open(fileName).lazy.detect { |line| line =~ /110216/i} }
end
end

</pre>

If you deal with large data and start chaining multiple enumeration methods together, the use of lazy evaluation prevents you from using unnecessary amounts of memory in temporary variables which makes lazy evaluation faster than non lazy evaluation.

=='''Drawbacks'''==

===Example===
We have seen usage and benefits of lazy enumeration in above examples but below simple example will give you drawback of it.

<pre>

require 'benchmark'
Benchmark.bm(8) do |x|
x.report("Non Lazy :") do
(1..10000000).select { |i| i % 3 == 0 || i % 5 == 0}.reduce(:+)
end
x.report("Lazy :") do
(1..10000000).lazy.select { |i| i % 3 == 0 || i % 5 == 0}.reduce(:+)
end
end

</pre>

Lazy enumeration is act as a proxy in between program and data so sometimes lazy enumeration gives non negligible performance hit. It is recommended not to use lazy enumeration everywhere as it adds another layer.<ref>https://bugs.ruby-lang.org/issues/6183</ref>

=='''[http://www.ruby-doc.org/core-2.0.0/Enumerator/Lazy.html Methods]'''==
Enumerator::Lazy overrides the following methods as 'lazy' version.
# Methods which transform the element:
##map(collect),
##flat_map(collect_concat),
##zip
# Methods which filters the element:
##select(find_all)
##grep
##take_while
##reject
##drop
##drop_while
# These lazy methods returns an instance of Enumerator::Lazy, where the 'normal' version returns an Array (and goes into infinite loop). It means that calling these methods does not generate any result. Actual values are generated when you call the methods like these on Enumerable::Lazy.
##take
##first
##find(detect)
#Enumerator::Lazy does not override these methods:
##chunk, cycle, slicebefore, each_cons, each_entry, each_slice,each_with_index, each_with_object.
##:Because they return an Enumerator.
##any?, include?, take. detect, find_index, first.
##:Because they never cause an infinite loop, because they need only finite number of elements
##inject, count, all?, none?, one?, max, max_by, min, min_by, minmax, minmax_by.
##:Because they need all elements to define the return value, and they are smart enough not to store all the element on the memory.
##entries, group_by, partition, sort, sort_by
##:Because of the size of their return value is linear to the input size.
##reverse_each
##:Because it needs the last element first.

=='''References'''==
<references/>

CSC/ECE 517 Spring 2015/ch1a 9 RA

2015-02-10T00:17:18Z

Achandr9: /* How a lazy enumerator works */

Lazy Enumerators

=='''Introduction'''==
In [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29#Ruby_1.8 Ruby 1.8] and [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29#Ruby_1.9 Ruby 1.9] the problem with enumeration that generate infinite sequences is that we have to write special, non-greedy, versions of methods. But, if you’re using [http://en.wikipedia.org/wiki/Ruby_(programming_language)#Ruby_2.0 Ruby 2.0] or later, you have this support built in. If you call Enumerator#lazy on any Ruby enumerator, you get back an instance of class [http://www.ruby-doc.org/core-2.0.0/Enumerator/Lazy.html Enumerator::Lazy]. Many basic class like Array and Hash has lazy method through Enumerator class.<ref>Programming Ruby 1.9 & 2.0 4th Edition</ref>

__TOC__

=='''[http://www.ruby-doc.org/core-2.0.0/Enumerator/Lazy.html Methods]'''==
Enumerable::Lazy overrides the following methods as 'lazy' version.
# Methods which transform the element:
##map(collect),
##flat_map(collect_concat),
##zip
# Methods which filters the element:
##select(find_all)
##grep
##take_while
##reject
##drop
##drop_while
# These lazy methods returns an instance of Enumerable::Lazy, where the 'normal' version returns an Array (and goes into infinite loop). It means that calling these methods does not generate any result. Actual values are generated when you call the methods like these on Enumerable::Lazy.
##take
##first
##find(detect)
#Enumerable::Lazy does not override these methods:
##chunk, cycle, slicebefore, each_cons, each_entry, each_slice,each_with_index, each_with_object.
##:Because they return an Enumerator.
##any?, include?, take. detect, find_index, first.
##:Because they never cause an infinite loop, because they need only finite number of elements
##inject, count, all?, none?, one?, max, max_by, min, min_by, minmax, minmax_by.
##:Because they need all elements to define the return value, and they are smart enough not to store all the element on the memory.
##entries, group_by, partition, sort, sort_by
##:Because of the size of their return value is linear to the input size.
##reverse_each
##:Because it needs the last element first.

=='''How a lazy enumerator works'''==
A lazy enumerator in Ruby works as both a data consumer and a data producer. To understand how it’s done, we have to understand what an Enumerator::Generator and an Enumerator::Yielder is.

A simple way of creating an enumerable series of data in Ruby is to create an array. However if we want more flexibility in handling each element of the series while generating it, we can do so by using an Enumerator::Generator.Consider the example below to create an Enumerator:

<pre>
even_natural_numbers = Enumerator.new do |yielder|
number = 0
loop do
number += 2
yielder.yield number
end
end
</pre>

Here a block with an yielder is passed to the constructor of the enumerator. Every time the next method of the enumerator is called, the block is executed till the point the yielder is called in the line “yielder.yield number”. The control is passed to the yielder and returned back to the enumerator generator block when the “next” method is called on the enumerator again.

[[File:Enumerator-constructor.png‎]]

To understand how the block is executed on each call of “next”, the above code can be modified as follows:
<pre>

even_natural_numbers = Enumerator.new do |yielder|
number = 0
loop do
number += 2
yielder.yield number
puts "continuing loop"
end
end

puts even_natural_numbers.next
puts even_natural_numbers.next

Output:
2
continuing loop
4

</pre>

On the first “next” call to ‘even_natural_numbers’, the value of number is 2 and it’s passed to the yielder. During the second “next” call, the execution of the generator block continues from the line ‘puts “continuing loop”’ and the blocks yields again with the value 4.

Printing the above even_natural_numbers object gives the output:
#<Enumerator: #<Enumerator::Generator:0x007fbb040b2e28>:each>

This shows that the enumerator object is created with a reference to an internal object called Enumerator::Generator and the “each” method is setup to call that generator.

In the above example, the enumerator acts as a lazy generator i.e. generating new numbers of the series only on demand. By cascading multiple such lazy enumerators, each enumerator can be made to act as a data generator as well as a consumer. Consider an example where the first 10 even numbers which are also multiples of 5 are to be generated:

If the “select” method is used on the enumerator “even_natural_numbers” as follows, an infinite loop is produced:

<pre>
puts even_natural_numbers.select {|v| v%5==0}.first(10)
</pre>

The reason behind the infinite loop is that the “select” method tries to iterate over the entire collection and doesn't pass the control to the next method in line unless the collection is exhausted which, in an infinite collection, never happens. Hence it’s necessary to define a lazy version of the select method to do something useful with the infinite range that’s being lazily generated.<ref>http://www.michaelharrison.ws/weblog/?p=163</ref> The code given below adds a lazy version of the “select” method to the existing “Enumerator” class:

<pre>
class Enumerator
def lazy_select(&block)
Enumerator.new do |yielder|
self.each do |val|
yielder.yield(val) if block.call(val)
end
end
end
end
</pre>

The lazy_select method creates an enumerator which yields to the next method in line on selecting each value that satisfies the condition in the block. Using the lazy_select method on even_natural_numbers won't give an infinite loop anymore.

<pre>
puts even_natural_numbers.lazy_select {|v| v%5==0}.first(5)
</pre>

The above line of code gives the output as:
10
20
30
40
50

The flow of numbers in the above chain of lazy methods can be illustrated as below:
[[File:Lazy-select.png‎]]

=='''Differences '''==
If you try to iterate over an infinite range in Enumerator then it will run into an endless loop while with Enumerator::Lazy you can avoid endless loop and get just the value you need.<ref>http://patshaughnessy.net/2013/4/3/ruby-2-0-works-hard-so-you-can-be-lazy</ref>

<pre>

> range = 1..Float::INFINITY
> range.collect { |n| n**2}.first(10) #endless loop

</pre>

but with lazy,

<pre>

> range = 1..Float::INFINITY
> range.lazy.collect { |n| n**2}.first(10)
=> [1, 4, 9, 16, 25, 36, 49, 64, 81, 100]

</pre>

Enumerator::Lazy acts just like the original, but it re-implements methods such as select and map so that they can work with infinite sequences. The lazy versions of the various methods do not return arrays of data. Instead, it returns a new enumerator that includes its own special processing—below example of map method returns an enumerator.<ref>http://patshaughnessy.net/2013/4/3/ruby-2-0-works-hard-so-you-can-be-lazy</ref>

<pre>

> range = 1..100
> range.map{|n| n**2}.take(10) #returns array
=> [1, 4, 9, 16, 25, 36, 49, 64, 81, 100]

</pre>

[[File:Enumerator map.png ]]

but with lazy,

<pre>

> range.lazy.map{|n| n**2}.take(10) #returns enumerator
=>#<Enumerator::Lazy:#<Enumerator::Lazy:#<Enumerator::Lazy:1..100>:map>:take(10)>

</pre>

=='''Examples '''==

===Example 1===

<pre>

require 'date'
require ‘benchmark’
Benchmark.bm(8) do |x|
x.report("Non Lazy :") do
puts (Date.new(2015)..Date.new(9999)).select{|d| d.day == 13 and d.friday?}.first(10)
end
x.report("Lazy :") do
puts (Date.new(2015)..Date.new(9999)).lazy.select{|d| d.day == 13 and d.friday?}.first(10)
end
end

</pre>

===Example 2===

This example give you idea of using lazy enumeration in file read example and comparing with non lazy enumeration way

<pre>

require 'benchmark'
fileName = "C:\\sample.txt"
Benchmark.bm(8) do |x|
x.report("Non Lazy :") do
50.times { File.readlines(fileName).detect { |line| line =~ /110216/i} }
end
x.report("Lazy :") do
50.times { File.open(fileName).lazy.detect { |line| line =~ /110216/i} }
end
end

</pre>

If you deal with large data and start chaining multiple enumeration methods together, the use of lazy evaluation prevents you from using unnecessary amounts of memory in temporary variables which makes lazy evaluation faster than non lazy evaluation.

=='''Drawbacks'''==

===Example===
We have seen usage and benefits of lazy enumeration in above examples but below simple example will give you drawback of it.

<pre>

require 'benchmark'
Benchmark.bm(8) do |x|
x.report("Non Lazy :") do
(1..10000000).select { |i| i % 3 == 0 || i % 5 == 0}.reduce(:+)
end
x.report("Lazy :") do
(1..10000000).lazy.select { |i| i % 3 == 0 || i % 5 == 0}.reduce(:+)
end
end

</pre>

Lazy enumeration is act as a proxy in between program and data so sometimes lazy enumeration gives non negligible performance hit. It is recommended not to use lazy enumeration everywhere as it adds another layer.<ref>https://bugs.ruby-lang.org/issues/6183</ref>

=='''References'''==
<references/>

File:Enumerator-constructor.png

2015-02-10T00:16:28Z

Achandr9: uploaded a new version of "File:Enumerator-constructor.png"

File:Enumerator-constructor.png

2015-02-10T00:15:53Z

Achandr9:

File:Enumerator-generator.png

2015-02-09T22:41:13Z

Achandr9: uploaded a new version of "File:Enumerator-generator.png"

CSC/ECE 517 Spring 2015/ch1a 9 RA

2015-02-09T19:16:20Z

Achandr9: /* Differences */

Lazy Enumerators

=='''Introduction'''==
In Ruby 1.8 and Ruby 1.9 the problem with enumeration that generate infinite sequences is that we have to write special, non-greedy, versions of methods. But, if you’re using Ruby 2.0 or later, you have this support built in. If you call Enumerator#lazy on any Ruby enumerator, you get back an instance of class Enumerator::Lazy. Many basic class like Array and Hash has lazy method through Enumerator class.<ref>Programming Ruby 1.9 & 2.0 4th Edition</ref>

The lazy methods returns a lazy enumerator whose methods Map/collect, flat_map/ collect_caoncat, select/ find_all, reject, grep, zip, take, #take_while, drop, #drop_while, and cycle enumerate values only on as-needed basis.<ref>http://www.ruby-doc.org/core-2.0.0/Enumerator/Lazy.html</ref>

__TOC__
=='''How a lazy enumerator works'''==
A lazy enumerator in Ruby works as both a data consumer and a data producer. To understand how it’s done, we have to understand what an Enumerator::Generator and an Enumerator::Yielder is.

A simple way of creating an enumerable series of data in Ruby is to create an array. However if we want more flexibility in handling each element of the series while generating it, we can do so by using an Enumerator::Generator.<ref>33333333333333</ref> Consider the example below to create an Enumerator:

<pre>
even_natural_numbers = Enumerator.new do |yielder|
number = 0
loop do
number += 2
yielder.yield number
end
end
</pre>

Here a block with an yielder is passed to the constructor of the enumerator. Everytime the next method of the enumerator is called, the block is executed till the point the yielder is called in the line “yielder.yield number”. The control is passed to the yielder and returned back to the enumerator generator block when the “next” method is called on the enumerator again.

[[File:Enumerator-generator.png‎]]

To understand how the block is executed on each call of “next”, the above code can be modified as follows:
<pre>

even_natural_numbers = Enumerator.new do |yielder|
number = 0
loop do
number += 2
yielder.yield number
puts "continuing loop"
end
end

puts even_natural_numbers.next
puts even_natural_numbers.next

Output:
2
continuing loop
4

</pre>

On the first “next” call to ‘even_natural_numbers’, the value of number is 2 and it’s passed to the yielder. During the second “next” call, the execution of the generator block continues from the line ‘puts “continuing loop”’ and the blocks yields again with the value 4.

Printing the above even_natural_numbers object gives the output:
#<Enumerator: #<Enumerator::Generator:0x007fbb040b2e28>:each>

This shows that the enumerator object is created with a reference to an internal object called Enumerator::Generator and the “each” method is setup to call that generator.

In the above example, the enumerator acts as a lazy generator i.e. generating new numbers of the series only on demand. By cascading multiple such lazy enumerators, each enumerator can be made to act as a data generator as well as a consumer. Consider an example where the first 10 even numbers which are also multiples of 5 are to be generated:

If the “select” method is used on the enumerator “even_natural_numbers” as follows, an infinite loop is produced:

<pre>
puts even_natural_numbers.select {|v| v%5==0}.first(10)
</pre>

The reason behind the infinite loop is that the “select” method tries to iterate over the entire collection and doesn’t pass the control to the next method in line unless the collection is exhausted which, in an infinite collection, never happens. Hence it’s necessary to define a lazy version of the select method to do something useful with the infinite range that’s being lazily generated. The code given below adds a lazy version of the “select” method to the existing “Enumerator” class:

<pre>
class Enumerator
def lazy_select(&block)
Enumerator.new do |yielder|
self.each do |val|
yielder.yield(val) if block.call(val)
end
end
end
end
</pre>

The lazy_select method creates an enumerator which yields to the next method in line on selecting each value that satisfies the condition in the block. Using the lazy_select method on even_natural_numbers won't give an infinte loop anymore.

<pre>
puts even_natural_numbers.lazy_select {|v| v%5==0}.first(5)
</pre>

The above line of code gives the output as:
10
20
30
40
50

The flow of numbers in the above chain of lazy methods can be illustrated as below:
[[File:Lazy-select.png‎]]

=='''Differences '''==
If you try to iterate over an infinite range in Enumerator then it will run into an endless loop while with Enumerator::Lazy you can avoid endless loop and get just the value you need.<ref>http://patshaughnessy.net/2013/4/3/ruby-2-0-works-hard-so-you-can-be-lazy</ref>

<pre>

> range = 1..Float::INFINITY
> range.collect { |n| n**2}.first(10) #endless loop

</pre>

but with lazy,

<pre>

> range = 1..Float::INFINITY
> range.lazy.collect { |n| n**2}.first(10)
=> [1, 4, 9, 16, 25, 36, 49, 64, 81, 100]

</pre>

Enumerator::Lazy acts just like the original, but it re-implements methods such as select and map so that they can work with infinite sequences. The lazy versions of the various methods do not return arrays of data. Instead, it returns a new enumerator that includes its own special processing—below example of map method returns an enumerator.<ref>http://patshaughnessy.net/2013/4/3/ruby-2-0-works-hard-so-you-can-be-lazy</ref>

<pre>

> range = 1..100
> range.map{|n| n**2}.take(10) #returns array
=> [1, 4, 9, 16, 25, 36, 49, 64, 81, 100]

</pre>

[[File:Enumerator map.png ]]

but with lazy,

<pre>

> range.lazy.map{|n| n**2}.take(10) #returns enumerator
=>#<Enumerator::Lazy:#<Enumerator::Lazy:#<Enumerator::Lazy:1..100>:map>:take(10)>

</pre>

=='''Examples '''==

===Example 1===

<pre>

require 'date'
require ‘benchmark’
Benchmark.bm(8) do |x|
x.report("Non Lazy :") do
puts (Date.new(2015)..Date.new(9999)).select{|d| d.day == 13 and d.friday?}.first(10)
end
x.report("Lazy :") do
puts (Date.new(2015)..Date.new(9999)).lazy.select{|d| d.day == 13 and d.friday?}.first(10)
end
end

</pre>

===Example 2===

This example give you idea of using lazy enumeration in file read example and comparing with non lazy enumeration way

<pre>

require 'benchmark'
fileName = "C:\\sample.txt"
Benchmark.bm(8) do |x|
x.report("Non Lazy :") do
50.times { File.readlines(fileName).detect { |line| line =~ /110216/i} }
end
x.report("Lazy :") do
50.times { File.open(fileName).lazy.detect { |line| line =~ /110216/i} }
end
end

</pre>

If you deal with large data and start chaining multiple enumeration methods together, the use of lazy evaluation prevents you from using unnecessary amounts of memory in temporary variables which makes lazy evaluation faster than non lazy evaluation.

=='''Drawbacks'''==

===Example===
We have seen usage and benefits of lazy enumeration in above examples but below simple example will give you drawback of it.

<pre>

require 'benchmark'
Benchmark.bm(8) do |x|
x.report("Non Lazy :") do
(1..10000000).select { |i| i % 3 == 0 || i % 5 == 0}.reduce(:+)
end
x.report("Lazy :") do
(1..10000000).lazy.select { |i| i % 3 == 0 || i % 5 == 0}.reduce(:+)
end
end

</pre>

Lazy enumeration is act as a proxy in between program and data so sometimes lazy enumeration gives non negligible performance hit. It is recommended not to use lazy enumeration everywhere as it adds another layer.<ref>https://bugs.ruby-lang.org/issues/6183</ref>

=='''References'''==
<references/>

File:Enumerator map.png

2015-02-09T19:10:36Z

Achandr9:

CSC/ECE 517 Spring 2015/ch1a 9 RA

2015-02-09T17:33:05Z

Achandr9: /* How a lazy enumerator works */

Lazy Enumerators

=='''Introduction'''==
In Ruby 1.8 and Ruby 1.9 the problem with enumeration that generate infinite sequences is that we have to write special, non-greedy, versions of methods. But, if you’re using Ruby 2.0 or later, you have this support built in. If you call Enumerator#lazy on any Ruby enumerator, you get back an instance of class Enumerator::Lazy. Many basic class like Array and Hash has lazy method through Enumerator class.<ref>Programming Ruby 1.9 & 2.0 4th Edition</ref>

The lazy methods returns a lazy enumerator whose methods Map/collect, flat_map/ collect_caoncat, select/ find_all, reject, grep, zip, take, #take_while, drop, #drop_while, and cycle enumerate values only on as-needed basis.<ref>http://www.ruby-doc.org/core-2.0.0/Enumerator/Lazy.html</ref>

__TOC__
=='''How a lazy enumerator works'''==
A lazy enumerator in Ruby works as both a data consumer and a data producer. To understand how it’s done, we have to understand what an Enumerator::Generator and an Enumerator::Yielder is.

A simple way of creating an enumerable series of data in Ruby is to create an array. However if we want more flexibility in handling each element of the series while generating it, we can do so by using an Enumerator::Generator.<ref>33333333333333</ref> Consider the example below to create an Enumerator:

<pre>
even_natural_numbers = Enumerator.new do |yielder|
number = 0
loop do
number += 2
yielder.yield number
end
end
</pre>

Here a block with an yielder is passed to the constructor of the enumerator. Everytime the next method of the enumerator is called, the block is executed till the point the yielder is called in the line “yielder.yield number”. The control is passed to the yielder and returned back to the enumerator generator block when the “next” method is called on the enumerator again.

[[File:Enumerator-generator.png‎]]

To understand how the block is executed on each call of “next”, the above code can be modified as follows:
<pre>

even_natural_numbers = Enumerator.new do |yielder|
number = 0
loop do
number += 2
yielder.yield number
puts "continuing loop"
end
end

puts even_natural_numbers.next
puts even_natural_numbers.next

Output:
2
continuing loop
4

</pre>

On the first “next” call to ‘even_natural_numbers’, the value of number is 2 and it’s passed to the yielder. During the second “next” call, the execution of the generator block continues from the line ‘puts “continuing loop”’ and the blocks yields again with the value 4.

Printing the above even_natural_numbers object gives the output:
#<Enumerator: #<Enumerator::Generator:0x007fbb040b2e28>:each>

This shows that the enumerator object is created with a reference to an internal object called Enumerator::Generator and the “each” method is setup to call that generator.

In the above example, the enumerator acts as a lazy generator i.e. generating new numbers of the series only on demand. By cascading multiple such lazy enumerators, each enumerator can be made to act as a data generator as well as a consumer. Consider an example where the first 10 even numbers which are also multiples of 5 are to be generated:

If the “select” method is used on the enumerator “even_natural_numbers” as follows, an infinite loop is produced:

<pre>
puts even_natural_numbers.select {|v| v%5==0}.first(10)
</pre>

The reason behind the infinite loop is that the “select” method tries to iterate over the entire collection and doesn’t pass the control to the next method in line unless the collection is exhausted which, in an infinite collection, never happens. Hence it’s necessary to define a lazy version of the select method to do something useful with the infinite range that’s being lazily generated. The code given below adds a lazy version of the “select” method to the existing “Enumerator” class:

<pre>
class Enumerator
def lazy_select(&block)
Enumerator.new do |yielder|
self.each do |val|
yielder.yield(val) if block.call(val)
end
end
end
end
</pre>

The lazy_select method creates an enumerator which yields to the next method in line on selecting each value that satisfies the condition in the block. Using the lazy_select method on even_natural_numbers won't give an infinte loop anymore.

<pre>
puts even_natural_numbers.lazy_select {|v| v%5==0}.first(5)
</pre>

The above line of code gives the output as:
10
20
30
40
50

The flow of numbers in the above chain of lazy methods can be illustrated as below:
[[File:Lazy-select.png‎]]

=='''Differences '''==
If you try to iterate over an infinite range in Enumerator then it will run into an endless loop while with Enumerator::Lazy you can avoid endless loop and get just the value you need.<ref>http://patshaughnessy.net/2013/4/3/ruby-2-0-works-hard-so-you-can-be-lazy</ref>

<pre>

> range = 1..Float::INFINITY
> range.collect { |n| n**2}.first(10) #endless loop

</pre>

but with lazy,

<pre>

> range = 1..Float::INFINITY
> range.lazy.collect { |n| n**2}.first(10)
=> [1, 4, 9, 16, 25, 36, 49, 64, 81, 100]

</pre>

Enumerator::Lazy acts just like the original, but it re-implements methods such as select and map so that they can work with infinite sequences. The lazy versions of the various methods do not return arrays of data. Instead, it returns a new enumerator that includes its own special processing—below example of map method returns an enumerator.<ref>http://patshaughnessy.net/2013/4/3/ruby-2-0-works-hard-so-you-can-be-lazy</ref>

<pre>

> range = 1..100
> range.map{|n| n**2}.take(10) #returns array
=> [1, 4, 9, 16, 25, 36, 49, 64, 81, 100]

</pre>

but with lazy,

<pre>

> range.lazy.map{|n| n**2}.take(10) #returns enumerator
=>#<Enumerator::Lazy:#<Enumerator::Lazy:#<Enumerator::Lazy:1..100>:map>:take(10)>

</pre>

=='''Examples '''==

===Example 1===

<pre>

require 'date'
require ‘benchmark’
Benchmark.bm(8) do |x|
x.report("Non Lazy :") do
puts (Date.new(2015)..Date.new(9999)).select{|d| d.day == 13 and d.friday?}.first(10)
end
x.report("Lazy :") do
puts (Date.new(2015)..Date.new(9999)).lazy.select{|d| d.day == 13 and d.friday?}.first(10)
end
end

</pre>

===Example 2===

This example give you idea of using lazy enumeration in file read example and comparing with non lazy enumeration way

<pre>

require 'benchmark'
fileName = "C:\\sample.txt"
Benchmark.bm(8) do |x|
x.report("Non Lazy :") do
50.times { File.readlines(fileName).detect { |line| line =~ /110216/i} }
end
x.report("Lazy :") do
50.times { File.open(fileName).lazy.detect { |line| line =~ /110216/i} }
end
end

</pre>

If you deal with large data and start chaining multiple enumeration methods together, the use of lazy evaluation prevents you from using unnecessary amounts of memory in temporary variables which makes lazy evaluation faster than non lazy evaluation.

=='''Drawbacks'''==

===Example===
We have seen usage and benefits of lazy enumeration in above examples but below simple example will give you drawback of it.

<pre>

require 'benchmark'
Benchmark.bm(8) do |x|
x.report("Non Lazy :") do
(1..10000000).select { |i| i % 3 == 0 || i % 5 == 0}.reduce(:+)
end
x.report("Lazy :") do
(1..10000000).lazy.select { |i| i % 3 == 0 || i % 5 == 0}.reduce(:+)
end
end

</pre>

Lazy enumeration is act as a proxy in between program and data so sometimes lazy enumeration gives non negligible performance hit. It is recommended not to use lazy enumeration everywhere as it adds another layer.<ref>https://bugs.ruby-lang.org/issues/6183</ref>

=='''References'''==
<references/>

File:Lazy-select.png

2015-02-09T17:30:20Z

Achandr9:

File:Lazy select.png

2015-02-09T17:25:37Z

Achandr9: uploaded a new version of "File:Lazy select.png"

File:Lazy select.png

2015-02-09T17:24:59Z

Achandr9:

CSC/ECE 517 Spring 2015/ch1a 9 RA

2015-02-09T16:56:07Z

Achandr9: /* How a lazy enumerator works */

Lazy Enumerators

=='''Introduction'''==
In Ruby 1.8 and Ruby 1.9 the problem with enumeration that generate infinite sequences is that we have to write special, non-greedy, versions of methods. But, if you’re using Ruby 2.0 or later, you have this support built in. If you call Enumerator#lazy on any Ruby enumerator, you get back an instance of class Enumerator::Lazy. Many basic class like Array and Hash has lazy method through Enumerator class.<ref>Programming Ruby 1.9 & 2.0 4th Edition</ref>

The lazy methods returns a lazy enumerator whose methods Map/collect, flat_map/ collect_caoncat, select/ find_all, reject, grep, zip, take, #take_while, drop, #drop_while, and cycle enumerate values only on as-needed basis.<ref>http://www.ruby-doc.org/core-2.0.0/Enumerator/Lazy.html</ref>

__TOC__
=='''How a lazy enumerator works'''==
A lazy enumerator in Ruby works as both a data consumer and a data producer. To understand how it’s done, we have to understand what an Enumerator::Generator and an Enumerator::Yielder is.

A simple way of creating an enumerable series of data in Ruby is to create an array. However if we want more flexibility in handling each element of the series while generating it, we can do so by using an Enumerator::Generator.<ref>33333333333333</ref> Consider the example below to create an Enumerator:

<pre>
even_natural_numbers = Enumerator.new do |yielder|
number = 0
loop do
number += 2
yielder.yield number
end
end
</pre>

Here a block with an yielder is passed to the constructor of the enumerator. Everytime the next method of the enumerator is called, the block is executed till the point the yielder is called in the line “yielder.yield number”. The control is passed to the yielder and returned back to the enumerator generator block when the “next” method is called on the enumerator again.

[[File:Enumerator-generator.png‎]]

To understand how the block is executed on each call of “next”, the above code can be modified as follows:
<pre>

even_natural_numbers = Enumerator.new do |yielder|
number = 0
loop do
number += 2
yielder.yield number
puts "continuing loop"
end
end

puts even_natural_numbers.next
puts even_natural_numbers.next

Output:
2
continuing loop
4

</pre>

On the first “next” call to ‘even_natural_numbers’, the value of number is 2 and it’s passed to the yielder. During the second “next” call, the execution of the generator block continues from the line ‘puts “continuing loop”’ and the blocks yields again with the value 4.

Printing the above even_natural_numbers object gives the output:
#<Enumerator: #<Enumerator::Generator:0x007fbb040b2e28>:each>

This shows that the enumerator object is created with a reference to an internal object called Enumerator::Generator and the “each” method is setup to call that generator.

In the above example, the enumerator acts as a lazy generator i.e. generating new numbers of the series only on demand. By cascading multiple such lazy enumerators, each enumerator can be made to act as a data generator as well as a consumer. Consider an example where the first 10 even numbers which are also multiples of 5 are to be generated:

If the “select” method is used on the enumerator “even_natural_numbers” as follows, an infinite loop is produced:

<pre>
puts even_natural_numbers.select {|v| v%5==0}.first(10)
</pre>

The reason behind the infinite loop is that the “select” method tries to iterate over the entire collection and doesn’t pass the control to the next method in line unless the collection is exhausted which, in an infinite collection, never happens. Hence it’s necessary to define a lazy version of the select method to do something useful with the infinite range that’s being lazily generated. The code given below adds a lazy version of the “select” method to the existing “Enumerator” class:

<pre>
class Enumerator
def lazy_select(&block)
Enumerator.new do |yielder|
self.each do |val|
yielder.yield(val) if block.call(val)
end
end
end
end
</pre>

The lazy_select method creates an enumerator which yields to the next method in line on selecting each value that satisfies the condition in the block. Using the lazy_select method on even_natural_numbers won't give an infinte loop anymore.

<pre>
puts even_natural_numbers.lazy_select {|v| v%5==0}.first(5)
</pre>

The above line of code gives the output as:
10
20
30
40
50

The flow of numbers in the above chain of lazy methods can be illustrated as below:

=='''Differences '''==
If you try to iterate over an infinite range in Enumerator then it will run into an endless loop while with Enumerator::Lazy you can avoid endless loop and get just the value you need.<ref>http://patshaughnessy.net/2013/4/3/ruby-2-0-works-hard-so-you-can-be-lazy</ref>

<pre>

> range = 1..Float::INFINITY
> range.collect { |n| n**2}.first(10) #endless loop

</pre>

but with lazy,

<pre>

> range = 1..Float::INFINITY
> range.lazy.collect { |n| n**2}.first(10)
=> [1, 4, 9, 16, 25, 36, 49, 64, 81, 100]

</pre>

Enumerator::Lazy acts just like the original, but it re-implements methods such as select and map so that they can work with infinite sequences. The lazy versions of the various methods do not return arrays of data. Instead, it returns a new enumerator that includes its own special processing—below example of map method returns an enumerator.<ref>http://patshaughnessy.net/2013/4/3/ruby-2-0-works-hard-so-you-can-be-lazy</ref>

<pre>

> range = 1..100
> range.map{|n| n**2}.take(10) #returns array
=> [1, 4, 9, 16, 25, 36, 49, 64, 81, 100]

</pre>

but with lazy,

<pre>

> range.lazy.map{|n| n**2}.take(10) #returns enumerator
=>#<Enumerator::Lazy:#<Enumerator::Lazy:#<Enumerator::Lazy:1..100>:map>:take(10)>

</pre>

=='''Examples '''==

===Example 1===

<pre>

require 'date'
require ‘benchmark’
Benchmark.bm(8) do |x|
x.report("Non Lazy :") do
puts (Date.new(2015)..Date.new(9999)).select{|d| d.day == 13 and d.friday?}.first(10)
end
x.report("Lazy :") do
puts (Date.new(2015)..Date.new(9999)).lazy.select{|d| d.day == 13 and d.friday?}.first(10)
end
end

</pre>

===Example 2===

This example give you idea of using lazy enumeration in file read example and comparing with non lazy enumeration way

<pre>

require 'benchmark'
fileName = "C:\\sample.txt"
Benchmark.bm(8) do |x|
x.report("Non Lazy :") do
50.times { File.readlines(fileName).detect { |line| line =~ /110216/i} }
end
x.report("Lazy :") do
50.times { File.open(fileName).lazy.detect { |line| line =~ /110216/i} }
end
end

</pre>

If you deal with large data and start chaining multiple enumeration methods together, the use of lazy evaluation prevents you from using unnecessary amounts of memory in temporary variables which makes lazy evaluation faster than non lazy evaluation.

=='''Drawbacks'''==

===Example===
We have seen usage and benefits of lazy enumeration in above examples but below simple example will give you drawback of it.

<pre>

require 'benchmark'
Benchmark.bm(8) do |x|
x.report("Non Lazy :") do
(1..10000000).select { |i| i % 3 == 0 || i % 5 == 0}.reduce(:+)
end
x.report("Lazy :") do
(1..10000000).lazy.select { |i| i % 3 == 0 || i % 5 == 0}.reduce(:+)
end
end

</pre>

Lazy enumeration is act as a proxy in between program and data so sometimes lazy enumeration gives non negligible performance hit. It is recommended not to use lazy enumeration everywhere as it adds another layer.<ref>https://bugs.ruby-lang.org/issues/6183</ref>

=='''References'''==
<references/>

CSC/ECE 517 Spring 2015/ch1a 9 RA

2015-02-09T16:46:08Z

Achandr9: /* How a lazy enumerator works */

Lazy Enumerators

=='''Introduction'''==
In Ruby 1.8 and Ruby 1.9 the problem with enumeration that generate infinite sequences is that we have to write special, non-greedy, versions of methods. But, if you’re using Ruby 2.0 or later, you have this support built in. If you call Enumerator#lazy on any Ruby enumerator, you get back an instance of class Enumerator::Lazy. Many basic class like Array and Hash has lazy method through Enumerator class.<ref>Programming Ruby 1.9 & 2.0 4th Edition</ref>

The lazy methods returns a lazy enumerator whose methods Map/collect, flat_map/ collect_caoncat, select/ find_all, reject, grep, zip, take, #take_while, drop, #drop_while, and cycle enumerate values only on as-needed basis.<ref>http://www.ruby-doc.org/core-2.0.0/Enumerator/Lazy.html</ref>

__TOC__
=='''How a lazy enumerator works'''==
A lazy enumerator in Ruby works as both a data consumer and a data producer. To understand how it’s done, we have to understand what an Enumerator::Generator and an Enumerator::Yielder is.

A simple way of creating an enumerable series of data in Ruby is to create an array. However if we want more flexibility in handling each element of the series while generating it, we can do so by using an Enumerator::Generator.<ref>33333333333333</ref> Consider the example below to create an Enumerator:

<pre>
even_natural_numbers = Enumerator.new do |yielder|
number = 0
loop do
number += 2
yielder.yield number
end
end
</pre>

Here a block with an yielder is passed to the constructor of the enumerator. Everytime the next method of the enumerator is called, the block is executed till the point the yielder is called in the line “yielder.yield number”. The control is passed to the yielder and returned back to the enumerator generator block when the “next” method is called on the enumerator again.

[[File:Enumerator-generator.png‎]]

To understand how the block is executed on each call of “next”, the above code can be modified as follows:
<pre>

even_natural_numbers = Enumerator.new do |yielder|
number = 0
loop do
number += 2
yielder.yield number
puts "continuing loop"
end
end

puts even_natural_numbers.next
puts even_natural_numbers.next

Output:
2
continuing loop
4

</pre>

On the first “next” call to ‘even_natural_numbers’, the value of number is 2 and it’s passed to the yielder. During the second “next” call, the execution of the generator block continues from the line ‘puts “continuing loop”’ and the blocks yields again with the value 4.

Printing the above even_natural_numbers object gives the output:
#<Enumerator: #<Enumerator::Generator:0x007fbb040b2e28>:each>

This shows that the enumerator object is created with a reference to an internal object called Enumerator::Generator and the “each” method is setup to call that generator.

In the above example, the enumerator acts as a lazy generator i.e. generating new numbers of the series only on demand. By cascading multiple such lazy enumerators, each enumerator can be made to act as a data generator as well as a consumer. Consider an example where the first 10 even numbers which are also multiples of 5 are to be generated:

If the “select” method is used on the enumerator “even_natural_numbers” as follows, an infinite loop is produced:

<pre>
puts even_natural_numbers.select {|v| v%5==0}.first(10)

</pre>
The reason behind the infinite loop is that the “select” method tries to iterate over the entire collection and doesn’t pass the control to the next method in line unless the collection is exhausted which, in an infinite collection, never happens. Hence it’s necessary to define a lazy version of the select method to do something useful with the infinite range that’s being lazily generated. The code given below adds a lazy version of the “select” method to the existing “Enumerator” class:

<pre>
class Enumerator
def lazy_select(&block)
Enumerator.new do |yielder|
self.each do |val|
yielder.yield(val) if block.call(val)
end
end
end
end

</pre>

The lazy_select method creates an enumerator which yields to the next method in line on selecting each value that satisfies the condition in the block.

=='''Differences '''==
If you try to iterate over an infinite range in Enumerator then it will run into an endless loop while with Enumerator::Lazy you can avoid endless loop and get just the value you need.<ref>http://patshaughnessy.net/2013/4/3/ruby-2-0-works-hard-so-you-can-be-lazy</ref>

<pre>

> range = 1..Float::INFINITY
> range.collect { |n| n**2}.first(10) #endless loop

</pre>

but with lazy,

<pre>

> range = 1..Float::INFINITY
> range.lazy.collect { |n| n**2}.first(10)
=> [1, 4, 9, 16, 25, 36, 49, 64, 81, 100]

</pre>

Enumerator::Lazy acts just like the original, but it re-implements methods such as select and map so that they can work with infinite sequences. The lazy versions of the various methods do not return arrays of data. Instead, it returns a new enumerator that includes its own special processing—below example of map method returns an enumerator.<ref>http://patshaughnessy.net/2013/4/3/ruby-2-0-works-hard-so-you-can-be-lazy</ref>

<pre>

> range = 1..100
> range.map{|n| n**2}.take(10) #returns array
=> [1, 4, 9, 16, 25, 36, 49, 64, 81, 100]

</pre>

but with lazy,

<pre>

> range.lazy.map{|n| n**2}.take(10) #returns enumerator
=>#<Enumerator::Lazy:#<Enumerator::Lazy:#<Enumerator::Lazy:1..100>:map>:take(10)>

</pre>

=='''Examples '''==

===Example 1===

<pre>

require 'date'
require ‘benchmark’
Benchmark.bm(8) do |x|
x.report("Non Lazy :") do
puts (Date.new(2015)..Date.new(9999)).select{|d| d.day == 13 and d.friday?}.first(10)
end
x.report("Lazy :") do
puts (Date.new(2015)..Date.new(9999)).lazy.select{|d| d.day == 13 and d.friday?}.first(10)
end
end

</pre>

===Example 2===

This example give you idea of using lazy enumeration in file read example and comparing with non lazy enumeration way

<pre>

require 'benchmark'
fileName = "C:\\sample.txt"
Benchmark.bm(8) do |x|
x.report("Non Lazy :") do
50.times { File.readlines(fileName).detect { |line| line =~ /110216/i} }
end
x.report("Lazy :") do
50.times { File.open(fileName).lazy.detect { |line| line =~ /110216/i} }
end
end

</pre>

If you deal with large data and start chaining multiple enumeration methods together, the use of lazy evaluation prevents you from using unnecessary amounts of memory in temporary variables which makes lazy evaluation faster than non lazy evaluation.

=='''Drawbacks'''==

===Example===
We have seen usage and benefits of lazy enumeration in above examples but below simple example will give you drawback of it.

<pre>

require 'benchmark'
Benchmark.bm(8) do |x|
x.report("Non Lazy :") do
(1..10000000).select { |i| i % 3 == 0 || i % 5 == 0}.reduce(:+)
end
x.report("Lazy :") do
(1..10000000).lazy.select { |i| i % 3 == 0 || i % 5 == 0}.reduce(:+)
end
end

</pre>

Lazy enumeration is act as a proxy in between program and data so sometimes lazy enumeration gives non negligible performance hit. It is recommended not to use lazy enumeration everywhere as it adds another layer.<ref>https://bugs.ruby-lang.org/issues/6183</ref>

=='''References'''==
<references/>

File:Enumerator-generator.png

2015-02-09T16:44:56Z

Achandr9: