In machine learning, supervised learning (SL) is a type of machine learning paradigm where an algorithm learns to map input data to a specific output based on example input-output pairs. This process involves training a statistical model using labeled data, meaning each piece of input data is provided with the correct output. The term "supervised" refers to the role of a teacher or supervisor who provides this training data, guiding the algorithm towards correct predictions. For instance, if you want a model to identify cats in images, supervised learning would involve feeding it many images of cats (inputs) that are explicitly labeled "cat" (outputs). The goal of supervised learning is for the trained model to accurately predict the output for new, unseen data. This requires the algorithm to effectively generalize from the training examples, a quality measured by its generalization error. Supervised learning is commonly used for tasks like classification (predicting a category, e.g., spam or not spam) and regression (predicting a continuous value, e.g., house prices). == Steps to follow == To solve a given problem of supervised learning, the following steps must be performed: Determine the type of training samples. Before doing anything else, the user should decide what kind of data is to be used as a training set. In the case of handwriting analysis, for example, this might be a single handwritten character, an entire handwritten word, an entire sentence of handwriting, or a full paragraph of handwriting. Gather a training set. The training set needs to be representative of the real-world use of the function. Thus, a set of input objects is gathered together with corresponding outputs, either from human experts or from measurements. Determine the input feature representation of the learned function. The accuracy of the learned function depends strongly on how the input object is represented. Typically, the input object is transformed into a feature vector, which contains a number of features that are descriptive of the object. The number of features should not be too large, because of the curse of dimensionality; but should contain enough information to accurately predict the output. Determine the structure of the learned function and corresponding learning algorithm. For example, one may choose to use support-vector machines or decision trees. Complete the design. Run the learning algorithm on the gathered training set. Some supervised learning algorithms require the user to determine certain control parameters. These parameters may be adjusted by optimizing performance on a subset (called a validation set) of the training set, or via cross-validation. Evaluate the accuracy of the learned function. After parameter adjustment and learning, the performance of the resulting function should be measured on a test set that is separate from the training set. == Algorithm choice == A wide range of supervised learning algorithms are available, each with its strengths and weaknesses. There is no single learning algorithm that works best on all supervised learning problems (see the No free lunch theorem). There are four major issues to consider in supervised learning: === Bias–variance tradeoff === A first issue is the tradeoff between bias and variance. Imagine that we have available several different, but equally good, training data sets. A learning algorithm is biased for a particular input x {\displaystyle x} if, when trained on each of these data sets, it is systematically incorrect when predicting the correct output for x {\displaystyle x} . A learning algorithm has high variance for a particular input x {\displaystyle x} if it predicts different output values when trained on different training sets. The prediction error of a learned classifier is related to the sum of the bias and the variance of the learning algorithm. Generally, there is a tradeoff between bias and variance. A learning algorithm with low bias must be "flexible" so that it can fit the data well. But if the learning algorithm is too flexible, it will fit each training data set differently, and hence have high variance. A key aspect of many supervised learning methods is that they are able to adjust this tradeoff between bias and variance (either automatically or by providing a bias/variance parameter that the user can adjust). === Function complexity and amount of training data === The second issue is of the amount of training data available relative to the complexity of the "true" function (classifier or regression function). If the true function is simple, then an "inflexible" learning algorithm with high bias and low variance will be able to learn it from a small amount of data. But if the true function is highly complex (e.g., because it involves complex interactions among many different input features and behaves differently in different parts of the input space), then the function will only be able to learn with a large amount of training data paired with a "flexible" learning algorithm with low bias and high variance. === Dimensionality of the input space === A third issue is the dimensionality of the input space. If the input feature vectors have large dimensions, learning the function can be difficult even if the true function only depends on a small number of those features. This is because the many "extra" dimensions can confuse the learning algorithm and cause it to have high variance. Hence, input data of large dimensions typically requires tuning the classifier to have low variance and high bias. In practice, if the engineer can manually remove irrelevant features from the input data, it will likely improve the accuracy of the learned function. In addition, there are many algorithms for feature selection that seek to identify the relevant features and discard the irrelevant ones. This is an instance of the more general strategy of dimensionality reduction, which seeks to map the input data into a lower-dimensional space prior to running the supervised learning algorithm. === Noise in the output values === A fourth issue is the degree of noise in the desired output values (the supervisory target variables). If the desired output values are often incorrect (because of human error or sensor errors), then the learning algorithm should not attempt to find a function that exactly matches the training examples. Attempting to fit the data too carefully leads to overfitting. You can overfit even when there are no measurement errors (stochastic noise) if the function you are trying to learn is too complex for your learning model. In such a situation, the part of the target function that cannot be modeled "corrupts" your training data – this phenomenon has been called deterministic noise. When either type of noise is present, it is better to go with a higher bias, lower variance estimator. In practice, there are several approaches to alleviate noise in the output values such as early stopping to prevent overfitting as well as detecting and removing the noisy training examples prior to training the supervised learning algorithm. There are several algorithms that identify noisy training examples and removing the suspected noisy training examples prior to training has decreased generalization error with statistical significance. === Other factors to consider === Other factors to consider when choosing and applying a learning algorithm include the following: Heterogeneity of the data. If the feature vectors include features of many different kinds (discrete, discrete ordered, counts, continuous values), some algorithms are easier to apply than others. Many algorithms, including support-vector machines, linear regression, logistic regression, neural networks, and nearest neighbor methods, require that the input features be numerical and scaled to similar ranges (e.g., to the [-1,1] interval). Methods that employ a distance function, such as nearest neighbor methods and support-vector machines with Gaussian kernels, are particularly sensitive to this. An advantage of decision trees is that they easily handle heterogeneous data. Redundancy in the data. If the input features contain redundant information (e.g., highly correlated features), some learning algorithms (e.g., linear regression, logistic regression, and distance-based methods) will perform poorly because of numerical instabilities. These problems can often be solved by imposing some form of regularization. Presence of interactions and non-linearities. If each of the features makes an independent contribution to the output, then algorithms based on linear functions (e.g., linear regression, logistic regression, support-vector machines, naive Bayes) and distance functions (e.g., nearest neighbor methods, support-vector machines with Gaussian kernels) generally perform well. However, if there are complex interactions among features, then algorithms such as decision trees and neural networks work better, becaus
Cups (app)
Cups (stylized as CUPS) was a mobile app launched in New York City in April 2014. It was a mobile payment and discovery platform for independent coffee shops nearby. The app was active in more than 400 cafes in New York, San Francisco, Philadelphia, Nashville, Minneapolis and Saint Paul, and other U.S. cities. == History == Cups was founded in Israel in 2012 by Gilad Rotem and four other co-founders, who were all high school friends. The company ran a limited beta pilot in Tel Aviv and Jerusalem, featuring 80 locations, from September 2012 until September 2014. Customers received all-you-can-drink coffee at certain coffee shops in Tel Aviv for approximately $45 a month. In October 2013, the founders relocated to New York. Cups participated in the Entrepreneur's Roundtable Accelerator program and went live in New York in 2014, initially working with 50 small coffee shops in Manhattan and Brooklyn. In early 2016, the company launched 30 locations in Philadelphia in February, followed by 40 more locations in San Francisco in March. == Functionality == The Cups app gave the user a list of the nearest participating coffee shops to their current location. The app user can order a drink using the app and pay the cashier with their phone. The cashier would enter a code that entered the purchase into the app's system. The app also allowed for onboard tipping and food purchases. The company reimbursed the coffee shop and kept a portion of their sales. In early 2016, the Cups Café Network was launched, using bulk purchasing power to land discounts with service providers which would normally be reserved for larger chains. In this way, the company aimed to help its café partners compete with the larger coffee chains.
TigerGraph
TigerGraph is a private company headquartered in Redwood City, California. It provides graph database and graph analytics software. == History == TigerGraph was founded in 2012 by programmer Yu, Ruoming, Li, Like and Mingxi, under the name GraphSQL. In September 2017, the company came out of stealth mode under the name TigerGraph with $33 million in funding. It raised an additional $32 million in funding in September 2019 and another $105 million in a series C round in February 2021. Cumulative funding as of March 2021 is $170 million. == Products == TigerGraph's hybrid transactional/analytical processing database and analytics software can scale to hundreds of terabytes of data with trillions of edges, and is used for data intensive applications such as fraud detection, customer data analysis (customer 360), IoT, artificial intelligence and machine learning. It is available using the cloud computing delivery model. The analytics uses C++ based software and a parallel processing engine to process algorithms and queries. It has its own graph query language that is similar to SQL. TigerGraph also provides a software development kit for creating graphs and visual representations. As of Mar 2024, TigerGraph version is up to version 4.2.0 TigerGraph offers free Community Edition for developers, researchers, and educators. It can be obtained from https://dl.tigergraph.com/ == Query Language == GSQL , designed by Mingxi Wu and Alin Deutsch in 2015, is a SQL-like Turing complete query language. GSQL includes additions to make it compliant with the Graph Query Language standard.
Data access layer
A data access layer (DAL) is a software architectural layer that provides access to data from one or more sources, such as a relational database, NoSQL database, SQL query engine, file system, or other persistent storage. It separates client code from the details of storage systems, query execution, connection handling, and data retrieval. Data access layers are commonly used to centralize data access logic, reduce coupling between applications and data sources, and provide a consistent interface for retrieving, writing, or querying data. Depending on the system, a data access layer may be implemented as application code, a shared library, an intermediary service, or part of a broader database abstraction layer. == In application architecture == In application software, a data access layer provides a boundary between business logic or application code and the systems used to store or retrieve data. For example, a data access layer may expose methods or interfaces for retrieving, writing, or querying data while hiding details such as connection management, SQL statements, storage APIs, error handling, and result conversion. Depending on the application, the layer may return objects, records, tabular results, documents, streams, or other representations of data. A common implementation is a set of classes, functions, or methods that directly reference database queries, stored procedures, storage APIs, or other data sources. For example, instead of using commands such as insert, delete, and update throughout an application to access a specific table, methods such as registerUser or loginUser may be implemented inside the data access layer. Business logic methods from an application can also be mapped to the data access layer. Instead of making several database queries directly, an application can call a single DAL method that abstracts those database calls. Applications using a data access layer may be either dependent on or independent from a particular database server. If the data access layer supports multiple database systems, the application can use any database system that the DAL can access. In either case, the data access layer provides a centralized location for calls into the underlying data store, which can make it easier to maintain, test, or port the application to other storage systems. == Implementation patterns == A data access layer can be implemented using several patterns and technologies, including data access objects, repositories, stored procedures, query builders, database drivers, or object–relational mapping tools. These mechanisms may implement part or all of a data access layer, but are not always equivalent to the layer itself. Object–relational mapping tools are commonly used in data access layers for object-oriented applications that map records in a relational database to objects in a programming language. Other data access layers may expose lower-level database interfaces, tabular results, document-oriented data, files, streams, or protocol-level interfaces. == Use with multiple underlying data systems == A data access layer may be used to abstract differences between multiple underlying data systems, allowing applications to access them through a more consistent interface. In such designs, applications call the DAL rather than interacting directly with each database or storage system. The layer may then handle connection management, query generation, result mapping, error handling, and other implementation details. A data access layer may be implemented as a shared library or as an intermediary service, such as a proxy or gateway. In this configuration, client applications or services connect to the data access layer, which then communicates with one or more underlying databases or query engines. This can provide a common location for authentication, authorization, logging, routing, and translation between different database interfaces. == Interfaces and protocols == Data access layers may expose or use standardized interfaces and protocols for database access. Examples include Open Database Connectivity (ODBC), Java Database Connectivity (JDBC), database-native wire protocols, and newer interfaces such as Apache Arrow Database Connectivity (ADBC) and Arrow Flight SQL. In systems that support multiple data stores, a data access layer may provide a consistent interface while using different drivers, protocols, or query mechanisms internally. == Distinction from related patterns == A data access layer is related to, but broader than, a data access object, which is usually an object-oriented design pattern for encapsulating access to a persistence mechanism. It is also related to a database abstraction layer, which focuses on hiding differences between database systems. In practice, the terms may overlap.
Snapshot isolation
In databases, and transaction processing (transaction management), snapshot isolation is a guarantee that all reads made in a transaction will see a consistent snapshot of the database (in practice it reads the last committed values that existed at the time it started), and the transaction itself will successfully commit only if no updates it has made conflict with any concurrent updates made since that snapshot. Snapshot isolation has been adopted by several major database management systems, such as InterBase, Firebird, Oracle, MySQL, PostgreSQL, SQL Anywhere, MongoDB and Microsoft SQL Server (2005 and later). The main reason for its adoption is that it allows better performance than serializability, yet still avoids most of the concurrency anomalies that serializability avoids (but not all). In practice snapshot isolation is implemented within multiversion concurrency control (MVCC), where generational values of each data item (versions) are maintained: MVCC is a common way to increase concurrency and performance by generating a new version of a database object each time the object is written, and allowing transactions' read operations of several last relevant versions (of each object). Snapshot isolation has been used to criticize the ANSI SQL-92 standard's definition of isolation levels, as it exhibits none of the "anomalies" that the SQL standard prohibited, yet is not serializable (the anomaly-free isolation level defined by ANSI). In spite of its distinction from serializability, snapshot isolation is sometimes referred to as serializable by Oracle. == Definition == A transaction executing under snapshot isolation appears to operate on a personal snapshot of the database, taken at the start of the transaction. When the transaction concludes, it will successfully commit only if the values updated by the transaction have not been changed externally since the snapshot was taken. Such a write–write conflict will cause the transaction to abort. In a write skew anomaly, two transactions (T1 and T2) concurrently read an overlapping data set (e.g. values V1 and V2), concurrently make disjoint updates (e.g. T1 updates V1, T2 updates V2), and finally concurrently commit, neither having seen the update performed by the other. Were the system serializable, such an anomaly would be impossible, as either T1 or T2 would have to occur "first", and be visible to the other. In contrast, snapshot isolation permits write skew anomalies. As a concrete example, imagine V1 and V2 are two balances held by a single person, Phil. The bank will allow either V1 or V2 to run a deficit, provided the total held in both is never negative (i.e. V1 + V2 ≥ 0). Both balances are currently $100. Phil initiates two transactions concurrently, T1 withdrawing $200 from V1, and T2 withdrawing $200 from V2. If the database guaranteed serializable transactions, the simplest way of coding T1 is to deduct $200 from V1, and then verify that V1 + V2 ≥ 0 still holds, aborting if not. T2 similarly deducts $200 from V2 and then verifies V1 + V2 ≥ 0. Since the transactions must serialize, either T1 happens first, leaving V1 = −$100, V2 = $100, and preventing T2 from succeeding (since V1 + (V2 − $200) is now −$200), or T2 happens first and similarly prevents T1 from committing. If the database is under snapshot isolation(MVCC), however, T1 and T2 operate on private snapshots of the database: each deducts $200 from an account, and then verifies that the new total is zero, using the other account value that held when the snapshot was taken. Since neither update conflicts, both commit successfully, leaving V1 = V2 = −$100, and V1 + V2 = −$200. Some systems built using multiversion concurrency control (MVCC) may support (only) snapshot isolation to allow transactions to proceed without worrying about concurrent operations, and more importantly without needing to re-verify all read operations when the transaction finally commits. This is convenient because MVCC maintains a series of recent history consistent states. The only information that must be stored during the transaction is a list of updates made, which can be scanned for conflicts fairly easily before being committed. However, MVCC systems (such as MarkLogic) will use locks to serialize writes together with MVCC to obtain some of the performance gains and still support the stronger "serializability" level of isolation. == Workarounds == Potential inconsistency problems arising from write skew anomalies can be fixed by adding (otherwise unnecessary) updates to the transactions in order to enforce the serializability property. Materialize the conflict Add a special conflict table, which both transactions update in order to create a direct write–write conflict. Promotion Have one transaction "update" a read-only location (replacing a value with the same value) in order to create a direct write–write conflict (or use an equivalent promotion, e.g. Oracle's SELECT FOR UPDATE). In the example above, we can materialize the conflict by adding a new table which makes the hidden constraint explicit, mapping each person to their total balance. Phil would start off with a total balance of $200, and each transaction would attempt to subtract $200 from this, creating a write–write conflict that would prevent the two from succeeding concurrently. However, this approach violates the normal form. Alternatively, we can promote one of the transaction's reads to a write. For instance, T2 could set V1 = V1, creating an artificial write–write conflict with T1 and, again, preventing the two from succeeding concurrently. This solution may not always be possible. In general, therefore, snapshot isolation puts some of the problem of maintaining non-trivial constraints onto the user, who may not appreciate either the potential pitfalls or the possible solutions. The upside to this transfer is better performance. == Terminology == Snapshot isolation is called "serializable" mode in Oracle and PostgreSQL versions prior to 9.1, which may cause confusion with the "real serializability" mode. There are arguments both for and against this decision; what is clear is that users must be aware of the distinction to avoid possible undesired anomalous behavior in their database system logic. == History == Snapshot isolation arose from work on multiversion concurrency control databases, where multiple versions of the database are maintained concurrently to allow readers to execute without colliding with writers. Such a system allows a natural definition and implementation of such an isolation level. InterBase, later owned by Borland, was acknowledged to provide SI rather than full serializability in version 4, and likely permitted write-skew anomalies since its first release in 1985. Unfortunately, the ANSI SQL-92 standard was written with a lock-based database in mind, and hence is rather vague when applied to MVCC systems. Berenson et al. wrote a paper in 1995 critiquing the SQL standard, and cited snapshot isolation as an example of an isolation level that did not exhibit the standard anomalies described in the ANSI SQL-92 standard, yet still had anomalous behaviour when compared with serializable transactions. In 2008, Cahill et al. showed that write-skew anomalies could be prevented by detecting and aborting "dangerous" triplets of concurrent transactions. This implementation of serializability is well-suited to multiversion concurrency control databases, and has been adopted in PostgreSQL 9.1, where it is known as Serializable Snapshot Isolation (SSI). When used consistently, this eliminates the need for the above workarounds. The downside over snapshot isolation is an increase in aborted transactions. This can perform better or worse than snapshot isolation with the above workarounds, depending on workload.
30 Boxes
30 Boxes is a minimalist calendaring IOS application created by 83 Degrees. Originating as a web application in March 2006, 30 Boxes was founded by Webshots cofounder Narendra Rocherolle. The website shut down some time in 2020, but relaunched for the IOS in February 2021. The original website was tailored towards "social media junkies". == Reception == Barry Collins of The Sunday Times appreciated the website's plain-language event adding feature, but did not appreciate that he was unable to see more than one month of events at a time. Collins was also unhappy that the website was not capable of warning him when he had two events scheduled at the same time. In a list of the best web-based calendar software for small businesses, Forbes ranked 30 Boxes second, after Google Calendar. They described 30 Boxes like “buying a new car with manual transmission and lots of extras—you don't just want to drive it, you want to fool around with it to see what it can do”.
Screen space ambient occlusion
Screen space ambient occlusion (SSAO) is a computer graphics technique for efficiently approximating the ambient occlusion effect in real time. It was developed by Vladimir Kajalin while working at Crytek and was used for the first time in 2007 by the video game Crysis, also developed by Crytek. == Implementation == The algorithm is implemented as a pixel shader, analyzing the scene depth buffer which is stored in a texture. For every pixel on the screen, the pixel shader samples the depth values around the current pixel and tries to compute the amount of occlusion from each of the sampled points. In its simplest implementation, the occlusion factor depends only on the depth difference between sampled point and current point. Without additional smart solutions, such a brute force method would require about 200 texture reads per pixel for good visual quality. This is not acceptable for real-time rendering on current graphics hardware. In order to get high quality results with far fewer reads, sampling is performed using a randomly rotated kernel. The kernel orientation is repeated every N screen pixels in order to have only high-frequency noise in the final picture. In the end this high frequency noise is greatly removed by a NxN post-process blurring step taking into account depth discontinuities (using methods such as comparing adjacent normals and depths). Such a solution allows a reduction in the number of depth samples per pixel to about 16 or fewer while maintaining a high quality result, and allows the use of SSAO in soft real-time applications like computer games. Compared to other ambient occlusion solutions, SSAO has the following advantages: Independent from scene complexity. No data pre-processing needed, no loading time and no memory allocations in system memory. Works with dynamic scenes. Works in the same consistent way for every pixel on the screen. No CPU usage – it can be executed completely on the GPU. May be easily integrated into any modern graphics pipeline. SSAO also has the following disadvantages: Rather local and in many cases view-dependent, as it is dependent on adjacent texel depths which may be generated by any geometry whatsoever. Hard to correctly smooth/blur out the noise without interfering with depth discontinuities, such as object edges (the occlusion should not "bleed" onto objects). Because SSAO operates only on the current depth buffer, it can miss occluding geometry that is not rasterized into the z-buffer and may produce undersampling-related artifacts.