Andrew Knyazev is an American mathematician. He graduated from the Faculty of Computational Mathematics and Cybernetics of Moscow State University under the supervision of Evgenii Georgievich D'yakonov (Russian: Евгений Георгиевич Дьяконов) in 1981 and obtained his PhD in Numerical Mathematics at the Russian Academy of Sciences under the supervision of Vyacheslav Ivanovich Lebedev (Russian: Вячеслав Иванович Лебедев) in 1985. He worked at the Kurchatov Institute between 1981–1983, and then to 1992 at the Marchuk Institute of Numerical Mathematics (Russian: ru:Институт вычислительной математики имени Г. И. Марчука РАН) of the Russian Academy of Sciences, headed by Gury Marchuk (Russian: Гурий Иванович Марчук). From 1993–1994, Knyazev held a visiting position at the Courant Institute of Mathematical Sciences of New York University, collaborating with Olof B. Widlund. From 1994 until retirement in 2014, he was a Professor of Mathematics at the University of Colorado Denver, supported by the National Science Foundation and United States Department of Energy grants. He was a recipient of the 2008 Excellence in Research Award, the 2000 college Teaching Excellence Award, and a finalist of the CU President's Faculty Excellence Award for Advancing Teaching and Learning through Technology in 1999. He was awarded the title of Professor Emeritus at the University of Colorado Denver and named the SIAM Fellow Class of 2016 and AMS Fellow Class of 2019. From 2012–2018, Knyazev worked at the Mitsubishi Electric Research Laboratories on algorithms for image and video processing, data sciences, optimal control, and material sciences, resulting in dozens of publications and 13 patent applications. Since 2018, he contributed to numerical techniques in quantum computing at Zapata Computing, real-time embedded anomaly detection in automotive data, and algorithms for silicon photonics-based hardware. Knyazev is mostly known for his work in numerical solution of large sparse eigenvalue problems, particularly preconditioning and the iterative method LOBPCG. Knyazev's implementation of LOBPCG is available in many open source software packages, e.g., BLOPEX, SciPy, and ABINIT. Knyazev collaborated with John Osborn on the theory of the Ritz method in the finite element method context and with Nikolai Sergeevich Bakhvalov (Russian: Николай Серге́евич Бахвалов) (Erdős number 3 via Leonid Kantorovich) on numerical solution of elliptic partial differential equations with large jumps in the main coefficients. Jointly with his Ph.D. students, Knyazev pioneered using majorization for bounds in the Rayleigh–Ritz method (see and references there) and contributed to the theory of angles between flats.
Perceptual robotics
Perceptual robotics is an interdisciplinary science linking Robotics and Neuroscience. It investigates biologically motivated robot control strategies, concentrating on perceptual rather than cognitive processes and thereby sides with J. J. Gibson's view against the Poverty of the stimulus theory. As a working definition, the following quote from Chapter 64 by H. Bülthoff, C. Wallraven and M. Giese from The Springer Handbook of Robotics, edited by Bruno Siciliano and Oussama Khatib, published by Springer in 2007, could be used: In the following we will apply the term Perceptual Robotics to signify the design of robots based on principles that are derived from human perception on all three levels in the sense of Marr. This includes a realization in terms of specific neural circuits as well as the transfer of more abstract biologically-inspired strategies for the solution of relevant computational problems.
Physical access
Physical access is a term in computer security that refers to the ability of people to physically gain access to a computer system. According to Gregory White, "Given physical access to an office, the knowledgeable attacker will quickly be able to find the information needed to gain access to the organization's computer systems and network." == Attacks and countermeasures == === Attacks === Physical access opens up a variety of avenues for hacking. Michael Meyers notes that "the best network software security measures can be rendered useless if you fail to physically protect your systems," since an intruder could simply walk off with a server and crack the password at his leisure. Physical access also allows hardware keyloggers to be installed. An intruder may be able to boot from a CD or other external media and then read unencrypted data on the hard drive. They may also exploit a lack of access control in the boot loader; for instance, pressing F8 while certain versions of Microsoft Windows are booting, specifying 'init=/bin/sh' as a boot parameter to Linux (usually done by editing the command line in GRUB), etc. One could also use a rogue device to access a poorly secured wireless network; if the signal were sufficiently strong, one might not even need to breach the perimeter. === Countermeasures === IT security standards in the United States typically call for physical access to be limited by locked server rooms, sign-in sheets, etc. Physical access systems and IT security systems have historically been administered by separate departments of organizations, but are increasingly being seen as having interdependent functions needing a single, converged security policy. An IT department could, for instance, check security log entries for suspicious logons occurring after business hours, and then use keycard swipe records from a building access control system to narrow down the list of suspects to those who were in the building at that time. Surveillance cameras might also be used to deter or detect unauthorized access.
System Service Descriptor Table
The System Service Descriptor Table (SSDT) is an internal dispatch table within Microsoft Windows. == Function == The SSDT maps syscalls to kernel function addresses. When a syscall is issued by a user space application, it contains the service index as parameter to indicate which syscall is called. The SSDT is then used to resolve the address of the corresponding function within ntoskrnl.exe. In modern Windows kernels, two SSDTs are used: One for generic routines (KeServiceDescriptorTable) and a second (KeServiceDescriptorTableShadow) for graphical routines. A parameter passed by the calling userspace application determines which SSDT shall be used. == Hooking == Modification of the SSDT allows to redirect syscalls to routines outside the kernel. These routines can be either used to hide the presence of software or to act as a backdoor to allow attackers permanent code execution with kernel privileges. For both reasons, hooking SSDT calls is often used as a technique in both Windows kernel mode rootkits and antivirus software. In 2010, many computer security products which relied on hooking SSDT calls were shown to be vulnerable to exploits using race conditions to attack the products' security checks.
Document-oriented database
A document-oriented database, or document store, is a computer program and data storage system designed for storing, retrieving, and managing document-oriented information, also known as semi-structured data. Document-oriented databases are one of the main categories of NoSQL databases, and the popularity of the term "document-oriented database" has grown alongside the adoption of NoSQL itself. XML databases are a subclass of document-oriented databases optimized for XML documents. Graph databases are similar, but add another layer, the relationship, which allows them to link documents for rapid traversal. Document-oriented databases are conceptually an extension of the key–value store, another type of NoSQL database. In key-value stores, data is treated as opaque by the database, whereas document-oriented systems exploit the internal structure of documents to extract metadata and optimize storage and queries. Although in practice the distinction can be minimal due to modern tooling, document stores are designed to provide a richer programming experience with modern programming techniques. Document databases differ significantly from traditional relational databases (RDBs). Relational databases store data in predefined tables, often requiring an object to be split across multiple tables. In contrast, document databases store all information for a given object in a single document, with each document potentially having a unique structure. This design eliminates the need for object-relational mapping when loading data into the database. == Documents == The central concept of a document-oriented database is the notion of a document. Although implementations vary in their specific definitions, document-oriented databases generally treat documents as self-contained units that encapsulate and encode data in a standardized format. Common encoding formats include XML, YAML, JSON, as well as binary representations such as BSON. Documents in a document store are equivalent to the programming concept of an object. They are not required to adhere to a fixed schema, and documents within the same collection may contain different fields or structures. Fields may be optional, and documents of the same logical type may differ in composition. For example, the following illustrates a document encoded in JSON: A second document might be encoded in XML as: The two example documents share some structural elements but also contain unique fields. The structure, text, and other data within each document are collectively referred to as the document's content and can be accessed or modified using retrieval or editing operations. Unlike relational databases, in which each record contains the same fields and unused fields are left empty, document-oriented databases do not require uniform fields across documents. This design allows new information to be added to some documents without affecting the structure of others. Document databases often support the storage of additional metadata alongside the document content. Such metadata may relate to organizational features, security, indexing, or other implementation-specific features. === CRUD operations === The core operations supported by a document-oriented database for manipulating documents are similar to those in other databases. Although terminology is not perfectly standardized, these operations are generally recognized as Create, Read, Update, and Delete (CRUD). Creation (C): Adds a new document to the database. Retrieval (R): Retrieves documents or fields based on queries. Update (U): Modifies the contents of existing documents. Deletion (D): Removes documents from the database. === Keys === Documents in a document-oriented database are addressed via a unique identifier. This identifier, often a string, URI, or path, can be used to retrieve the document from the database. Most document stores maintain an index on the key to optimize retrieval, and in some implementations the key is required when creating or inserting a new document. === Retrieval === In addition to key-based access, document-oriented databases typically provide an API or query language that enables retrieval based on document content or associated metadata. For example, a query may return all documents with a specific field matching a given value. The available query features, indexing options, and performance characteristics vary across implementations. Document stores differ from key-value stores in that they exploit the internal structure and metadata of stored documents. In many key-value stores, values are treated as opaque or "black-box" data, meaning the database system does not interpret their internal structure. By contrast, document-oriented databases can classify and interpret document content. This enables queries that distinguish between types of data––for example, retrieving all phone numbers containing "555" without also matching a postal code such as "55555." === Editing === Document databases typically provide mechanisms for updating or editing the content or metadata of a document. Updates may involve replacing the entire document or modifying individual elements or fields within the document. === Organization === Document database implementations support a variety of methods for organizing documents, including: Collections: Groups of documents. Depending on the implementation, a document may be required to belong to a single collection or may be allowed in multiple collections. Tags and non-visible metadata: Additional data stored outside the main document content. Directory hierarchies: Documents organized in a tree-like structure, often based on path or URI. These organizational structures may differ between logical and physical representations (e.g. on disk or in memory). == Relationship to other databases == === Relationship to key-value stores === A document-oriented database can be viewed as a specialized form of key-value store, which is itself a category of NoSQL database. In a basic key-value store, the stored value is typically treated as opaque by the database system. By contrast, a document-oriented database provides APIs or a query and update language that allows queries and modifications based on the internal structure of the document. For users who do not require advanced query, retrieval, or update capabilities, the distinction between document-oriented databases and key-value stores may be minimal. === Relationship to search engines === Some search engine and information retrieval systems, such as Apache Solr and Elasticsearch, provide document storage and support core document operations. As a result, they may meet certain functional definitions of a document-oriented database, although their primary design goals differ. === Relationship to relational databases === In a relational database, data is organized into predefined types represented as tables. Each table contains rows (records) with a fixed set of columns (fields), so all records in a table share the same structure. Administrators typically define indexes on selected fields to improve query performance. A central principle of relational database design is database normalization, in which data that might otherwise be repeated is stored in separate tables and linked using keys. When records in different tables are related, a foreign key is used to associate them. For example, an address book application may store a contact's name, image, phone numbers, mailing addresses, and email addresses. In a normalized relational design, separate tables might be created for contacts, phone numbers, and email addresses. The phone number table would include a foreign key referencing the associated contact. To reconstruct a complete contact record, the database retrieves related information from each table using the foreign keys and combines it into a single record. In contrast, a document-oriented database stores all data related to an object within a single document, and stored in the database as a single entry. In the address book example,the contact's name, image, and contact information may be stored together in one document. The document is retrieved using a unique key, and all related information is returned together, without needing to look up multiple tables. A key difference between the document-oriented and relational models is that the data formats are not predefined in the document case. In most cases, any sort of document can be stored in a database, and documents can change in type and form over time. For example, a new field such as COUNTRY_FLAG can be added to new documents as they are inserted without affecting existing documents. To aid retrieval, document-oriented systems generally allow the administrator to provide hints to the database for locating certain types of information. These hints work in a similar fashion to indexes in relational databases. Many systems also allow additional metadata outside the content of the document itself
Pocketbook (application)
Pocketbook was a Sydney-based free budget planner and personal finance app launched in 2012. The app helped users setup and manage budgets, track spending and manage bills. As of 2016 Pocketbook claimed to support over 250,000 Australians, in January 2018 that number was 435,000. After being acquired by Zip Co Ltd in 2016, it was announced in 2022 that the app was to be shut down and all user accounts deleted. == History == Pocketbook was founded by Alvin Singh and Bosco Tan in 2012. It was conceived in 2011 in a Wolli Creek apartment as a tool for Alvin and Bosco to take control of their money. In 2013, Pocketbook raised $500,000 from technology fund Tank Stream Ventures, and a group of investors including TV personality David Koch, Geoff Levy, David Shein and Peter Cooper. In September 2016 Digital retail finance and payment industry player zipMoney (now trading as Zip Co Limited) acquired Pocketbook in a $7.5m deal == Features == The app synced with the bank account of users and would organize spending into different categories. Users could also be reminded of bill payments, analyse spending and set spending limits. They can also be alerted of fraudulent transactions and deductions. The app employs security measures like end to end encryption, CloudFlare protection, fraud detection, identity protection etc. Pocketbook was available via web and mobile version. == Awards == Personal Finance Innovator of the Year by Fintech Business Awards 2017 Innovator of the Year by OPTUS MyBusiness Awards 2017 Best Finance App of 2016 by Australian Fintech Best Personal Finance App: Pocketbook won the 2016 Finder Innovation Awards, presented at a gala dinner hosted by media personality and The New Inventors presenter James O'Loghlin. Best Mobile App of the Year Winner: StartCon hosted the first annual Australasian Startup Awards. Over 200 nominations in 14 categories and an overall winner were reviewed, and winners were determined by public voting, with over 63,000 votes in total. Best New Startup 2014 by StartupSmart. Finalist in the SWIFT Innotribe startup competition in Dubai in 2013.
Comparison of color models in computer graphics
This article provides introductory information about the RGB, HSV, and HSL color models from a computer graphics (web pages, images) perspective. An introduction to colors is also provided to support the main discussion. == Basics of color == === Primary colors and hue === First, "color" refers to the human brain's subjective interpretation of combinations of a narrow band of wavelengths of light. For this reason, the definition of "color" is not based on a strict set of physical phenomena. Therefore, even basic concepts like "primary colors" are not clearly defined. For example, traditional "Painter's Colors" use red, blue, and yellow as the primary colors, "Printer's Colors" use cyan, yellow, and magenta, and "Light Colors" use red, green, and blue. "Light colors", more formally known as additive colors, are formed by combining red, green, and blue light. This article refers to additive colors and refers to red, green, and blue as the primary colors. Hue is a term describing a pure color, that is, a color not modified by tinting or shading (see below). In additive colors, hues are formed by combining two primary colors. When two primary colors are combined in equal intensities, the result is a "secondary color". === Color wheel === A color wheel is a tool that provides a visual representation of the relationships between all possible hues. The primary colors are arranged around a circle at equal (120 degree) intervals. (Warning: Color wheels frequently depict "Painter's Colors" primary colors, which leads to a different set of hues than additive colors.) The illustration shows a simple color wheel based on the additive colors. Note that the position (top, right) of the starting color, typically red, is arbitrary, as is the order of green and blue (clockwise, counter-clockwise). The illustration also shows the secondary colors, yellow, cyan, and magenta, located halfway between (60 degrees) the primary colors. == Complementary color == The complement of a hue is the hue that is opposite it (180 degrees) on the color wheel. Using additive colors, mixing a hue and its complement in equal amounts produces white. === Tints and shades === The following discussion uses an illustration involving three projectors pointing to the same spot on a screen. Each projector is capable of generating one hue. The "intensities" of each projector are "matched" and can be equally adjusted from zero to full. (Note: "Intensity" is used here in the same sense as the RGB color model. The subject of matching, or "gamma correction", is beyond the level of this article.) A shade is produced by "dimming" a maximum chroma color. Painters refer to this as "adding black". In our illustration, one projector is set to full intensity, a second is set to some intensity between zero and full, and third is set to zero. "Dimming" is accomplished by decreasing each projector's intensity setting to the same fraction of its start setting. In the shade example, with any fully shaded hue, that all three projectors are set to zero intensity, resulting in black. A tint is produced by "lightening" a maximum chroma color. Painters refer to this as "adding white". In our illustration, one projector is set to full intensity, a second is set to some intensity between zero and full, and third is set to zero. "Lightening" is accomplished by increasing each projector's intensity setting by the same fraction from its start setting to full. In the tinting example, note that the third projector is now contributing. When the hue is fully lightened, all three projectors are each at full intensity, and the result is white. Note an attribute of the total intensity in the additive model. If full intensity for one projector is 1, then a primary color has a combined intensity of 1. A secondary color has a total intensity of 2. White has a total intensity of 3. Tinting, or "adding white", increases the total intensity of the hue. While this is simply a fact, the HSL model will take this fact into account in its design. === Tones === Tone is a general term, typically used by painters, to refer to the effects of reducing the "colorfulness" of a maximum chroma color; painters refer to it as "adding gray". Note that gray is not a color or even a single concept but refers to all the range of values between black and white where all three primary colors are equally represented. The general term is provided as more specific terms have conflicting definitions in different color models. Thus, shading takes a hue toward black, tinting takes a hue towards white, and tones cover the range between. == Choosing a color model == No one color model is necessarily "better" than another. Typically, the choice of a color model is dictated by external factors, such as a graphics tool or the need to specify colors according to the CSS2 or CSS3 standard. The following discussion only describes how the models function, centered on the concepts of hue, shade, tint, and tone. === RGB === The RGB model's approach to colors is important because: It directly reflects the physical properties of "Truecolor" displays As of 2011, most graphic cards define pixel values in terms of the colors red, green, and blue. The typical range of intensity values for each color, 0–255, is based on taking a binary number with 32 bits and breaking it up into four bytes of 8 bits each. 8 bits can hold a value from 0 to 255. The fourth byte is used to specify the "alpha", or the opacity, of the color. Opacity comes into play when layers with different colors are stacked. If the color in the top layer is less than fully opaque (alpha < 255), the color from underlying layers "shows through". In the RGB model, hues are represented by specifying one color as full intensity (255), a second color with a variable intensity, and the third color with no intensity (0). The following provides some examples using red as the full-intensity and green as the partial-intensity colors; blue is always zero: Shades are created by multiplying the intensity of each primary color by 1 minus the shade factor, in the range 0 to 1. A shade factor of 0 does nothing to the hue, a shade factor of 1 produces black: new intensity = current intensity (1 – shade factor) The following provides examples using orange: Tints are created by modifying each primary color as follows: the intensity is increased so that the difference between the intensity and full intensity (255) is decreased by the tint factor, in the range 0 to 1. A tint factor of 0 does nothing, a tint factor of 1 produces white: new intensity = current intensity + (255 – current intensity) tint factor The following provides examples using orange: Tones are created by applying both a shade and a tint. The order in which the two operations are performed does not matter, with the following restriction: when a tint operation is performed on a shade, the intensity of the dominant color becomes the "full intensity"; that is, the intensity value of the dominant color must be used in place of 255. The following provides examples using orange: === HSV === The HSV, or HSB, model describes colors in terms of hue, saturation, and value (brightness). Note that the range of values for each attribute is arbitrarily defined by various tools or standards. Be sure to determine the value ranges before attempting to interpret a value. Hue corresponds directly to the concept of hue in the Color Basics section. The advantages of using hue are The angular relationship between tones around the color circle is easily identified Shades, tints, and tones can be generated easily without affecting the hue Saturation corresponds directly to the concept of tint in the Color Basics section, except that full saturation produces no tint, while zero saturation produces white, a shade of gray, or black. Value corresponds directly to the concept of intensity in the Color Basics section. Pure colors are produced by specifying a hue with full saturation and value Shades are produced by specifying a hue with full saturation and less than full value Tints are produced by specifying a hue with less than full saturation and full value Tones are produced by specifying a hue and both less than full saturation and value White is produced by specifying zero saturation and full value, regardless of hue Black is produced by specifying zero value, regardless of hue or saturation Shades of gray are produced by specifying zero saturation and between zero and full value The advantage of HSV is that each of its attributes corresponds directly to the basic color concepts, which makes it conceptually simple. The perceived disadvantage of HSV is that the saturation attribute corresponds to tinting, so desaturated colors have increasing total intensity. For this reason, the CSS3 standard plans to support RGB and HSL but not HSV. === HSL === The HSL model describes colors in terms of hue, saturation, and lightness (also called luminance). (Note: the definition of sa