An event store is a type of database optimized for storage of events. Conceptually, an event store records only the events affecting an entity, dossier, or policy, and the state of the entity at any point in its history can be reconstructed by replaying its contributing events in sequential order. Events (and their corresponding data) are the only "real" facts that should be stored in the database. All other objects can be derived from these events, meaning they are instantiated in memory by runtime code as needed (e.g. for showing in a user interface). In theory, any object that aggregates over recorded event data is not stored in the database. Instead these objects are built 'on the fly', by traversing the event history. When the aggregated object instance is no longer needed, it can simply be discarded (released from memory). == Example with insurance policies == For example, the event store concept of a database can be applied to insurance policies or pension dossiers. In these policies or dossiers the instantiation of each object that make up the dossier or policy (the person, partner(s), employments, etc.) can be derived and can be instantiated in memory based on the real world events. == Double timeline == A crucial part of an event store database is that each event has a double timeline: This enables event stores to correct errors of events that have been entered into the event store database before. The two dates are: Valid date is the date at which the event has become valid. Transaction date is the date at which the event is entered into the database. == Error correction == Another crucial part of an event store database is that events that are stored are not allowed to be changed. Once stored, also erroneous events are not changed anymore. The only way to change (or better: correct) these events is to instantiate a new event with the new values and using the double timeline. A correcting event would have the new values of the original event, with an event data of that corrected event, but a different transaction date. This mechanism ensures reproducibility at each moment in the time, even in the time period before the correction has taken place. It also allows to reproduce situations based on erroneous events (if required). == Advantages and disadvantages == One advantage of the event store concept is that handling the effects of back dated events (events that take effect before previous events and that may even invalidate them) is much easier. An event store will simplify the code in that rolling back erroneous situations and rolling up the new, correct situations is not needed anymore. Disadvantage may be that the code needs to re-instantiate all objects in memory based on the events each time a service call is received for a specific dossier or policy. == Compared to regular databases == In regular databases, handling backdated events to correct previous, erroneous events can be painful as it often results in rolling back all previous, erroneous transactions and objects and rolling up the new, correct transactions and objects. In an event store, only the new event (and its corresponding facts) are stored. The code will then redetermine the transactions and objects based on the new facts in memory.
Generative design
Generative design is an iterative design process that uses software to generate outputs that fulfill a set of constraints iteratively adjusted by a designer. Whether a human, test program, or artificial intelligence, the designer algorithmically or manually refines the feasible region of the program's inputs and outputs with each iteration to fulfill evolving design requirements. By employing computing power to evaluate more design permutations than a human alone is capable of, the process is capable of producing an optimal design that mimics nature's evolutionary approach to design through genetic variation and selection. The output can be images, sounds, architectural models, animation, and much more. It is, therefore, a fast method of exploring design possibilities that is used in various design fields such as art, architecture, communication design, and product design. Generative design has become more important, largely due to new programming environments or scripting capabilities that have made it relatively easy, even for designers with little programming experience, to implement their ideas. Additionally, this process can create solutions to substantially complex problems that would otherwise be resource-exhaustive with an alternative approach, making it a more attractive option for problems with a large or unknown solution set. It is also facilitated with tools in commercially available CAD packages. Not only are implementation tools more accessible, but also tools leveraging generative design as a foundation. Recent advancements have led to the development of Deep Generative Design, a framework that integrates topology optimization with deep learning models, such as Generative Adversarial Networks (GANs). Unlike traditional evolutionary methods that primarily focus on engineering performance, this approach uses deep generative models to enhance aesthetic diversity and novelty while simultaneously satisfying engineering constraints. For instance, research by Oh et al. (2019) proposed a framework using Boundary Equilibrium GANs (BEGAN) to generate diverse design options which are then refined through density-based topology optimization, allowing for the exploration of complex design spaces that balance structural integrity with visual variation. In practice, generative design does not solely aim to produce a single optimal solution, but involves iteratively refining the design problem by modifying parameters, constraints, and evaluation criteria within a computational model, resulting in multiple design alternatives from which the designer selects. == Use in architecture == Generative design in architecture is an iterative design process that enables architects to explore a wider solution space with more possibility and creativity. Architectural design has long been regarded as a wicked problem. Compared with traditional top-down design approach, generative design can address design problems efficiently, by using a bottom-up paradigm that uses parametric-defined rules to generate complex solutions. The solution itself then evolves to a good, if not optimal, solution. The advantage of using generative design as a design tool is that it does not construct fixed geometries, but take a set of design rules that can generate an infinite set of possible design solutions. The generated design solutions can be more sensitive, responsive, and adaptive to the problem. Generative design involves rule definition and result analysis that are integrated with the design process. By defining parameters and rules, the generative approach is able to provide optimized solution for both structural stability and aesthetics. Possible design algorithms include cellular automata, shape grammar, genetic algorithm, space syntax, and most recently, artificial neural network. Due to the high complexity of the solution generated, rule-based computational tools, such as finite element method and topology optimisation, are preferred to evaluate and optimise the generated solution. The iterative process provided by computer software enables the trial-and-error approach in design, and involves architects interfering with the optimisation process. Historically precedent work includes Antoni Gaudí's Sagrada Família, which used rule based geometrical forms for structures, and Buckminster Fuller's Montreal Biosphere where the rules were designed to generate individual components, rather than the final product. More recent generative-design cases include Foster and Partners' Queen Elizabeth II Great Court, where the tessellated glass roof was designed using a geometric schema to define hierarchical relationships, and then the generated solution was optimized based on geometrical and structural requirements. == Use in sustainable design == Generative design in sustainable design is an effective approach addressing energy efficiency and climate change at the early design stage, recognizing buildings contribute to approximately one-third of global greenhouse gas emissions and 30%-40% of total building energy use. It integrates environmental principles with algorithms, enabling exploration of countless design alternatives to enhance energy performance, reduce carbon footprints, and minimize waste. A key feature of generative design in sustainable design is its ability to incorporate Building Performance Simulations (BPS) into the design process. Simulation programs such as EnergyPlus, Ladybug Tools,, and so on, combined with generative algorithms, can optimize design solutions for cost-effective energy use and zero-carbon building designs. For example, the GENE_ARCH system used a Pareto algorithm with building energy simulation for the whole building design optimization. Generative design has improved sustainable facade design, as illustrated by the algorithm of cellular automata and daylight simulations in adaptive facade design. In addition, genetic algorithms were used with radiation simulations for energy-efficient photo-voltaic (PV) modules on high-rise building facades. Generative design is also applied to life cycle analysis (LCA), as demonstrated by a framework using grid search algorithms to optimize exterior wall design for minimum environmental impact. Multi-objective optimization embraces multiple diverse sustainability goals, such as interactive kinetic louvers using biomimicry and daylight simulations to enhance daylight, visual comfort, and energy efficiency. The study of PV and shading systems can maximize on-site electricity, improve visual quality, and daylight performance. Artificial intelligence (AI) and machine learning (ML) further improve computation efficiency in complex climate-responsive sustainable design. One study employed reinforcement learning to identify the relationship between design parameters and energy use for a sustainable campus, while other studies tried hybrid algorithms, such as using the genetic algorithm and GANs to balance daylight illumination and thermal comfort under different roof conditions. Other popular AI tools were also integrated, including deep reinforcement learning (DRL) and computer vision (CV), to generate an urban block according to direct sunlight hours and solar heat gains. These AI-driven generative design methods enable faster simulations and design decision making, resulting in designs that are environmentally responsible. == Use in additive manufacturing == Additive manufacturing (AM) is a process that creates physical models directly from three-dimensional (3D) data by joining materials layer by layer. It is used in industries to produce a variety of end-use parts, which are final components designed for direct application in products or systems. AM provides design flexibility and enables material reduction in lightweight applications, such as aerospace, automotive, medical, and portable electronic devices, where minimizing weight is critical for performance. Generative design, one of the four key methods for lightweight design in AM, is commonly applied to optimize structures for specific performance requirements. Generative design can help create optimized solutions that balance multiple objectives, such as enhancing performance while minimizing cost. In design for additive manufacturing (DfAM), multi-objective topology optimization is used to generate a set of candidate solutions. Designers then assess these options using their expertise and key performance indicators (KPIs) to select the best option for implementation. However, integrating AM constraints (e.g., speed of build, materials, build envelope, and accuracy) into generative design remains challenging, as ensuring all solutions are valid is complex. Balancing multiple design objectives while limiting computational costs adds further challenges for designers. To overcome these difficulties, researchers proposed a generative design method with manufacturing validation to improve decision-making efficiency. This method starts with a cons
CPU modes
CPU modes (also called processor modes, CPU states, CPU privilege levels and other names) are operating modes for the central processing unit of most computer architectures that place restrictions on the type and scope of operations that can be performed by instructions being executed by the CPU. For example, this design allows an operating system to run with more privileges than application software by running the operating systems and applications in different modes. Ideally, only highly trusted kernel code is allowed to execute in the unrestricted mode; everything else (including non-supervisory portions of the operating system) runs in a restricted mode and must use a system call (via interrupt) to request the kernel perform on its behalf any operation that could damage or compromise the system, making it impossible for untrusted programs to alter or damage other programs (or the computing system itself). Device drivers are designed to be part of the kernel due to the need for frequent I/O access. Multiple modes can be implemented, e.g. allowing a hypervisor to run multiple operating system supervisors beneath it, which is the basic design of many virtual machine systems available today. == Mode types == The unrestricted mode is often called kernel mode, but many other designations exist (master mode, supervisor mode, privileged mode, etc.). Restricted modes are usually referred to as user modes, but are also known by many other names (slave mode, problem state, etc.). Hypervisor Hypervisor mode is used to support virtualization, allowing the simultaneous operation of multiple operating systems. Kernel and user In kernel mode, the CPU may perform any operation allowed by its architecture; any instruction may be executed, any I/O operation initiated, any area of memory accessed, and so on. In the other CPU modes, certain restrictions on CPU operations are enforced by the hardware. Typically, certain instructions are not permitted (especially those—including I/O operations—that could alter the global state of the machine), some memory areas cannot be accessed, etc. User-mode capabilities of the CPU are typically a subset of those available in kernel mode, but in some cases, such as hardware emulation of non-native architectures, they may be significantly different from those available in standard kernel mode. Some CPU architectures support more modes than those, often with a hierarchy of privileges. These architectures are often said to have ring-based security, wherein the hierarchy of privileges resembles a set of concentric rings, with the kernel mode in the center. Multics hardware was the first significant implementation of ring security, but many other hardware platforms have been designed along similar lines, including the Intel 80286 protected mode, and the IA-64 as well, though it is referred to by a different name in these cases. Mode protection may extend to resources beyond the CPU hardware itself. Hardware registers track the current operating mode of the CPU, but additional virtual-memory registers, page-table entries, and other data may track mode identifiers for other resources. For example, a CPU may be operating in Ring 0 as indicated by a status word in the CPU itself, but every access to memory may additionally be validated against a separate ring number for the virtual-memory segment targeted by the access, and/or against a ring number for the physical page (if any) being targeted. This has been demonstrated with the PSP handheld system. Hardware that meets the Popek and Goldberg virtualization requirements makes writing software to efficiently support a virtual machine much simpler. Such a system can run software that "believes" it is running in supervisor mode, but is actually running in user mode. == Architectures == Several computer systems introduced in the 1960s, such as the IBM System/360, DEC PDP-6/PDP-10, the GE-600/Honeywell 6000 series, and the Burroughs B5000 series and B6500 series, support two CPU modes; a mode that grants full privileges to code running in that mode, and a mode that prevents direct access to input/output devices and some other hardware facilities to code running in that mode. The first mode is referred to by names such as supervisor state (System/360), executive mode (PDP-6/PDP-10), master mode (GE-600 series), control mode (B5000 series), and control state (B6500 series). The second mode is referred to by names such as problem state (System/360), user mode (PDP-6/PDP-10), slave mode (GE-600 series), and normal state (B6500 series); there are multiple non-control modes in the B5000 series. === RISC-V === RISC-V has three main CPU modes: User Mode (U), Supervisor Mode (S), and Machine Mode (M). Virtualization is supported via an orthogonal CSR setting instead of a fourth mode.
Security of the Java software platform
The Java software platform provides a number of features designed for improving the security of Java applications. This includes enforcing runtime constraints through the use of the Java Virtual Machine (JVM), a security manager that sandboxes untrusted code from the rest of the operating system, and a suite of security APIs that Java developers can utilise. Despite this, criticism has been directed at the programming language, and Oracle, due to an increase in malicious programs that revealed security vulnerabilities in the JVM, which were subsequently not properly addressed by Oracle in a timely manner. == Security features == === The JVM === The binary form of programs running on the Java platform is not native machine code but an intermediate bytecode. The JVM performs verification on this bytecode before running it to prevent the program from performing unsafe operations such as branching to incorrect locations, which may contain data rather than instructions. It also allows the JVM to enforce runtime constraints such as array bounds checking. This means that Java programs are significantly less likely to suffer from memory safety flaws such as buffer overflow than programs written in languages such as C which do not provide such memory safety guarantees. The platform does not allow programs to perform certain potentially unsafe operations such as pointer arithmetic or unchecked type casts. It manages memory allocation and initialization and provides automatic garbage collection which in many cases (but not all) relieves the developer from manual memory management. This contributes to type safety and memory safety. === Security manager === The platform provides a security manager which allows users to run untrusted bytecode in a "sandboxed" environment designed to protect them from malicious or poorly written software by preventing the untrusted code from accessing certain platform features and APIs. For example, untrusted code might be prevented from reading or writing files on the local filesystem, running arbitrary commands with the current user's privileges, accessing communication networks, accessing the internal private state of objects using reflection, or causing the JVM to exit. The security manager also allows Java programs to be cryptographically signed; users can choose to allow code with a valid digital signature from a trusted entity to run with full privileges in circumstances where it would otherwise be untrusted. Users can also set fine-grained access control policies for programs from different sources. For example, a user may decide that only system classes should be fully trusted, that code from certain trusted entities may be allowed to read certain specific files, and that all other code should be fully sandboxed. === Security APIs === The Java Class Library provides a number of APIs related to security, such as standard cryptographic algorithms, authentication, and secure communication protocols. === The sun.misc.Unsafe class === sun.misc.Unsafe is an internal utility class in the Java programming language which is a collection of low-level unsafe operations. While it is not a part of the official Java Class Library, it is called internally by the Java libraries. It resides in an unofficial Java module named jdk.unsupported. Beginning in Java 11, it has been partially migrated to jdk.internal.misc.Unsafe (which resides in module java.base). Its primary feature is to allow direct memory management (similar to C memory management) and memory address manipulation, manipulating objects and fields, thread manipulation, and concurrency primitives. Its declaration is: public final class Unsafe;, and it is a singleton class with a private constructor. It contains the following methods, many of which are declared native (invoking Java Native Interface): static Unsafe getUnsafe(): retrieves the Unsafe instance. It uses sun.reflect.Reflection to do so. int getInt(Object o, long offset): fetches a value (a field or array element) in the object at the given offset. (There are corresponding getBoolean(), getByte(), getShort(), getChar(), getLong(), getFloat(), and getDouble() methods as well.) void putInt(Object o, long offset, int x): stores a value into an object at the given offset. (There are corresponding putBoolean(), putByte(), putShort(), putChar(), putLong(), putFloat(), and putDouble() methods as well.) Object getObject(Object o, long offset): fetches a reference value from an object at the given offset. void putObject(Object o, long offset, Object x): stores a reference value into an object at the given offset. int getInt(long address): fetches a value at the given address. (There are corresponding getBoolean(), getByte(), getShort(), getChar(), getLong(), getFloat(), and getDouble() methods as well.) void putInt(long address, int x): stores a value into the given address. (There are corresponding putBoolean(), putByte(), putShort(), putChar(), putLong(), putFloat(), and putDouble() methods as well.) long getAddress(long address): fetches a native pointer from a given address. void putAddress(long address, long x): stores a native pointer into a given address. long allocateMemory(long bytes): allocates a block of native memory of the given size (similar to malloc()). long reallocateMemory(long address, long bytes): resizes a block of native memory to the given size (similar to realloc()). void setMemory(Object o, long offset, long bytes, byte value), void setMemory(long address, long bytes, byte value): sets all bytes in a block of memory to a fixed value (similar to memset()). void copyMemory(Object srcBase, long srcOffset, Object destBase, long destOffset, long bytes), void copyMemory(long srcAddress, long destAddress, long bytes): sets all bytes in a given block of memory to a copy of another block (similar to memcpy()). void freeMemory(long address): deallocates a block of native memory obtained from allocateMemory() or reallocateMemory(), similar to free()). long staticFieldOffset(Field f): obtains the location of a given field in the storage allocation of its class. long objectFieldOffset(Field f): obtains the location of a given static field in conjunction with staticFieldBase(). Object staticFieldBase(Field f): obtains the location of a given static field in conjunction with staticFieldOffset(). void ensureClassInitialized(Class c): ensures the given class has been initialized. int arrayBaseOffset(Class arrayClass): obtains the offset of the first element in the storage allocation of a given array class. int arrayIndexScale(Class arrayClass): obtains the scale factor for addressing elements in the storage allocation of a given array class. static int addressSize(): obtains the size (in bytes) of a native pointer. int pageSize(): obtains the size (in bytes) of a native memory page. Class defineClass(String name, byte[] b, int off, int len, ClassLoader loader, ProtectionDomain protectionDomain): signals to the JVM to define a class without security checks. Class defineAnonymousClass(Class hostClass, byte[] data, Object[] cpPatches): signals to the JVM to define a class but do not make it known to the class loader or system directory. Object allocateInstance(Class cls) throws InstantiationException: allocates an instance of a class without running its constructor. void monitorEnter(Object o): locks an object. void monitorExit(Object o): unlocks an object. boolean tryMonitorEnter(Object o): tries to lock an object, returning whether the lock succeeded. void throwException(Throwable ee): throws an exception without telling the verifier. final boolean compareAndSwapInt(Object o, long offset, int expected, int x): updates a variable to x if it is holding expected, returning whether the operation succeeded. (There are corresponding compareAndSwapLong() and compareAndSwapObject() methods as well.) int getIntVolatile(Object o, long offset): volatile version of getInt(). (There are corresponding getBooleanVolatile(), getByteVolatile(), getShortVolatile(), getCharVolatile(), getLongVolatile(), getFloatVolatile(), getDoubleVolatile(), and getObjectVolatile() methods as well.) void putIntVolatile(Object o, long offset, int x): volatile version of putInt(). (There are corresponding putBooleanVolatile(), putByteVolatile(), putShortVolatile(), putCharVolatile(), putLongVolatile(), putFloatVolatile(), putDoubleVolatile(), and putObjectVolatile() methods as well.) void putOrderedInt(Object o, long offset, int x): version of putIntVolatile() not guaranteeing immediate visibility of storage to other threads. (There are corresponding putOrderedLong() and putOrderedObject() methods as well.) void unpark(Object thread): unblocks a thread. void park(boolean isAbsolute, long time): blocks the current thread. int getLoadAverage(double[] loadavg, int nelems): gets the load average in the system run queue assigned to available processors averaged over various periods of time. void invokeCleaner(ByteBuffe
Data remanence
Data remanence is the residual representation of digital data that remains even after attempts have been made to remove or erase the data. This residue may result from data being left intact by a nominal file deletion operation, by reformatting of storage media that does not remove data previously written to the media, or through physical properties of the storage media that allow previously written data to be recovered. Data remanence may make inadvertent disclosure of sensitive information possible should the storage media be released into an uncontrolled environment (e.g., thrown in refuse containers or lost). Various techniques have been developed to counter data remanence. These techniques are classified as clearing, purging/sanitizing, or destruction. Specific methods include overwriting, degaussing, encryption, and media destruction. Effective application of countermeasures can be complicated by several factors, including media that are inaccessible, media that cannot effectively be erased, advanced storage systems that maintain histories of data throughout the data's life cycle, and persistence of data in memory that is typically considered volatile. Several standards exist for the secure removal of data and the elimination of data remanence. == Causes == Many operating systems, file managers, and other software provide a facility where a file is not immediately deleted when the user requests that action. Instead, the file is moved to a holding area (i.e. the "trash"), making it easy for the user to undo a mistake. Similarly, many software products automatically create backup copies of files that are being edited, to allow the user to restore the original version, or to recover from a possible crash (autosave feature). Even when an explicit deleted file retention facility is not provided or when the user does not use it, operating systems do not actually remove the contents of a file when it is deleted unless they are aware that explicit erasure commands are required, like on a solid-state drive. (In such cases, the operating system will issue the Serial ATA TRIM command or the SCSI UNMAP command to let the drive know to no longer maintain the deleted data.) Instead, they simply remove the file's entry from the file system directory because this requires less work and is therefore faster, and the contents of the file—the actual data—remain on the storage medium. The data will remain there until the operating system reuses the space for new data. In some systems, enough filesystem metadata are also left behind to enable easy undeletion by commonly available utility software. Even when undelete has become impossible, the data, until it has been overwritten, can be read by software that reads disk sectors directly. Computer forensics often employs such software. Likewise, reformatting, repartitioning, or reimaging a system is unlikely to write to every area of the disk, though all will cause the disk to appear empty or, in the case of reimaging, empty except for the files present in the image, to most software. Finally, even when the storage media is overwritten, physical properties of the media may permit recovery of the previous contents. In most cases however, this recovery is not possible by just reading from the storage device in the usual way, but requires using laboratory techniques such as disassembling the device and directly accessing/reading from its components. § Complications below gives further explanations for causes of data remanence. == Countermeasures == There are three levels commonly recognized for eliminating remnant data: === Clearing === Clearing is the removal of sensitive data from storage devices in such a way that there is assurance that the data may not be reconstructed using normal system functions or software file/data recovery utilities. The data may still be recoverable, but not without special laboratory techniques. Clearing is typically an administrative protection against accidental disclosure within an organization. For example, before a hard drive is re-used within an organization, its contents may be cleared to prevent their accidental disclosure to the next user. === Purging === Purging or sanitizing is the physical rewrite of sensitive data from a system or storage device done with the specific intent of rendering the data unrecoverable at a later time. Purging, proportional to the sensitivity of the data, is generally done before releasing media beyond control, such as before discarding old media, or moving media to a computer with different security requirements. === Destruction === The storage media is made unusable for conventional equipment. Effectiveness of destroying the media varies by medium and method. Depending on recording density of the media, and/or the destruction technique, this may leave data recoverable by laboratory methods. Conversely, destruction using appropriate techniques is the most secure method of preventing retrieval. == Specific methods == === Overwriting === A common method used to counter data remanence is to overwrite the storage media with new data. This is often called wiping or shredding a disk or file, by analogy to common methods of destroying print media, although the mechanism bears no similarity to these. Because such a method can often be implemented in software alone, and may be able to selectively target only part of the media, it is a popular, low-cost option for some applications. Overwriting is generally an acceptable method of clearing, as long as the media is writable and not damaged. The simplest overwrite technique writes the same data everywhere—often just a pattern of all zeros. At a minimum, this will prevent the data from being retrieved simply by reading from the media again using standard system functions. The UEFI in modern machines may offer an ATA class disk erase function as well. The ATA-6 standard governs secure erases specifications. Bitlocker is whole disk encryption and illegible without the key. Writing a fresh GPT allows a new file system to be established. Blocks will set empty but LBA read is illegible. New data will be unaffected and work fine. In an attempt to counter more advanced data recovery techniques, specific overwrite patterns and multiple passes have often been prescribed. These may be generic patterns intended to eradicate any trace signatures; an example is the seven-pass pattern 0xF6, 0x00, 0xFF,
Cone tracing
Cone tracing and beam tracing are a derivative of the ray tracing algorithm that replaces rays, which have no thickness, with thick rays. == Principles == In ray tracing, rays are often modeled as geometric ray with no thickness to perform efficient geometric queries such as a ray-triangle intersection. From a physics of light transport point of view, however, this is an inaccurate model provided the pixel on the sensor plane has non-zero area. In the simplified pinhole camera optics model, the energy reaching the pixel comes from the integral of radiance from the solid angle by which the sensor pixel sees the scene through the pinhole at the focal plane. This yields the key notion of pixel footprint on surfaces or in the texture space, which is the back projection of the pixel on to the scene. Note that this approach can also represent a lens-based camera and thus depth of field effects, using a cone whose cross-section decreases from the lens size to zero at the focal plane, and then increases. Real optical system do not focus on exact points because of diffraction and imperfections. This can be modeled with a point spread function (PSF) weighted within a solid angle larger than the pixel. From a signal processing point of view, ignoring the point spread function and approximating the integral of radiance with a single, central sample (through a ray with no thickness) can lead to strong aliasing because the "projected geometric signal" has very high frequencies exceeding the Nyquist-Shannon maximal frequency that can be represented using the uniform pixel sampling rate. The physically based image formation model can be approximated by the convolution with the point spread function assuming the function is shift-invariant and linear. In practice, techniques such as multisample anti-aliasing estimate this cone-based model by oversampling the signal and then performing a convolution (the reconstruction filter). The backprojected cone footprint onto the scene can also be used to directly pre-filter the geometry and textures of the scene. Note that contrary to intuition, the reconstruction filter should not be the pixel footprint (as the pinhole camera model would suggest), since a box filter has poor spectral properties. Conversely, the ideal sinc function is not practical, having infinite support with possibly negative values which often creates ringing artifacts due to the Gibbs phenomenon. A Gaussian or a Lanczos filter are considered good compromises. == Computer graphics models == Cone and Beam early papers rely on different simplifications: the first considers a circular section and treats the intersection with various possible shapes. The second treats an accurate pyramidal beam through the pixel and along a complex path, but it only works for polyhedrical shapes. Cone tracing solves certain problems related to sampling and aliasing, which can plague conventional ray tracing. However, cone tracing creates a host of problems of its own. For example, just intersecting a cone with scene geometry leads to an enormous variety of possible results. For this reason, cone tracing has remained mostly unpopular. In recent years, increases in computer speed have made Monte Carlo algorithms like distributed ray tracing - i.e. stochastic explicit integration of the pixel - much more used than cone tracing because the results are exact provided enough samples are used. But the convergence is so slow that even in the context of off-line rendering a huge amount of time can be required to avoid noise. Differential cone-tracing, considering a differential angular neighborhood around a ray, avoids the complexity of exact geometry intersection but requires a LOD representation of the geometry and appearance of the objects. MIPmapping is an approximation of it limited to the integration of the surface texture within a cone footprint. Differential ray-tracing extends it to textured surfaces viewed through complex paths of cones reflected or refracted by curved surfaces. Raymarching methods over signed distance fields (SDFs) naturally allow easy use of cone-like tracing, at zero additional cost to the tracing, and both speeds up tracing and improves quality. Voxel cone tracing is a real-time algorithm that uses a hierarchical voxel representation of scene geometry, such as a sparse voxel octree, to support fast cone tracing for indirect illumination. This approach allows for the approximation of effects like glossy reflections and ambient occlusion at interactive framerates without the need for precomputation.
Hedgeable
Hedgeable, Inc. was a U.S. based financial services company and digital wealth management platform headquartered in New York City. Hedgeable was known for not following set allocations, and instead actively managing accounts in response to market movements. On August 9, 2018, Hedgeable closed its doors to new investors, with existing investors required to transfer out of the company. The company claimed that it was not shutting down but simply removing its SEC registration. == History == Hedgeable was founded in 2009 by twin brothers Michael and Matthew Kane, who previously worked at high-net worth investment managers such as Bridgewater Associates and Spruce Private Investors. Both Michael and Matthew graduated from Penn State University with degrees in finance. Hedgeable is a Registered Investment Advisor with the U.S. Securities and Exchange Commission. The company has received funding from SixThirty and Route 66 Ventures as well as various other angel investors. On August 9, 2018, Hedgeable closed its doors to new investors. == Investing Strategies == Hedgeable did not follow a buy-and-hold approach, but instead actively manages accounts in response to market movements focusing on downside protection in bear markets. Their strategy was different from other robo-advisors, which use Modern Portfolio Theory. Hedgeable offered investment options including Exchange Traded Funds (ETFs) to individual stocks, master limited partnerships, private equity and bitcoin. Mutual funds were not used in portfolios. Although the firm's focus was to provide a direct-to-consumer service, Hedgeable's investment strategies were available to financial advisors and institutions as well through a variety of platforms. == Product Features == When it was open to external clients, Hedgeable aimed to gamify their personal finance experience. Clients could open a new account or transfer an existing account. Hedgeable accepted retirement accounts, taxable accounts, business accounts and various other account types. Hedgeable offered the following features: Downside protection Account aggregation Alternative investments Alpha rewards API Mobile app It was awarded 4/5 for client transparency by Paladin Research. Hedgeable was the winner of the Finovate Fall 2015 Best of Show Award and the GREAT 2015 Tech Award (FinTech Category). In 2016, Hedgeable launched its first iOS mobile app in order to expand their product offerings.