Alec Baldwin and wife Hilaria reveal devastating miscarriage brought them closer
Alec Baldwin and wife Hilaria have opened up about their devastating miscarriage, insisting it has brought them closer.
The model – who shares Carmen, Rafael, Leonardo and Romeo with the actor – revealed the heartbreaking news that they had lost their baby at four months, after suffering a previous loss in April.
But the pair revealed their tragic news made them determined to try and add to their family again.
During an appearance at the American Museum of Natural History’s 2019 Gala, 61-year-old Alec vowed: ‘We’re going to have another one, just not now. It’s a question of time. It was a surprise.’
When asked how they were coping as a couple, he continued: ‘If we were closer… I would be sewn to her.’
‘I feel like we started dating again,’ Hilaria, 35, agreed, before explaining she is feeling ‘a lot better’ and less ‘alone’.
Advertisement Advertisement
‘Physically, I am feeling a lot better. Emotionally, I’m feeling a lot better,’ she added to Extra.
‘Sharing can be hard, but once you share, it feels a little more real and then once it’s more real, you can heal…
‘It also made me feel not alone.’
Hilaria and Alec announced their pregnancy earlier this year, after previously suffering a miscarriage back in April.
Just last month, the author confirmed they were welcoming a baby girl into their brood.
Sadly she told fans last week that their little one died at the four-month mark.
‘We are very sad to share that today we learned that our baby passed away at 4 months,’ she captioned an emotional video of herself and Carmen.
‘We also want you to know that even though we are not okay right now, we will be.
‘We are so lucky with our four healthy babies—and we will never lose sight of this. I told Carmen and took this so I could send it to Alec.
‘I guess this is a good way to share it with you too. I told her that this baby isn’t going to come after all…but we will try very hard to give her a little sister another time.
Advertisement Advertisement
‘I’m really devastated right now…I was not expecting this when I went to my scan today. I don’t know what else to say.
‘I’m still in shock and don’t have this all quite clear. Please no paparazzi…that’s all I ask.’
Got a showbiz story?
If you've got a story, video or pictures get in touch with the Metro.co.uk Entertainment team by emailing us<EMAIL_ADDRESS>calling 020 3615 2145 or by visiting our Submit Stuff page - we'd love to hear from you.


Package com.ai_blockchain.kafka_bc
Class TEKafkaLog4jAppender
- java.lang.Object
-
- org.apache.log4j.AppenderSkeleton
-
- org.apache.kafka.log4jappender.KafkaLog4jAppender
-
- com.ai_blockchain.kafka_bc.TEKafkaLog4jAppender
-
- All Implemented Interfaces:
org.apache.kafka.clients.producer.Callback
,org.apache.log4j.Appender
,org.apache.log4j.spi.OptionHandler
public class TEKafkaLog4jAppender extends org.apache.kafka.log4jappender.KafkaLog4jAppender implements org.apache.kafka.clients.producer.Callback
A tamper evident log4j appender that produces log messages to Kafka
-
-
Constructor Summary
Constructors Constructor Description TEKafkaLog4jAppender()
-
Method Summary
All Methods Static Methods Instance Methods Concrete Methods Modifier and Type Method Description protected void
append(org.apache.log4j.spi.LoggingEvent event)
Append the given logging event to the topic for this log.void
onCompletion(org.apache.kafka.clients.producer.RecordMetadata metadata, java.lang.Exception exception)
A callback method the user can implement to provide asynchronous handling of request completion.static void
setLogger(java.lang.String kafkaIPAddress, java.lang.String containerName, org.apache.log4j.Logger logger)
Sets the given logger to include logging to the Kafka message network.-
Methods inherited from class org.apache.log4j.AppenderSkeleton
addFilter, clearFilters, doAppend, finalize, getErrorHandler, getFilter, getFirstFilter, getLayout, getName, getThreshold, isAsSevereAsThreshold, setErrorHandler, setLayout, setName, setThreshold
-
Methods inherited from class org.apache.kafka.log4jappender.KafkaLog4jAppender
activateOptions, close, getBrokerList, getClientJaasConfPath, getCompressionType, getKafkaProducer, getKerb5ConfPath, getProducer, getRequiredNumAcks, getRetries, getSaslKerberosServiceName, getSecurityProtocol, getSslKeystoreLocation, getSslKeystorePassword, getSslKeystoreType, getSslTruststoreLocation, getSslTruststorePassword, getSyncSend, getTopic, requiresLayout, setBrokerList, setClientJaasConfPath, setCompressionType, setKerb5ConfPath, setRequiredNumAcks, setRetries, setSaslKerberosServiceName, setSecurityProtocol, setSslKeystoreLocation, setSslKeystorePassword, setSslKeystoreType, setSslTruststoreLocation, setSslTruststorePassword, setSyncSend, setTopic
-
-
-
-
Method Detail
-
setLogger
public static void setLogger(java.lang.String kafkaIPAddress, java.lang.String containerName, org.apache.log4j.Logger logger)
Sets the given logger to include logging to the Kafka message network.- Parameters:
kafkaIPAddress
- the IP address of the Kafka broker, such as "kafka:9092" or "<IP_ADDRESS>:9092"containerName
- the container name, for distinct topicslogger
- the logger for attaching the Kafka appender
-
append
protected void append(org.apache.log4j.spi.LoggingEvent event)
Append the given logging event to the topic for this log.- Overrides:
append
in classorg.apache.kafka.log4jappender.KafkaLog4jAppender
- Parameters:
event
- the given logging event
-
onCompletion
public void onCompletion(org.apache.kafka.clients.producer.RecordMetadata metadata, java.lang.Exception exception)
A callback method the user can implement to provide asynchronous handling of request completion. This method will be called when the record sent to the server has been acknowledged. Exactly one of the arguments will be non-null.- Specified by:
onCompletion
in interfaceorg.apache.kafka.clients.producer.Callback
- Parameters:
metadata
- The metadata for the record that was sent (i.e. the partition and offset). Null if an error occurred.exception
- The exception thrown during processing of this record. Null if no error occurred. Possible thrown exceptions include: Non-Retriable exceptions (fatal, the message will never be sent): InvalidTopicException OffsetMetadataTooLargeException RecordBatchTooLargeException RecordTooLargeException UnknownServerException Retriable exceptions (transient, may be covered by increasing #.retries): CorruptRecordException InvalidMetadataException NotEnoughReplicasAfterAppendException NotEnoughReplicasException OffsetOutOfRangeException TimeoutException UnknownTopicOrPartitionException
-
-


| Field Summary | ||
|---|---|---|
const Number | NONE | |
| Display unit is None. | ||
const Number | HUNDREDS | |
| Specifies the values on the chart shall be divided by 100. | ||
const Number | THOUSANDS | |
| Specifies the values on the chart shall be divided by 1,000. | ||
const Number | TEN_THOUSANDS | |
| Specifies the values on the chart shall be divided by 10,000. | ||
const Number | HUNDRED_THOUSANDS | |
| Specifies the values on the chart shall be divided by 100,000. | ||
const Number | MILLIONS | |
| Specifies the values on the chart shall be divided by 1,000,000. | ||
const Number | TEN_MILLIONS | |
| Specifies the values on the chart shall be divided by 10,000,000. | ||
const Number | HUNDRED_MILLIONS | |
| Specifies the values on the chart shall be divided by 100,000,000. | ||
const Number | BILLIONS | |
| Specifies the values on the chart shall be divided by 1,000,000,000. | ||
const Number | TRILLIONS | |
| Specifies the values on the chart shall be divided by 1,000,000,000,000. | ||
const Number | PERCENTAGE | |
| The values on the chart shall be divided by 0.01. | ||
const Number | CUST | |
| specifies a custom value for the display unit. |
| Field Detail |
|---|
NONE | |
const Number NONE |
HUNDREDS | |
const Number HUNDREDS |
THOUSANDS | |
const Number THOUSANDS |
TEN_THOUSANDS | |
const Number TEN_THOUSANDS |
HUNDRED_THOUSANDS | |
const Number HUNDRED_THOUSANDS |
MILLIONS | |
const Number MILLIONS |
TEN_MILLIONS | |
const Number TEN_MILLIONS |
HUNDRED_MILLIONS | |
const Number HUNDRED_MILLIONS |
BILLIONS | |
const Number BILLIONS |
TRILLIONS | |
const Number TRILLIONS |
PERCENTAGE | |
const Number PERCENTAGE |
CUST | |
const Number CUST |


Adds a search bar and type filter to the Salesforce Change Set interface. Using the checkbox in the table header will only check the rows that are visible. Also adds a Show All link above the paging to show all items for the current item type.
Field Set API Names
When adding a field to a Field Set, this will add the API name next to the field name. There is a known Salesforce issue where certain related fields will all display as the same name (eg. BillingAddress or Name instead of BillingStreet and FirstName, respectively).
Setup Search
In the Setup area in Salesforce, if you try and use the quick search in the left sidebar before the placeholder text is loaded, your text will be appended to the placeholder text and your search will not find what you are looking for. This will prevent the placeholder text from being loaded by default.
Object/Field API Name
When creating a new object or field, this will automatically remove the underscores in the Object/Field Name field (API Name).
Field History Tracking Counter
Displays the total number of selected fields to track history for out of the total number Salesforce allows.
Setup Area Check All
When editing settings in the setup area, this will add a checkbox to the header row cells if there is a checkbox in that column. This will allow checking and unchecking all checkboxes in that column.
Select Failed Tests Button
Adds a new button to the Apex Test Execution page called "Select Failed Tests...".
Clicking on this button will open the "Select Tests" modal, and select all tests that failed in the previous test run.
Add to Page Layout Uncheck All
When creating a new field, this setting will by default uncheck all checkboxes for adding the field to a page layout.
Allowed Number of Field History Fields
When setting the field history tracking fields, the specified "Allowed Number of Field History FIelds" will show as the "of X Selected". For example,
if 40 is entered and 5 fields are selected, the label will say "(5 of 40 selected)". By default, Salesforce allows 20 fields to be selected. However,
this limit can be increased by purchasing more.


| Document number: | WG21/N1422 = J16/03-0004 |
| Date: | February 24, 2003 |
| Project: | Programming Language C++ |
| Reference: | ISO/IEC IS 14882:1998(E) |
| Reply to: | Walter E. Brown<EMAIL_ADDRESS>|
| Fermi National Accelerator Laboratory |
|
| Batavia, Illinois, USA |
I. Background and Motivation II. Impact On the C++ Standard III. Design Decisions IV. Proposed Text V. Relationship to Earlier Proposal VI. Acknowledgements VII. References
Why is this important? What kinds of problems does it address, and what kinds of programmers is it intended to support? Is it based on existing practice?
Compared to C++ [ISO:14882], C99 [ISO:9899] provides an extended <math.h> header and library. Among the additions introduced by C99 are selected mathematical functions from categories of particular interest to the numerical computing communities: exponential and logarithmic functions, circular and hyperbolic functions, and special functions.
In particular, C99 specifies the following traditional and extended functions of numerical interest in <math.h>, each with variants to accomodate arguments of types float, double, and long double:
All these functions either (a) are already part of the C++ standard library, or (b) have already been proposed [Plauger] and discussed [Dawes, Item 1] for incorporation into the forthcoming C++ Library Technical Report [Josuttis]. We here propose to augment the C++ standard library with additional functions from the above Special Functions category.
Mathematical Special Functions are appropriate for this TR because they plug an obvious hole ("Filling Gaps," as [Austern] phrases it) in the existing standard library. While these functions are clearly numerical in nature and will likely be most heavily used by the scientific and engineering communities, other communities of programmers also have needs, ranging from frequent to intermittent, for these functions.
This Special Functions proposal additionally falls into the "Standards Coordination and Infrastructure" categories identified in [Austern] as targets for the TR, for this proposal is based on an existing standard, Quantities and units [ISO:31] Part 11: Mathematical signs and symbols for use in the physical sciences and technology. We draw particular attention to the tables constituting ISO:31-11 paragraphs 8 ("Exponential and logarithmic functions"), 9 ("Circular and hyperbolic functions"), 10 ("Complex numbers"), and 14 ("Special functions").
There is a long history of implementation experience with these functions, as evidenced, for example, by section C of the Fortran-based SLATEC Common Mathematical Library [SLATEC]. Today, special functions constitute important subsets of such well-respected add-on libraries as the NAG C Library, [NAG], the IMSL C Numerical Library [IMSL], and the GNU Scientific Library [GSL]. Further, some standard C libraries such as the SGI C library [SGI] and the GNU C library [GNU C] also provide, as extensions, a few of the proposed special functions. The benefits of incorporating them into the C++ Standard Library include predictability of interface and behavior across a broad spectrum of implementations, leading to improved portability and interoperability for applications that make use of these functions.
Finally, we believe that adoption of this proposal would send a clear message to the various numeric computing communities that, contrary to significant popular belief within these communities, C++ is an eminently suitable programming language for their problem domain, too.
What does it depend on, and what depends on it? Is it a pure extension, or does it require changes to standard components? Does it require core language changes?
This proposal is a pure extension. It does not require any changes in the core language. It does not require changes to any standard classes or functions. It does not require changes to any of the standard requirement tables. All the functions are mathematically well-understood, all have proven their utility in practice over a considerable period of time, and all have been previously implemented in C and C++.
This proposal does not depend on any other C++ library extensions. This proposal potentially overlaps slightly with another proposal [Plauger] that would incorporate the bulk of C99's library additions into C++. The potential commonality between the two proposals is, however, limited to a rather tiny part of <math.h> that is essentially identical in the two proposals; see section V for details.
Why did you choose the specific design that you did? What alternatives did you consider, and what are the tradeoffs? What are the consequences of your choice, for users and implementors? What decisions are left up to implementors? If there are any similar libraries in use, how do their design decisions compare to yours?
Following the precedent set by C99, this proposal recommends that declarations for all the proposed special functions be incorporated into <math.h> and thence extended into <cmath> in the obvious way.
An alternative design would present these additional declarations in a new header. Obvious names for this header, e.g., <special_functions.h>, seem unwieldy, and no suitably descriptive shorter names have come to mind. Further, it seems likely that implemention of some of the special functions can make advantageous use of extant functionality in <math.h> and so it seemed reasonable to avoid the separation.
Because the set of mathematical functions that can be considered Special Functions is potentially unbounded, we considered several options in selecting our list of candidates for standardization.
This proposal recommends adoption of the list of Special Functions specified in the ISO standard Quantities and units [ISO:31, Part 11, paragraph 14]. This list has already received international scrutiny and endorsement via the standardization process. Further consultations with respected scientific colleagues have confirmed that these Special Functions would, if incorporated into the C++ standard library, constitute a significant contribution to the numeric community.
A second possibility was the adoption of all the Special Functions listed in the (exhaustive!) Handbook of Mathematical Functions [Abramowitz & Stegun], the generally-accepted standard reference for this domain. However, a careful inspection of this work's extensive contents strongly suggests that its scope may be overly broad. More importantly, many of the listed functions appear to be very difficult to implement. (Indeed, a colleague suggested, not entirely in jest, that "several Ph.D. dissertations could result" from such efforts!)
We considered, third, adopting a list taken from an existing library in this domain. The Special Functions portion of the GNU Scientific Library [GSL], for example, seemed to present a reasonable set for consideration. Indeed, these functions largely constitute a superset of the list recommended above, and are all clearly implementable. However, we felt it advantageous to require only the functions in the above list, in order to allow implementers the freedom to add value by providing additional functions.
A final possibility was the construction of an ad hoc list of Special Functions. We rejected this as the least defensible of the alternatives, since there are no obvious criteria for accepting some and rejecting others, other than a feel for general utility.
We note, in passing, that we have omitted both the cylindrical and the spherical Hankel functions from our list of candidates for standardization. Our motivation for this is straightforward: we have restricted ourselves to functions taking real-valued arguments, and producing real-valued results. The Hankel functions do not qualify.
It is possible to declare the desired additional <cmath> functionality in either of two ways: as (specialized) function templates or as families of overloaded functions. We recommend overloading.
This recommendation based in significant part on arguments favoring consistency of form with the existing contents of the affected headers: There are no templates today in <math.h> or in <cmath>. Further, we are unaware of any current Special Functions implementation that is based on template technology.
Additional reasons take into account the possible future extension of the new functions to additional headers (such as, for example, <complex>). To do so in the presence of function templates would raise such issues as the location of the primary template and the concomitant need to coordinate multiple cooperating headers. We prefer to avoid such entanglements.
Most of the proposed functions must advise their caller of domain and/or range errors. In the context of C++, this would arguably be best done by throwing appropriate exceptions.
However, no standard functions in <cmath> today throw exceptions. Rather, mimicking the behavior of the functions in <math.h>, each sets a global errno variable to a suitable code (i.e., EDOM or ERANGE) defined in <cerrno>.
We recommend that this existing behavior be preserved with respect to the proposed new functions. Not only is this a matter of consistency, but it preserves the possibility that a compatible version of this proposal might be incorporated into a future revision of C99.
Having recommended, in the previous subsection, the continued use of error codes, a further question arises: Are the existing EDOM, ERANGE error codes sufficient to the needs of the proposed Special Functions?
We note that several current implementations of some of the proposed Special Functions do define their own codes to supplement the codes mandated by the standard. They incorporate codes for such situations as overflow, underflow, loss of precision, singularities, and the like, and make these codes accessible via additional global variables analogous to errno, or via other means.
Nothing in this proposal should be construed as preventing implementors from such optional extensions. However, this proposal recommends against requiring such behavior. We base this recommendation on consistency with current standards. In particular, we call attention to §7.12.1 of C99 [ISO:9899].
In selecting names for the proposed new functions, we were moved to retain their traditional (mathematical) names. For example, we kept the names of a few functions which are customarily denoted using Greek letters (spelled out, of course: beta, zeta [but tgamma for compatibility with C99]). We also kept the function names erf and erfc because they are both traditional and descriptive, as well as for compatibility with C99.
In the remaining (majority of) cases, the traditional mathematical names are mostly single letters (e.g., J and N). We judged such names to be too brief and insufficiently descriptive for programming purposes. Also, such one-character names are frequently reserved by coding standards to signify local variables. For these reasons, we recommend against use of the traditional names. Instead, we chose such names as bessel_J and neumann_N, combining a descriptive prefix with a traditional suffix.
We note in passing that this policy resulted in a few pairs of our names that differ only in the case of a single character (e.g., bessel_J and bessel_j). In each instance, this is an artifact of the traditional mathematical naming convention that we preserved on the basis of prior art as the accepted canonical mathematical nomenclature. While some coding standards recommend or require avoidance of multiple identifiers that differ only in case, we believe it appropriate in the present context to embrace case-sensitivity in distinguishing otherwise-identical names.
Many of the proposed special functions have definitions over some or all of the complex plane as well as over some or all of the real numbers. Further, some of these functions can produce complex results, even over real-valued arguments. The present proposal restricts itself by considering only real-valued arguments and (correspondingly) real-valued results.
Our investigation of the alternative led us to realize that the complex landscape for the special functions is figuratively dotted with land mines. In coming to our recommendation, we gave weight to the statement from a respected colleague that "Several Ph.D. dissertations would [or could] result from efforts to implement this set of functions over the complex domain." This led us to take the position that there is insufficient prior art in this area to serve as a basis for standardization, and that such standardization would be therefore premature. While we could perhaps consider standardizing some subset of the special functions over the complex domain, we far prefer to treat this set of special functions as a unit.
We further ruled out (via domain errors, for example) the possibility
that these special functions could return complex results. In making
this recommendation, we followed the past practice of C++ and of C99:
functions taking real arguments always return real results; only functions
taking complex arguments return complex results. Perhaps the best example
of this is the sqrt
function: it always returns a value
of type matching its parameter's type. To do otherwise opens the door
to a number of small, but bothersome technical issues. As one example,
which header (<cmath>
or <complex>
)
would declare such a function whose domain and range are different?
Finally, none of our colleagues or reviewers has presented any compelling need or rationale for the extension to the complex domain or range. While there would certainly be some segments of the user community that could take advantage of such functionality (and we certainly don't mean to prohibit vendors from providing such as extensions), there seems to be insufficient demand to require such at present.
Among the functions in this proposal, there are several (e.g.,
spherical harmonics: sph_Y()
) for which multiple phase
and normalization conventions exist. Because the choices do not easily
co-exist, we have opted to resolve any such ambiguities by appealing to
a common source, the aforementioned standard Handbook of Mathematical
Functions by [Abramowitz & Stegun].
It has been suggested that the functions constituting the subject of this proposal be reviewed within the framework of one or more parts of the International Standard for Language Independent Arithmetic [ISO:10967-1, ISO:10967-2, ISO:10967-3]. While we applaud the motivation underlying the suggestion, we recommend against such a perspective, believing it to be premature and not yet feasible.
Only LIA Part 1 has been formally adopted as an International Standard: LIA Part 2 is a Final Draft, while LIA Part 3 is only a Committee Draft. Further, LIA Part 1 does not speak to the subject of the present proposal, while Parts 2 and 3 restrict themselves to coverage of "elementary" numerical functions such as those already part of the C++ standard library. Thus, none of the LIA documents addresses (or even mentions) any of the functions comprising the present proposal.
Finally, we note that the C++ standards body has to date not adopted any "conformity statement" regarding the LIA "binding standard" to be used by a conforming C++ implementation. In the absence of such guidance, it is unclear how to apply to C++ the principles (let alone the details) of the LIA documents.
In our view, the present situation is best summarized as constituting a lack of prior art: C++ has not determined how LIA is to apply to an implementation and, in any event, none of the functions comprising the present proposal are in the scope of the LIA documents as currently drafted. For these reasons, we believe there is today an insufficient basis on which to evaluate the present proposal with respect to LIA.
Note: the wording presented in these subsections describes the contents of the <cmath> header.  A domain error occurs if l is less than zero.
A range error (due to underflow) occurs if x is too close to
any of the roots of the bessel_J function.
Returns:
The bessel_J functions return Jl(x) as denoted
in [ISO:31, Item No. 11-14.1].
26.x.3 cylindrical Neumann functions; cylindrical Bessel functions (of the second kind)
double neumann_N( double l, double x ); float neumann_N( float l, float x ); long double neumann_N( long double l, long double x );
Effects:
These functions compute the cylindrical Neumann functions (as defined
by [Abramowitz & Stegun, §9.1.2,
etc.]), also known as the cylindrical Bessel functions of the
second kind, of their respective arguments l and x.
A domain error occurs if x is less than or equal to zero.
A range error (due to overflow) occurs (a) if the magnitude of l
is too large, or (b) if x is too small. A range error (due
to underflow) occurs if x is too close to any of the roots of
the neumann_N function.
Returns:
The neumann_N functions return Nl(x) as
denoted in [ISO:31, Item No. 11-14.2].
26.x.4.1 regular modified cylindrical Bessel functions
double bessel_I( double l, double x ); float bessel_I( float l, float x ); long double bessel_I( long double l, long double x );
Effects:
These functions compute the regular modified cylindrical Bessel
functions (as defined by [Abramowitz & Stegun,
§9.6.3, etc.) of their respective arguments l and
x. A domain error occurs if l is not an integer and
either (a) l is less than or equal to zero or (b) x
is less than or equal to zero. A range error occurs if x
is too large.
Returns:
The bessell_I functions return Il(x) as
denoted in [ISO:31, Item No. 11-14.4].
26.x.4.2 irregular modified cylindrical Bessel functions
double bessel_K( double l, double x ); float bessel_K( float l, float x ); long double bessel_K( long double l, long double x );
Effects:
These functions compute the irregular modified cylindrical Bessel
functions (as defined by [Abramowitz & Stegun,
§9.6.4, etc.]) of their respective arguments l
and x. A domain error occurs if l is not an integer
and either (a) l is less than or equal to zero or (b) x
is less than or equal to zero. A range error occurs (a) if the magnitude
of l is too large, or (b) if x is too small.
Returns:
The bessell_K functions return Kl(x) as
denoted in [ISO:31, Item No. 11-14.4].
26.x.5 spherical Bessel functions (of the first kind)
double bessel_j( double l, double x ); float bessel_j( float l, float x ); long double bessel_j( long double l, long double x );
Effects:
These functions compute the spherical Bessel functions of the first
kind (as defined by [Abramowitz & Stegun,
§10.1.1, etc.) of their respective arguments l
and x. A domain error occurs if l is less than zero.
A range error (due to overflow) occurs if l equals zero and the
magnitude of x is too small. A range error (due to underflow)
occurs if x is too close to any of the roots of the
bessel_j function.
Returns:
The bessell_j functions return jl(x) as
denoted in [ISO:31, Item No. 11-14.5].
26.x.6 spherical Neumann functions; spherical Bessel functions (of the second kind)
double neumann_n( double l, double x ); float neumann_n( float l, float x ); long double neumann_n( long double l, long double x );
Effects:
These functions compute the spherical Neumann functions (as defined
by [Abramowitz & Stegun, §10.1.1,
etc.]), also known as the spherical Bessel functions of the second
kind, of their respective arguments x. A domain error occurs if
x is less than or equal to zero. A range error (due to overflow)
occurs (a) if the magnitude of l is too large, or (b) if the
magnitude of x is too small. A range error (due to underflow)
occurs if x is too close to any of the roots of the
neumann_n function.
Returns:
The neumann_n functions return nl(x) as
denoted in [ISO:31, Item No. 11-14.6].
26.x.7 Legendre polynomials
double legendre_Pl( unsigned l, double x ) float legendre_Pl( unsigned l, float x ) long double legendre_Pl( unsigned l, long double x )
Effects:
These functions compute the Legendre polynomials (as defined by [Abramowitz & Stegun, §8.1.1, etc.])
of their respective arguments l and x. A domain
error occurs if x is greater than one. A range error (due to
underflow) occurs if x is too close to any of the roots of the
legendre_Pl function.
Returns:
The legendre_Pl functions return Pl(x) as
denoted in [ISO:31, Item No. 11-14.8].
26.x.8 associated Legendre functions
double legendre_Plm( unsigned l, unsigned m, double x ) float legendre_Plm( unsigned l, unsigned m, float x ) long double legendre_Plm( unsigned l, unsigned m, long double x )
Effects:
These functions compute the associated Legendre functions (as defined
by [Abramowitz & Stegun, §8.1.1,
etc.]) of their respective arguments l, m,
and x. A domain error occurs (a) if m is greater than
l, or (b) if x is greater than one. A range error
(due to overflow) occurs if l is too large. A range error
(due to underflow) occurs if x is too close to any of the roots
of the legendre_Plm function.
Returns:
The legendre_Plm functions return
Plm(x) as denoted in [ISO:31, Item No. 11-14.9].
26.x.9 spherical harmonics
double sph_Y( unsigned l, int m, double theta, double phi ) float sph_Y( unsigned l, int m, float theta, float phi ) long double sph_Y( unsigned l, int m, long double theta, long double phi )
Effects:
These functions compute spherical harmonic functions (as defined by
[Abramowitz & Stegun, §8.1.1 footnote
2, etc.) of their respective arguments l, m,
theta, and phi. A domain error occurs if the magnitude
of m is greater than l. A range error (due to overflow)
occurs if l is too large. A range error (due to underflow)
occurs if either theta or phi is too close to any of
the roots of the sph_Y function.
Returns:
The sph_Y functions return
Ylm(φ,θ) as denoted in [ISO:31, Item No. 11-14.10].
26.x.10 Hermite polynomials
double hermite( unsigned n, double x ); float hermite( unsigned n, float x ); long double hermite( unsigned n, long double x );
Effects:
These functions compute the Hermite polynomials (as defined by [Abramowitz & Stegun, §13.6.17 and -.18,
etc.) of their respective arguments n and x.
A range error (due to overflow) occurs if the magnitude of x is
too large. A range error (due to underflow) occurs if x is
too close to any of the roots of the hermite function.
Returns:
The hermite functions return Hn(x) as denoted
in [ISO:31, Item No. 11-14.11].
26.x.11 Laguerre polynomials
double laguerre_0(unsigned n, double x); float laguerre_0(unsigned n, float x); long double laguerre_0(unsigned n, long double x);
Effects:
These functions compute the Laguerre polynomials (as defined by [Abramowitz & Stegun, §13.6.9, etc.])
of their respective arguments n and x. A range error
occurs (due to overflow) if the magnitude of x is too large. A
range error (due to underflow) occurs if x is too close to any
of the roots of the laguerre_0 function.
Returns:
The laguerre_0 functions return Ln(x) as
denoted in [ISO:31, Item No. 11-14.12].
26.x.12 associated Laguerre polynomials
double laguerre_m(unsigned n, unsigned m, double x); float laguerre_m(unsigned n, unsigned m, float x); long double laguerre_m(unsigned n, unsigned m, long double x);
Effects:
These functions compute the associated Laguerre polynomials (as defined
by [Abramowitz & Stegun, §13.6.9,
etc.]) of their respective arguments n, m,
and x. A domain error occurs if m is greater than
n. A range error (due to overflow) occurs if the magnitude
of x is too large. A range error (due to underflow) occurs
if x is too close to any of the roots of the laguerre_m
function.
Returns:
The laguerre_m functions return
Lnm(x) as denoted in [ISO:31, Item No. 11-14.13].
26.x.13 hypergeometric functions
double hyperg_2F1(double a, double b, double c, double x) ; float hyperg_2F1(float a, float b, float c, float x) ; long double hyperg_2F1(long double a, long double b, long double c, long double x) ;
Effects:
These functions compute the hypergeometric functions (as defined by [Abramowitz & Stegun, §15.1.1, etc.])
of their respective arguments a, b, c, and
x. A domain error occurs if the magnitude of x is
greater than or equal to one. A range error (due to overflow) occurs if
the magnitude of x is too close to one at the same time that
c-a-b is an integer. A range error (due to underflow) occurs
if x is too close to any of the roots of the hyperg_2F1
function.
Returns:
The hyperg_2F1 functions return F(a,b;c;x) as denoted in
[ISO:31, Item No. 11-14.14].
26.x.14 confluent hypergeometric functions
double hyperg_1F1(double a, double c, double x) ; float hyperg_1F1(float a, float c, float x) ; long double hyperg_1F1(long double a, long double c, long double x) ;
Effects:
These functions compute the confluent hypergeometric functions (as
defined by [Abramowitz & Stegun, §13.1.2,
etc.]) of their respective arguments a, c,
and x. A domain error occurs (a) if c is a negative
integer, or (b) if c is zero. A range error (due to overflow)
occurs if the magnitude of x is too large. A range error (due
to underflow) occurs if x is too close to any of the roots of
the hyperg_1F1 function.
Returns:
The hyperg_1F1 functions return F(a;c;x) as denoted in
[ISO:31, Item No. 11-14.15].
26.x.15.1 (incomplete) elliptic integral of the first kind
double ellint_F( double k, double phi ); float ellint_F( float k, float phi ); long double ellint_F( long double k, long double phi );
Effects:
These functions compute the incomplete elliptic integral of the first
kind (as defined by [Abramowitz & Stegun,
§17.2.6, etc.) of their respective arguments k and
phi. A domain error occurs (a) if k is less than or
equal to zero, or (b) if k is greater than or equal to one, or
(c) if phi is negative. A range error occurs if the magnitude
of k is too close to one.
Returns:
The ellint_F functions return F(k,φ) as denoted in
[ISO:31, Item No. 11-14.16].
26.x.15.2 (complete) elliptic integral of the first kind
double ellint_K( double k ); float ellint_K( float k); long double ellint_K( long double k);
Effects:
These functions compute the complete elliptic integral of the first
kind (as defined by [Abramowitz & Stegun,
§17.3.1, etc.]) of their respective arguments k.
A domain error occurs (a) if k is less than or equal to zero,
or (b) if k is greater than or equal to one. A range error
occurs if the magnitude of k is too close to one.
Returns:
The ellint_K functions return K(k) as denoted in [ISO:31, Item No. 11-14.16].
26.x.16.1 (incomplete) elliptic integral of the second kind
double ellint_E( double k, double phi ); float ellint_E( float k, float phi ); long double ellint_E( long double k, long double phi );
Effects:
These functions compute the incomplete elliptic integral of the second
kind (as defined by [Abramowitz & Stegun,
§17.2.9, etc.]) of their respective arguments k
and phi. A domain error occurs (a) if k is less than
or equal to zero, or (b) if k is greater than or equal to one,
or (c) if phi is negative. A range error occurs if the magnitude
of k is too close to one.
Returns:
The ellint_E functions return E(k,φ) as denoted in
[ISO:31, Item No. 11-14.17].
26.x.16.2 (complete) elliptic integral of the second kind
double ellint_E2( double k ); float ellint_E2( float k ); long double ellint_E2( long double k );
Effects:
These functions compute the complete elliptic integral of the second
kind (as defined by [Abramowitz & Stegun,
§17.2.9, etc.) of their respective arguments k
and phi. A domain error occurs (a) if k is less than
or equal to zero, or (b) if k is greater than or equal to one.
A range error occurs if the magnitude of k is too close to one.
Returns:
The ellint_E2 functions return E(k) as denoted in [ISO:31, Item No. 11-14.17].
26.x.17.1 (incomplete) elliptic integral of the third kind
double ellint_P( double k, double n, double phi ); float ellint_P( float k, float n, float phi ); long double ellint_P( long double k, long double n, long double phi );
Effects:
These functions compute the incomplete elliptic integral of the third
kind (as defined by [Abramowitz & Stegun,
§17.7.1, etc.) of their respective arguments k,
n, and phi. A domain error occurs (a) if k
is less than or equal to zero, or (b) if k is greater than or
equal to one, or (c) if phi is negative. A range error occurs
if the magnitude of k is too close to one.
Returns:
The ellint_P functions return Π(k,n,φ) as denoted
in [ISO:31, Item No. 11-14.18].
26.x.17.2 (complete) elliptic integral of the third kind
double ellint_P2( double k, double n ); float ellint_P2( float k, float n ); long double ellint_P2( long double k, long double n );
Effects:
These functions compute the complete elliptic integral of the third
kind (as defined by [Abramowitz & Stegun,
§17.7.2, etc.) of their respective arguments k,
n, and phi. A domain error occurs (a) if k
is less than or equal to zero, or (b) if k is greater than
or equal to one. A range error occurs if the magnitude of k
is too close to one.
Returns:
The ellint_P2 functions return Π(k,n,π/2) as
denoted in [ISO:31, Item No. 11-14.18].
26.x.19 beta function
double beta( double x, double y ); float beta( float x, float y ); long double beta( long double x, long double y );
Effects:
These functions compute the beta function (as defined by [Abramowitz & Stegun, §6.2 and §6.1])
of their respective arguments x and y. A domain error
occurs (a) if either x or y is a negative integer,
or (b) if either x or y is zero. A range error
occurs if the magnitude of x or the magnitude of y
is too large or too small.
Returns:
The beta functions return Β(x,y) as denoted in
[ISO:31, Item No. 11-14.20].
26.x.20 exponential integral
double ei( double x ); float ei( float x ); long double ei( long double x );
Effects:
These functions compute the exponential integral (as defined by [Abramowitz & Stegun, §5.1.1, etc.])
of their respective arguments x. A domain error occurs
if x is less than or equal to zero. A range error (due to
overflow) occurs (a) if x is to small, or (b) if x x
is too large. A range error (due to underflow) occurs if x is
too close to the single root of the ei function.
Returns:
The ei functions return Ei(x) as denoted in [ISO:31, Item No. 11-14.21].
26.x.22 Riemann zeta function
double zeta( double x ); float zeta( float x ); long double zeta( long double x );
Effects:
These functions compute the Riemann zeta function (as defined by [Abramowitz & Stegun, §23.2.1, etc.])
of their respective arguments x. A range error (due to overflow)
occurs if x is too close to one.
Returns:
The zeta functions return ζ(x) as denoted in [ISO:31, Item No. 11-14.23].
We noted in section II that there is a small potential overlap between this proposal (which is based on [ISO:31]) and an earlier proposal (which is based on [C99]). However, no competition is intended between the two proposals. Indeed, we have coordinated efforts to ensure that no incompatibilities result.
In particular, this section describes three functions (erf
,
erfc
, and tgamma
) originating in the C99
library and previously proposed for C++ standardization as part of
[Plauger]. They are mentioned in the present
proposal for two reasons, however: (1) these functions are traditionally
characterized as mathematical special functions, and (2) they form part of
[ISO:31], on which our proposal is based.
We emphasize that these functions are here described solely in the interest of completeness so that the full spectrum of envisioned mathematical special functions may be viewed together. For purposes of the C++ standardization effort, these functions should be considered part of the [Plauger] proposal. The language in the remainder of this section should therefore be considered solely for informative purposes.
|
erf erfc tgamma |
26.x.1 Synopsis
// (26.x.18) gamma function: double tgamma( double ); float tgamma( float ); long double tgamma( long double ); // (26.x.21.1) error function: double erf( double ); float erf( float ); long double erf( long double ); // (26.x.21.2) complementary error function: double erfc( double ); float erfc( float ); long double erfc( long double );
26.x.18 gamma function
double tgamma( double x ); float tgamma( float x ); long double tgamma( long double x );
Effects:
These functions compute the gamma function (as defined by [Abramowitz & Stegun, §6.1.1, etc.])
of their respective arguments x. A domain error occurs (a)
if x is a negative integer, or (b) if x is zero.
A range error occurs if the magnitude of x is too large or
too small.
Returns:
The tgamma functions return Γ(x) as denoted in
[ISO:31, Item No. 11-14.19].
Note:
This family of overloaded functions corresponds to the functions specified
in [C99, §<IP_ADDRESS>].
26.x.21.1 error function
double erf( double x ); float erf( float x ); long double erf( long double x );
Effects:
These functions compute the error function (as defined by [Abramowitz & Stegun, §7.1.1, etc.])
of their respective arguments x.
Returns:
The erf functions return erf(x) as denoted in [ISO:31, Item No. 11-14.22].
Note:
This family of overloaded functions corresponds to the functions specified
in [C99, §<IP_ADDRESS>].
26.x.21.2 complementary error function
double erfc( double x ); float erfc( float x ); long double erfc( long double x );
Effects:
These functions compute the complementary error function (as defined
by [Abramowitz & Stegun, §7.1.2,
etc.]) of their respective arguments x.
Returns:
The erf functions return erfc(x) as denoted in [ISO:31, Item No. 11-14.22].
Note:
This family of overloaded functions corresponds to the functions specified
in [C99, §<IP_ADDRESS>].
It is a pleasure to acknowledge the significant contributions provided by a number of colleagues at Fermilab: James Amundson, Mark Fischler, Jeffrey Kallenbach, Leo Michelotti, and Marc Paterno. Their active participation has materially improved this proposal, and their inspiration and support are deeply appreciated.
We extend special thanks to our Fermilab colleague John Marraffino for his extensive involvement with all aspects of this proposal's development.
We have also received valuable input and feedback from Matt Austern, Beman Dawes, Gabriel Dos Reis, and Fred J. Tydeman. We are grateful to them and to our outside reviewers for their careful consideration of earlier drafts of this document: Their thoughtful comments and suggestions inspired several refinements and enhancements to this proposal.
Finally, we appreciate the support of the Fermi National Accelerator Laboratory's Computing Division, sponsors of our participation in the C++ standards effort. Thank you, one and all.


{% extends "base.html" %} {% block title %}Logs{% endblock %} {% block nav %}{{ super() }}{% endblock %} {% block content %}
tail: Output to browser in real time. Similar to 'tail -f'
arm: Static output of just the ARM log entries
full: Static output of all of the log including MakeMKV and
HandBrake
download: Download the full log file


To reach our frightening lodgings, pay the ferry-master one gold coin. DO NOT look him directly in the eyes or your soul will be forfeit.


OpenSprites is still in development!
To see how far we are in development, why not take a peek at our GitHub Repository or the development thread?
You can view our progress so far at the OpenSprites Developer's Sandbox site.
If you have any questions, feel free to ask on our forums.


You may paste an image or HTML file to display it on all screens. There are currently
0
screens connected.
Clock
Screen
Reload


clickingbad_efficiency
MANUFACTURING
Item
Owned
Next Cost
Initial Cost
Heisenbelt
$41,032,501,000,000
Meth Star
$1,632,501,000,000
DISTRIBUTION
Meth Horizon
Space Mules


| User | Country | Usage | Payment Method | Activity | ||
|---|---|---|---|---|---|---|
|
|
Yiorgos Avraamu
New | Registered: Jan 1, 2015
|
50%
Jun 11, 2015 - Jul 10, 2015
|
Last login
10 sec ago
|
|
||
|
|
Avram Tarasios
Recurring | Registered: Jan 1, 2015
|
10%
Jun 11, 2015 - Jul 10, 2015
|
Last login
5 minutes ago
|
|
||
|
|
Quintin Ed
New | Registered: Jan 1, 2015
|
74%
Jun 11, 2015 - Jul 10, 2015
|
Last login
1 hour ago
|
|
||
|
|
Enéas Kwadwo
New | Registered: Jan 1, 2015
|
98%
Jun 11, 2015 - Jul 10, 2015
|
Last login
Last month
|
|
||
|
|
Agapetus Tadeáš
New | Registered: Jan 1, 2015
|
22%
Jun 11, 2015 - Jul 10, 2015
|
Last login
Last week
|
|
||
|
|
Friderik Dávid
New | Registered: Jan 1, 2015
|
43%
Jun 11, 2015 - Jul 10, 2015
|
Last login
Yesterday
|
|


A castling move.
Draws a checkerboard pattern for chess boards and converts touch input to ChessMoves.
The coordinate parser for used to parse chess SGF
.
Base class for the different types of moves for Chess.
A pass move.
SgfType.Stone type for Chess.
The possible types of ChessStones.
An en passant capture pawn move.
A move where a pawn reaches the last row and is then promoted to another piece.
(extensions in package onion.w4v3xrmknycexlsd.lib.sgfcharm_chess)
(extensions in package onion.w4v3xrmknycexlsd.lib.sgfcharm_chess)
A move of a ChessStone to a point, potentially capturing what was at the target point before.


TABLE OF INTERACTIONS WITH
LEDIPASVIR
See also: substances with absorption reduced by gastro-intestinal targeted medications, antacids, and absorbents
From the French ANSM drug interactions document of
September 2016, pp. 140-141
LEDIPASVIR RxNorm: 1591922 ATC: not found |
AMIODARONE RxNorm: 703 ATC: C01BD01 |
Only with the bitherapy ledipasvir/sofosbuvir, onset of bradycardia, possibly abruptly, which can have fatal consequences. |
Not recommended If administering these together cannot be avoided, strict monitoring of patients is recommended, in particular during the first weeks of treatment with the bitherapy (clinical monitoring and EKG). |
LEDIPASVIR RxNorm: 1591922 ATC: not found |
ANTICONVULSANT ENZYMATIC INDUCERS CLASS CODE: N03A-001 |
Large decrease of the plasma concentrations of the ledipasvir due to increase of its hepatic metabolism by the anticonvulsant enzymatic inducer. |
CONTRAINDICATION |
LEDIPASVIR RxNorm: 1591922 ATC: not found |
PROTON PUMP INHIBITORS CLASS CODE: A02BC-001 |
Decrease of the concentrations of the ledipasvir when the proton pump inhibitor is administered before the ledipasvir |
Precaution for use It is recommended that the proton pump inhibitor and the ledipasvir be administered simultaneously |
LEDIPASVIR RxNorm: 1591922 ATC: not found |
HMG-COA REDUCTASE INHIBITORS (STATINS) CLASS CODE: C10AA |
Risk of increase of the plasma concentrations of the statin and of its undesirable effects of the rhabdomyolysis type |
Contraindication --with the rosuvastatin Precaution for use --with the other HMG-CoA reductase inhibitors. Clinical and biological monitoring. Possible adjustment of the dosage of the statin |
LEDIPASVIR RxNorm: 1591922 ATC: not found |
ST JOHNS WORT Hypericum perforatum RxNorm: 258326 ATC: not found |
Risk of large decrease of the plasma concentrations of the ledipasvir due to increase of its hepatic metabolism by the St Johns wort |
CONTRAINDICATION |
LEDIPASVIR RxNorm: 1591922 ATC: not found |
RIFAMPICIN RxNorm: 9384 ATC: J04AB02 |
Large decrease of the plasma concentrations of the ledipasvir due to increase of its hepatic metabolism by the ripampicin |
CONTRAINDICATION |
LEDIPASVIR RxNorm: 1591922 ATC: not found |
TENOFOVIR DISOPROXIL RxNorm: 300195 ATC: J05AF07 |
When co-administered with a protease inhibitor, increase of the plasma concentrations of the tenofovir by the ledipasvir |
Precaution for use Clinical and biological monitoring, especially of the renal function |


| Modifier and Type | Method and Description |
|---|---|
Map<Language,Message> |
LocalizationManagement.getAvailableLanguages(String messageKey,
boolean resourceBundleFallback)
Return for a given message key the localized message for each of the currently available
languages
|
| Modifier and Type | Method and Description |
|---|---|
Collection<Language> |
CommunoteTool.getLanguages()
Delegates to
MasterDataManagement.getLanguages() |
Collection<Language> |
CommunoteTool.getUsedLanguages()
Delegates to
MasterDataManagement.getUsedLanguages() |
| Modifier and Type | Method and Description |
|---|---|
Language |
MasterDataManagementBase.findLanguageByCode(String languageCode) |
Language |
MasterDataManagement.findLanguageByCode(String languageCode)
Finds a language by the language code.
|
protected Language |
MasterDataManagementImpl.handleFindLanguageByCode(String languageCode)
Performs the core logic for
MasterDataManagementBase.findLanguageByCode(String) |
protected abstract Language |
MasterDataManagementBase.handleFindLanguageByCode(String languageCode)
Performs the core logic for
MasterDataManagementBase.findLanguageByCode(String) |
| Modifier and Type | Method and Description |
|---|---|
Collection<Language> |
MasterDataManagementImpl.getAvailableLanguages()
This method returns all available languages.
|
Collection<Language> |
MasterDataManagement.getAvailableLanguages()
This method returns all available languages.
|
List<Language> |
MasterDataManagementBase.getLanguages() |
List<Language> |
MasterDataManagement.getLanguages() |
Collection<Language> |
MasterDataManagementImpl.getUsedLanguages()
This method returns all available languages plus the language of the current user.
|
Collection<Language> |
MasterDataManagement.getUsedLanguages()
This method returns all available languages plus the language of the current user.
|
protected List<Language> |
MasterDataManagementImpl.handleGetLanguages()
Performs the core logic for
MasterDataManagementBase.getLanguages() |
protected abstract List<Language> |
MasterDataManagementBase.handleGetLanguages()
Performs the core logic for
MasterDataManagementBase.getLanguages() |
| Modifier and Type | Method and Description |
|---|---|
Language |
Message.getLanguage() |
| Modifier and Type | Method and Description |
|---|---|
static Message |
Message.Factory.newInstance(String messageKey,
String message,
boolean isHtml,
Language language)
Constructs a new instance of
Message , taking all
possible properties (except the identifier(s))as arguments. |
void |
Message.setLanguage(Language language) |
| Modifier and Type | Class and Description |
|---|---|
class |
LanguageImpl |
| Modifier and Type | Method and Description |
|---|---|
static Language |
Language.Factory.newInstance()
Constructs a new instance of
Language . |
static Language |
Language.Factory.newInstance(String languageCode,
String name,
String nameLocalized)
Constructs a new instance of
Language , taking all
possible properties (except the identifier(s))as arguments. |
| Modifier and Type | Method and Description |
|---|---|
Language |
LanguageDaoBase.create(Language language) |
Language |
LanguageDao.create(Language language)
Creates an instance of com.communote.server.persistence.user.Language and adds it to the
persistent store.
|
Language |
LanguageDaoBase.findByLanguageCode(String languageCode) |
Language |
LanguageDao.findByLanguageCode(String languageCode)
Finds a language by the given code
|
protected Language |
LanguageDaoImpl.handleFindByLanguageCode(String languageCode)
Performs the core logic for
LanguageDaoBase.findByLanguageCode(String) |
protected abstract Language |
LanguageDaoBase.handleFindByLanguageCode(String languageCode)
Performs the core logic for
LanguageDaoBase.findByLanguageCode(String) |
Language |
LanguageDaoBase.load(Long id) |
Language |
LanguageDao.load(Long id)
Loads an instance of com.communote.server.persistence.user.Language from the persistent
store.
|
| Modifier and Type | Method and Description |
|---|---|
Collection<Language> |
LanguageDaoBase.create(Collection<Language> entities) |
Collection<Language> |
LanguageDao.create(Collection<Language> entities)
Creates a new instance of com.communote.server.persistence.user.Language and adds from the
passed in
entities collection |
Collection<Language> |
LanguageDaoBase.create(int transform,
Collection<Language> entities) |
Collection<Language> |
LanguageDaoBase.loadAll() |
Collection<Language> |
LanguageDao.loadAll()
Loads all entities of type
Language . |
| Modifier and Type | Method and Description |
|---|---|
Object |
LanguageDaoBase.create(int transform,
Language language) |
Object |
LanguageDao.create(int transform,
Language language)
Does the same thing as
LanguageDao.create(com.communote.server.model.user.Language) with an
additional flag called transform . |
Language |
LanguageDaoBase.create(Language language) |
Language |
LanguageDao.create(Language language)
Creates an instance of com.communote.server.persistence.user.Language and adds it to the
persistent store.
|
void |
LanguageDaoBase.evict(Language entity)
Evicts (removes) the entity from the hibernate cache
|
void |
LanguageDao.evict(Language entity)
Evicts (removes) the entity from the hibernate cache
|
void |
LanguageDaoBase.remove(Language language) |
void |
LanguageDao.remove(Language language)
Removes the instance of com.communote.server.persistence.user.Language from the persistent
store.
|
protected Object |
LanguageDaoBase.transformEntity(int transform,
Language entity)
Allows transformation of entities into value objects (or something else for that matter),
when the
transform flag is set to one of the constants defined in
com.communote.server.persistence.user.LanguageDao , please note that the
LanguageDao.TRANSFORM_NONE constant denotes no transformation, so the entity itself will be
returned. |
void |
LanguageDaoBase.update(Language language) |
void |
LanguageDao.update(Language language)
Updates the
language instance in the persistent store. |
| Modifier and Type | Method and Description |
|---|---|
Collection<Language> |
LanguageDaoBase.create(Collection<Language> entities) |
Collection<Language> |
LanguageDao.create(Collection<Language> entities)
Creates a new instance of com.communote.server.persistence.user.Language and adds from the
passed in
entities collection |
Collection<Language> |
LanguageDaoBase.create(int transform,
Collection<Language> entities) |
Collection<?> |
LanguageDao.create(int transform,
Collection<Language> entities)
Does the same thing as
LanguageDao.create(com.communote.server.model.user.Language) with an
additional flag called transform . |
void |
LanguageDaoBase.remove(Collection<Language> entities) |
void |
LanguageDao.remove(Collection<Language> entities)
Removes all entities in the given
entities |
void |
LanguageDaoBase.update(Collection<Language> entities) |
void |
LanguageDao.update(Collection<Language> entities)
Updates all instances in the
entities collection in the persistent store. |
Copyright © 2019 Communote team. All rights reserved.


Flash and JavaScript are required for this feature.
Download the video from iTunes U or the Internet Archive.
Description: This lecture explores genetic algorithms at a conceptual level. We consider three approaches to how a population evolves towards desirable traits, ending with ranks of both fitness and diversity. We briefly discuss how this space is rich with solutions.
Instructor: Patrick H. Winston
Lecture 13: Learning: Genet...
Related Resources
More information about Evolved Virtual Creatures, which is shown at the end of the lecture.
PATRICK WINSTON: I have extremely bad news.
Halloween falls this year on a Sunday.
But we in 6.034 refuse to suffer the slings and arrows of outrageous fortune.
So we've decided that Halloween is today, as far 6.034 is concerned.
Kenny, could you give me a hand, please?
If you could take that and put it over there.
STUDENT: [INAUDIBLE]?
PATRICK WINSTON: Mm hm.
Just give it to them.
You can take as much of this as you like.
The rest will be given to that herd of stampeding freshman that comes in after.
It's a cornucopia of legal drugs.
Chocolate does produce a kind of mild high, and I recommend it before quizzes and giving lectures.
I have a friend of mine, one of the Nobel laureates in biology, always eats chocolate before he lectures.
Gives him a little edge.
Otherwise, he'll be flat.
So I recommend it.
It will take, I suppose, a little while to digest that neural net stuff.
A little richer than usual in mathematics.
So today, we're going to talk about another effort at mimicking biology.
This is easy stuff.
It's just conceptual.
And you won't see this on the next quiz.
But you will see it on the final.
It's one of those quiz five type problems, where I ask you questions to see if you were here and awake.
So a typical question might be, Professor Winston is a creationist, or something like that.
Not too hard to answer.
In any event, if it's been hard to develop a real understanding of intelligence, occasionally the hope is that by mimicking biology or mimicking evolution, you can circumnavigate all the problems.
And one of those kinds of efforts is ever to imitate evolution.
So we're going to talk today about so-called genetic algorithms, which are naive attempts to mimic naive evolution.

But I've found in talking with students that many times, they're a little fuzzy on some of the details.
So let's start off by reflecting a little bit about how that works.
So let's see, we need pink and blue.
And here's our cell, and here is its nucleus, and here are mommy and daddy's chromosomes.
We'll just pretend there's one pair.
Now ordinarily, in ordinary cell division, you get two cells.
Both have a nucleus, and the process of producing them involves the duplication of those chromosomes.
And then one pair ends up in each of the child cells, and that's all there is to that.
That's mitosis.
But then, when we talk about reproduction, it's more complicated because those chromosomes get all twisted up, and they break, and they recombine.
So when we talk about the cells that split off from one of these germ cells, it's no longer appropriate to talk about the pink one and the blue one, because the pink one and the blue one are all mixed up.
So you get two chromosomes here and two here.
But through some miracle of nature, which has always amazed me, these two cells split, in turn, into four cells altogether.
And each of those four cells at the bottom gets one of the chromosomes that was produced by the twisting up of the rope and recombination.
Then, along comes a special occasion.
And now we can think of this as being a blue one and this as being a pink one.
And they come together, and you get a new person, like so.
Note that your mother and father's chromosomes are never, never recombined.
It's your grandparents chromosomes that recombine.
So that's what it's like.
And the main thing to note about this is-- well, a couple things.
If you happen to be female, this part of the process-- this part over here-- took place before you were born.
If you happen to be male, it's going on right now as we speak, which probably explains something.
But in any event, it's going on right now.
But whenever it goes on, there are lots of opportunities for throwing dice.
So God threw all the dice before you were born, if you happen to be a female, in this part of the process over here.
Then, of course, more dice got thrown here when the decision was made about which particular cells got to fuse to form a new individual.
So I want to beat on this idea of lots of choice.
When we talk about genetic algorithms, and we talk about nature, there are lots of choices in there.
And that means there are lots of choices to intervene, to screw around, to make things work out the way you want.
But in any event, there we are.
That's the basic idea, and it all starts with chromosomes.
So we could think of implementing something that imitates that with the ACTG stuff that you learned all about in Seminar 1.
But we're computer scientists.
We don't like Base 4.
We like Base 2.
So I'm going to just suggest that our chromosomes are binary in this system that we're going to build.
So that might be a chromosome.
And it doesn't have to be binary.
It can be symbolic for fall I care.
But it's just some string of things that determine how the ultimate system behaves.
So it all starts out, then, with some of these chromosomes, some of these simulated chromosomes, simulated, simplified, and naive.
And there's a population of chromosomes.
The population of chromosomes-- it might be subject to a little bit of mutation.
That is to say, a zero becomes a one, or a one becomes a zero.
That happens a lot.
That mutation stuff happens over here when things get twisted up and recombined.
There are copying errors and stuff.
Cosmic rays hit it all the time.
All sorts of reasons why there might be a single point of change.
That produces the mutation effect.
So here, we have a population that starts off over here.
And some of those things are subject to mutation.

How many of these mutations do you allow per chromosome, for example?
How many of the chromosomes just slip through without any mutation?
Those are choices you can make.
Once you've made those choices, then we have the crossover phenomenon.
Let's identify one of these guys as the pink one and one of these guys as the blue one.
And so now we have the pink one cruised along as well as the blue one.
The pink one and the blue one cross and produce a new chromosome, just like in nature.
So we take the front part of one, back part of the other, and we fuse them together.
And some may slip by without any of that, like so.
Well, these things are meant to be combined in pairs, like so, but they may not have any crossover in them.
So you have another set of choices.
How many crossovers do you allow per recombination?
You get another set of choices.
So now we've got a population of modified chromosomes through mutation and crossover.
So the next thing to do is we have the genotype to phenotype transition.
That is to say the chromosome determines the individual.
It may be a person.
It may be a cow.
It may be a computer program.
I don't care what.
But that code down there has to be interpreted to be a something.
So it is the genotype, and it has to be interpreted to be something which is the phenotype, the thing that the stuff down there is encoding for.
So here, we have a bunch of individuals.
Now, each of those individuals, because they have varying chromosomal composition, will have a different fitness.
So these fitnesses might be-- well, who knows how they might be scored.
But we're computer scientists.
We might as well use numbers.
So maybe this guy's fitness is 88, and this guy's fitness is 77, and so on.
So now that we've got fitness-- by the way, notice all the choices involved there-- choice of how you interpret the genotype, choice about how the phenotype produces the fitness.
And now we have a choice about how the fitness produces a probability, like 0.8 and 0.1, or something like that-- probability of survival into the next generation.
So now, once we've got those probabilities, we actually have selection.
And those phenotypes out there produce genotypes, a new set of chromosomes, and that completes our loop that goes back in there.
And so that's the new generation.
Sounds simple.
So if you're going to make this work, of course, you have a million choices, as I'm going to emphasize over and over again.
And one of your choices is, for example, how do you compute the probability of survival to the next generation given the fitness?
So we have to go, somehow, from numbers like these to probabilities like those.
So I'm going to talk about several ways of doing it.
None of them are magic.
None of them was specified and stipulated by God as the right way.
But they have increasingly good properties with respect to this kind of processing.
So the simplest thing you can do-- idea number one for computing the-- see, what you do is you get this whole bag of individuals, and you have to decide who's going to survive to the next generation.
So at each step, everything in the bank has a probability of being the one you pick out and put in the next generation.
So at any step, the sum of the probabilities for each of those guys is 1, because that's how high probability works.
The probability of a complete set, added all up, is probability of 1.
So one thing you can do is you can say that the probability that you're going to draw individual i is equal to, or maybe is proportional to, the fitness of that individual.
I haven't completed the expression, so it's not a probability yet, because some piece of it won't add up to 1.
How can I ensure that it will add up to 1?
That's easy.
Right.
All I have to do is divide by the sum of the fitnesses over i.
So there's a probability measure that's produced from the fitnesses.
Yeah.
STUDENT: You need to make sure that the fitnesses aren't negative.
PATRICK WINSTON: Have to make sure the fitnesses are what?
STUDENT: Aren't negative.
PATRICK WINSTON: He says I have to make sure the fitnesses aren't negative.
Yeah, it would be embarrassing if they were.
So we'll just [? strike ?] anything like that as 0.
You've got a lot of choice how you can calculate the fitness.
And maybe you will produce negative numbers, in which case you have to think a little bit more about it.
So now, what about an example?
Well, I'm going to show you an example.
Why don't I show you the example.
What we're going to do is we're going to have a genetic algorithm that looks for an optimal value in a space.
And there's the space.

Let me show you how that space was produced.
The fitness is a function of x and y, and it's equal to the sine of some constant times x, quantity squared, times the sine of some constant y, quantity squared, e to the plus x plus y divided by some constant.
So sigma and omega there are just in there so that it kind of makes a nice picture for demonstration.
So there's a space.
And clearly, where you want to be in this space is in the upper right-hand corner.
That's the optimal value.
But we have a genetic algorithm that doesn't know anything.
All it knows how to do is mutate and cross over.
So it's going to start off with a population of 1.
It's a little red dot down in the lower left.
So here's how it's going to evolve.
There's going to be s chromosome consisting of two numbers, an x number and a y number, like, say, 0.3 and 0.7.
Here's another one, which might be 0.6 and 0.2.
So the mutation operator is going to take one of those values and change it a little bit.
So it might say, well, we'll take 3, and we'll make it 0.2.
And the crossover operation is going to exchange the x and y values of pairs.
So if we have a crossover here, then what we're going to get out from this one-- well, we're going to get out a combination of these two.
And it's going to look like this.
Because what we're going to do is we're going to take the x value of 1 and combine it with the y value of the other one.
So this is going to be 0.2-- my mutated value and 0.2-- and this is going to be 0.6 and 0.7.
So that's how my little genetic algorithm heck is going to work.
So having coded this up, we can now see how it flows.
Let's run it 10 generations.
So the population is rapidly expanded to some fixed limit.
I forgot what it is-- 30 or so.
And we can run that 100 generations.
And so this seems to be getting stuck, kind of, right?
So what's the problem?
The problem is local maxima.
This is fundamentally a hill-climbing mechanism.
Note that I have not included any crossover so far.
So if I do have crossover, then if I've got a good x value and a good y value, I can cross them over and get them both in the same situation.
But nevertheless, this thing doesn't seem to be working very well.
STUDENT: Professor, I have a question.
PATRICK WINSTON: Yeah.
STUDENT: That picture is just the contour lines of that function.
PATRICK WINSTON: The contour lines of that function.
So the reason you see a lot of contour lines in the upper right is because it gets much higher because there's that exponential term that increases as you go up to the right.
So I don't know, it looks-- let's put some crossover in and repeat the experience.
We'll run 100 generations.
I don't know.
It just doesn't seem to be going anywhere.
Sometimes, it'll go right to the global maximum.
Sometimes it takes a long time.
It's got a random number generator in there, so I have no control over it.
So it's going to get there.
I couldn't tell whether the crossover was doing any good or not.
Oh, well, here's one.
Let's make this a little bit more complicated.
Suppose that's the space.
Now it's going to be in real trouble, because it'll never get across that moat.
You know, you would think that it would climb up to the x maximum or to the y maximum, but it's not going to do very well.
Even with crossover, it's just not going to do very well, because it's climbing up those local hills.
Anybody got an idea about one simple thing we could do to make it work better?
Yeah, you could increase step size, right?
Let me you see if that will help.
You know, even that doesn't seem to help.
So we have to conclude-- do we conclude that this is a bad idea?
Well, we don't have to conclude it's a bad idea yet, because we may just look at it and ask why five times.
And we might ask, well, maybe we can get a better mechanism in there to translate fitness into probability of survival.
Using this formula is kind of strange, anyway, because suppose temperature is one of your fitness characteristics.
The hotter, the better.
Then the ratio of the probability that you'll survive versus the person next to you, that ratio will depend on whether you're measuring the temperature in Celsius or Fahrenheit, right?
Because you've shifted the origin that shifts the ratio that shifts the probability of success.
So it seems kind of strange to just take these things right straight into probabilities.
So a better idea-- idea number two-- is to say, well, shoot, maybe we don't care about what the actual fitnesses are.
All we really care about is the rank order of all the candidates.
So the candidate with the most fitness will have the most probability of getting into the next generation.
The candidate with the second-most fitness will have the second-highest probability, and so on.
But we're not going to use the actual fitnesses themselves to make the determination.
Instead, what we're going to do with this mechanism number two-- this is the rank space method-- is this.
We're going to say that the probability of the highest-ranking individual of getting into the next generation is some constant P sub c, which, of course, you can select.
You have another choice.
Then, if that guy doesn't get selected, the probability of the second-highest-ranking individual getting in the next generation is going to be the probability that that guy didn't get in there.
That's 1 minus P sub c times the same probability constant.
And so you can see how this is going.

And then there's only one individual left.
And then if you got through all these guys and haven't got anybody selected, then you've got to select the last guy.
And so the probability you're going to select the last guy is going to be 1 minus P sub c to the n minus 1.
So it's a probability you've missed all those guys in the first n minus 1 choices.
Yeah, it is, honest to God.
See, this is the probability that this last guys is going to get selected.
It's not the probability that it's the last guy getting selected, given that the others haven't been select.
Trust me, it's right.
Are you thinking it ought to be 1?
STUDENT: What?
PATRICK WINSTON: Were you thinking it ought to be 1?
STUDENT: No, I was thinking that I was wondering why you were re-rolling the dice, so to speak.
PATRICK WINSTON: You are re-rolling the dice.
You've got a probability each time, except for the last time, when, of course, you have to take it.
There's nothing left.
There's no other choice.
STUDENT: I have a question.
PATRICK WINSTON: Yeah, [INAUDIBLE].
STUDENT: So when you jump from [INAUDIBLE], that makes sense.
[INAUDIBLE] you're saying [INAUDIBLE].
PATRICK WINSTON: It's the probability [INAUDIBLE] the first two choices.
STUDENT: Yeah, but the second choice had probability one minus P sub c times P sub c, not-- PATRICK WINSTON: Think about it this way.
It's the probability you didn't choose the first two.
So the probability you didn't choose the first one is one minus P sub c.
The probability you didn't choose the next one, as well, because you're choosing that next one with probability P sub c, it's the square of it.
So that might work better.
Let's give it a shot.
Let's go back to our original space choice, and we set and switch to the rank fitness method.
And we'll run out 100 generations.
Whoa!
What happened there?
That was pretty fast.
Maybe I used a big step size.
Yeah, that's a little bit more reasonable.
Oops-- what happened?
It's really getting stuck on a local maximum.
So evidently, I've choosed a constant P sub c such that it just drove it right up the nearest hill.
On the other hand, if I change the step size a little bit, maybe I can get it to spread out.
I sure did.
And now that it's managed to evolve over there to find the maximum value, now I can clamp down on the step size again.
And now it shows no more diversity.
It's just locked on to that global maximum.
So this is not unlike what evolution sometimes does.
Sometimes, species collapse into a state where they don't change for 500 million or 600 million years, like sharks, for example.
Sometimes, they only survive if they've got a lot of diversity built into their way of life so that they can adjust to habitat changes.

You make everything kind of vibrate more, make bigger steps.
So this kind of process, where you may start with a big step size and then gradually reduce the step size, is called simulated annealing, because it's like letting a metal cool down.

And then you slowly reduce the step size, so you actually crawl up to the local maxima that are available.
So that seemed to work pretty well.
Let's see if we can get it to work on the harder problem of the moat.
So it's not doing very well.
Better increase the step size.
No, it's still kind of stuck.
Even though it's got the capacity to cross over, it's so stuck on that lower right-hand corner, it can't get up that vertical branch to get to a point where a crossover will produce a value up there in the upper right-hand corner.
So we're still not home yet.
So what's the trouble?
The trouble is that the fitness mechanism is just driving things up to the local maximum.
It's just terribly unfortunate.
What to do?
Well, here's something you could do.
You can say, well, if the problem is we've lost the diversity in our population, then we can measure the diversity-- not only the fitness of the set of individuals we're selecting from, but we can measure how different they are on the individuals we've already selected for the next population.
In other words, we can get a diverse population as well as a fit population if, when we make our selection, we consider not only their fitness but how different they are from the individuals that have already been selected.
So that's going to be mechanism number three.
So now we have a space, and we can measure fitness along one axis-- ordinary fitness-- and this is rank space fitness, so that's going to be P sub c.
There will always be some individual with the highest fitness.
And over here-- that might not be P sub c, actually.
But there'll be some individual with a maximal fitness, and at any given step in the selection of the next population, there'll be some individual that's maximally diverse from all of the individuals that have been selected for the next generation so far.
So what kind of individual would you like to pick for the next generation?
Well, the one with the highest fitness rank and the one with the highest diversity rank.
So what you'd really like is you'd like to have somebody right there.
And if you can't have somebody right there, if there's nobody right there with a maximum fitness, a maximum diversity at the same time, then maybe you can draw in iso-goodness lines, like so, which are just how far you are from that ideal.
So let's summarize.
You've got to pick some individuals for the next population.
When we pick the first individual, all we've got to go on is how fit the individual is, because there's nobody else in that next generation.
After the first individual is selected, then we can look at our set of candidates, and we can say which candidate would be more different from the set of things we've already selected than all the others.
That would get the highest diversity rank and so on down the candidate list.
So let's see how that might work.
So we're going to use a combination of fitness rank and diversity rank.
And we'll just use the simple one so far.
We'll use a small step size, and we'll let this run 100 generations to see what happens.
Bingo.
It crawls right up there, because it's trying to keep itself spread out.
It uses that diversity measurement to do that.
And at the same time, it's seeking high fitness, so that's why it's crawling up to the upper right-hand corner.
But in the end, that diversity piece of it is keeping the things spread out.

You don't care about diversity anymore, And we could just turn that off.
Is that thing still running?
Go back to fitness rank-- bingo.
So there you are-- you're stuck for 600 million years.
So let's see if this will handle the moat problem.
See, our step size is still small.
We'll just let this run.
So the diversity of P sub is keeping it spread out, pretty soon, bingo, it's right in there.
It's across that big moat, because it's got the crossover mechanism that combines the best of the x's and the best of the y's.
So that seems to work pretty well.
OK, so see, these are some of the things that you can think about when you're thinking-- oh, and of course, we're a shark, we're going to forget about diversity.
We'll change the selection method from fitness and diversity rank to just diversity.
It collapses down on to the highest hill.
Yeah, [INAUDIBLE], what?
STUDENT: How does step size translate into mutations?
PATRICK WINSTON: Oh, just the-- question is, how does step size translate into mutation?
Instead of allowing myself to take steps as big as 1/10, I might allow myself to take steps as big as 3/10, according to some distribution.
So what to say about all this?
It's very seductive, because it's nature, right?
The trouble is, it's naive nature.
And as evolutionary theories go, this is horrible.
This is naive.
So we'd like to use real evolutionary theory, except we don't have real evolutionary theory.
Evolution is still a mystery.
Some things are pretty obvious.
You can breed fast race horses.
That works just like so.
The trouble is, we don't have any real good idea about how speciation takes place and how a lot of evolution works, because all these chromosomes are connected to their phenotype consequences in very complicated ways that nobody fully understands.
So there's a great deal of magic in that genotype to phenotype transition that nobody really understands very well.
So when people write these programs that are in the style of so-called genetic algorithm, they're taking a photograph of high school biology, and they're spending a long time building programs based on that naive idea.
But that naive idea has lots of places for intervention, because look at all the things you can screw around with in that process of going from one generation to the next.
By the way, what does mutation do?
It's basically hill climbing, right?
It's producing a little spread out, and you're using the fitness thing to climb the hill.
So you get a lot of choices about how you handle that.
Then you get a lot of choices about much crossover you're doing.
What does crossover do?
It kind of combines strong features of multiple individuals into one individual, maybe.
So you've got all kinds of choices there.
And then your genotype to phenotype translation-- how do you interpret something like those zeroes and ones as an if-then rule, for example, as something that's in the hands of the designer?
Then you've got all the rest of those things, all which are left up to the designer.
So in the end, you really have to ask-- when you see an impressive demonstration, you have to say, where does the credit lie?
And I mean that pun intentionally, because usually the people who are claiming the credit are lying about where it's coming from.
But nevertheless, let me give you a couple of examples of where this has found actual, bona fide practical application.
So when you look for practical application, you might say, well, in what kind of problem does a good front piece combine with a good back piece to produce a good thing overall?
And the answer is, when you're making a plan.
So you might have a problem in planning that requires you to take a series of steps.
And you might have two plans, each of which is a series of steps.
And you might combine these to produce something new that's the front half of one and the back half of another.
So that's practical application number one.
And that requires you to interpret your chromosome as an indicator of the steps in the plan.
Another example is drawn from a [? UROP ?] project a student did for me some years ago.
He was a freshman.
He came to me and said, I want to do a [? UROP ?] project.
And I said, have you taken 6.034?
And he said no.
And I said, go away.
And he said, I don't want to go away.
I want to do a [? UROP ?] project.
So I said, have you read my book?
He said no.
I said, well, go away, then.
And he said, I don't want to go away.
I want to do a UROP project.
So I said, I don't have any [? UROP ?] projects.
He said, that's OK.
I've got my own.
He's a finance-type guy, so he was interested in whether he could build a rule-based expert system that could predict the winners at horse races.
So his rule-based expert system consisted of rules like this.
If x and y, then some conclusion.
If l and m, then some kind of conclusion.
And from these, he would produce rules like if x prime-- that's a slightly mutated version of the x antecedent-- and m, then some conclusion.
So it's mutation and crossover.
And he was able to produce a system that seemed to work about as well as the handicappers in the newspaper.
So he started losing money at a less fast rate.
He is now doing something in the stock market, they say.
Doesn't talk so much about it, though.
But an interesting application.
He came up with rules like, if the sum of the jockey's weight on the post position is low, that's good.
Well, that makes sense in the end, because the jockey's weight is always between 100 and 110 pounds, and the post position is always between 1 and 10 or something, so they were commensurate values.
And a low one is good, in fact.
Not bad.
But neither of those-- I mean, this is real stuff.
My company uses this sort of stuff to do some planning work.
But neither of those is as impressive as the demonstration I'm about to show you that involves the evolution of creatures.
And these creatures consist of block-like objects, like so.
And they combine like this, and so on.
And so how can you make a feature like that from a [? 0-1 ?] chromosome?
Well, some of the bits in the chromosome are interpreted as the number of objects.
Others are interpreted as the sizes of the objects.
Others are interpreted as the structure of how the objects are articulated.
And still others are interpreted as fixing the control algorithm by which the creature operates.
So you see how that roughly goes?
Would you like to see a film of that in action?
Yes.
OK.
[INAUDIBLE] always likes to see the films.
STUDENT: How would you measure diversity in that graph?
PATRICK WINSTON: The question is, how do I measure the diversity of the graph?
I did it the same way I measured the fitness.
That is to say, I calculated the distance-- the actual metric distance-- of all the candidates for the next generation from all of the candidates that had already been selected.
I summed that up.
And from that sum, I could rank them according to how different they were from the individuals that were already in the next generation.
It's like giving a rank, and then from the rank, I use that kind of calculation to determine a fitness, ie, a probability of survival, and then I just combine the two kinds of probabilities.
STUDENT: So you always kept-- every time that you started something, [? you cached ?] those.

PATRICK WINSTON: I'm always using the individuals that have already been selected at every step, so every step is a little different because it's working with a new set of individuals that have already been selected for the next generation.
OK?
So let's see how this works.
So this is showing the evolution of some swimming creatures.
And they're evolved according to how well they can swim, how fast they can go.
Some of them have quite exotic mechanisms, and some of them quite natural.
That looked like a sperm cell floating away there.
Once you have these things evolving, then of course, you can get groups of them to evolve together.
So you saw already some that were evolving to swim.
These are evolving to move around on the land.
It's interesting-- this was done by Karl Sims, who at the time was at a then-thriving company, Thinking Machines, a fresh spinoff from MIT.
So he was using a vastly parallel computer, super powerful for its day, thousands of processors, to do this.
And it was a demonstration of what you could do with lots of computing.
In the early stages of the experimentation, though, its notion of physics wasn't quite complete, so some of the creatures evolved to move by hitting themselves in the chest and not knowing about the conservation of momentum.
I thought that was just great.
So here they are, out doing some further-- So you look at these, and you say, wow, there must be something to this.
This is interesting.
These are complicated.
I think this is one of the ones that was trained, initially, to swim and then to do land locomotion.
So eventually, Karl got around to thinking about how to make these things evolve so that they would compete for food.
That's the fastest, I think, by the way, of the land locomotors.
So that was training them to-- evolving them to jump.
This is evolving them to follow a little red dot.
Some of them have stumbled upon quite exotic methods, as you can see.
Seem to be flailing around, but somehow manage to-- sort of like watching people take a quiz.
Making progress on it.
But now we're on to the food competition.
So some of them go for the food, and some of them go to excluding their opponent from the food, not actually caring too much about whether they get it.
That's sort of what children do.
There's a kind of hockey player-- now, here's two hockey players.
Watch this.
They're kind of-- one succeeds-- it reminds me a little bit of hockey, rugby, something like that.
Sometimes, they just get kind of confused, go right after their opponent, forgetting about the food.
Gives up.
I think these are the overall winners in this elimination contest.
I can't quite get there.
OK, so you look at that, and you say, wow, that's cool.
Genetic algorithms must be the way to go.
I remember the first time I saw this film.
It was over in Kresge.
I was walking out of the auditorium with Toma Poggio And we looked at each other, and we said the same thing simultaneously.
We didn't say that genetic algorithms were the way to go.
What we said was, wow, that space is rich in solutions.
What we were amazed by was not that simple-minded genetic algorithms produced solutions but that the space was so rich with solutions that almost any mechanism that was looking around in that space would find them.
But there's yet another way of thinking about it, and that is you could say, wow, look at how smart Karl Sims is, because Karl Sims is the one who had his hands on all the levers, all those choices.
And I kept emphasizing, all those choices that enabled him to trick this thing, in some sense, into stumbling across the solutions in a space that was guaranteed to be rich with solutions.
So you have to ask-- so first of all, diversity is good.
We noticed when we put diversity into the genetic algorithm calculations, we were much better at finding solutions.
But the next gold star idea that I'd really like to have you go away with is the idea that you have to ask where the credit lies.
Does it lie with the ingenuity of the programmer or with the value of the algorithm itself?
In this case, impressive as it is, the credit lies in the richness of the space and in the intelligence of the programmer, not necessarily in the idea of genetic algorithms.


Module m.logger
Simple Lua logger
Functions
| level (level) | Set the current accepted log level. |
| create (tag) | Create a logger instance |
| instance.debug (...) | Log with level set to DEBUG |
| instance.info (...) | Log with level set to INFO |
| instance.warn (...) | Log with level set to WARN |
| instance.error (...) | Log with level set to ERROR |
| instance.fatal (...) | Log with level set to FATAL |
| instance.d (...) | Log with level set to DEBUG |
| instance.i (...) | Log with level set to INFO |
| instance.w (...) | Log with level set to WARN |
| instance.e (...) | Log with level set to ERROR |
| instance.f (...) | Log with level set to FATAL |
Functions
- level (level)
-
Set the current accepted log level. Any logger calls with a level less than
this will be silenced
Parameters:
- level The minimum accepted level
- create (tag)
-
Create a logger instance
Parameters:
- tag Optional tag to preprend to all log output
Returns:
-
Logger instance§
- instance.debug (...)
-
Log with level set to DEBUG
Parameters:
- ...
- instance.info (...)
-
Log with level set to INFO
Parameters:
- ...
- instance.warn (...)
-
Log with level set to WARN
Parameters:
- ...
- instance.error (...)
-
Log with level set to ERROR
Parameters:
- ...
- instance.fatal (...)
-
Log with level set to FATAL
Parameters:
- ...
- instance.d (...)
-
Log with level set to DEBUG
Parameters:
- ...
- instance.i (...)
-
Log with level set to INFO
Parameters:
- ...
- instance.w (...)
-
Log with level set to WARN
Parameters:
- ...
- instance.e (...)
-
Log with level set to ERROR
Parameters:
- ...
- instance.f (...)
-
Log with level set to FATAL
Parameters:
- ...


Are there web sites that have a design you really admire? Do you wish you could create attractive and effective designs? Are you "design-challenged" and need to know the basics of creating good-looking web sites, mobile apps or other digital media?
You may never be a world famous designer, but you can design attractive, effective and high-quality digital media by understanding the foundations of design.  If you're approaching design for the first time and need to be able to apply your new design skills quickly, you need to take this course.
In this exciting series of lectures and activities, expert designer Joesph Caserto will start with the foundations including line, shape, space, color and texture and apply the design foundations to every day digital work. You'll learn to create beautiful typography, learn to understand your audience , create effective layouts and examine motion, sound and interactivity.
With over 30 fascinating video lectures, multiple lab exercises, and fascinating insight from your instructor, you'll be creating designs that everyone will be talking about.
You've learned a little Javascript, but you still look at websites with slick, smooth and elegant user interfaces and want to know how web developers create that. The answer is simple: Ajax. You've probably heard of it, but you've always wondered "What is Ajax"? Ajax is simply Asynchronous Javascript and XML. By taking our Ajax course, you can make pages on your web application respond quickly, and with a minimum of screen refreshes.
With our Ajax course and a little Javascript knowledge you can use Ajax to take database information and store, alter, sort and conditionally format it all on the client side. This minimizes the load on your server and makes your applications respond quickly and without reloading the HTML page. Ajax communicates with the server behind the scenes while your user continues to use your web site, accessing the information they want. Our course will show you numerous Ajax examples and help you become proficient in using Ajax.
In our Ajax course, master trainer Mark Lassoff takes you through the basics of Ajax right to advanced topics like parsing JSON responses from web services. Our Ajax course is recommended for all web developers who want to improve their client side skills, and make professional, fast and responsive web applications.
Anyone who has worked in web development for more than five minutes can tell you: the difference between an outstanding site and a terrible site is the quality of the CSS. With our CSS Tutorial for Beginners course, you can learn to make high-quality, graphically amazing and thoroughly impressive web sites.
All it takes is a little creativity and a strong understanding of CSS design and code and your website will look exactly the way you want it to.
LearnToProgram's Zachary Kingston brings you this dynamic and comprehensive CSS course. This CSS Tutorial for Beginners is perfect for both beginners who don't understand how to use CSS and experts who don't understand why they cannot get their website to look exactly the way they want it to.
Watch over 4 hours of engaging video lectures, sharpen your skills with fun and creative lab exercises, and study the dozens of style sheet examples provided.