The Stanhope Demonstrator was the first machine to solve problems in logic. It was designed by Charles Stanhope, 3rd Earl Stanhope to demonstrate consequences in logic symbolically. The first model was constructed in 1775. It consisted of two slides coloured red and gray mounted in a square brass frame. This could be used to demonstrate the solution to a syllogistic type of problem in which objects might have two different properties and the question was how many would have both properties. Scales marked zero to ten were used to set the numbers or proportions of objects with the two properties. This form of inference anticipated the numerically definite syllogism which Augustus De Morgan laid out in his book, Formal Logic, in 1847. == Construction == The device was a brass plate about four inches square which was mounted on a piece of mahogany which was three-quarters of an inch thick. There was an opening with a depression in the wood about one and a half inches square and half an inch deep. This opening was called the holon, meaning "whole", and represented the full set of objects under consideration. A slide of red translucent glass could be inserted from the right across the holon. A slide of gray wood could be slid under the red slide. When the device was used for the "Rule for the Logic of Certainty", the gray slider was inserted from the left. When it was used for the "Rule for the Logic of Probability", the gray slider was inserted from above. The red and the gray sliders represented the two affirmative propositions which were being combined. Stanhope called these ho and los. At least four of the devices with this square style were built. In 1879, Robert Harley wrote that he had one which he had been given by Stanhope's great-grandson, Arthur, who had kept one. The other two were owned by Henry Prevost Babbage – the son of Charles Babbage, who continued his work on the Analytical Engine. One of the devices was donated to the Science Museum, London by the last Earl in 1953. Other styles, such as circular models, were constructed, but these were less convenient.
Shaded Picture System
The Shaded Picture System was a 3D raster computer display processor introduced by Evans & Sutherland in October 1973. The Shaded Picture System was the first general-purpose, commercially available raster computer graphics display processor capable of real-time, shaded 3D graphics. It could only display black and white graphics at a resolution of 256 by 256. It was extremely expensive, and very few units were ever sold. == History == The principles of shaded, hidden-line true 3D graphics were pioneered at the University of Utah in 1967. However, this algorithm was slow and would take several minutes to produce an image. In 1970, Gary Watkins developed a FORTRAN simulator of a faster algorithm that would theoretically generate shaded 3D images in real-time, "if implemented in suitable hardware". The simulator itself was still not capable of real-time shaded 3D image rendering. Evans & Sutherland developed a functional prototype of this "suitable hardware", which was later sold as the Shaded Picture System in 1973. About a year earlier in 1972, Evans & Sutherland sold the first and only CT1 to Case Western Reserve University. The CT1, or Continuous Tone 1, was a specialized image generator, not meant as a marketable or mass-produced product. At the time, the CT1, along with G.E./NASA's upgraded Electronic Scene Generator from 1971, would have been the only real-time raster graphics systems sold to customers comparable to the Shaded Picture System, although both the CT1 and Electronic Scene Generator were intentionally produced as one-off products and specialized for the needs of their customers. The Shaded Picture System, in contrast, was intentionally marketed.In early 1975, Evans & Sutherland demonstrated a random-access video frame buffer using relatively low-cost semiconductor memory, which was much more capable than the Shaded Picture System. When interfaced with a (non-shaded) E&S Picture System, the frame buffer had a resolution of 512 by 512 in grayscale and partial color capabilities. By the end of 1975, this frame buffer was commercially available.
ISO/IEC 11801
International standard ISO/IEC 11801 Information technology — Generic cabling for customer premises specifies general-purpose telecommunication cabling systems (structured cabling) that are suitable for a wide range of applications (analog and ISDN telephony, various data communication standards, building control systems, factory automation). It is published by ISO/IEC JTC 1/SC 25/WG 3 of the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC). It covers both balanced copper cabling and optical fibre cabling. The standard was designed for use within commercial premises that may consist of either a single building or of multiple buildings on a campus. It was optimized for premises that span up to 3 km, up to 1 km2 office space, with between 50 and 50,000 persons, but can also be applied for installations outside this range. A major revision was released in November 2017, unifying requirements for commercial, home and industrial networks. == Classes and categories == The standard defines several link/channel classes and cabling categories of twisted-pair copper interconnects, which differ in the maximum frequency for which a certain channel performance is required: Class A: Up to 100 kHz using Category 1 cable and connectors Class B: Up to 1 MHz using Category 2 cable and connectors Class C: Up to 16 MHz using Category 3 cable and connectors Class D: Up to 100 MHz using Category 5e cable and connectors Class E: Up to 250 MHz using Category 6 cable and connectors Class EA: Up to 500 MHz using category 6A cable and connectors (Amendments 1 and 2 to ISO/IEC 11801, 2nd Ed.) Class F: Up to 600 MHz using Category 7 cable and connectors Class FA: Up to 1 GHz (1000 MHz) using Category 7A cable and connectors (Amendments 1 and 2 to ISO/IEC 11801, 2nd Ed.) Class BCT-B: Up to 1 GHz (1000 MHz) using with coaxial cabling for BCT applications. (ISO/IEC 11801-1, Edition 1.0 2017-11) Class I: Up to 2 GHz (2000 MHz) using Category 8.1 cable and connectors (ISO/IEC 11801-1, Edition 1.0 2017-11) Class II: Up to 2 GHz (2000 MHz) using Category 8.2 cable and connectors (ISO/IEC 11801-1, Edition 1.0 2017-11) The standard link impedance is 100 Ω. (The older 1995 version of the standard also permitted 120 Ω and 150 Ω in Classes A−C, but this was removed from the 2002 edition.) The standard defines several classes of optical fiber interconnect: OM1: Multimode, 62.5 μm core; minimum modal bandwidth of 200 MHz·km at 850 nm OM2: Multimode, 50 μm core; minimum modal bandwidth of 500 MHz·km at 850 nm OM3: Multimode, 50 μm core; minimum modal bandwidth of 2000 MHz·km at 850 nm OM4: Multimode, 50 μm core; minimum modal bandwidth of 4700 MHz·km at 850 nm OM5: Multimode, 50 μm core; minimum modal bandwidth of 4700 MHz·km at 850 nm and 2470 MHz·km at 953 nm OS1: Single-mode, maximum attenuation 1 dB/km at 1310 and 1550 nm OS1a: Single-mode, maximum attenuation 1 dB/km at 1310, 1383, and 1550 nm OS2: Single-mode, maximum attenuation 0.4 dB/km at 1310, 1383, and 1550 nm Grandfathered === OM5 === OM5 fiber is designed for wideband applications using SWDM multiplexing of 4–16 carriers (40G=4λ×10G, 100G=4λ×25G, 400G=4×4λ×25G) in the 850–953 nm range. === Category 7 === Class F channel and Category 7 cable are backward compatible with Class D/Category 5e and Class E/Category 6. Class F features even stricter specifications for crosstalk and system noise than Class E. To achieve this, shielding was added for individual wire pairs and the cable as a whole. Unshielded cables rely on the quality of the twists to protect from EMI. This involves a tight twist and carefully controlled design. Cables with individual shielding per pair such as Category 7 rely mostly on the shield and therefore have pairs with longer twists. The Category 7 cable standard was ratified in 2002, and primarily introduced to support 10 gigabit Ethernet over 100 m of copper cabling. Like the earlier standards, it contains four twisted copper wire pairs rated for transmission frequencies of up to 600 MHz. However, in 2006, Category 6A was ratified for Ethernet to allow 10 Gbit/s while still using the conventional 8P8C connector. Care is required to avoid signal degradation by mixing cable and connectors not designed for that use, however similar. Most manufacturers of active equipment and network cards have chosen to support the 8P8C for their 10 gigabit Ethernet products on copper and not GG45, ARJ45, or TERA connectors as Class F would have originally called for. Therefore, the Category 6 specification was revised to Category 6A to permit this use; products therefore require a Class EA channel (ie, Cat 6A). As of 2019, some equipment has been introduced which has connectors supporting the Class F (Category 7) channel. Note, however, that Category 7 is not recognized by the TIA/EIA. === Category 7A === Class FA (Class F Augmented) channels and Category 7A cables, introduced by ISO 11801 Edition 2 Amendment 2 (2010), are defined at frequencies up to 1000 MHz. The intent of the Class FA was to possibly support the future 40 gigabit Ethernet: 40GBASE-T. Simulation results have shown that 40 gigabit Ethernet may be possible at 50 meters and 100 gigabit Ethernet at 15 meters. In 2007, researchers at Pennsylvania State University predicted that either 32 nm or 22 nm circuits would allow for 100 gigabit Ethernet at 100 meters. However, in 2016, the IEEE 802.3bq working group ratified the amendment 3 which defines 25GBASE-T and 40GBASE-T on Category 8 cabling specified to 2000 MHz. The Class FA therefore does not support 40G Ethernet. As of 2025, there is no equipment that has connectors supporting the Class FA (Category 7A) channel. Category 7A is not recognized in TIA/EIA. === Category 8 === Category 8 was ratified by the TR43 working group under ANSI/TIA 568-C.2-1. It is defined up to 2000 MHz and only for distances up to 30 m or 36 m, depending on the patch cords used. ISO/IEC JTC 1/SC 25/WG 3 developed the equivalent standard ISO/IEC 11801-1:2017/COR 1:2018, with two options: Class I channel (Category 8.1 cable): minimum cable design U/FTP or F/UTP, fully backward compatible and interoperable with Class EA (Category 6A) using 8P8C connectors; Class II channel (Category 8.2 cable): F/FTP or S/FTP minimum, interoperable with Class FA (Category 7A) using TERA or GG45. == Abbreviations for twisted pairs == Annex E, Acronyms for balanced cables, provides a system to specify the exact construction for both unshielded and shielded balanced twisted pair cables. It uses three letters—U for unshielded, S for braided shielding, and F for foil shielding—to form a two-part abbreviation in the form of xx/xTP, where the first part specifies the type of overall cable shielding, and the second part specifies shielding for individual cable elements. Common cable types include U/UTP (unshielded cable); U/FTP (individual pair shielding without the overall screen); F/UTP, S/UTP, or SF/UTP (overall screen without individual shielding); and F/FTP, S/FTP, or SF/FTP (overall screen with individual foil shielding). == 2017 edition == In November 2017, a new edition was released by ISO/IEC JTC 1/SC 25 "Interconnection of information technology equipment" subcommittee. It is a major revision of the standard which has unified several prior standards for commercial, home, and industrial networks, as well as data centers, and defines requirements for generic cabling and distributed building networks. The new series of standards replaces the former 11801 standard and includes six parts: == Versions == ISO/IEC 11801:1995 (Ed. 1) ISO/IEC 11801:2000 (Ed. 1.1) – Edition 1, Amendment 1 ISO/IEC 11801:2002 (Ed. 2) ISO/IEC 11801:2008 (Ed. 2.1) – Edition 2, Amendment 1 ISO/IEC 11801:2010 (Ed. 2.2) – Edition 2, Amendment 2 ISO/IEC 11801-1:2017, -1:2017/Cor 1:2018, -2:2017, -3:2017, -3:2017/Amd 1:2021, -3:2017/Cor 1:2018, -4:2017, -4:2017/Cor 1:2018, -5:2017, -5:2017/Cor 1:2018, -6:2017, -6:2017/Cor 1:2018 (As of September 2023, this set is current.)
WebCL
WebCL (Web Computing Language) is a JavaScript binding to OpenCL for heterogeneous parallel computing within any compatible web browser without the use of plug-ins, first announced in March 2011. It is developed on similar grounds as OpenCL and is considered as a browser version of the latter. Primarily, WebCL allows web applications to actualize speed with multi-core CPUs and GPUs. With the growing popularity of applications that need parallel processing like image editing, augmented reality applications and sophisticated gaming, it has become more important to improve the computational speed. With these background reasons, a non-profit Khronos Group designed and developed WebCL, which is a Javascript binding to OpenCL with a portable kernel programming, enabling parallel computing on web browsers, across a wide range of devices. In short, WebCL consists of two parts, one being Kernel programming, which runs on the processors (devices) and the other being JavaScript, which binds the web application to OpenCL. The completed and ratified specification for WebCL 1.0 was released on March 19, 2014. == Implementation == Currently, no browsers natively support WebCL. However, non-native add-ons are used to implement WebCL. For example, Nokia developed a WebCL extension. Mozilla does not plan to implement WebCL in favor of WebGL Compute Shaders, which were in turn scrapped in favor of WebGPU. Mozilla (Firefox) - hg.mozilla.org/projects/webcl/ === WebCL working draft === Samsung (WebKit) - github.com/SRA-SiliconValley/webkit-webcl (unavailable) Nokia (Firefox) - github.com/toaarnio/webcl-firefox (down since Nov 2014, Last Version for FF 34) Intel (Crosswalk) - www.crosswalk-project.org === Example C code === The basic unit of a parallel program is kernel. A kernel is any parallelizable task used to perform a specific job. More often functions can be realized as kernels. A program can be composed of one or more kernels. In order to realize a kernel, it is essential that a task is parallelizable. Data dependencies and order of execution play a vital role in producing efficient parallelized algorithms. A simple example can be thought of the case of loop unrolling performed by C compilers, where a statement like:can be unrolled into:Above statements can be parallelized and can be made to run simultaneously. A kernel follows a similar approach where only the snapshot of the ith iteration is captured inside kernel. Rewriting the above code using a kernel:Running a WebCL application involves the following steps: Allow access to devices and provide context Hand over the kernel to a device Cause the device to execute the kernel Retrieve results from the device Use the data inside JavaScript Further details about the same can be found at == Exceptions List == WebCL, being a JavaScript based implementation, doesn't return an error code when errors occur. Instead, it throws an exception such as OUT_OF_RESOURCES, OUT_OF_HOST_MEMORY, or the WebCL-specific WEBCL_IMPLEMENTATION_FAILURE. The exception object describes the machine-readable name and human-readable message describing the error. The syntax is as follows: From the code above, it can be observed that the message field can be a NULL value. Other exceptions include: INVALID_OPERATION – if the blocking form of this function is called from a WebCLCallback INVALID_VALUE – if eventWaitList is empty INVALID_CONTEXT – if events specified in eventWaitList do not belong to the same context INVALID_DEVICE_TYPE – if deviceType is given, but is not one of the valid enumerated values DEVICE_NOT_FOUND – if there is no WebCLDevice available that matches the given deviceType More information on exceptions can be found in the specs document. There is another exception that is raised upon trying to call an object that is ‘released’. On using the release method, the object doesn't get deleted permanently but it frees the resources associated with that object. In order to avoid this exception, releaseAll method can be used, which not only frees the resources but also deletes all the associated objects created. == Security == WebCL, being an open-ended software developed for web applications, has lots of scope for vulnerabilities in the design and development fields too. This forced the developers working on WebCL to give security the utmost importance. Few concerns that were addressed are: Out-of-bounds Memory Access: This occurs by accessing the memory locations, outside the allocated space. An attacker can rewrite or erase all the important data stored in those memory locations. Whenever there arises such a case, an error must be generated at the compile time, and zero must be returned at run-time, not letting the program override the memory. A project WebCL Validator, was initiated by the Khronos Group (developers) on handling this vulnerability. Memory Initialization: This is done to prevent the applications to access the memory locations of previous applications. WebCL ensures that this doesn't happen by initializing all the buffers, variables used to zero before it runs the current application. OpenCL 1.2 has an extension ‘cl_khr_initialize_memory’, which enables this. Denial of Service: The most common attack on web applications cannot be eliminated by WebCL or the browser. OpenCL can be provided with watchdog timers and pre-emptive multitasking, which can be used by WebCL in order to detect and terminate the contexts that are taking too long or consume lot of resources. There is an extension of OpenCL 1.2 ‘cl_khr_terminate_context’ like for the previous one, which enables to terminate the process that might cause a denial of service attack. == Related browser bugs == Bug 664147 - [WebCL] add openCL in gecko, Mozilla Bug 115457: [Meta] WebCL support for WebKit, WebKit Bugzilla
Web API
A web API is an application programming interface (API) for either a web server or a web browser. As a web development concept, it can be related to a web application's client side (including any web frameworks being used). A server-side web API consists of one or more publicly exposed endpoints to a defined request–response message system, typically expressed in JSON or XML by means of an HTTP-based web server. A server API (SAPI) is not considered a server-side web API, unless it is publicly accessible by a remote web application. == Client side == A client-side web API is a programmatic interface to extend functionality within a web browser or other HTTP client. Originally these were most commonly in the form of native plug-in browser extensions however most newer ones target standardized JavaScript bindings. The Mozilla Foundation created their WebAPI specification which is designed to help replace native mobile applications with HTML5 applications. Google created their Native Client architecture which is designed to help replace insecure native plug-ins with secure native sandboxed extensions and applications. They have also made this portable by employing a modified LLVM AOT compiler. == Server side == A server-side web API consists of one or more publicly exposed endpoints to a defined request–response message system, typically expressed in JSON or XML. The web API is exposed most commonly by means of an HTTP-based web server. Mashups are web applications which combine the use of multiple server-side web APIs. Webhooks are server-side web APIs that take input as a Uniform Resource Identifier (URI) that is designed to be used like a remote named pipe or a type of callback such that the server acts as a client to dereference the provided URI and trigger an event on another server which handles this event thus providing a type of peer-to-peer IPC. === Endpoints === Endpoints are important aspects of interacting with server-side web APIs, as they specify where resources can be accessed by third-party software. Usually the access is via a URI to which HTTP requests are posted, and from which the response is thus expected. Web APIs may be public or private, the latter of which requires an access token. Endpoints need to be static, otherwise the correct functioning of software that interacts with them cannot be guaranteed. If the location of a resource changes (and with it the endpoint) then previously written software will break, as the required resource can no longer be found at the same place. As API providers still want to update their web APIs, many have introduced a versioning system in the URI that points to an endpoint. === Resources versus services === Web 2.0 Web APIs often use machine-based interactions such as REST and SOAP. RESTful web APIs use HTTP methods to access resources via URL-encoded parameters, and use JSON or XML to transmit data. By contrast, SOAP protocols are standardized by the W3C and mandate the use of XML as the payload format, typically over HTTP. Furthermore, SOAP-based Web APIs use XML validation to ensure structural message integrity, by leveraging the XML schemas provisioned with WSDL documents. A WSDL document accurately defines the XML messages and transport bindings of a Web service. === Documentation === Server-side web APIs are interfaces for the outside world to interact with the business logic. For many companies this internal business logic and the intellectual property associated with it are what distinguishes them from other companies, and potentially what gives them a competitive edge. They do not want this information to be exposed. However, in order to provide a web API of high quality, there needs to be a sufficient level of documentation. One API provider that not only provides documentation, but also links to it in its error messages is Twilio. However, there are now directories of popular documented server-side web APIs. === Growth and impact === The number of available web APIs has grown consistently over the past years, as businesses realize the growth opportunities associated with running an open platform, that any developer can interact with. ProgrammableWeb tracks over 24000 Web APIs that were available in 2022, up from 105 in 2005. Web APIs have become ubiquitous. There are few major software applications/services that do not offer some form of web API. One of the most common forms of interacting with these web APIs is via embedding external resources, such as tweets, Facebook comments, YouTube videos, etc. In fact there are very successful companies, such as Disqus, whose main service is to provide embeddable tools, such as a feature-rich comment system. Any website of the TOP 100 Alexa Internet ranked websites uses APIs and/or provides its own APIs, which is a very distinct indicator for the prodigious scale and impact of web APIs as a whole. As the number of available web APIs has grown, open source tools have been developed to provide more sophisticated search and discovery. APIs.json provides a machine-readable description of an API and its operations, and the related project APIs.io offers a searchable public listing of APIs based on the APIs.json metadata format. === Business === ==== Commercial ==== Many companies and organizations rely heavily on their Web API infrastructure to serve their core business clients. In 2014 Netflix received around 5 billion API requests, most of them within their private API. ==== Governmental ==== Many governments collect a lot of data, and some governments are now opening up access to this data. The interfaces through which this data is typically made accessible are web APIs. Web APIs allow for data, such as "budget, public works, crime, legal, and other agency data" to be accessed by any developer in a convenient manner. == Example == An example of a popular web API is the Astronomy Picture of the Day API operated by the American space agency NASA. It is a server-side API used to retrieve photographs of space or other images of interest to astronomers, and metadata about the images. According to the API documentation, the API has one endpoint: https://api.nasa.gov/planetary/apod The documentation states that this endpoint accepts GET requests. It requires one piece of information from the user, an API key, and accepts several other optional pieces of information. Such pieces of information are known as parameters. The parameters for this API are written in a format known as a query string, which is separated by a question mark character (?) from the endpoint. An ampersand (&) separates the parameters in the query string from each other. Together, the endpoint and the query string form a URL that determines how the API will respond. This URL is also known as a query or an API call. In the below example, two parameters are transmitted (or passed) to the API via the query string. The first is the required API key and the second is an optional parameter — the date of the photograph requested. https://api.nasa.gov/planetary/apod?api_key=DEMO_KEY&date=1996-12-03 Visiting the above URL in a web browser will initiate a GET request, calling the API and showing the user a result, known as a return value or as a return. This API returns JSON, a type of data format intended to be understood by computers, but which is somewhat easy for a human to read as well. In this case, the JSON contains information about a photograph of a white dwarf star: The above API return has been reformatted so that names of JSON data items, known as keys, appear at the start of each line. The last of these keys, named url, indicates a URL which points to a photograph: https://apod.nasa.gov/apod/image/9612/ngc2440_hst2.jpg Following the above URL, a web browser user would see this photo: Although this API can be called by an end user with a web browser (as in this example) it is intended to be called automatically by software or by computer programmers while writing software. JSON is intended to be parsed by a computer program, which would extract the URL of the photograph and the other metadata. The resulting photo could be embedded in a website, automatically sent via text message, or used for any other purpose envisioned by a software developer.
Inception (deep learning architecture)
Inception is a family of convolutional neural network (CNN) for computer vision, introduced by researchers at Google in 2014 as GoogLeNet (later renamed Inception v1). The series was historically important as an early CNN that separates the stem (data ingest), body (data processing), and head (prediction), an architectural design that persists in all modern CNN. == Version history == === Inception v1 === In 2014, a team at Google developed the GoogLeNet architecture, an instance of which won the ImageNet Large-Scale Visual Recognition Challenge 2014 (ILSVRC14). The name came from the LeNet of 1998, since both LeNet and GoogLeNet are CNNs. They also called it "Inception" after a "we need to go deeper" internet meme, a phrase from Inception (2010) the film. Because later, more versions were released, the original Inception architecture was renamed again as "Inception v1". The models and the code were released under Apache 2.0 license on GitHub. The Inception v1 architecture is a deep CNN composed of 22 layers. Most of these layers were "Inception modules". The original paper stated that Inception modules are a "logical culmination" of Network in Network and (Arora et al, 2014). Since Inception v1 is deep, it suffered from the vanishing gradient problem. The team solved it by using two "auxiliary classifiers", which are linear-softmax classifiers inserted at 1/3-deep and 2/3-deep within the network, and the loss function is a weighted sum of all three: L = 0.3 L a u x , 1 + 0.3 L a u x , 2 + L r e a l {\displaystyle L=0.3L_{aux,1}+0.3L_{aux,2}+L_{real}} These were removed after training was complete. This was later solved by the ResNet architecture. The architecture consists of three parts stacked on top of one another: The stem (data ingestion): The first few convolutional layers perform data preprocessing to downscale images to a smaller size. The body (data processing): The next many Inception modules perform the bulk of data processing. The head (prediction): The final fully-connected layer and softmax produces a probability distribution for image classification. This structure is used in most modern CNN architectures. === Inception v2 === Inception v2 was released in 2015, in a paper that is more famous for proposing batch normalization. It had 13.6 million parameters. It improves on Inception v1 by adding batch normalization, and removing dropout and local response normalization which they found became unnecessary when batch normalization is used. === Inception v3 === Inception v3 was released in 2016. It improves on Inception v2 by using factorized convolutions. As an example, a single 5×5 convolution can be factored into 3×3 stacked on top of another 3×3. Both has a receptive field of size 5×5. The 5×5 convolution kernel has 25 parameters, compared to just 18 in the factorized version. Thus, the 5×5 convolution is strictly more powerful than the factorized version. However, this power is not necessarily needed. Empirically, the research team found that factorized convolutions help. It also uses a form of dimension-reduction by concatenating the output from a convolutional layer and a pooling layer. As an example, a tensor of size 35 × 35 × 320 {\displaystyle 35\times 35\times 320} can be downscaled by a convolution with stride 2 to 17 × 17 × 320 {\displaystyle 17\times 17\times 320} , and by maxpooling with pool size 2 × 2 {\displaystyle 2\times 2} to 17 × 17 × 320 {\displaystyle 17\times 17\times 320} . These are then concatenated to 17 × 17 × 640 {\displaystyle 17\times 17\times 640} . Other than this, it also removed the lowest auxiliary classifier during training. They found that the auxiliary head worked as a form of regularization. They also proposed label-smoothing regularization in classification. For an image with label c {\displaystyle c} , instead of making the model to predict the probability distribution δ c = ( 0 , 0 , … , 0 , 1 ⏟ c -th entry , 0 , … , 0 ) {\displaystyle \delta _{c}=(0,0,\dots ,0,\underbrace {1} _{c{\text{-th entry}}},0,\dots ,0)} , they made the model predict the smoothed distribution ( 1 − ϵ ) δ c + ϵ / K {\displaystyle (1-\epsilon )\delta _{c}+\epsilon /K} where K {\displaystyle K} is the total number of classes. === Inception v4 === In 2017, the team released Inception v4, Inception ResNet v1, and Inception ResNet v2. Inception v4 is an incremental update with even more factorized convolutions, and other complications that were empirically found to improve benchmarks. Inception ResNet v1 and v2 are both modifications of Inception v4, where residual connections are added to each Inception module, inspired by the ResNet architecture. === Xception === Xception ("Extreme Inception") was published in 2017. It is a linear stack of depthwise separable convolution layers with residual connections. The design was proposed on the hypothesis that in a CNN, the cross-channels correlations and spatial correlations in the feature maps can be entirely decoupled. Training each network took 3 days on 60 K80 GPUs, or approximately 0.5 petaFLOP-days.
Infone
Infone was a service launched by Metro One Telecommunications in 2003. The service was discontinued effective December 14, 2005. == How it worked == Infone included directory assistance and other services via a toll-free phone number. A user could call 888-411-1111 to request directory assistance, directions, traffic information, movie times, call completion, dinner reservation assistance and other services. Infone provided a number of innovative 411 'concierge'-like services, including movie listings from a live operator, and offered a feature where they could provide information from a linked Microsoft Outlook calendar when set up in advance. For a period of time they advertised heavily on U.S. television, featuring ads with then Governor of Minnesota Jesse Ventura, emphasizing their use of all U.S. based operators. The price offered was $0.89 per call up to 15 minutes (for use when the operator connects you to the requested number, as well as for additional information requests afterwards), with $0.05 for each additional minute, making Infone also a competitively priced long-distance service. New users received 5–10 free calls. Infone identified a registered user (along with billing information; the service was only payable by credit card) by caller ID (numbers were registered on signing up) and by an advanced voiceprint recognition system (VPRS) from SpeechWorks that identified the user when the user called from an unregistered telephone number (or no caller ID) through the use of a personal phrase spoken by the user (e.g., "Hello Infone!") after the welcome tone.