Fri Apr 16 09:12:27 2021
EVENTS
 FREE
SOFTWARE
INSTITUTE

POLITICS
JOBS
MEMBERS'
CORNER

MAILING
LIST

NYLXS Mailing Lists and Archives
NYLXS Members have a lot to say and share but we don't keep many secrets. Join the Hangout Mailing List and say your peice.

DATE 2016-11-01

LEARN

2021-04-16 | 2021-03-16 | 2021-02-16 | 2021-01-16 | 2020-12-16 | 2020-11-16 | 2020-10-16 | 2020-09-16 | 2020-08-16 | 2020-07-16 | 2020-06-16 | 2020-05-16 | 2020-04-16 | 2020-03-16 | 2020-02-16 | 2020-01-16 | 2019-12-16 | 2019-11-16 | 2019-10-16 | 2019-09-16 | 2019-08-16 | 2019-07-16 | 2019-06-16 | 2019-05-16 | 2019-04-16 | 2019-03-16 | 2019-02-16 | 2019-01-16 | 2018-12-16 | 2018-11-16 | 2018-10-16 | 2018-09-16 | 2018-08-16 | 2018-07-16 | 2018-06-16 | 2018-05-16 | 2018-04-16 | 2018-03-16 | 2018-02-16 | 2018-01-16 | 2017-12-16 | 2017-11-16 | 2017-10-16 | 2017-09-16 | 2017-08-16 | 2017-07-16 | 2017-06-16 | 2017-05-16 | 2017-04-16 | 2017-03-16 | 2017-02-16 | 2017-01-16 | 2016-12-16 | 2016-11-16 | 2016-10-16 | 2016-09-16 | 2016-08-16 | 2016-07-16 | 2016-06-16 | 2016-05-16 | 2016-04-16 | 2016-03-16 | 2016-02-16 | 2016-01-16 | 2015-12-16 | 2015-11-16 | 2015-10-16 | 2015-09-16 | 2015-08-16 | 2015-07-16 | 2015-06-16 | 2015-05-16 | 2015-04-16 | 2015-03-16 | 2015-02-16 | 2015-01-16 | 2014-12-16 | 2014-11-16 | 2014-10-16

Key: Value:

Key: Value:

MESSAGE
DATE 2016-11-06
FROM Ruben Safir
SUBJECT Re: [Learn] Fwd: templates within templates
From learn-bounces-at-nylxs.com Sun Nov 6 02:08:59 2016
Return-Path:
X-Original-To: archive-at-mrbrklyn.com
Delivered-To: archive-at-mrbrklyn.com
Received: from www.mrbrklyn.com (www.mrbrklyn.com [96.57.23.82])
by mrbrklyn.com (Postfix) with ESMTP id D523A161312;
Sun, 6 Nov 2016 02:08:58 -0500 (EST)
X-Original-To: learn-at-nylxs.com
Delivered-To: learn-at-nylxs.com
Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89])
by mrbrklyn.com (Postfix) with ESMTP id 16F59160E77
for ; Sun, 6 Nov 2016 02:08:54 -0500 (EST)
Received: from [10.0.0.62] (www.mrbrklyn.com [96.57.23.82])
by mailbackend.panix.com (Postfix) with ESMTPSA id 81DBB196B5
for ; Sun, 6 Nov 2016 02:08:54 -0500 (EST)
To: learn-at-nylxs.com
References:




<776149bb-7ba3-3fcd-9d1d-9a0dc3c72069-at-mrbrklyn.com>
<5e897753-b0d1-4f34-9331-5cde04e7d61a.maildroid-at-localhost>
<88478b52-0672-c74e-4177-2552ebda5976-at-mrbrklyn.com>
From: Ruben Safir
Message-ID: <4a159569-653c-f84c-02ee-7f5fa6236dcf-at-panix.com>
Date: Sun, 6 Nov 2016 02:08:53 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <88478b52-0672-c74e-4177-2552ebda5976-at-mrbrklyn.com>
Subject: Re: [Learn] Fwd: templates within templates
X-BeenThere: learn-at-nylxs.com
X-Mailman-Version: 2.1.17
Precedence: list
List-Id:
List-Unsubscribe: ,

List-Archive:
List-Post:
List-Help:
List-Subscribe: ,

Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: learn-bounces-at-nylxs.com
Sender: "Learn"

http://www-h.eng.cam.ac.uk/help/tpl/talks/C++graphs.html


Trees, Graphs and C++

This document aims to provide enough background information to
encourage you to write graph-related C++ code. First some Standard
Containers are shown in action, and their use extended to deal with
user-defined classes. Then some Tree and Graph concepts are introduced.
Finally implementation ideas are given to help tackle some exercises,
building on C++'s supplied containers.

Introduction to Standard Containers

Many books exist dealing with sorting and organising data. With the
emergence of languages that support data abstraction, people tried to
generalise data structures. The Smalltalk language introduced some
useful ideas. These have been developed and brought into the mainstream
with C++'s Standard Library. The Standard Library includes containers
that hold data. Containers are grouped into 3 types

Sequential - the order of the elements matter (e.g. vector)
Associative - the order of the elements doesn't matter (e.g. set)
Adapters - containers that are modifications of other containers
(e.g. stack)

These containers have many member functions in common. For example,
s.size() gives the number of elements in the container s if s is a set,
a list or even a string of characters. The Standard Library also
includes algorithms that operate on the containers. To be of maximum use
these algorithms need to be able to operate on as many types of
containers as possible, so each container has member functions that give
algorithms access to the data. For example, s.begin() will always return
an Iterator (like a pointer) to the first element of a container s. By
hiding the implementation details of containers in this way, high-level
generic algorithms can be written which will not only work with the
standard containers but also with any new containers that a programmer
might write.

The Standard Library doesn't contain a tree container, but if you wrote
one so that it had the standard hooks that algorithms require, then
algorithms like copy etc. should work with it. Clearly a tree container
would require some special routines that other containers wouldn't
support, but C++ makes it easy to add functionality in, building on what
you already have.

....


University of Cambridge
Department of Engineering
Computing Help

Introduction to Standard Containers
Developing Containers
Queues
Trees
Tree Traversal
Graphs
Graph Traversal
Implementing Graph Algorithms
References
Exercises

Trees, Graphs and C++

This document aims to provide enough background information to
encourage you to write graph-related C++ code. First some Standard
Containers are shown in action, and their use extended to deal with
user-defined classes. Then some Tree and Graph concepts are introduced.
Finally implementation ideas are given to help tackle some exercises,
building on C++'s supplied containers.

Introduction to Standard Containers

Many books exist dealing with sorting and organising data. With the
emergence of languages that support data abstraction, people tried to
generalise data structures. The Smalltalk language introduced some
useful ideas. These have been developed and brought into the mainstream
with C++'s Standard Library. The Standard Library includes containers
that hold data. Containers are grouped into 3 types

Sequential - the order of the elements matter (e.g. vector)
Associative - the order of the elements doesn't matter (e.g. set)
Adapters - containers that are modifications of other containers
(e.g. stack)

These containers have many member functions in common. For example,
s.size() gives the number of elements in the container s if s is a set,
a list or even a string of characters. The Standard Library also
includes algorithms that operate on the containers. To be of maximum use
these algorithms need to be able to operate on as many types of
containers as possible, so each container has member functions that give
algorithms access to the data. For example, s.begin() will always return
an Iterator (like a pointer) to the first element of a container s. By
hiding the implementation details of containers in this way, high-level
generic algorithms can be written which will not only work with the
standard containers but also with any new containers that a programmer
might write.

The Standard Library doesn't contain a tree container, but if you wrote
one so that it had the standard hooks that algorithms require, then
algorithms like copy etc. should work with it. Clearly a tree container
would require some special routines that other containers wouldn't
support, but C++ makes it easy to add functionality in, building on what
you already have.
Developing Containers

Ways to extend the basic use of containers include

Using standard containers to store user-defined objects (see later)
Creating completely new containers (see the References section for
examples)
Building new containers from existing ones (note however that
containers weren't designed to be inherited from - they don't have a
virtual destructor for example - so take care)

Queues

Before we look at trees, let's see how to use some simpler containers.

#include
#include
#include
using namespace std;

int main()
{
deque Q; // An empty, elastic, container ready to hold ints.
// A deque is a double-ended queue. Queues (unlike lists) are
// data structures where you wouldn't expect to insert new items
// anywhere else but at the ends

Q.push_back(0); // Many containers have a push_back
// routine. It's a way to add elements
// to a container in a safe way - the
// container will grow if it's not big enough.
Q.push_back(2);
Q.push_back(1);

for(int i=0;i cout << Q[i].value; cout << " ";
}
cout <
// Now let's sort!
sort(Q.begin(), Q.end());
// the arguments we've given to sort mean that the whole queue
// will be sorted, and that the result will be copied back to
// the original queue. sort uses the default sorting criterium
// for integers, and can use the swap function of Q to switch
// elements around.

for(int i=0;i cout << Q[i].value; cout << " ";
}
cout <// Output: 0 1 2

}

To create a queue of strings rather than a queue of integers, we don't
need to change much. This ease of coping with different data types will
be useful when we come to create trees.

#include
#include // added so that we can use strings
#include
#include
using namespace std;

int main()
{
deque Q; // changed

Q.push_back("standard");
Q.push_back("template");

Q.push_back("library");

for(int i=0;i cout << Q[i].value; cout << " ";
}
cout <
// Now let's sort!
sort(Q.begin(), Q.end());
// sort uses the default sorting criterium for strings - alphabetical

for(int i=0;i cout << Q[i].value; cout << " ";
}
cout <}

As well as being able to have queues of standard items like strings and
integers, we can also invent our own types and have queues of those. The
main problem is that when we sort we have to specify the sort criteria
for our own types. It's sufficient to specify what the '<' operator
should do for your own type. Here's an example

#include
#include
#include
using namespace std;

class simple {
public:
int value;
// redefine the '<' operator, so when 2 simple objects are
// compared, the 'value' fields of the objects are compared.
const bool operator<(const simple &rhs) const
{ return this->value < rhs.value; }
};

int main()
{
deque Q; // An empty, elastic, container.

simple s;
s.value=0;
Q.push_back(s);
s.value=2;
Q.push_back(s);
s.value=1;
Q.push_back(s);

for(int i=0;i cout << Q[i].value; cout << " ";
}
cout < // Output: 0 2 1

// Now let's sort! sort uses the '<' operator that we created in the
'simple' class
sort(Q.begin(), Q.end());

for(int i=0;i cout << Q[i].value; cout << " ";
}
cout < // Output: 0 1 2
}

Trees

There are many types of tree structures (threaded trees, Splay trees,
2-3 trees, etc). The choice depends on many factors - how dynamic the
data is, whether best-case or worst-case behaviour is the most
important, whether you want to avoid recursion, etc. Trees are often a
natural choice (e.g. when writing a chess program) but they are also
effective in many situations where data that's received sequentially can
be beneficially stored in a more organised fashion - e.g. parsing
mathematical expressions, parsing sentences, reading words that later
need to be searched, or retrieved in alphabetical order.

Binaries trees (where each node has at most 2 children) are commonly
used - not because they most closely model reality, but because they're
computationally and mathematically more easy to deal with.

Suppose that a program were to be given 10,000 words (non-unique) and
had to list the unique words used. Suppose also that memory was at a
premium, so that storing every non-unique word is to be avoided. Each
time a word is read the program needs to check if the word's new and
store it only if it is. If the words are stored in an array
alphabetically, searching will be faster, but adding a word to the start
of the array will be slow because subsequent words will have to be shifted.

Using a binary tree will speed things up. Each time a word is read, the
program starts at the top of the tree. If the node is empty, the word is
stored there, otherwise the left or right branch is taken according to
whether the word comes before or after the word stored in the node. For
example, suppose the first 5 words were "standard", "template",
"library", "data" and "structures". "standard" would be stored in the
top node. "template" would be stored in the right-child node of the top
node. "library" would be stored in the left-child node of the top node.

standard
/ \
library template

"data" comes before "standard" so the left link will be taken. "data"
comes before "library", so "data" will be stored in the left-child node
of "library". The final tree looks like this

standard
/ \
library template
/ /
data structures

If this tree remains balanced, then it could fit 10,000 words within 15
layers, so a word-search would require only 15 comparisons at most.
Insertions (new nodes) are cheap too. Contrast this with the worst case
array scenario, where 10,000 comparisons might need to be made before a
search is complete!
However, if the words are supplied in alphabetical order, this
tree-based method suffers - each new word will add a right-node,
deepening the tree each time, making searching as slow as with arrays.
Various techniques exist to combat this. The benefits of these
techniques are so enormous that simple binary trees aren't used in big
programs - see the appendix.
Tree Traversal

There are 2 basic approaches to brute-force tree searching -
breadth-first and depth-first. With breadth-first you start at the top
node then visit all its childen before visiting its children's childen -
i.e. you explore the tree layer by layer. With depth-first searching you
keep going down, backtracking when you can go no further. The purpose of
the search and the shape of the tree affect the choice of approach. For
example, if you're playing chess and you don't have much time to think,
it's better to do a breadth-first search rather than looking at one move
(which might be bad anyway) at great depth.

With either method there's a choice of ways to order operations on the node.

pre-order - node, left-branch, right-branch
in-order - left-branch, node, right-branch
post-order - left-branch, right-branch, node

As an example consider the following tree, which represents a
mathematical expression.

-
/ \
* *
/ \ / \
2 + 3 -
/ \ / \
x 5 y 4

If you do a depth-first search, processing each left-branch and
right-branch of a node before printing the node's contents you'll get

2 x 5 + * 3 y 4 - * -

(check to see if you agree with this!) which is the expression in
post-fix notation but if you deal with nodes differently (still
depth-first search, but this time processing the left-branch, printing
the contents of the node, then processing the right-branch) you'll get
something much closer to the normal representation.

The depth-first algorithm can be described more formally as follows

Form one element queue Q consisting of the root node
Until the Q is empty or the goal has been reached, determine if the
first element in Q is the goal.
If it is, do nothing
If is isn't, remove the first element from Q and add the first
element's children, if any, to the front of the queue (so that children
are searched before siblings)
If the goal is reached, success; else failure


--
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com

DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com

Being so tracked is for FARM ANIMALS and and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013
_______________________________________________
Learn mailing list
Learn-at-nylxs.com
http://lists.mrbrklyn.com/mailman/listinfo/learn

  1. 2016-11-01 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] how is it indexing in cuda
  2. 2016-11-01 Ruben Safir <ruben.safir-at-my.liu.edu> Re: [Learn] not adequately speced of explained
  3. 2016-11-01 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] how is it indexing in cuda
  4. 2016-11-01 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] not adequately speced of explained
  5. 2016-11-02 Christopher League <league-at-contrapunctus.net> Re: [Learn] Fitch Algorithm - C++
  6. 2016-11-02 Ruben Safir <mrbrklyn-at-panix.com> Re: [Learn] Fitch Algorithm - C++
  7. 2016-11-02 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] how is it indexing in cuda
  8. 2016-11-02 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fitch Algorithm - C++
  9. 2016-11-02 IEEE Computer Society <csconnection-at-computer.org> Subject: [Learn] Hear Google's John Martinis Take on Quantum Computing at
  10. 2016-11-02 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] opencl
  11. 2016-11-02 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] scheduled for tommorw
  12. 2016-11-02 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] threads tutorial
  13. 2016-11-03 Ruben Safir <mrbrklyn-at-panix.com> Re: [Learn] Fitch Algorithm - C++
  14. 2016-11-03 Ruben Safir <mrbrklyn-at-panix.com> Re: [Learn] Fitch Algorithm - C++
  15. 2016-11-03 Ruben Safir <mrbrklyn-at-panix.com> Re: [Learn] Fitch Algorithm - C++
  16. 2016-11-03 Christopher League <league-at-contrapunctus.net> Re: [Learn] huffman code
  17. 2016-11-03 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] huffman code
  18. 2016-11-03 Ruben Safir <ruben.safir-at-my.liu.edu> Re: [Learn] huffman code
  19. 2016-11-03 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fitch algorithm from the beginning
  20. 2016-11-03 From: <mrbrklyn-at-panix.com> Subject: [Learn] huffman code
  21. 2016-11-03 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Phenology meeting
  22. 2016-11-03 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] relevant hackathon
  23. 2016-11-03 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] relevant hackathon
  24. 2016-11-04 Ruben Safir <mrbrklyn-at-panix.com> Re: [Learn] huffman code
  25. 2016-11-04 Christopher League <league-at-contrapunctus.net> Subject: [Learn] Fitch/Sankoff
  26. 2016-11-05 Christopher League <league-at-contrapunctus.net> Re: [Learn] Fwd: templates within templates
  27. 2016-11-05 ruben safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: Re: const T vs T const
  28. 2016-11-05 ruben safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: Template Library files and Header linking troubles
  29. 2016-11-05 ruben safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: templates within templates
  30. 2016-11-06 Ruben Safir <mrbrklyn-at-panix.com> Re: [Learn] Fwd: templates within templates
  31. 2016-11-06 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] Fwd: templates within templates
  32. 2016-11-06 Ruben Safir <mrbrklyn-at-panix.com> Re: [Learn] Fwd: templates within templates
  33. 2016-11-06 Christopher League <league-at-contrapunctus.net> Re: [Learn] Fwd: templates within templates
  34. 2016-11-06 Ruben Safir <mrbrklyn-at-panix.com> Re: [Learn] Fwd: templates within templates
  35. 2016-11-06 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] Fwd: templates within templates
  36. 2016-11-06 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] Fwd: templates within templates
  37. 2016-11-06 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] GNU Parallel 20161022 ('Matthew') released [stable]
  38. 2016-11-07 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] templates and ostream for future reference
  39. 2016-11-08 Christopher League <league-at-contrapunctus.net> Re: [Learn] C++ signature ambiguity
  40. 2016-11-08 Ruben Safir <ruben.safir-at-my.liu.edu> Re: [Learn] C++ signature ambiguity
  41. 2016-11-08 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] C++ signature ambiguity
  42. 2016-11-08 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: Invitation: Phylogeny meeting -at- Weekly from 10:15 to
  43. 2016-11-08 Ruben Safir <mrbrklyn-at-panix.com> Subject: [Learn] Fwd: [nylug-talk] RSVP open: Wed Nov 16,
  44. 2016-11-09 Christopher League <league-at-contrapunctus.net> Re: [Learn] merge sort parallel hw
  45. 2016-11-09 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] merge sort parallel hw
  46. 2016-11-09 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] merge sort parallel hw
  47. 2016-11-09 Christopher League <league-at-contrapunctus.net> Re: [Learn] merge sort parallel hw
  48. 2016-11-09 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] mergesort tutorial
  49. 2016-11-09 Christopher League <league-at-contrapunctus.net> Re: [Learn] mergesort tutorial
  50. 2016-11-09 Christopher League <league-at-contrapunctus.net> Re: [Learn] namespace and external files confusion
  51. 2016-11-09 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] namespace and external files confusion
  52. 2016-11-09 From: "Carlos R. Mafra" <crmafra-at-gmail.com> Re: [Learn] Question about a small change
  53. 2016-11-09 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] =?utf-8?q?C++_call_of_overloaded_=E2=80=98track=28int*=26?=
  54. 2016-11-09 ruben safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: lost arguments
  55. 2016-11-09 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: [dinosaur] Dating origins of dinosaurs,
  56. 2016-11-09 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] merge sort parallel hw
  57. 2016-11-09 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] mergesort tutorial
  58. 2016-11-09 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] namespace and external files confusion
  59. 2016-11-10 Christopher League <league-at-contrapunctus.net> Re: [Learn] merge sort parallel hw
  60. 2016-11-10 Ruben Safir <mrbrklyn-at-panix.com> Re: [Learn] merge sort parallel hw
  61. 2016-11-10 Ruben Safir <mrbrklyn-at-panix.com> Re: [Learn] merge sort parallel hw
  62. 2016-11-10 Ruben Safir <ruben.safir-at-my.liu.edu> Re: [Learn] merge sort parallel hw
  63. 2016-11-10 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] [Hangout-NYLXS] mergesort tutorial
  64. 2016-11-10 Ruben Safir <mrbrklyn-at-panix.com> Subject: [Learn] Fwd: [Hangout-NYLXS] ease your mind- everything in the
  65. 2016-11-10 Ruben Safir <ruben.safir-at-my.liu.edu> Subject: [Learn] Fwd: [Hangout-NYLXS] R Programming Workshop
  66. 2016-11-10 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Paleocast phenogenetic tree building
  67. 2016-11-11 Christopher League <league-at-contrapunctus.net> Re: [Learn] merge sort parallel hw
  68. 2016-11-12 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] HW of mergesort in parallel
  69. 2016-11-13 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] merge sort in parallel assignment
  70. 2016-11-14 Christopher League <league-at-contrapunctus.net> Re: [Learn] merge sort in parallel assignment
  71. 2016-11-14 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] merge sort in parallel assignment
  72. 2016-11-14 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] merge sort parallel hw
  73. 2016-11-14 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] CUDA and video
  74. 2016-11-14 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] PNG Graphic formats and CRCs
  75. 2016-11-15 ruben safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: PNG coding
  76. 2016-11-15 ruben safir <ruben.safir-at-my.liu.edu> Subject: [Learn] Fwd: PNG Coding
  77. 2016-11-16 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] Fwd: lost arguments
  78. 2016-11-16 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] relevant hackathon
  79. 2016-11-16 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] C++ Workshop Announcement
  80. 2016-11-16 Ruben Safir <mrbrklyn-at-panix.com> Subject: [Learn] Fwd: Re: ref use
  81. 2016-11-16 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] ref use
  82. 2016-11-16 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] why use a reference wrapper int his example
  83. 2016-11-17 Ruben Safir <mrbrklyn-at-panix.com> Re: [Learn] [Hangout-NYLXS] at K&R now
  84. 2016-11-17 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: [Hangout-NYLXS] Fwd: PNG Coding
  85. 2016-11-18 ruben safir <ruben-at-mrbrklyn.com> Subject: [Learn] C++ workshop and usenet responses
  86. 2016-11-19 ruben safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: ref use
  87. 2016-11-20 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] when is the constructor called for an object
  88. 2016-11-21 ruben safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: creating a binary tree
  89. 2016-11-21 ruben safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: hidden static
  90. 2016-11-21 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: ISBI 2017 Call for Abstracts and Non-Author
  91. 2016-11-21 ruben safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: PNG coding
  92. 2016-11-21 ruben safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: Re: the new {} syntax
  93. 2016-11-21 ruben safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: when is the constructor called for an object
  94. 2016-11-21 ruben safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: when is the constructor called for an object
  95. 2016-11-21 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: [dinosaur] Eoconfuciusornis feather keratin and
  96. 2016-11-21 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] look what I found
  97. 2016-11-22 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Cuccuency book
  98. 2016-11-22 ruben safir <ruben.safir-at-my.liu.edu> Subject: [Learn] declare a func or call an object
  99. 2016-11-22 Ruben Safir <ruben.safir-at-my.liu.edu> Subject: [Learn] Fwd: Re: Using CLIPS as a library
  100. 2016-11-23 Ruben Safir <ruben.safir-at-my.liu.edu> Subject: [Learn] Fwd: Simple C++11 Wrapper for CLIPS 6.30
  101. 2016-11-23 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Parrelel Programming HW2 with maxpath
  102. 2016-11-24 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] great research news for big data
  103. 2016-11-24 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] mapping algorithms
  104. 2016-11-24 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Todays meeting
  105. 2016-11-25 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: [dinosaur] Flightless theropod phylogenetic variation
  106. 2016-11-26 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] Note to self for Thursday
  107. 2016-11-26 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fitch etc
  108. 2016-11-26 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Note to self for Thursday
  109. 2016-11-26 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] operator<<() overloading details and friend
  110. 2016-11-27 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] 130 year old feathers analysis
  111. 2016-11-27 ruben safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: ACM/SPEC ICPE 2017 - Call for Tutorial Proposals
  112. 2016-11-27 ruben safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: ACM/SPEC ICPE 2017 - Call for Workshop Proposals
  113. 2016-11-27 ruben safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: CfP 22nd Conf. Reliable Software Technologies,
  114. 2016-11-27 ruben safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: Seeking contributors for psyche-c
  115. 2016-11-29 Christopher League <league-at-contrapunctus.net> Re: [Learn] Look at this exciting output by my test program
  116. 2016-11-29 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] Look at this exciting output by my test program
  117. 2016-11-29 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] Look at this exciting output by my test program
  118. 2016-11-29 Christopher League <league-at-contrapunctus.net> Re: [Learn] Quantum Entanglement
  119. 2016-11-29 Ruben Safir <mrbrklyn-at-panix.com> Re: [Learn] Quantum Entanglement
  120. 2016-11-29 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Here is the paper I was talking out
  121. 2016-11-29 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Look at this exciting output by my test program
  122. 2016-11-29 nylxs <mrbrklyn-at-optonline.net> Subject: [Learn] Look at this exciting output by my test program
  123. 2016-11-29 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Quantum Entanglement
  124. 2016-11-29 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] The Death of PBS
  125. 2016-11-29 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] witmer lab ohio and 3d imaging
  126. 2016-11-30 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] phylogenetic crawler

NYLXS are Do'ers and the first step of Doing is Joining! Join NYLXS and make a difference in your community today!