| Topology |
CPU: Intel(R) Core(TM) i5-8600K CPU @ 3.60GHz, CPU family: x86_64, GPU: Intel(R) UHD Graphics 630, RAM size: 32789696 kB, OS family: Linux, OS version: Linux-4.15.0-47-generic-x86_64-with-Ubuntu-16.04-xenial, Python version: 3.5.2 |
CPU: Intel(R) Core(TM) i3-7100 CPU @ 3.90GHz, CPU family: Intel64 Family 6 Model 158 Stepping 9, GenuineIntel, GPU: Intel(R) HD Graphics 630, RAM size: 8256420 KB, OS family: Windows, OS version: Windows-10-10.0.17134-SP0, Python version: 3.6.0 |
CPU: Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz, CPU family: Intel64 Family 6 Model 158 Stepping 9, GenuineIntel, GPU: Intel(R) HD Graphics 630, RAM size: 16641852 KB, OS family: Windows, OS version: Windows-10-10.0.17763-SP0, Python version: 3.6.5 |
CPU: Intel(R) Core(TM) i5-8300H CPU @ 2.30GHz, CPU family: Intel64 Family 6 Model 158 Stepping 10, GenuineIntel, GPU: Intel(R) UHD Graphics 630, RAM size: 8245928 KB, OS family: Windows, OS version: Windows-10-10.0.17763-SP0, Python version: 3.6.5 |
|
|
FP32;ImageNET;1; Sync;Plugin: CPU Iteration count: 1000 Thread count: 1 |
FP32;ImageNET;1; Sync;Plugin: CPU Iteration count: 1000 Thread count: 2 |
FP32;ImageNET;1; Sync;Plugin: CPU Iteration count: 1000 Thread count: 4 |
FP32;ImageNET;1; Sync;Plugin: CPU Iteration count: 1000 Thread count: 6 |
FP32;ImageNET;2; Sync;Plugin: CPU Iteration count: 1000 Thread count: 1 |
FP32;ImageNET;2; Sync;Plugin: CPU Iteration count: 1000 Thread count: 2 |
FP32;ImageNET;2; Sync;Plugin: CPU Iteration count: 1000 Thread count: 4 |
FP32;ImageNET;2; Sync;Plugin: CPU Iteration count: 1000 Thread count: 6 |
FP32;ImageNET;4; Sync;Plugin: CPU Iteration count: 1000 Thread count: 1 |
FP32;ImageNET;4; Sync;Plugin: CPU Iteration count: 1000 Thread count: 2 |
FP32;ImageNET;4; Sync;Plugin: CPU Iteration count: 1000 Thread count: 4 |
FP32;ImageNET;4; Sync;Plugin: CPU Iteration count: 1000 Thread count: 6 |
FP32;ImageNET;8; Sync;Plugin: CPU Iteration count: 1000 Thread count: 1 |
FP32;ImageNET;8; Sync;Plugin: CPU Iteration count: 1000 Thread count: 2 |
FP32;ImageNET;8; Sync;Plugin: CPU Iteration count: 1000 Thread count: 4 |
FP32;ImageNET;8; Sync;Plugin: CPU Iteration count: 1000 Thread count: 6 |
FP32;ImageNET;1; Async;Plugin: CPU Async request count: 1 Iteration count: 1000 Stream count: 1 |
FP32;ImageNET;1; Async;Plugin: CPU Async request count: 2 Iteration count: 1000 Stream count: 2 |
FP32;ImageNET;1; Async;Plugin: CPU Async request count: 4 Iteration count: 1000 Stream count: 4 |
FP32;ImageNET;1; Async;Plugin: CPU Async request count: 6 Iteration count: 1000 Stream count: 6 |
FP32;ImageNET;2; Async;Plugin: CPU Async request count: 1 Iteration count: 1000 Stream count: 1 |
FP32;ImageNET;2; Async;Plugin: CPU Async request count: 2 Iteration count: 1000 Stream count: 2 |
FP32;ImageNET;2; Async;Plugin: CPU Async request count: 4 Iteration count: 1000 Stream count: 4 |
FP32;ImageNET;2; Async;Plugin: CPU Async request count: 6 Iteration count: 1000 Stream count: 6 |
FP32;ImageNET;4; Async;Plugin: CPU Async request count: 1 Iteration count: 1000 Stream count: 1 |
FP32;ImageNET;4; Async;Plugin: CPU Async request count: 2 Iteration count: 1000 Stream count: 2 |
FP32;ImageNET;4; Async;Plugin: CPU Async request count: 4 Iteration count: 1000 Stream count: 4 |
FP32;ImageNET;4; Async;Plugin: CPU Async request count: 6 Iteration count: 1000 Stream count: 6 |
FP32;ImageNET;8; Async;Plugin: CPU Async request count: 1 Iteration count: 1000 Stream count: 1 |
FP32;ImageNET;8; Async;Plugin: CPU Async request count: 2 Iteration count: 1000 Stream count: 2 |
FP32;ImageNET;8; Async;Plugin: CPU Async request count: 4 Iteration count: 1000 Stream count: 4 |
FP32;ImageNET;8; Async;Plugin: CPU Async request count: 6 Iteration count: 1000 Stream count: 6 |
FP32;ImageNET;1; Sync;Plugin: GPU Iteration count: 1000 |
FP32;ImageNET;2; Sync;Plugin: GPU Iteration count: 1000 |
FP32;ImageNET;4; Sync;Plugin: GPU Iteration count: 1000 |
FP32;ImageNET;8; Sync;Plugin: GPU Iteration count: 1000 |
FP16;ImageNET;1; Sync;Plugin: GPU Iteration count: 1000 |
FP16;ImageNET;2; Sync;Plugin: GPU Iteration count: 1000 |
FP16;ImageNET;4; Sync;Plugin: GPU Iteration count: 1000 |
FP16;ImageNET;8; Sync;Plugin: GPU Iteration count: 1000 |
FP16;ImageNET;1; Sync;Plugin: MYRIAD Iteration count: 1000 |
FP16;ImageNET;2; Sync;Plugin: MYRIAD Iteration count: 1000 |
FP16;ImageNET;4; Sync;Plugin: MYRIAD Iteration count: 1000 |
FP16;ImageNET;8; Sync;Plugin: MYRIAD Iteration count: 1000 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Average time of single pass |
FPS |
|
| Average time of single pass |
FPS |
|
| Average time of single pass |
FPS |
|
| Average time of single pass |
FPS |
|
| Average time of single pass |
FPS |
|
| Average time of single pass |
FPS |
|
| Average time of single pass |
FPS |
|
| Average time of single pass |
FPS |
|
| Average time of single pass |
FPS |
|
| Average time of single pass |
FPS |
|
| Average time of single pass |
FPS |
|
| Average time of single pass |
FPS |
|
| Average time of single pass |
FPS |
|
| Average time of single pass |
FPS |
|
| Average time of single pass |
FPS |
|
| Average time of single pass |
FPS |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FP32;ImageNET;1; Sync;Plugin: CPU Iteration count: 1000 Thread count: 1 |
FP32;ImageNET;1; Sync;Plugin: CPU Iteration count: 1000 Thread count: 2 |
FP32;ImageNET;1; Sync;Plugin: CPU Iteration count: 1000 Thread count: 4 |
FP32;ImageNET;2; Sync;Plugin: CPU Iteration count: 1000 Thread count: 1 |
FP32;ImageNET;2; Sync;Plugin: CPU Iteration count: 1000 Thread count: 2 |
FP32;ImageNET;2; Sync;Plugin: CPU Iteration count: 1000 Thread count: 4 |
FP32;ImageNET;4; Sync;Plugin: CPU Iteration count: 1000 Thread count: 1 |
FP32;ImageNET;4; Sync;Plugin: CPU Iteration count: 1000 Thread count: 2 |
FP32;ImageNET;4; Sync;Plugin: CPU Iteration count: 1000 Thread count: 4 |
FP32;ImageNET;8; Sync;Plugin: CPU Iteration count: 1000 Thread count: 1 |
FP32;ImageNET;8; Sync;Plugin: CPU Iteration count: 1000 Thread count: 2 |
FP32;ImageNET;8; Sync;Plugin: CPU Iteration count: 1000 Thread count: 4 |
FP32;ImageNET;1; Async;Plugin: CPU Async request count: 1 Iteration count: 1000 Stream count: 1 |
FP32;ImageNET;1; Async;Plugin: CPU Async request count: 2 Iteration count: 1000 Stream count: 2 |
FP32;ImageNET;2; Async;Plugin: CPU Async request count: 1 Iteration count: 1000 Stream count: 1 |
FP32;ImageNET;2; Async;Plugin: CPU Async request count: 2 Iteration count: 1000 Stream count: 2 |
FP32;ImageNET;4; Async;Plugin: CPU Async request count: 1 Iteration count: 1000 Stream count: 1 |
FP32;ImageNET;4; Async;Plugin: CPU Async request count: 2 Iteration count: 1000 Stream count: 2 |
FP32;ImageNET;8; Async;Plugin: CPU Async request count: 1 Iteration count: 1000 Stream count: 1 |
FP32;ImageNET;8; Async;Plugin: CPU Async request count: 2 Iteration count: 1000 Stream count: 2 |
FP32;ImageNET;1; Sync;Plugin: GPU Iteration count: 1000 |
FP32;ImageNET;2; Sync;Plugin: GPU Iteration count: 1000 |
FP32;ImageNET;4; Sync;Plugin: GPU Iteration count: 1000 |
FP32;ImageNET;8; Sync;Plugin: GPU Iteration count: 1000 |
FP16;ImageNET;1; Sync;Plugin: GPU Iteration count: 1000 |
FP16;ImageNET;2; Sync;Plugin: GPU Iteration count: 1000 |
FP16;ImageNET;4; Sync;Plugin: GPU Iteration count: 1000 |
FP16;ImageNET;8; Sync;Plugin: GPU Iteration count: 1000 |
|
|
|
|
|
|
|
|
|
|
|
|
|
| Average time of single pass |
FPS |
|
| Average time of single pass |
FPS |
|
| Average time of single pass |
FPS |
|
| Average time of single pass |
FPS |
|
| Average time of single pass |
FPS |
|
| Average time of single pass |
FPS |
|
| Average time of single pass |
FPS |
|
| Average time of single pass |
FPS |
|
|
|
|
|
|
|
|
|
|
FP32;ImageNET;1; Sync;Plugin: CPU Iteration count: 1000 Thread count: 1 |
FP32;ImageNET;1; Sync;Plugin: CPU Iteration count: 1000 Thread count: 2 |
FP32;ImageNET;1; Sync;Plugin: CPU Iteration count: 1000 Thread count: 4 |
FP32;ImageNET;1; Sync;Plugin: CPU Iteration count: 1000 Thread count: 8 |
FP32;ImageNET;2; Sync;Plugin: CPU Iteration count: 1000 Thread count: 1 |
FP32;ImageNET;2; Sync;Plugin: CPU Iteration count: 1000 Thread count: 2 |
FP32;ImageNET;2; Sync;Plugin: CPU Iteration count: 1000 Thread count: 4 |
FP32;ImageNET;2; Sync;Plugin: CPU Iteration count: 1000 Thread count: 8 |
FP32;ImageNET;4; Sync;Plugin: CPU Iteration count: 1000 Thread count: 1 |
FP32;ImageNET;4; Sync;Plugin: CPU Iteration count: 1000 Thread count: 2 |
FP32;ImageNET;4; Sync;Plugin: CPU Iteration count: 1000 Thread count: 4 |
FP32;ImageNET;4; Sync;Plugin: CPU Iteration count: 1000 Thread count: 8 |
FP32;ImageNET;8; Sync;Plugin: CPU Iteration count: 1000 Thread count: 1 |
FP32;ImageNET;8; Sync;Plugin: CPU Iteration count: 1000 Thread count: 2 |
FP32;ImageNET;8; Sync;Plugin: CPU Iteration count: 1000 Thread count: 4 |
FP32;ImageNET;8; Sync;Plugin: CPU Iteration count: 1000 Thread count: 8 |
FP32;ImageNET;1; Async;Plugin: CPU Async request count: 1 Iteration count: 1000 Stream count: 1 |
FP32;ImageNET;1; Async;Plugin: CPU Async request count: 2 Iteration count: 1000 Stream count: 2 |
FP32;ImageNET;1; Async;Plugin: CPU Async request count: 4 Iteration count: 1000 Stream count: 4 |
FP32;ImageNET;2; Async;Plugin: CPU Async request count: 1 Iteration count: 1000 Stream count: 1 |
FP32;ImageNET;2; Async;Plugin: CPU Async request count: 2 Iteration count: 1000 Stream count: 2 |
FP32;ImageNET;2; Async;Plugin: CPU Async request count: 4 Iteration count: 1000 Stream count: 4 |
FP32;ImageNET;4; Async;Plugin: CPU Async request count: 1 Iteration count: 1000 Stream count: 1 |
FP32;ImageNET;4; Async;Plugin: CPU Async request count: 2 Iteration count: 1000 Stream count: 2 |
FP32;ImageNET;4; Async;Plugin: CPU Async request count: 4 Iteration count: 1000 Stream count: 4 |
FP32;ImageNET;8; Async;Plugin: CPU Async request count: 1 Iteration count: 1000 Stream count: 1 |
FP32;ImageNET;8; Async;Plugin: CPU Async request count: 2 Iteration count: 1000 Stream count: 2 |
FP32;ImageNET;8; Async;Plugin: CPU Async request count: 4 Iteration count: 1000 Stream count: 4 |
FP32;ImageNET;1; Sync;Plugin: GPU Iteration count: 1000 |
FP32;ImageNET;2; Sync;Plugin: GPU Iteration count: 1000 |
FP32;ImageNET;4; Sync;Plugin: GPU Iteration count: 1000 |
FP32;ImageNET;8; Sync;Plugin: GPU Iteration count: 1000 |
FP16;ImageNET;1; Sync;Plugin: GPU Iteration count: 1000 |
FP16;ImageNET;2; Sync;Plugin: GPU Iteration count: 1000 |
FP16;ImageNET;4; Sync;Plugin: GPU Iteration count: 1000 |
FP16;ImageNET;8; Sync;Plugin: GPU Iteration count: 1000 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Average time of single pass |
FPS |
|
| Average time of single pass |
FPS |
|
| Average time of single pass |
FPS |
|
| Average time of single pass |
FPS |
|
| Average time of single pass |
FPS |
|
| Average time of single pass |
FPS |
|
| Average time of single pass |
FPS |
|
| Average time of single pass |
FPS |
|
| Average time of single pass |
FPS |
|
| Average time of single pass |
FPS |
|
| Average time of single pass |
FPS |
|
| Average time of single pass |
FPS |
|
|
|
|
|
|
|
|
|
|
FP32;ImageNET;1; Sync;Plugin: CPU Iteration count: 1000 Thread count: 1 |
FP32;ImageNET;1; Sync;Plugin: CPU Iteration count: 1000 Thread count: 2 |
FP32;ImageNET;1; Sync;Plugin: CPU Iteration count: 1000 Thread count: 4 |
FP32;ImageNET;2; Sync;Plugin: CPU Iteration count: 1000 Thread count: 1 |
FP32;ImageNET;2; Sync;Plugin: CPU Iteration count: 1000 Thread count: 2 |
FP32;ImageNET;2; Sync;Plugin: CPU Iteration count: 1000 Thread count: 4 |
FP32;ImageNET;4; Sync;Plugin: CPU Iteration count: 1000 Thread count: 1 |
FP32;ImageNET;4; Sync;Plugin: CPU Iteration count: 1000 Thread count: 2 |
FP32;ImageNET;4; Sync;Plugin: CPU Iteration count: 1000 Thread count: 4 |
FP32;ImageNET;8; Sync;Plugin: CPU Iteration count: 1000 Thread count: 1 |
FP32;ImageNET;8; Sync;Plugin: CPU Iteration count: 1000 Thread count: 2 |
FP32;ImageNET;8; Sync;Plugin: CPU Iteration count: 1000 Thread count: 4 |
FP32;ImageNET;1; Async;Plugin: CPU Async request count: 1 Iteration count: 1000 Stream count: 1 |
FP32;ImageNET;1; Async;Plugin: CPU Async request count: 2 Iteration count: 1000 Stream count: 2 |
FP32;ImageNET;2; Async;Plugin: CPU Async request count: 1 Iteration count: 1000 Stream count: 1 |
FP32;ImageNET;2; Async;Plugin: CPU Async request count: 2 Iteration count: 1000 Stream count: 2 |
FP32;ImageNET;4; Async;Plugin: CPU Async request count: 1 Iteration count: 1000 Stream count: 1 |
FP32;ImageNET;4; Async;Plugin: CPU Async request count: 2 Iteration count: 1000 Stream count: 2 |
FP32;ImageNET;8; Async;Plugin: CPU Async request count: 1 Iteration count: 1000 Stream count: 1 |
FP32;ImageNET;8; Async;Plugin: CPU Async request count: 2 Iteration count: 1000 Stream count: 2 |
|
|
|
|
|
|
|
|
|
|
|
|
|
| Average time of single pass |
FPS |
|
| Average time of single pass |
FPS |
|
| Average time of single pass |
FPS |
|
| Average time of single pass |
FPS |
|
| Average time of single pass |
FPS |
|
| Average time of single pass |
FPS |
|
| Average time of single pass |
FPS |
|
| Average time of single pass |
FPS |
|
|
| alexnet |
|
|
|
|
densenet-121 |
|
|
|
|
densenet-161 |
|
|
|
|
densenet-169 |
|
|
|
|
densenet-201 |
|
|
|
|
googlenet-v1 |
|
|
|
|
googlenet-v2 |
|
|
|
|
googlenet-v3 |
|
|
|
|
googlenet-v4 |
|
|
|
|
inception-resnet-v2 |
|
|
|
|
mobilenet-ssd |
|
|
|
|
resnet-101 |
|
|
|
|
resnet-152 |
|
|
|
|
resnet-50 |
|
|
|
|
squeezenet1.0 |
|
|
|
|
squeezenet1.1 |
|
|
|
|
ssd300 |
|
|
|
|
ssd512 |
|
|
|
|
ssd_mobile_net_v2_coco |
|
|
|
|
vgg16 |
|
|
|
|
vgg19 |
|
|
|
|


#assign l2caching_using_bean = "true">
To enable bean caching we add the @Cache
annotation to the entity bean
type.
We use the naturalKey
attribute to define a natural unique key
that can be used.
Ebean will then automatically maintain a natural key lookup cache and use this with queries that use the natural key properties in where expressions.
```java @Cache(naturalKey = "email") ``` ```java // Multiple properties make up the unique natural key @Cache(naturalKey = {"store","sku"}) ````If @Cache has been defined on the bean then Ebean will automatically try and use the L2 bean cache.
```java @Cache @Entity @Table(name="country") public class Country { ``` ```java // automatically use the cache Country country = Ebean.find(Country.class,"NZ"); // references automatically use the cache too Country countryRef = Ebean.getReference(Country.class,"NZ"); // hit the country cache automatically via navigation // ... and lazy loading Customer customer = Ebean.find(Customer.class, 1); Address billingAddress = customer.getBillingAddress(); Country c2 = billingAddress.getCountry(); ```
We can explicitly specify to use the bean cache via query.setUseCache()
and for the
bean cache we can say when we do not want to use the cache.


Weld Tests
Person's name
A job this person does
Another Person's name
A job this new person does
Sidecase #1: associated data key
Sidecase #2: additional classes (no data equiv)
My Name
Leet Developer
My Name
Leet Developer
My Name
Leet Developer
My Name
Leet Developer
My Name
Leet Developer
Please enter your email address so we can spam you later
My Name
Leet Developer
The default key
:
This will be removed
zero
one
two
:


Pako v1.0
Pako License
Copyright (C) 2014-2017 by Vitaly Puzrin and Andrei Tuputcyn Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.  IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. (C) 1995-2013 Jean-loup Gailly and Mark Adler (C) 2014-2017 Vitaly Puzrin and Andrey Tupitsin This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software. Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions: 1. The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required. 2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software. 3. This notice may not be removed or altered from any source distribution.


Module
A module is a discrete unit of functionality that can be run, tested, and debugged independently. Modules includes such things as source code, build scripts, unit tests, deployment descriptors, etc. In the project, each module can use a specific SDK or inherit the SDK defined on the project level (see the SDK section later in this guide). A module can depend on other modules of the project.
Getting the current module
To determine the module in the project in question to which the specified VirtualFile
belongs use ModuleUtilCore#findModuleForFile
. Use ModuleUtilCore#findModuleForPsiElement
to find the module for a given PsiElement
.
Accessing module roots
Information about module roots can be accessed via the class ModuleRootManager.java, for example, an instance of ModuleFileIndex.java can be obtained, which is similar to the ProjectFileIndex.java but in the scope of a module.
ModuleRootManager.getInstance(currentModule).getFileIndex()
Checking belonging to a module source root
To check if a virtual file or directory belongs to a module source root, use the ProjectFileIndex.getSourceRootForFile
method. This method returns null if the file or directory does not belong to any source root of modules in the project.
VirtualFile moduleSourceRoot = ProjectRootManager.getInstance(project).getFileIndex().getSourceRootForFile(virtualFileOrDirectory);


--- layout: documentation title: ReactiveX - backpressure id: backpressure ---
In ReactiveX it is not difficult to get into a situation in which an Observable is emitting items more rapidly than an operator or observer can consume them. This presents the problem of what to do with such a growing backlog of unconsumed items.
For example, imagine using the Zip operator to zip together two infinite Observables, one of which emits items twice as frequently as the other. A naive implementation of the operator would have to maintain an ever-expanding buffer of items emitted by the faster Observable to eventually combine with items emitted by the slower one. This could cause ReactiveX to seize an unwieldy amount of system resources.
There are a variety of strategies with which you can exercise flow control and backpressure in ReactiveX in order to alleviate the problems caused when a quickly-producing Observable meets a slow-consuming observer, which include, in some ReactiveX implementations, reactive pull backpressure and some backpressure-specific operators.
A cold Observable emits a particular sequence of items, but can begin emitting this sequence when its observer finds it to be convenient, and at whatever rate the observer desires, without disrupting the integrity of the sequence. For example if you convert a static iterable into an Observable, that Observable will emit the same sequence of items no matter when it is later subscribed to or how frequently those items are observed. Examples of items emitted by a cold Observable might include the results of a database query, file retrieval, or web request.
A hot Observable begins generating items to emit immediately when it is created. Subscribers typically begin observing the sequence of items emitted by a hot Observable from somewhere in the middle of the sequence, beginning with the first item emitted by the Observable subsequent to the establishment of the subscription. Such an Observable emits items at its own pace, and it is up to its observers to keep up. Examples of items emitted by a hot Observable might include mouse & keyboard events, system events, or stock prices.
When a cold Observable is multicast (when it is converted into a connectable Observable and its Connect method is called), it effectively becomes hot and for the purposes of backpressure and flow-control it should be treated as a hot Observable.
Cold Observables are ideal for the reactive pull model of backpressure implemented by some implementations of ReactiveX (which is described elsewhere). Hot Observables typically do not cope well with a reactive pull model, and are better candidates for other flow control strategies, such as the use of the operators described on this page, or operators like Buffer, Sample, Debounce, or Window.
TBD
{% endlang_operator %} {% lang_operator RxGroovy onBackpressureBuffer onBackpressureDrop onBackpressureLatest %}RxGroovy implements reactive pull backpressure, and many of its operators support that form of backpressure. It also has three operators that you can apply to Observables that have not been written to support backpressure: {% endlang_operator %} {% lang_operator RxJava 1․x onBackpressureBuffer onBackpressureDrop onBackpressureLatest %}
RxJava implements reactive pull backpressure, and many of its operators support that form of backpressure. It also has three operators that you can apply to Observables that have not been written to support backpressure: {% endlang_operator %} {% lang_operator RxJava 2․x Flowable %}
TBD
{% endlang_operator %} {% lang_operator RxJS controlled pausable pausableBuffered stopAndWait windowed %}
RxJS implements backpressure by transforming an ordinary Observable into a
ControlledObservable
with the controlled
operator. This forces the
Observable to respect pull request
s from its observer rather than pushing items on
its own initiative.
There are also two operators that convert an ordinary Observable into at
PausableObservable
.
TBD
{% endlang_operator %} {% lang_operator Rx.NET %}TBD
{% endlang_operator %} {% lang_operator RxPY %}TBD
{% endlang_operator %} {% lang_operator Rx.rb %}TBD
{% endlang_operator %} {% lang_operator RxScala onBackpressureBuffer onBackpressureDrop onBackpressureLatest %}TBD
{% endlang_operator %}


This is a game of programming!
Your task is to program the movement of elevators, by writing a
program in
JavaScript.
The goal is to transport people in an efficient manner.
Depending on how well you do it, you can progress through the ever
more difficult challenges.
Only the very best programs will be able to complete all the
challenges.
Enter your code in the input window below the game view, and press the
Apply button to start the
challenge.
You can increase or decrease the speed of time by pressing the
and
buttons.
If your program contains an error, you can use the developer tools in
your web browser to try and debug it. If you want to start over with
the code, press the Reset button.
This will revert the code to a working but simplistic
implementation.
If you have a favorite text editor, such as
Sublime Text, feel free to
edit the code there and paste it into the game editor.
Your code is automatically saved in your local storage, so don't worry
- it doesn't disappear if you accidentally close the browser.
Your code must declare an object containing at least two functions called init and update. Like this:
{
init: function(elevators, floors) {
// Do stuff with the elevators and floors, which are both arrays of objects
},
update: function(dt, elevators, floors) {
// Do more stuff with the elevators and floors
// dt is the number of game seconds that passed since the last time update was called
}
}
These functions will then be called by the game during the
challenge.
init will be called when the
challenge starts, and
update repeatedly during the
challenge.
Normally you will put most of your code in the init function, to set up event listeners and logic.
elevator.goToFloor(1);
if(elevator.currentFloor() > 2) { ... }
It is possible to listen for events, like when stopping at a floor, or a button has been pressed.
elevator.on("idle", function() { elevator.goToFloor(0); });
elevator.on("floor_button_pressed", function(floorNum) { ... } );
floor.on("up_button_pressed", function() { ... } );
| Property | Type | Explanation | Example |
|---|---|---|---|
| goToFloor | function | Queue the elevator to go to specified floor number. If you specify true as second argument, the elevator will go to that floor directly, and then go to any other queued floors. |
|
| stop | function | Clear the destination queue and stop the elevator if it is moving. Note that you normally don't need to stop elevators - it is intended for advanced solutions with in-transit rescheduling logic. Also, note that the elevator will probably not stop at a floor, so passengers will not get out. |
|
| currentFloor | function | Gets the floor number that the elevator currently is on. |
|
| goingUpIndicator | function | Gets or sets the going up indicator, which will affect passenger behaviour when stopping at floors. |
|
| goingDownIndicator | function | Gets or sets the going down indicator, which will affect passenger behaviour when stopping at floors. |
|
| maxPassengerCount | function | Gets the maximum number of passengers that can occupy the elevator at the same time. |
|
| loadFactor | function | Gets the load factor of the elevator. 0 means empty, 1 means full. Varies with passenger weights, which vary - not an exact measure. |
|
| destinationDirection | function | Gets the direction the elevator is currently going to move toward. Can be "up", "down" or "stopped". | |
| destinationQueue | array | The current destination queue, meaning the floor numbers the elevator is scheduled to go to. Can be modified and emptied if desired. Note that you need to call checkDestinationQueue() for the change to take effect immediately. |
|
| checkDestinationQueue | function | Checks the destination queue for any new destinations to go to. Note that you only need to call this if you modify the destination queue explicitly. |
|
| getPressedFloors | function | Gets the currently pressed floor numbers as an array. |
|
| Event | Explanation | Example |
|---|---|---|
| idle | Triggered when the elevator has completed all its tasks and is not doing anything. |
|
| floor_button_pressed | Triggered when a passenger has pressed a button inside the elevator. |
|
| passing_floor | Triggered slightly before the elevator will pass a floor. A good time to decide whether to stop at that floor. Note that this event is not triggered for the destination floor. Direction is either "up" or "down". |
|
| stopped_at_floor | Triggered when the elevator has arrived at a floor. |
|
| Property | Type | Explanation | Example |
|---|---|---|---|
| floorNum | function | Gets the floor number of the floor object. |
|
| Event | Explanation | Example |
|---|---|---|
| up_button_pressed | Triggered when someone has pressed the up button at a floor. Note that passengers will press the button again if they fail to enter an elevator. |
|
| down_button_pressed | Triggered when someone has pressed the down button at a floor. Note that passengers will press the button again if they fail to enter an elevator. |
|


|
Loads the current value of the processor's time-stamp counter into the EDX:EAX registers. The time-stamp counter is contained in a 64-bit MSR. The high-order 32 bits of the MSR are loaded into the EDX register, and the low-order 32 bits are loaded into the EAX register. The processor monotonically increments the time-stamp counter MSR every clock cycle and resets it to 0 whenever the processor is reset. See "Time Stamp Counter" in Chapter 15 of the IA-32 Intel Architecture Software Developer's Manual, Volume 3 for specific details of the time stamp counter behavior.
When in protected or virtual 8086 mode, the time stamp disable (TSD) flag in register CR4 restricts the use of the RDTSC instruction as follows. When the TSD flag is clear, the RDTSC instruction can be executed at any privilege level; when the flag is set, the instruction can only be executed at privilege level 0. (When in real-address mode, the RDTSC instruction is always enabled.) The time-stamp counter can also be read with the RDMSR instruction, when executing at privilege level 0.
The RDTSC instruction is not a serializing instruction. Thus, it does not necessarily wait until all previous instructions have been executed before reading the counter. Similarly, subsequent instructions may begin execution before the read operation is performed.
This instruction was introduced into the IA-32 Architecture in the Pentium processor.
|


Man appears in court following robbery at Lenton Abbey Premier store
It happened on Friday, November 15
by Joseph LockerA 33-year-old man has been bailed by Nottingham magistrates after being charged with assault by beating and theft.
Shadrach Pennant, of Plantation Road in Nottingham, was charged in connection with a reported robbery at a Premier store in Lenton Abbey.
The incident happened in Woodside Road on Friday, November 15, and the shopkeeper sustained minor injuries.
A Nottinghamshire Police spokesman added: "He was bailed to appear at Nottingham Magistrates’ Court on 2 January 2020."
With the General Election approaching we want to give you all the results and reactions as they happen. Join our new WhatsApp service to receive breaking news alerts throughout the night by texting ELECTION to<PHONE_NUMBER>2. The first messages will go out December 12 after polls close.


About-Us
Our History
Our company has a long history of running the Snake River, with over 50 years of experience. Since 2001 we’ve been owned and operated by the Great Salt Lake Council, Boy Scouts of America. But our history began many years before that. Since 1959 Boy Scouts have floated the Snake in good ol’ fashioned aluminum canoes. Running the river was a different sport back then when life jackets were optional but baby oil for the perfect summer tan was not. Eventually, in the 1970s the boys wanted a taste of the good stuff (whitewater that is) and so the camp expanded to include other activities, including whitewater rafting.
For many years the camp was associated with Lone Eagle Whitewater Rafting, and in 2001 the Great Salt Lake Council BSA officially purchased Lone Eagle which later became Teton Whitewater. Because of our history, we love spending time on the river, whether it’s on a beautiful scenic trip (reminiscent of our canoeing days) or on an adventurous whitewater trip. Since that first summer in 1959, our company has maintained the tradition of having great respect for the river and the abundant wildlife that surround it.
Meet the Managers
Arne Carter
Arne is Teton Whitewater’s loveable manager/head honcho. Born on the banks of a mystical river, Arne loves kayaking, rafting, laughing and singing interpretatively. Something interesting about Arne is that he’s a real Norwegian Viking, red beard & all! He is fluent in English, Chinese, and sarcasm. Arne's favorite color is shiny, and he has never, and I mean NEVER lost a tickle fight! He has YEARS of experience on the river and knows it like the back of his hand, believe it or not he has done over 2,000 runs on the Snake!
Matt Pratt
Adventure Matt Pratt is the literal son of the river Gods. He is the reason that the Snake River is safe for families all over. Matt has graced us with another year at Teton Whitewater and has been guiding for over a decade! When Matt's not running things here at TWW he is finishing up his bachelors degree in accounting along with running any off-season operations. He loves running rivers along with almost any other outdoor activity. Having spent 2 years in Argentina he speaks fluent Spanish and loves to talk any chance he gets!


Another cross post, somewhat edited, from a recent MAET assignment. Below is a short reflection (slightly adapted for the post) I wrote comparing Missional Thinking (big idea, goal-based) and Instrumental Thinking (short term, tool-based) in education.
You can see the entire assignment response in my Google Doc
Schools are facing a variety of problems, especially concerns over annual budgets. Competing internal and external factors carve up the funds available faster than the Thanksgiving turkey, often leaving very little behind to explore new areas of possibility. Free tools, as a result, are (ironically) at a premium in the education world. Google Apps for Education is, without a doubt, an extremely powerful suite of tools available to schools at no out-of-pocket expense. Budget issues aside, the allure of “free” and what Google Apps offers can lead to narrow thinking and a loss of larger opportunities when it comes to classroom use.
This was a tough assignment for me because the lines between instrumental and missional thinking are so nuanced. At first, I thought the two were woven together, with missional thinking directing the instrumental decisions. Now that I’ve taken nearly a week to think about it more, I’m not so sure that’s the best description. If you’re working as a missional thinker, your decisions will always support the larger goal of the group or organization. If you’re working with an instrumental mindset, the decisions you make will be for your own benefit. There are significant parallels here between the way an Alchemist and Opportunist work.
At first, I thought the two were woven together, with missional thinking directing the instrumental decisions.
I chose the problem of deciding to implement school-wide tools for two reasons. First, I think it is a decision that could fall easily into either camp…it isn’t as clear cut as some of the other ed tech discussions happening right now. Second, Google Apps should be leading to larger discussions of school culture and how technology will influence that, but I don’t hear those very often.
If you open a conference program, you will see no less than 10 or 12 sessions on Google Docs, but rarely a session on how the use of the platform has contributed to meaningful, systemic change within a class or across a district. I struggle to connect or find deeper discussion when tools are simply picked up because they’re free. This discussion could have a lot of great ideas as well as some individual anecdotes, but I wouldn’t expect much more meat than that. The only exception could be a discussion on collaboration, but (and I may sound pessimistic or cynical) “collaboration” is the new term of endearment for student work. Using Google Docs for the sake of collaboration (I honestly think “cooperation” is more descriptive thanks to some thoughts from Dave Tchozewski) is the same as using Google Docs because they’re free.
When having discussions about systemic change, it is so easy to include the name of the tool you’re considering, and I think that would shift the missional thought process into the realm of instrumental thinking. The missional discussion should consider larger truths of digital learning and forward-thinking organizations. They consider the desired behavior rather than the potential tangible or economic benefits of a particular tool. The people in this conversation are dealing with deep philosophical issues around education. Technology needs to be part of the discussion, but it shouldn’t be off in its own category. The other big differentiator is that any number of tools can be used in a plan to answer the questions asked. Each would serve their own unique purpose, and when combined with one another, serve the mission of the organization much more thoroughly and effectively than any instrument alone.
Written on February 14th, 2014 by Brian Bennett Categorized in: All MAET
Leave a comment


Training in international trade in Coimbatore from next year
Global Network Institute will conduct the training courses to empower entrepreneurs
by Special CorrespondentAhmedabad-based Global Network Institute will start operations in Coimbatore, launching training programmes in international trade, in January next year. Participants will get hands-on training in international market strategy, selecting trading partners, online exports, shipping procedures, etc.
Sectors with export potential in the Coimbatore region are: aerospace, defence, agro products and food processing, gem and jewellery, automobile components, textiles, etc.
Jagat Shah, founder of Global Network Institute, said the aim is to empower primarily women entrepreneurs and SMEs and help them explore global markets.
Manufacturers, traders, family-owned businesses and students can undergo the training. The courses will be short-term programmes that will help any aspiring exporter take his business to the global market, he said.
The institute offers follow up and refresher courses too.


#include <GrPolygonNode.h>
Public Member Functions | |
| GrPolygonNode (const tstring &name, MMat4x4 local) | |
| class header. | |
| ~GrPolygonNode () | |
| const tstring & | GetName () const |
| void | SetLocal (const MMat4x4 &local) |
| transform management. | |
| const MMat4x4 & | GetLocal () const |
| unsigned int | GetChildCount () const |
| child management. | |
| GrPolygonNode * | GetChild (unsigned int idx) |
| public methods | |
| void | AddChild (GrPolygonNode *child) |
| void | RemoveChild (unsigned int idx) |
| bool | DeleteChildTree (const char *name, bool ignoreCase) |
| GrPolygonNode * | FindNode (const char *name, bool ignoreCase) |
| finds a node by it's name. | |
| unsigned int | GetMeshCount () const |
| polygon group management. | |
| URef< GrPolygonMesh > | GetMesh (unsigned int idx) |
| void | AddMesh (URef< GrPolygonMesh > mesh) |
| void | RemoveMesh (unsigned int idx) |
| void | BuildMeshList (UFastArray< URef< GrPolygonMesh > > &meshes) |
| void | SetOptimizeEnable (bool enabled) |
| bool | GetOptimizeEnable () const |
| bool | Optimize (GrPolygonGroup &worldPolygons, const tstring &noOptimizePostfix) |
| void | Prune (const tstring &noOptimizePostfix) |
| removes unnecessary nodes from the tree. | |
| void | Update (const MMat4x4 &parentWorld=MMat4x4()) |
| updates transforms and bounding volumes. |
Definition at line 22 of file GrPolygonNode.h.
class header.
File: GrPolygonNode.cpp Author: Kevin Bray Created: 01-16-06 Copyright © 2004 Bootstrap Studios. All rights reserved. project includes. class GrPolygonNode ctor & dtor
Definition at line 24 of file GrPolygonNode.cpp.
| GrPolygonNode::~GrPolygonNode | ( | ) |
Definition at line 33 of file GrPolygonNode.cpp.
| void GrPolygonNode::AddChild | ( | GrPolygonNode * | child | ) |
Definition at line 58 of file GrPolygonNode.cpp.
| void GrPolygonNode::AddMesh | ( | URef< GrPolygonMesh > | mesh | ) |
Definition at line 137 of file GrPolygonNode.cpp.
| void GrPolygonNode::BuildMeshList | ( | UFastArray< URef< GrPolygonMesh > > & | meshes | ) |
builds a list of all meshes used. Each mesh will only show up once in the resulting list.
add meshes to the mesh list if they aren't already added.
check to see if the mesh is already in the list.
check to see if the mesh is already added. If so, break.
add the mesh if it isn't already in the list.
recurse children.
Definition at line 153 of file GrPolygonNode.cpp.
| bool GrPolygonNode::DeleteChildTree | ( | const char * | name, | |
| bool | ignoreCase | |||
| ) |
did we find the tree?
delete and remove the child.
found it... return true.
recurse.
didn't find it... return false.
Definition at line 74 of file GrPolygonNode.cpp.
| GrPolygonNode * GrPolygonNode::FindNode | ( | const char * | name, | |
| bool | ignoreCase | |||
| ) |
finds a node by it's name.
are we the node being searched for?
recurse.
not found.
Definition at line 104 of file GrPolygonNode.cpp.
| GrPolygonNode * GrPolygonNode::GetChild | ( | unsigned int | idx | ) |
| unsigned int GrPolygonNode::GetChildCount | ( | ) | const [inline] |
| const MMat4x4& GrPolygonNode::GetLocal | ( | ) | const [inline] |
Definition at line 32 of file GrPolygonNode.h.
| URef< GrPolygonMesh > GrPolygonNode::GetMesh | ( | unsigned int | idx | ) |
Definition at line 129 of file GrPolygonNode.cpp.
| unsigned int GrPolygonNode::GetMeshCount | ( | ) | const [inline] |
| const tstring& GrPolygonNode::GetName | ( | ) | const [inline] |
Definition at line 28 of file GrPolygonNode.h.
| bool GrPolygonNode::GetOptimizeEnable | ( | ) | const [inline] |
Definition at line 58 of file GrPolygonNode.h.
| bool GrPolygonNode::Optimize | ( | GrPolygonGroup & | worldPolygons, | |
| const tstring & | noOptimizePostfix | |||
| ) |
go through children. Do not recurse any children with the noOptimizePostfix.
optimize this node into worldPolygons.
optimize meshes.
Definition at line 187 of file GrPolygonNode.cpp.
| void GrPolygonNode::Prune | ( | const tstring & | noOptimizePostfix | ) |
removes unnecessary nodes from the tree.
call prune internal on our children.
now remove and delete all nodes that do not specify the no optimize tag!
Definition at line 218 of file GrPolygonNode.cpp.
| void GrPolygonNode::RemoveChild | ( | unsigned int | idx | ) |
Definition at line 66 of file GrPolygonNode.cpp.
| void GrPolygonNode::RemoveMesh | ( | unsigned int | idx | ) |
Definition at line 145 of file GrPolygonNode.cpp.
| void GrPolygonNode::SetLocal | ( | const MMat4x4 & | local | ) | [inline] |
| void GrPolygonNode::SetOptimizeEnable | ( | bool | enabled | ) | [inline] |
tree optimization. Returns world space polygons in the group passed in. All polygons returned in worldPolygons are removed from the true. Returns true if all polygons in the hierarchy were placed in worldPolygons.
Definition at line 57 of file GrPolygonNode.h.
updates transforms and bounding volumes.
update our world matrix.
recurse.
Definition at line 285 of file GrPolygonNode.cpp.


Filters
Polymer supports several default filters for working with data. They’re used in {{}}
expressions by piping an object (containing key/value pairs) to the filter:
{{ {...} | filterName }}
The value of the mustache will include the space-separated keys from the object whose corresponding expressions are truthy.
tokenList
The tokenList
filter is useful for binding to the class
attribute. It allows you
to dynamically set/remove class names based on the object passed to it. If the object
key is truthy, the name will be applied as a class.
For example:

results in the follow if user.selected == true
and user.type == 'super'
:

styleObject
For simple property values, Polymer allows you to bind to the style
attribute directory:

{{color}}

If the element’s color
property is “red”, this results in the following:

red

However, for the non-literal case (the binded value is an object) use the styleObject
filter:

...

{{color}}

In this examples styles
is an object of the form {color: 'red', background: 'blue'}
.


Data Structures | |
| struct | _SListIterator |
| Definition of a SListIterator. More... | |
Defines | |
| #define | SLIST_NULL ((void *) 0) |
| A null SListValue. | |
Typedefs | |
| typedef struct _SListEntry | SListEntry |
| Represents an entry in a singly-linked list. | |
| typedef struct _SListIterator | SListIterator |
| Structure used to iterate over a list. | |
| typedef void * | SListValue |
| Value stored in a list. | |
| typedef int(* | SListCompareFunc )(SListValue value1, SListValue value2) |
| Callback function used to compare values in a list when sorting. | |
| typedef int(* | SListEqualFunc )(SListValue value1, SListValue value2) |
| Callback function used to determine of two values in a list are equal. | |
Functions | |
| void | slist_free (SListEntry *list) |
| Free an entire list. | |
| SListEntry * | slist_prepend (SListEntry **list, SListValue data) |
| Prepend a value to the start of a list. | |
| SListEntry * | slist_append (SListEntry **list, SListValue data) |
| Append a value to the end of a list. | |
| SListEntry * | slist_next (SListEntry *listentry) |
| Retrieve the next entry in a list. | |
| SListValue | slist_data (SListEntry *listentry) |
| Retrieve the value stored at a list entry. | |
| SListEntry * | slist_nth_entry (SListEntry *list, int n) |
| Retrieve the entry at a specified index in a list. | |
| SListValue | slist_nth_data (SListEntry *list, int n) |
| Retrieve the value stored at a specified index in the list. | |
| int | slist_length (SListEntry *list) |
| Find the length of a list. | |
| SListValue * | slist_to_array (SListEntry *list) |
| Create a C array containing the contents of a list. | |
| int | slist_remove_entry (SListEntry **list, SListEntry *entry) |
| Remove an entry from a list. | |
| int | slist_remove_data (SListEntry **list, SListEqualFunc callback, SListValue data) |
| Remove all occurrences of a particular value from a list. | |
| void | slist_sort (SListEntry **list, SListCompareFunc compare_func) |
| Sort a list. | |
| SListEntry * | slist_find_data (SListEntry *list, SListEqualFunc callback, SListValue data) |
| Find the entry for a particular value in a list. | |
| void | slist_iterate (SListEntry **list, SListIterator *iter) |
| Initialise a SListIterator structure to iterate over a list. | |
| int | slist_iter_has_more (SListIterator *iterator) |
| Determine if there are more values in the list to iterate over. | |
| SListValue | slist_iter_next (SListIterator *iterator) |
| Using a list iterator, retrieve the next value from the list. | |
| void | slist_iter_remove (SListIterator *iterator) |
| Delete the current entry in the list (the value last returned from slist_iter_next). |
A singly-linked list stores a collection of values. Each entry in the list (represented by a pointer to a SListEntry structure) contains a link to the next entry. It is only possible to iterate over entries in a singly linked list in one direction.
To create a new singly-linked list, create a variable which is a pointer to a SListEntry, and initialise it to NULL.
To destroy a singly linked list, use slist_free.
To add a new value at the start of a list, use slist_prepend. To add a new value at the end of a list, use slist_append.
To find the length of a list, use slist_length.
To access a value in a list by its index in the list, use slist_nth_data.
To search a list for a value, use slist_find_data.
To sort a list into an order, use slist_sort.
To find a particular entry in a list by its index, use slist_nth_entry.
To iterate over each value in a list, use slist_iterate to initialise a SListIterator structure, with slist_iter_next and slist_iter_has_more to retrieve each value in turn. slist_iter_remove can be used to efficiently remove the current entry from the list.
Given a particular entry in a list (SListEntry):
| typedef int(* SListCompareFunc)(SListValue value1, SListValue value2) |
Callback function used to compare values in a list when sorting.
| typedef struct _SListEntry SListEntry |
Represents an entry in a singly-linked list.
The empty list is represented by a NULL pointer. To initialise a new singly linked list, simply create a variable of this type containing a pointer to NULL.
| typedef int(* SListEqualFunc)(SListValue value1, SListValue value2) |
Callback function used to determine of two values in a list are equal.
| SListEntry* slist_append | ( | SListEntry ** | list, | |
| SListValue | data | |||
| ) |
Append a value to the end of a list.
| list | Pointer to the list to append to. | |
| data | The value to append. |
| SListValue slist_data | ( | SListEntry * | listentry | ) |
Retrieve the value stored at a list entry.
| listentry | Pointer to the list entry. |
| SListEntry* slist_find_data | ( | SListEntry * | list, | |
| SListEqualFunc | callback, | |||
| SListValue | data | |||
| ) |
Find the entry for a particular value in a list.
| list | The list to search. | |
| callback | Callback function to be invoked to determine if values in the list are equal to the value to be searched for. | |
| data | The value to search for. |
| void slist_free | ( | SListEntry * | list | ) |
Free an entire list.
| list | The list to free. |
| int slist_iter_has_more | ( | SListIterator * | iterator | ) |
Determine if there are more values in the list to iterate over.
| iterator | The list iterator. |
| SListValue slist_iter_next | ( | SListIterator * | iterator | ) |
Using a list iterator, retrieve the next value from the list.
| iterator | The list iterator. |
| void slist_iter_remove | ( | SListIterator * | iterator | ) |
Delete the current entry in the list (the value last returned from slist_iter_next).
| iterator | The list iterator. |
| void slist_iterate | ( | SListEntry ** | list, | |
| SListIterator * | iter | |||
| ) |
Initialise a SListIterator structure to iterate over a list.
| list | Pointer to the list to iterate over. | |
| iter | Pointer to a SListIterator structure to initialise. |
| int slist_length | ( | SListEntry * | list | ) |
Find the length of a list.
| list | The list. |
| SListEntry* slist_next | ( | SListEntry * | listentry | ) |
Retrieve the next entry in a list.
| listentry | Pointer to the list entry. |
| SListValue slist_nth_data | ( | SListEntry * | list, | |
| int | n | |||
| ) |
Retrieve the value stored at a specified index in the list.
| list | The list. | |
| n | The index into the list. |
| SListEntry* slist_nth_entry | ( | SListEntry * | list, | |
| int | n | |||
| ) |
Retrieve the entry at a specified index in a list.
| list | The list. | |
| n | The index into the list . |
| SListEntry* slist_prepend | ( | SListEntry ** | list, | |
| SListValue | data | |||
| ) |
Prepend a value to the start of a list.
| list | Pointer to the list to prepend to. | |
| data | The value to prepend. |
| int slist_remove_data | ( | SListEntry ** | list, | |
| SListEqualFunc | callback, | |||
| SListValue | data | |||
| ) |
Remove all occurrences of a particular value from a list.
| list | Pointer to the list. | |
| callback | Callback function to invoke to compare values in the list with the value to remove. | |
| data | The value to remove from the list. |
| int slist_remove_entry | ( | SListEntry ** | list, | |
| SListEntry * | entry | |||
| ) |
Remove an entry from a list.
| list | Pointer to the list. | |
| entry | The list entry to remove. |
| void slist_sort | ( | SListEntry ** | list, | |
| SListCompareFunc | compare_func | |||
| ) |
Sort a list.
| list | Pointer to the list to sort. | |
| compare_func | Function used to compare values in the list. |
| SListValue* slist_to_array | ( | SListEntry * | list | ) |
Create a C array containing the contents of a list.
| list | The list. |


This module contains a set of functions that return pyfftw.FFTW objects.
The interface to create these objects is mostly the same as numpy.fft, only instead of the call returning the result of the FFT, a pyfftw.FFTW object is returned that performs that FFT operation when it is called. Users should be familiar with numpy.fft before reading on.
In the case where the shape argument, s (or n in the 1-dimensional case), dictates that the passed-in input array be copied into a different processing array, the returned object is an instance of a child class of pyfftw.FFTW, _FFTWWrapper, which wraps the call method in order to correctly perform that copying. That is, subsequent calls to the object (i.e. through __call__()) should occur with an input array that can be sliced to the same size as the expected internal array. Note that a side effect of this is that subsequent calls to the object can be made with an array that is bigger than the original (but not smaller).
Only the call method is wrapped; update_arrays() still expects an array with the correct size, alignment, dtype etc for the pyfftw.FFTW object.
When the internal input array is bigger along any axis than the input array that is passed in (due to s dictating a larger size), then the extra entries are padded with zeros. This is a one time action. If the internal input array is then extracted using pyfftw.FFTW.input_array, it is possible to persistently fill the padding space with whatever the user desires, so subsequent calls with a new input only overwrite the values that aren’t padding (even if the array that is used for the call is bigger than the original - see the point above about bigger arrays being sliced to fit).
The precision of the FFT operation is acquired from the input array. If an array is passed in that is not of float type, or is of an unknown float type, an attempt is made to convert the array to a double precision array. This results in a copy being made.
If an array of the incorrect complexity is passed in (e.g. a complex array is passed to a real transform routine, or vice-versa), then an attempt is made to convert the array to an array of the correct complexity. This results in a copy being made.
Although the array that is internal to the pyfftw.FFTW object will be correctly loaded with the values within the input array, it is not necessarily the case that the internal array is the input array. The actual internal input array can always be retrieved with pyfftw.FFTW.input_array.
Example:
>>> import pyfftw
>>> a = pyfftw.empty_aligned(4, dtype='complex128')
>>> fft = pyfftw.builders.fft(a)
>>> a[:] = [1, 2, 3, 4]
>>> fft() # returns the output
array([ 10.+0.j, -2.+2.j, -2.+0.j, -2.-2.j])
More examples can be found in the tutorial.
The following functions are supported. They can be used with the same calling signature as their respective functions in numpy.fft.
Standard FFTs
Real FFTs
The first caveat is that the dtype of the input array must match the transform. For example, for fft and ifft, the dtype must be complex, for rfft it must be real, and so on. The other point to note from this is that the precision of the transform matches the precision of the input array. So, if a single precision input array is passed in, then a single precision transform will be used.
The second caveat is that repeated axes are handled differently; with the returned pyfftw.FFTW object, axes that are repeated in the axes argument are considered only once, as compared to numpy.fft in which repeated axes results in the DFT being taken along that axes as many times as the axis occurs (this is down to the underlying library).
Note that unless the auto_align_input argument to the function is set to True, the 'FFTW_UNALIGNED' flag is set in the returned pyfftw.FFTW object. This disables some of the FFTW optimisations that rely on aligned arrays. Also worth noting is that the auto_align_input flag only results in a copy when calling the resultant pyfftw.FFTW object if the input array is not already aligned correctly.
In addition to the arguments that are present with their complementary functions in numpy.fft, each of these functions also offers the following additional keyword arguments:
overwrite_input: Whether or not the input array can be overwritten during the transform. This sometimes results in a faster algorithm being made available. It causes the 'FFTW_DESTROY_INPUT' flag to be passed to the pyfftw.FFTW object. This flag is not offered for the multi-dimensional inverse real transforms, as FFTW is unable to not overwrite the input in that case.
planner_effort: A string dictating how much effort is spent in planning the FFTW routines. This is passed to the creation of the pyfftw.FFTW object as an entry in the flags list. They correspond to flags passed to the pyfftw.FFTW object.
The valid strings, in order of their increasing impact on the time to compute are: 'FFTW_ESTIMATE', 'FFTW_MEASURE' (default), 'FFTW_PATIENT' and 'FFTW_EXHAUSTIVE'.
The Wisdom that FFTW has accumulated or has loaded (through pyfftw.import_wisdom()) is used during the creation of pyfftw.FFTW objects.
threads: The number of threads used to perform the FFT.
auto_align_input: Correctly byte align the input array for optimal usage of vector instructions. This can lead to a substantial speedup.
Setting this argument to True makes sure that the input array is correctly aligned. It is possible to correctly byte align the array prior to calling this function (using, for example, pyfftw.byte_align()). If and only if a realignment is necessary is a new array created. If a new array is created, it is up to the calling code to acquire that new input array using pyfftw.FFTW.input_array.
The resultant pyfftw.FFTW object that is created will be designed to operate on arrays that are aligned. If the object is called with an unaligned array, this would result in a copy. Despite this, it may still be faster to set the auto_align_input flag and incur a copy with unaligned arrays than to set up an object that uses aligned arrays.
It’s worth noting that just being aligned may not be sufficient to create the fastest possible transform. For example, if the array is not contiguous (i.e. certain axes have gaps in memory between slices), it may be faster to plan a transform for a contiguous array, and then rely on the array being copied in before the transform (which pyfftw.FFTW will handle for you). The auto_contiguous argument controls whether this function also takes care of making sure the array is contiguous or not.
auto_contiguous: Make sure the input array is contiguous in memory before performing the transform on it. If the array is not contiguous, it is copied into an interim array. This is because it is often faster to copy the data before the transform and then transform a contiguous array than it is to try to take the transform of a non-contiguous array. This is particularly true in conjunction with the auto_align_input argument which is used to make sure that the transform is taken of an aligned array.
Like auto_align_input, If a new array is created, it is up to the calling code to acquire that new input array using pyfftw.FFTW.input_array.
avoid_copy: By default, these functions will always create a copy (and sometimes more than one) of the passed in input array. This is because the creation of the pyfftw.FFTW object generally destroys the contents of the input array. Setting this argument to True will try not to create a copy of the input array, likely resulting in the input array being destroyed. If it is not possible to create the object without a copy being made, a ValueError is raised.
Example situations that require a copy, and so cause the exception to be raised when this flag is set:
This argument is distinct from overwrite_input in that it only influences a copy during the creation of the object. It changes no flags in the pyfftw.FFTW object.
The exceptions raised by each of these functions are as per their equivalents in numpy.fft, or as documented above.
Return a pyfftw.FFTW object representing a 1D FFT.
The first three arguments are as per numpy.fft.fft(); the rest of the arguments are documented in the module docs.
Return a pyfftw.FFTW object representing a 1D inverse FFT.
The first three arguments are as per numpy.fft.ifft(); the rest of the arguments are documented in the module docs.
Return a pyfftw.FFTW object representing a 2D FFT.
The first three arguments are as per numpy.fft.fft2(); the rest of the arguments are documented in the module docs.
Return a pyfftw.FFTW object representing a 2D inverse FFT.
The first three arguments are as per numpy.fft.ifft2(); the rest of the arguments are documented in the module docs.
Return a pyfftw.FFTW object representing a n-D FFT.
The first three arguments are as per numpy.fft.fftn(); the rest of the arguments are documented in the module docs.
Return a pyfftw.FFTW object representing an n-D inverse FFT.
The first three arguments are as per numpy.fft.ifftn(); the rest of the arguments are documented in the module docs.
Return a pyfftw.FFTW object representing a 1D real FFT.
The first three arguments are as per numpy.fft.rfft(); the rest of the arguments are documented in the module docs.
Return a pyfftw.FFTW object representing a 1D real inverse FFT.
The first three arguments are as per numpy.fft.irfft(); the rest of the arguments are documented in the module docs.
Return a pyfftw.FFTW object representing a 2D real FFT.
The first three arguments are as per numpy.fft.rfft2(); the rest of the arguments are documented in the module docs.
Return a pyfftw.FFTW object representing a 2D real inverse FFT.
The first three arguments are as per numpy.fft.irfft2(); the rest of the arguments are documented in the module docs.
Return a pyfftw.FFTW object representing an n-D real FFT.
The first three arguments are as per numpy.fft.rfftn(); the rest of the arguments are documented in the module docs.
Return a pyfftw.FFTW object representing an n-D real inverse FFT.
The first three arguments are as per numpy.fft.rfftn(); the rest of the arguments are documented in the module docs.


'E.T.': Steven Spielberg's Joyful Excursion, Back to Childhood, Forward to the Unknown
|
|
Sunday, June 6, 1982
THE SAME visionary impulse that produced Steven Spielberg's wonderstruck UFO movie, "Close Encounters of the Third Kind," has now inspired a fresh, delightful variation on the theme: "E.T." Both films are propelled by the need to reach Up There or Out There, to verify the existence of sentient beings beyond our earthly habitat and confirm a spiritual rapport across the cosmos. Spielberg does it masterfully.
Opening Friday at 13 area theaters, including an engagement in 70mm and six-track Dolby Stereo at the K-B Cinema, "E.T" is a science-fiction comedy-fantasy-suspense thriller which traces the development of a profound emotional bond between an ugly-beautiful little creature from outer space and a valiant, resourceful kid from the American suburbs.
A straggler, the creature is inadvertently left behind by a spaceship which has landed under cover of darkness in a dense forest, where several diminutive silhouettes can be seen gathering examples of the flora. Facing apprehension by a shadowy group of human hunters who have witnessed the sudden departure of the ship and detected his presence, the abandoned, terrified alien beats a desperate retreat through the woods, struggling to elude the beams of darting, pursuing searchlights. The thick, protective underbrush suddenly ends and the fugitive confronts the outskirts of civilization--a suburban community nestled in the foothills.
The creature seeks concealment in the back yard shed of a house that borders on a cornfield--a setting bathed in hazy, dreamily beautiful moonlight--but he's a little noisy. He attracts the curiosity of one of the residents, a 10-year-old boy named Elliott, the middle sibling in a family of five recently reduced to four. (The parents have separated, we discover, and the father is conspicuously missing. According to rumor, he's somewhere in Mexico with his girlfriend.) Investigating a strange rattling in the shed, Elliott cautiously stands outside and tosses his softball through the open door. An instant later the ball is tossed right back at him by an unseen hand.
Despite this unnerving experience, Elliott proves to be an ingenious investigator. Snooping around the property the following night, he meets his quarry face to face and the suddenness of the encounter scares them in opposite directions. However, Elliott knows that this "goblin" is not a figment of his imagination. He hits on an approach that works like a charm: a friendly, irresistible offering of M&Ms. Reassured, the creature reciprocates with an offering of his own and then enters the sanctuary of Elliott's bedroom, scooping up a trail of candies with two long, dexterous digits. And so begins one of the funniest, sweetest love stories in movie history.
E.T., short for "extra-terrestrial," is the nickname given by Elliott (Henry Smith, a juvenile actor who combines winning naturalness with an amazing expressive range) to his squat, inquisitive, exotic guest. The names of child and creature are intended to suggest affinities. Spielberg shows the process that leads from these tentative opening gestures of friendship to an abiding, supernatural attachment: E.T. reveals miraculous powers and his liking for Elliott imposes remarkable forms of closeness, like telepathy and interlocked metabolisms.
"E.T." is essentially a spiritual autobiography, a portrait of the filmmaker as a typical suburban kid set apart by an uncommonly fervent, mystical imagination. It comes out disarmingly funny, spontaneous, bighearted. "I wanted E.T. to become a kind of conscience and companion to kids growing up in the '80s," Spielberg said in a recent interview. "In the '50s I had Jiminy Cricket and Winnie-the-Pooh as imaginary sidekicks and preceptors. They were creatures who outlived their original contexts and I hope the same thing happens with E.T."
Elliott and E.T. may have begun as alter egos of the filmmaker, but they emerge as autonomous, fully imagined characters. The chronicle of their friendship is deftly contrived to generate a giddy succession of humorous episodes, sustain a melodramatic plot and inspire rich sentimental gratification.
The humor revolves around culture shock. E.T. finds it necessary to adapt to Elliott's strange environment. He's an adroit mimic and quick study, mentally far superior to the Earthlings. Nevertheless, he sometimes misinterprets the unfamiliar behavior surrounding him. For example, after Elliott decides to take his teen-age brother Mike (Robert MacNaughton) and their kid sister Gertie (Drew Barrymore, a 6-year-old granddaughter of the late great John, who reveals a delightfully impish presence and a stunning sense of timing) into his confidence, the immediate consequence is pandemonium. Gertie shrieks at the sight of E.T., who misconstrues her reaction as a conventional form of greeting and shrieks right back. Perhaps the wittiest single sight gag in the movie is the image of Gertie fleeing in panic with E.T. waddling along in her wake, still imitating her hysterical reaction out of sheer friendliness.
E.T.'s assimilation also suggests a subtler humorous purpose. E.T. seems to embody the process of childhood development and socialization at an accelerated rate. He's constantly outdistancing the siblings as they attempt to familiarize him with the local folkways. He keeps adding new dimensions, evolving from stray pet to playmate, copycat, alter ego, miracle worker, foster parent, mentor and ultimately divinity.
The new dimensions are physical as well. Brilliantly constructed by Carlo Rambaldi, the creature reveals a complex, poetically expressive anatomy. For example, the first and last feature that we're made aware of is his heart, an organ that burns with visible, red-hot intensity in moments of emotional urgency, since his chest cavity is covered by an alarmingly thin, transparent membrane. Later there are equally distinctive, stirring aspects connected with the way E.T. uses his digits, speaks, changes coloration, breathes and moves his eyes.
The screenwriter, Melissa Mathison, had contributed to the script of "The Black Stallion," a movie Spielberg greatly admired. The idyllic friendship between boy and alien in "E.T." clearly echoes the animistic union of boy and wild animal in "The Black Stallion." Even certain details are similar: The M&Ms that Elliott leaves for E.T. recall the sugar cubes Alec left for the stallion.


{% load i18n %} {% load rules %} {% load accounts_tags %} {% has_perm 'projects.change_membership_object' request.user project as can_change_membership %} {% has_perm 'projects.is_project_owner' request.user project as is_project_owner %} {% has_perm 'projects.delete_membership_object' request.user project as can_delete_membership %} {% has_perm 'projects.add_membership_object' request.user project as can_add_membership %} {% if can_add_membership %}
| {% trans 'User' %} | {% trans 'E-Mail' %} | {% trans 'Role' %} | {% for membership in memberships %}|
|---|---|---|---|
| {% full_name membership.user %} | {{ membership.user.email }} | {{ membership.role }} | {% if membership.user != request.user and can_change_membership %} {% endif %} {% if can_delete_membership %} {% if is_project_owner and membership.last_owner == False or membership.user == request.user and membership.last_owner == False %} {% endif %} {% endif %} | {% endfor %}


Ready to start your order? I bet you can smell those beans
now. Here we go:
Order just for me
Pick up at Cuckoo Coffee
Group Order
Pick up or free delivery
(minimum order of 5 for free delivery)
Where is Cuckoo Coffee located? We're at 123 Super Tech Park Drive
in Westfor, Massachusetts 01886.
Not sure if you can get here or not?
Get Directions


Example 10: Coin Flips, Confidence, and Classifiers
February 25, 2022As we learned previously, etcetera abduction lacks the ability to reason about negation, which prohibits us from expressing "exclusive or" (XOR) relationships, e.g., the same person can be infected and healthy in the same interpretation.
However, there is a handy trick that you can use to approximate an XOR relationship using etcetera abduction, which we'll call the "XOR trick". This trick capitalizes on the fact that etcetera abduction uses exactly one axiom from the knowledge base to directly prove an observable in any given interpretation. If we craft our axioms just right, we can use the XOR trick to force etcetera abduction to pick exactly one from a set of options in a given interpretation.
Coin flips and snowstorms
Imagine you observe a coin being flipped:
(coinflip' E1 Coin1)
The probability of any such observation is its prior, and coin flips are very rare. But that is not what we're interested in. We'd like to interpret two possible worlds.
In World 1:
(coinflip' E1 Coin1) (heads' E2 Coin1)
In World 2:
(coinflip' E1 Coin1) (tails' E2 Coin1)
We have a bit of knowledge about this domain. Heads and tails each happen 50% of the time when there is a coin flip. Coin flips are pretty rare.
(if (etc0_coinflip 0.01 e coin) (coinflip' e coin)) (if (and (coinflip' e1 coin) (etc1_heads' 0.5 e e1 coin)) (heads' e coin)) (if (and (coinflip' e1 coin) (etc1_tails' 0.5 e e1 coin)) (tails' e coin))
These are two different interpretation problems, but they both have similar top interpretations. The most likely interpretation of World 1 is that the heads is explained by the coin flip, which is explained by its prior, and etcetera of 50%. Similarly for World 2.
We can force etcetera abduction to reason about both of these possibilities in a single interpretation problem by observing an XOR, where the only explanations for the XOR are the two options:
(coinflip' E1 Coin1) (xor_heads_tails' E2 Coin1) (if (and (heads' e1 coin) (etc1_xor_heads_tails 1.0 e e1 coin)) (xor_heads_tails' e coin)) (if (and (tails' e1 coin) (etc2_xor_heads_tails 1.0 e e1 coin)) (xor_heads_tails' e coin))
> python -m etcabductionpy -i coinflips.lisp ((etc0_coinflip 0.01 E1 Coin1) (etc1_heads' 0.5 $1 E1 Coin1) (etc1_xor_heads_tails 1.0 E2 $1 Coin1)) ((etc0_coinflip 0.01 E1 Coin1) (etc1_tails' 0.5 $1 E1 Coin1) (etc2_xor_heads_tails 1.0 E2 $1 Coin1)) ((etc0_coinflip 0.01 $2 Coin1) (etc0_coinflip 0.01 E1 Coin1) (etc1_heads' 0.5 $1 $2 Coin1) (etc1_xor_heads_tails 1.0 E2 $1 Coin1)) ((etc0_coinflip 0.01 $1 Coin1) (etc0_coinflip 0.01 E1 Coin1) (etc1_tails' 0.5 $2 $1 Coin1) (etc2_xor_heads_tails 1.0 E2 $2 Coin1)) 4 solutions.
Now when we interpret the coin flip and the XOR, the top 2 interpretations, equally likely, are that the heads was due to chance and the coin flip, and likewise for tails. The assumptions entail the coin flip, one of either heads or tails, and the XOR observation as well.
Similarly, we can force etcetera abduction to simultaneously interpret mutually exclusive observations that are not equally likely.
(xor_sunny_snowstorm' E1) (if (etc0_sunny 0.6 e) (sunny' e)) (if (etc0_snowstorm 0.2 e) (snowstorm' e)) (if (and (sunny' e1) (etc1_xor_sunny_snowstorm 1.0 e e1 coin)) (xor_sunny_snowstorm' e)) (if (and (snowstorm' e1) (etc2_xor_sunny_snowstorm 1.0 e e1 coin)) (xor_sunny_snowstorm' e))
Notice the 1.0 probabilities in these axioms assigned to the etcetera literals. By our previous definitions, this is the conditional probability that it is one of either sunny or a snowstorm, given that it is sunny (and implicitly, sunny implies not snowstorm). Not super informative, but logically correct.
What is the best interpretation of this single observation? It will be dependent on the prior probabilities of sunny and snowstorm. Whichever one is more likely will be the top interpretation. The top interpretation of a single xor will always be the option with the largest prior probability. If more is known, an option with a lesser probability might be in the top interpretation.
> python -m etcabductionpy -i sunny-snowstorm.lisp ((etc0_sunny 0.6 $1) (etc1_xor_sunny_snowstorm 1.0 E1 $1 $2)) ((etc0_snowstorm 0.2 $1) (etc2_xor_sunny_snowstorm 1.0 E1 $1 $2)) 2 solutions.
A flash of light, maybe
What if we're uncertain about some observation? For example, you might have seen a flash of light in the dark, but maybe you imagined it. These are actually two different interpretation problems.
In World 1:
(dark' E1) (flash_of_light' E2 L)
In World 2:
(dark' E1)
You have some knowledge of this domain. You know that darkness sometimes happens. You konw a bit about flashes of light and how they might be due to fireflies. Plus you know that fireflies come out at night, but are otherwise very rare.
(if (etc0_dark 0.3 e) (dark' e)) (if (etc0_flash_of_light 0.01 e l) (flash_of_light' e l)) (if (and (firefly' e1 f) (etc1_flash_of_light 0.8 e e1 l f)) (flash_of_light' e l)) (if (etc0_firefly 0.01 e f) (firefly' e f)) (if (and (dark' e1) (etc1_firefly 0.7 e e1 f)) (firefly' e f))
In World 1, the flash of light might be a firefly (.8), because fireflies often come out in the dark (.7), and its occasionally dark (.3). In World 2, the best interpretation is that it is occasionally dark (.3), and so the probability of this interpretation is going to beat the best interpretation of World 1.
Can we force etcetera abduction to consider both worlds simultaneously? Yes, by using the XOR trick.
(dark' E1) (xor_flash_of_light' E2 L) (if (and (flash_of_light' e1 l) (etc1_xor_flash_of_light 1.0 e e1 l)) (xor_flash_of_light' e l)) (if (etc2_xor_flash_of_light 1.0 e l) (xor_flash_of_light' e l))
> python -m etcabductionpy -i flashoflight.lisp ((etc0_dark 0.3 E1) (etc2_xor_flash_of_light 1.0 E2 L)) ((etc0_dark 0.3 E1) (etc1_firefly 0.7 $3 E1 $1) (etc1_flash_of_light 0.8 $2 $3 L $1) (etc1_xor_flash_of_light 1.0 E2 $2 L)) ((etc0_dark 0.3 $4) (etc0_dark 0.3 E1) (etc1_firefly 0.7 $3 $4 $1) (etc1_flash_of_light 0.8 $2 $3 L $1) (etc1_xor_flash_of_light 1.0 E2 $2 L)) ((etc0_dark 0.3 E1) (etc0_flash_of_light 0.01 $1 L) (etc1_xor_flash_of_light 1.0 E2 $1 L)) ((etc0_dark 0.3 E1) (etc0_firefly 0.01 $3 $1) (etc1_flash_of_light 0.8 $2 $3 L $1) (etc1_xor_flash_of_light 1.0 E2 $2 L)) 5 solutions.
The best explanation of the darkness and the xor is going to be the prior probability of dark (.3).
But what if you are really, really, really confident that you saw a flash of light? Maybe not 100% confident, but at least 99% confident? We would like some way of factoring in this confidence into the interpretation problem.
We need some way of tipping the scales of our interpretations in favor of World 1, but still allow for that 1% chance that we are wrong. We want some way of saying that the likelihood of World 1 is 99%, and World 2 is 1%, as follows:
In World 1:
(dark' E1) (flash_of_light' E2 L) (likelihood' E3 0.99)
In World 2:
(dark' E1) (likelihood' E3 0.01)
This looks promising, but we need some way of interpreting the likelihood observation with a prior probability that is exactly the same magnitude as the value in the likelihood literal. Fortunately we can do this with a simple variable substitution, as follows:
(if (etc0_likelihood pr e) (likelihood' e pr))
But how do we construct the XOR version, to force etcetera abduction to reason about both possible worlds as a single interpretation problem? We need the specific values representing our confidence to appear in antecedents of our axioms, but we don't necessarily want to hard-code these numbers into our knowledge base axioms, directly. One solution is include the confidence values in the XOR observation itself:
(dark' E1) (xor_flash_of_light' E2 L 0.99 0.01)
Then these confidence values can be substituted in the right places in each of the explanations for the XOR:
(if (and (flash_of_light' e1 l) (likelihood' e2 pr1) (etc1_xor_flash_of_light 1.0 e e1 e2 l pr1 pr2)) (xor_flash_of_light' e l pr1 pr2)) (if (and (likelihood' e1 pr2) (etc2_xor_flash_of_light 1.0 e e1 l pr1 pr2)) (xor_flash_of_light' e l pr1 pr2))
> python -m etcabductionpy -i flashoflight2.lisp ((etc0_dark 0.3 E1) (etc0_likelihood 0.99 $4) (etc1_firefly 0.7 $3 E1 $2) (etc1_flash_of_light 0.8 $1 $3 L $2) (etc1_xor_flash_of_light 1.0 E2 $1 $4 L 0.99 0.01)) ((etc0_dark 0.3 $3) (etc0_dark 0.3 E1) (etc0_likelihood 0.99 $5) (etc1_firefly 0.7 $2 $3 $4) (etc1_flash_of_light 0.8 $1 $2 L $4) (etc1_xor_flash_of_light 1.0 E2 $1 $5 L 0.99 0.01)) ((etc0_dark 0.3 E1) (etc0_likelihood 0.01 $1) (etc2_xor_flash_of_light 1.0 E2 $1 L 0.99 0.01)) ((etc0_dark 0.3 E1) (etc0_flash_of_light 0.01 $1 L) (etc0_likelihood 0.99 $2) (etc1_xor_flash_of_light 1.0 E2 $1 $2 L 0.99 0.01)) ((etc0_dark 0.3 E1) (etc0_firefly 0.01 $2 $3) (etc0_likelihood 0.99 $4) (etc1_flash_of_light 0.8 $1 $2 L $3) (etc1_xor_flash_of_light 1.0 E2 $1 $4 L 0.99 0.01)) 5 solutions.
Now this single interpretation problem factors in the confidence in the two worlds, and the top interpretation is that there was a flash of light, because it has a high likelihood and because of a firefly, because fireflies come out in the dark, because dark happens from time to time.
There is one simplification we can make in XOR trick axioms, in order to clean up our formulation and avoid unnecessary backchaining. Since there is only one possible explanation for likelihood literals, and that probability is already specified, we can remove it as an antecedent and factor its uncertainty into the etcetera literals directly, swapping 1.0 for the likelihood value (1.0 * likelihood = likelihood). Our two XOR axioms are thus simplified as follows:
(if (and (flash_of_light' e1 l) (etc1_xor_flash_of_light pr1 e e1 l pr2)) (xor_flash_of_light' e l pr1 pr2)) (if (etc2_xor_flash_of_light pr2 e l pr1) (xor_flash_of_light' e l pr1 pr2))
Classifiers
With these preliminaries out of the way, we can now use the XOR trick to let us use etcetera abduction to intrepret the output of classifiers. A classifier assigns to an input a label from a set of mutually exclusive options. These assignments can be encoded as observations, as follows:
(assignment' E1 Classifier1 Input1 Label2) (assignment' E2 Classifier1 Input2 Label4) (assignment' E2 Classifier1 Input3 Label1)
A well-calibrated classifier can alternatively provide a confidence distribution over the set of possible labels for a given input. For example, a four-class classifier might provide the following distributions:
(four_class_distribution' E4 Classifier1 Input1 0.2 0.6 0.1 0.1) (four_class_distribution' E5 Classifier1 Input2 0.1 0.1 0.1 0.7) (four_class_distribution' E6 Classifier1 Input3 0.4 0.3 0.2 0.1)
Etcetera abduction can be forced to simultaneously consider all four possibilities for each input using the XOR trick, i.e., by treating each classification as a mutually exclusive explanation with its own likelihood.
(if (and (assignment' e1 classifier input Label1) (etc1_four_class_distribution pr1 e e1 classifier input pr2 pr3 pr4)) (four_class_distribution' e classifier input pr1 pr2 pr3 pr4)) (if (and (assignment' e1 classifier input Label2) (etc2_four_class_distribution pr2 e e1 classifier input pr1 pr3 pr4)) (four_class_distribution' e classifier input pr1 pr2 pr3 pr4)) (if (and (assignment' e1 classifier input Label3) (etc3_four_class_distribution pr3 e e1 classifier input pr1 pr2 pr4)) (four_class_distribution' e classifier input pr1 pr2 pr3 pr4)) (if (and (assignment' e1 classifier input Label4) (etc4_four_class_distribution pr4 e e1 classifier input pr1 pr2 pr3)) (four_class_distribution' e classifier input pr1 pr2 pr3 pr4))
The XOR trick also works if only a portion of the confidence distribution is observed, e.g. only the likelihoods of the top few class labels.
(top_two_distribution' E7 Classifier1 Input1 Label2 0.6 Label1 0.2) (top_two_distribution' E8 Classifier1 Input2 Label4 0.7 Label1 0.1) (top_two_distribution' E9 Classifier1 Input3 Label1 0.4 Label2 0.3) (if (and (assignment' e1 classifier input firstlabel) (etc1_top_two_distribution pr1 e e1 classifier input firstlabel secondlabel pr2)) (top_two_distribution' e classifier input firstlabel pr1 secondlabel pr2)) (if (and (assignment' e1 classifier input secondlabel) (etc2_top_two_distribution pr2 e e1 classifier input firstlabel pr1 secondlabel)) (top_two_distribution' e classifier input firstlabel pr1 secondlabel pr2))
The explanation for any given assignment depends on the classifier. For example, maybe Classifier1 has been trained to classify the suit of a card drawn from a deck of poker cards, based on its photograph.
(if (and (spade' e1 input) (etc1_Classifier1_assignment 1.0 e e1 input)) (assignment' e Classifier1 input Label1)) (if (and (club' e1 input) (etc2_Classifier1_assignment 1.0 e e1 input)) (assignment' e Classifier1 input Label2)) (if (and (heart' e1 input) (etc3_Classifier1_assignment 1.0 e e1 input)) (assignment' e Classifier1 input Label3)) (if (and (diamond' e1 input) (et4_Classifier1_assignment 1.0 e e1 input)) (assignment' e Classifier1 input Label4))
Above, all of the conditional probabilities are 1.0, e.g. the probability that Classifier1 assigns Label1 to an input given that the input is a spade is 100%. However, they need not be all 100%, and if the actual confusion matrix is known for a particular classifier, then these probabilities should be used instead. For example, there is some small probability that a club is misclassified as a spade.
(if (and (club' e1 input) (etc_Classifier1_club_mislabeled_as_spade 0.024 e e1 input)) (assignment' e Classifier1 input Label2))
If the input is drawn from a complete deck of cards, the prior probability of each suit is equal. If some of the cards are missing, then the priors may be different.
(if (etc0_spade 0.26 e input) (spade' e input)) (if (etc0_club 0.24 e input) (club' e input)) (if (etc0_heart 0.27 e input) (heart' e input)) (if (etc0_diamond 0.23 e input) (diamond' e input))
For a single four_class_distribution observation, the probability of any given interpretation would be the product of the prior of the suit, the conditional probability of the label given the suit, and the confidence of the classifier.
In the case where the priors are all equal and the classifier is never confused, then the top interpretation will always make the label assignment with the highest confidence. If there are more observations, to include additional information about the situational context, then a less likely classifier assignment may be seen in the top interpretation.
Indeed, the only reason we would want to go through all of this trouble is to provide a mechanism for promoting lower-confidence class labels, when we know more about the situational context than the output of a single classifier. If you don't have any other information, just multiply a few numbers and be done with it! The opportunity here is to use etcetera abduction to interpret classifier output in knowledge-rich contexts.


Woman orders coffee pods, room service robot delivers it
The woman was baffled to see a robot waiting for her at her doorstep with the coffee pods she ordered for
by mid-day online correspondentShanghai (China): When Anna Fifield, staying at a hotel in Shaghani ordered for coffee pods from the room service, little did she know that she is in for a surprise. The journalist was baffled to see a robot waiting for her at her doorstep with the coffee pods she ordered for.
Fifield took to Twitter to express her excitement and posted a video of the robot delivering the coffee pods., with the captions, “I called for more coffee pods in my Shanghai hotel room and this is how they came to me:”
After sharing the video, some users shared the similar experience they faced in the comments, some told Fifield what the robot was telling her after delivering the pods. Some users also praised the innovation behind creating such machines.
One user asked if the robot knocked. Fifield said that it called the room to say that it was waiting for her at the doorstep.
The video received more than 29,900 likes and was retweeted over 6,300 times.
Sign up for all the latest news, top galleries and trending videos from Mid-day.com
Subscribe
Loading...


--- layout: default title: image cropping --- {% highlight css %} // Size mixin @mixin size($w, $h: $w) { width: $w; height: $h; } // Responsive images mixin @mixin responsive-image($position: null, $size: 320px, $radius: 0) { @include size($size); border-radius: $radius; object-fit: cover; object-position: $position; } {% endhighlight %}


Considered hot day area and time frame. (a) Regions north of 30° latitude that either have a high population density (at least 30 people per square kilometer) or are agricultural regions (NH AgPop area) are highlighted in gray. (b) Annual time series of daily concurrent hot day area fraction of the NH AgPop area for 1959–1988 (gray) and 2018 (purple).