Tuesday, 26 March 2013
Monday, 11 March 2013
| day | 8:30-9:20 | 9:40-10:30 | 10:50-11:40 |
| Monday | Communication Skill Mr.Farrukh Kamran | Communication Skill Mr.Farrukh Kamran | Assembly langauge Mr.Saif-ur-Rehman |
| Tuesday | OOP Ms.Rabia Khan | Web Engineering Mr.Roman | Assembly langauge Mr.Saif-ur-Rehman |
| Wednesday | Communication Skill Mr.Farrukh Kamran | Artificial Intilligence Mr.M.Sohail | OOP Ms.Rabia Khan |
| Thursday | Web Engineering Mr.Roman | Artificial Intilligence Mr.M.Sohail | Assembly langauge Mr.Saif-ur-Rehman |
| Friday | Web Engineering Mr.Roman | Artificial Intilligence Mr.M.Sohail | OOP Ms.Rabia Khan |
Difference Between Graph and Tree
Graph vs Tree
Graph and Tree are used in data
structures. There are certainly some differences between Graph and Tree.
A set of vertices having a binary relation is called a graph whereas
tree is a data structure that has a set of nodes linked to each other.
Graph
A graph is a set of items that are
connected by edges and each item is known as node or vertex. In other
words, a graph can be defined as the set of vertices and there is a
binary relation between these vertices.
In implementation of a graph, the nodes
are implemented as objects or structures. The edges can be represented
in different ways. One of the ways is that each node can be associated
with an incident edges array. If the information is to be stored in
nodes rather than edges then the arrays acts as pointers to nodes and
also represent edges. One of the advantages of this approach is that
additional nodes can be added to the graph. Existing nodes can be
connected by adding elements to arrays. But there is one disadvantage
because time is required in order to determine whether there is an edge
between the nodes.
Other way to do this is to keep a two
dimensional array or matrix M that has Boolean values. The existence of
edge from node i to j is specified by entry Mij. One of the advantages
of this method is to find out if there is any edge between two nodes.
Tree
Tree is also a data structure used in
computer science. It is similar to the structure of the tree and has a
set of nodes that are linked to each other.
A node of a tree may contain a condition
or value. It can also be a tree of its own or it can represent a
separate data structure. Zero or more nodes are present in a tree data
structure. If a node has a child then it is called parent node of that
child. There can be at most one parent of a node. The longest downward
path from the node to a leaf is the height of the node. The depth of
node is represented by the path to its root.
In a tree, the topmost node is called
root node. The root node has no parents as it is the top most one. From
this node, all tree operations begin. By using links or edges, other
nodes can be reached from the root node. The bottom-most level nodes are
called leaf nodes and they don’t have any children. The node that has
number of child nodes is called inner node or internal node.
|
Difference between graph and tree: • A tree can be described as a specialized case of graph with no self loops and circuits. • There are no loops in a tree whereas a graph can have loops. • There are three sets in a graph i.e. edges, vertices and a set that represents their relation while a tree consists of nodes that are connected to each other. These connections are referred to as edges. • In tree there are numerous rules spelling out how connections of nodes can occur whereas graph has no rules dictating the connection among the nodes. |
Related posts:
Tags: C, Computer Science, Data Structures, EDGE, graph, Integer, Java, Node, Pointer, programming language, tree, Vertex
DISQUS seems to be taking longer than usual. Reload?
Copyright © 2010-2012 Difference Between.
All rights reserved.
Terms of Use and Privacy Policy : Legal.
By Mujtaba Khan
Difference Between Graph and Tree
Graph vs Tree
Graph and Tree are used in data
structures. There are certainly some differences between Graph and Tree.
A set of vertices having a binary relation is called a graph whereas
tree is a data structure that has a set of nodes linked to each other.
Graph
A graph is a set of items that are
connected by edges and each item is known as node or vertex. In other
words, a graph can be defined as the set of vertices and there is a
binary relation between these vertices.
In implementation of a graph, the nodes
are implemented as objects or structures. The edges can be represented
in different ways. One of the ways is that each node can be associated
with an incident edges array. If the information is to be stored in
nodes rather than edges then the arrays acts as pointers to nodes and
also represent edges. One of the advantages of this approach is that
additional nodes can be added to the graph. Existing nodes can be
connected by adding elements to arrays. But there is one disadvantage
because time is required in order to determine whether there is an edge
between the nodes.
Other way to do this is to keep a two
dimensional array or matrix M that has Boolean values. The existence of
edge from node i to j is specified by entry Mij. One of the advantages
of this method is to find out if there is any edge between two nodes.
Tree
Tree is also a data structure used in
computer science. It is similar to the structure of the tree and has a
set of nodes that are linked to each other.
A node of a tree may contain a condition
or value. It can also be a tree of its own or it can represent a
separate data structure. Zero or more nodes are present in a tree data
structure. If a node has a child then it is called parent node of that
child. There can be at most one parent of a node. The longest downward
path from the node to a leaf is the height of the node. The depth of
node is represented by the path to its root.
In a tree, the topmost node is called
root node. The root node has no parents as it is the top most one. From
this node, all tree operations begin. By using links or edges, other
nodes can be reached from the root node. The bottom-most level nodes are
called leaf nodes and they don’t have any children. The node that has
number of child nodes is called inner node or internal node.
| Difference between graph and tree: • A tree can be described as a specialized case of graph with no self loops and circuits. • There are no loops in a tree whereas a graph can have loops. • There are three sets in a graph i.e. edges, vertices and a set that represents their relation while a tree consists of nodes that are connected to each other. These connections are referred to as edges. • In tree there are numerous rules spelling out how connections of nodes can occur whereas graph has no rules dictating the connection among the nodes. |
Related posts:
Tags: C, Computer Science, Data Structures, EDGE, graph, Integer, Java, Node, Pointer, programming language, tree, Vertex
Copyright © 2010-2012 Difference Between.
All rights reserved.
Terms of Use and Privacy Policy : Legal.
Wednesday, 6 March 2013
html by Mujtaba
Introduction to HTML 3.0
HyperText Markup Language (HTML) is a simple markup system used to create hypertext documents that are portable from one platform to another. HTML documents are SGML documents with generic semantics that are appropriate for representing information from a wide range of applications. HTML markup can represent hypertext news, mail, documentation, and hypermedia; menus of options; database query results; simple structured documents with in-lined graphics; and hypertext views of existing bodies of information.
HTML has been in use by the World-Wide Web (WWW) global information initiative since 1990. The HTML 3.0 specification provides a number of new features, and is broadly backwards compatible with HTML 2.0. It is defined as an application of International Standard ISO ISO8879:1986 Standard Generalized Markup Language (SGML). This specificiation will be proposed as the Internet Media Type (RFC 1590) and MIME Content Type (RFC 1521) called "text/html; version=3.0".
How to participate in refining HTML 3.0
The process of refining HTML 3.0 into a formal standard will be carried out by the IETF HTML working group. The World Wide Web Organization is continuing to develop a freeware testbed browser for HTML 3.0 ("Arena") to encourage people to try out the proposed features. The discussion list for HTML 3.0 is www-html with html-wg reserved for use by the IETF working group for detailed matters relating to the formal specification. The process for developing HTML 3.0 is open, and anyone who is interested and able to contribute to this effort is welcome to join in.
Note: make mailing list names into hypertext links to their archives and add info on how to join these lists
HTML 3.0 Overview
HTML 3.0 builds upon HTML 2.0 and provides full backwards compatibility. Tables have been one of the most requested features, with text flow around figures and math as runners up. Traditional SGML table models, e.g. the CALS table model, are really complex. The HTML 3.0 proposal for tables uses a lightweight style of markup suitable for rendering on a very wide range of output devices, including braille and speech synthesizers.
HTML 3.0 introduces a new element: FIG for inline figures. This provides for client-side handling of hotzones while cleanly catering for non-graphical browsers. Text can be flowed around figures and you can control when to break the flow to begin a new element.
Including support for equations and formulae in HTML 3.0 adds relatively little complexity to a browser. The proposed format is strongly influenced by TeX. Like tables, the format uses a lightweight style of markup - simple enough to type in by hand, although it will in most cases be easier to use a filter from a word processing format or a direct HTML 3.0 wysiwyg editor. The level of support is compatible with most word processing software, and avoids the drawbacks from having to convert math to inline images.
The Web has acted as a huge exercise in user testing, and we have been able to glean lots of information from the ways people abuse HTML in trying to get a particular effect; as well as from explicit demand for new features. HTML 3.0, as a result, includes support for customised lists; fine positioning control with entities like &emspace; horizontal tabs and horizontal alignment of headers and paragraph text.
Additional features include a static banner area for corporate logos, disclaimers and customized navigation/search controls. The LINK element can be used to provide standard toolbar/menu items for navigation, such as previous and next buttons. The NOTE element is used for admonishments such as notes, cautions or warnings, and also used for footnotes.
Forms have been extended to support graphical selection menus with client-side handling of events similar to FIG. Other new form field types include range controls, scribble on image, file upload and audio input fields. Client-side scripting of forms is envisaged with the script attribute of the FORM element. Forms and tables make for a powerful combination offering rich opportunities for laying out custom interfaces to remote information systems.
To counter the temptation to add yet more presentation features, HTML 3.0 is designed (but doesn't require) to be used together with style sheets which give rich control over document rendering, and can take into account the user's preferences, the window size and other resource limitations, such as which fonts are actually available. This work will eventually lead to smart layout under the author's control, with rich magazine style layouts for full screen viewing, switching to simpler layouts when the window is shrunk.
The SGML Open consortium is promoting use of DSSSL Lite by James Clark. This is a simplified subset of DSSSL - the document style semantics specification language. DSSSL is a ISO standard for representing presentation semantics for SGML documents, but is much too complex in its entirety to be well suited to the World Wide Web. Håkon Lie maintains a list of pointers to work on style sheets.
Transition Strategy from HTML 2.0
The use of the MIME content type: "text/html; version=3.0" is recommended to prevent existing HTML 2.0 user agents screwing up by attempting to show 3.0 documents. Tests have shown that the suggested content type will safely cause existing user agents to display the save to file dialog rather than incorrectly displaying the document as if it were HTML 2.0.
To make it easy for servers to distinguish 3.0 documents from 2.0 documents, it is suggested that 3.0 files are saved with the extension ".html3" (or ".ht3" for PCs). Servers can also exploit the accept headers in HTTP requests from HTML user agents, to distinguish whether each client can or cannot support HTML 3.0. This makes it practical for information providers to start providing HTML 3.0 versions of existing documents for newer user agents, without impacting older user agents. It is envisaged that programs will be made available for automatic down conversion of 3.0 to 2.0 documents. This conversion could be carried out in batch mode, or on the fly (with caching for greater efficiency).
Design Guidelines
The HTML 3.0 draft specification has been written to the following guidelines.
Lingua Franca for the Web
HTML is intended as a common medium for tying together information from widely different sources. A means to rise above the interoperability problems with existing document formats, and a means to provide a truly open interface to proprietary information systems.
Simplicity
The first version of HTML was designed to be extremely simple, both to author and to write browsers for. This has played a major role in the incredibly rapid growth of the World Wide Web. HTML 3.0 provides a clean superset of HTML 2.0 adding high value features such as tables, text flow around figures and math, while still remaining a simple document format. The pressures to adopt the complexities of traditional SGML applications has been resisted, for example the Department of Defense's CALS table model or the ISO 12083 math DTD.
Scaleability
As time goes by, people's expectations change, and more will be demanded of HTML. One manifestation of this is the pressure to add yet more tags. HTML 3.0 introduces a means for subclassing elements in an open-ended way. This can be used to distinguish the role of a paragraph element as being a couplet in a stansa, or a mathematical term as being a tensor. This ability to make fresh distinctions can be exploited to impart distinct rendering styles or to support richer search mechanisms, without further complicating the HTML document format itself. Scaleability is also achieved via URI based links for embedding information in other formats. Initially limited to a few image formats, inline support is expected to rapidly evolve to cover drawing formats, video, distributed virtual reality and a general means for embedding other applications.
Platform Independence
HTML is designed to allow rendering on a very wide range of devices, from clunky teletypes, to terminals, DOS, Windows, Macs and high end Workstations, as well as non-visual media such as speech and braille. In this, it allows users to exploit the legacy of older equipment as well as the latest and best of new machines. HTML 3.0 provides for improved support for non-graphical clients, allowing for rich markup in place of the figures shown on graphical clients. HTML can be rendered on a wide variety of screen sizes, using a scrolling or paged model. The fonts and presentation can be adjusted to suit the resources available in the host machine and the user's preferences.
Content not Presentation Markup
Information providers are used to tight control over the final appearence of documents. The need for platform independence weighs against this, but there is still a strong pressure to find appropriate means for information providers to express their intentions. The experience with proprietary document formats has shown the dangers of mixing presentation markup with content (or structural) markup. It becomes difficult to apply different presentation styles. It becomes painful to incorporate material from different sources (with different presentation styles). It becomes difficult to be truly platform independent. As a result, HTML 3.0 is designed for use with linked style information that defines the intended presentation style for each element. Style sheets can be expressed in a platform independent fashion or used to provide more detailed control for particular classes of clients or output media.
Support for Cascaded Style Sheets
For the Web, it is valuable to allow for a cascading of style preferences. The client has certain built-in preferences; the publisher may require a particular house style, e.g. for brand distinction; the author may feel the need to override the house style for special cases; the end-user may feel strongly about certain things, e.g. large fonts for easier visibility or avoiding certain colors due to an inability to distinguish between them. HTML 3.0 supports style sheets via the use of the LINK element to reference a style sheet with a URI. Authors can place overrides in separate style sheets or include them in the document head within the STYLE element. The effectiveness of caching mechanisms for speeding up the retrieval of style sheets is enhanced by the separation of style information into generic commonly used style sheets, and overrides specific to this document.
Support for Non-Visual Media
HTML 3.0 is designed to cater for the needs of the visually impaired. Markup for inline figures includes support for rich descriptions, along with hypertext links that double up as defining geometric hotzones for graphical browsers, simplifying the author's job in catering for the different groups of users. Table markup includes provision for abbreviated row and column names for each cell, which are essential for conversion to speech or braille. Math markup treats formulae and equations as hierarchies of expressions. This allows disambiguating pauses to be inserted in appropriate places during conversion to speech.
Support for different ways of creating HTML
HTML 3.0 has been designed to be created in a variety of different ways. It is deliberately simple enough to type in by hand. It can be authored using wysiwyg editors for HTML, or it can be generated via export filters from common word processing formats, or other SGML applications.
Mujtaba Ahmed Khan
Mujtaba Ahmed Khan
2 Introduction to HTML 4
2.1 What is the World Wide Web?
The World Wide Web (Web) is a network of information resources. The Web relies on three mechanisms to make these resources readily available to the widest possible audience:
- A uniform naming scheme for locating resources on the Web (e.g., URIs).
- Protocols, for access to named resources over the Web (e.g., HTTP).
- Hypertext, for easy navigation among resources (e.g., HTML).
The ties between the three mechanisms are apparent throughout this specification.
2.1.1 Introduction to URIs
Every resource available on the Web -- HTML document, image, video clip, program, etc. -- has an address that may be encoded by aUniversal Resource Identifier, or "URI".
URIs typically consist of three pieces:
- The naming scheme of the mechanism used to access the resource.
- The name of the machine hosting the resource.
- The name of the resource itself, given as a path.
Consider the URI that designates the W3C Technical Reports page:
http://www.w3.org/TR
This URI may be read as follows: There is a document available via the HTTP protocol (see [RFC2616]), residing on the machine www.w3.org, accessible via the path "/TR". Other schemes you may see in HTML documents include "mailto" for email and "ftp" for FTP.
Here is another example of a URI. This one refers to a user's mailbox:
...this is text... For all comments, please send email to <A href="mailto:joe@someplace.com">Joe Cool</A>.
Note. Most readers may be familiar with the term "URL" and not the term "URI". URLs form a subset of the more general URI naming scheme.
2.1.2 Fragment identifiers
Some URIs refer to a location within a resource. This kind of URI ends with "#" followed by an anchor identifier (called the fragment identifier). For instance, here is a URI pointing to an anchor named section_2:
http://somesite.com/html/top.html#section_2
2.1.3 Relative URIs
A relative URI doesn't contain any naming scheme information. Its path generally refers to a resource on the same machine as the current document. Relative URIs may contain relative path components (e.g., ".." means one level up in the hierarchy defined by the path), and may contain fragment identifiers.
Relative URIs are resolved to full URIs using a base URI. As an example of relative URI resolution, assume we have the base URI "http://www.acme.com/support/intro.html". The relative URI in the following markup for a hypertext link:
<A href="suppliers.html">Suppliers</A>
would expand to the full URI "http://www.acme.com/support/suppliers.html", while the relative URI in the following markup for an image
<IMG src="../icons/logo.gif" alt="logo">
would expand to the full URI "http://www.acme.com/icons/logo.gif".
- Link to another document or resource, (see the A and LINK elements).
- Link to an external style sheet or script (see the LINK and SCRIPT elements).
- Include an image, object, or applet in a page, (see the IMG, OBJECT, APPLET and INPUT elements).
- Create an image map (see the MAP and AREA elements).
- Submit a form (see FORM).
- Create a frame document (see the FRAME and IFRAME elements).
- Cite an external reference (see the Q, BLOCKQUOTE, INS and DEL elements).
- Refer to metadata conventions describing a document (see the HEAD element).
2.2 What is HTML?
To publish information for global distribution, one needs a universally understood language, a kind of publishing mother tongue that all computers may potentially understand. The publishing language used by the World Wide Web is HTML (from HyperText Markup Language).
HTML gives authors the means to:
- Publish online documents with headings, text, tables, lists, photos, etc.
- Retrieve online information via hypertext links, at the click of a button.
- Design forms for conducting transactions with remote services, for use in searching for information, making reservations, ordering products, etc.
- Include spread-sheets, video clips, sound clips, and other applications directly in their documents.
2.2.1 A brief history of HTML
HTML was originally developed by Tim Berners-Lee while at CERN, and popularized by the Mosaic browser developed at NCSA. During the course of the 1990s it has blossomed with the explosive growth of the Web. During this time, HTML has been extended in a number of ways. The Web depends on Web page authors and vendors sharing the same conventions for HTML. This has motivated joint work on specifications for HTML.
HTML 2.0 (November 1995, see [RFC1866]) was developed under the aegis of the Internet Engineering Task Force (IETF) to codify common practice in late 1994. HTML+ (1993) and HTML 3.0 (1995, see [HTML30]) proposed much richer versions of HTML. Despite never receiving consensus in standards discussions, these drafts led to the adoption of a range of new features. The efforts of the World Wide Web Consortium's HTML Working Group to codify common practice in 1996 resulted in HTML 3.2 (January 1997, see[HTML32]). Changes from HTML 3.2 are summarized in Appendix A
Most people agree that HTML documents should work well across different browsers and platforms. Achieving interoperability lowers costs to content providers since they must develop only one version of a document. If the effort is not made, there is much greater risk that the Web will devolve into a proprietary world of incompatible formats, ultimately reducing the Web's commercial potential for all participants.
Each version of HTML has attempted to reflect greater consensus among industry players so that the investment made by content providers will not be wasted and that their documents will not become unreadable in a short period of time.
HTML has been developed with the vision that all manner of devices should be able to use information on the Web: PCs with graphics displays of varying resolution and color depths, cellular telephones, hand held devices, devices for speech for output and input, computers with high or low bandwidth, and so on.
2.3 HTML 4
HTML 4 extends HTML with mechanisms for style sheets, scripting, frames, embedding objects, improved support for right to left and mixed direction text, richer tables, and enhancements to forms, offering improved accessibility for people with disabilities.
HTML 4.01 is a revision of HTML 4.0 that corrects errors and makes some changes since the previous revision.
2.3.1 Internationalization
This version of HTML has been designed with the help of experts in the field of internationalization, so that documents may be written in every language and be transported easily around the world. This has been accomplished by incorporating [RFC2070], which deals with the internationalization of HTML.
One important step has been the adoption of the ISO/IEC:10646 standard (see [ISO10646]) as the document character set for HTML. This is the world's most inclusive standard dealing with issues of the representation of international characters, text direction, punctuation, and other world language issues.
HTML now offers greater support for diverse human languages within a document. This allows for more effective indexing of documents for search engines, higher-quality typography, better text-to-speech conversion, better hyphenation, etc.
2.3.2 Accessibility
As the Web community grows and its members diversify in their abilities and skills, it is crucial that the underlying technologies be appropriate to their specific needs. HTML has been designed to make Web pages more accessible to those with physical limitations. HTML 4 developments inspired by concerns for accessibility include:
- Better distinction between document structure and presentation, thus encouraging the use of style sheets instead of HTML presentation elements and attributes.
- Better forms, including the addition of access keys, the ability to group form controls semantically, the ability to group SELECToptions semantically, and active labels.
- The ability to markup a text description of an included object (with the OBJECT element).
- A new client-side image map mechanism (the MAP element) that allows authors to integrate image and text links.
- The requirement that alternate text accompany images included with the IMG element and image maps included with the AREAelement.
- Support for the title and lang attributes on all elements.
- Support for the ABBR and ACRONYM elements.
- A wider range of target media (tty, braille, etc.) for use with style sheets.
- Better tables, including captions, column groups, and mechanisms to facilitate non-visual rendering.
- Long descriptions of tables, images, frames, etc.
Authors who design pages with accessibility issues in mind will not only receive the blessings of the accessibility community, but will benefit in other ways as well: well-designed HTML documents that distinguish structure and presentation will adapt more easily to new technologies.
2.3.3 Tables
The new table model in HTML is based on [RFC1942]. Authors now have greater control over structure and layout (e.g., column groups). The ability of designers to recommend column widths allows user agents to display table data incrementally (as it arrives) rather than waiting for the entire table before rendering.
Note. At the time of writing, some HTML authoring tools rely extensively on tables for formatting, which may easily cause accessibility problems.
2.3.4 Compound documents
HTML now offers a standard mechanism for embedding generic media objects and applications in HTML documents. The OBJECTelement (together with its more specific ancestor elements IMG and APPLET) provides a mechanism for including images, video, sound, mathematics, specialized applications, and other objects in a document. It also allows authors to specify a hierarchy of alternate renderings for user agents that don't support a specific rendering.
2.3.5 Style sheets
Style sheets simplify HTML markup and largely relieve HTML of the responsibilities of presentation. They give both authors and users control over the presentation of documents -- font information, alignment, colors, etc.
Style information can be specified for individual elements or groups of elements. Style information may be specified in an HTML document or in external style sheets.
The mechanisms for associating a style sheet with a document is independent of the style sheet language.
Before the advent of style sheets, authors had limited control over rendering. HTML 3.2 included a number of attributes and elements offering control over alignment, font size, and text color. Authors also exploited tables and images as a means for laying out pages. The relatively long time it takes for users to upgrade their browsers means that these features will continue to be used for some time. However, since style sheets offer more powerful presentation mechanisms, the World Wide Web Consortium will eventually phase out many of HTML's presentation elements and attributes. Throughout the specification elements and attributes at risk are marked as "deprecated". They are accompanied by examples of how to achieve the same effects with other elements or style sheets.
2.3.6 Scripting
Through scripts, authors may create dynamic Web pages (e.g., "smart forms" that react as users fill them out) and use HTML as a means to build networked applications.
The mechanisms provided to include scripts in an HTML document are independent of the scripting language.
2.3.7 Printing
Sometimes, authors will want to make it easy for users to print more than just the current document. When documents form part of a larger work, the relationships between them can be described using the HTML LINK element or using W3C's Resource Description Framework (RDF) (see [RDF10]).
2.4 Authoring documents with HTML 4
We recommend that authors and implementors observe the following general principles when working with HTML 4.
2.4.1 Separate structure and presentation
HTML has its roots in SGML which has always been a language for the specification of structural markup. As HTML matures, more and more of its presentational elements and attributes are being replaced by other mechanisms, in particular style sheets. Experience has shown that separating the structure of a document from its presentational aspects reduces the cost of serving a wide range of platforms, media, etc., and facilitates document revisions.
2.4.2 Consider universal accessibility to the Web
To make the Web more accessible to everyone, notably those with disabilities, authors should consider how their documents may be rendered on a variety of platforms: speech-based browsers, braille-readers, etc. We do not recommend that authors limit their creativity, only that they consider alternate renderings in their design. HTML offers a number of mechanisms to this end (e.g., the altattribute, the accesskey attribute, etc.)
Furthermore, authors should keep in mind that their documents may be reaching a far-off audience with different computer configurations. In order for documents to be interpreted correctly, authors should include in their documents information about the natural language and direction of the text, how the document is encoded, and other issues related to internationalization.
2.4.3 Help user agents with incremental rendering
By carefully designing their tables and making use of new table features in HTML 4, authors can help user agents render documents more quickly. Authors can learn how to design tables for incremental rendering (see the TABLE element). Implementors should consult the notes on tables in the appendix for information on incremental algorithms.
Subscribe to:
Posts (Atom)