%inherit file='/base/index.html' /> <%def name="title()">Cronus Agent Memory Profiler Help%def> <%def name="head()">
This is a work in progress. It will grow a bit and it may not be entirely accurate everywhere.
All this was done on a checkout of<EMAIL_ADDRESS>you should be able to check that out and follow along using something like:
bzr revert<EMAIL_ADDRESS>in a pkgcore branch.
Heapy is powerful but has a learning curve. Problems are the documentation (http://guppy-pe.sourceforge.net/heapy_Use.html among others) is a bit unusual and there are various dynamic importing and other tricks in use that mean things like dir() are less helpful than they are on more "normal" python objects. This document's main purpose is to show you how to ask heapy various kinds of questions. It may or may not show a few cases where pkgcore uses more memory than it should too.
First, get an x86. Heapy currently does not like 64 bit archs much.
Emerge it:
emerge guppy
Fire up an interactive python prompt, set stuff up:
>>> from guppy import hpy >>> from pkgcore.config import load_config >>> c = load_config() >>> hp = hpy()
Just to show how annoying heapy's internal tricks are:
>>> dir(hp) ['__doc__', '__getattr__', '__init__', '__module__', '__setattr__', '_hiding_tag_', '_import', '_name', '_owner', '_share'] >>> help(hp) Help on class _GLUECLAMP_ in module guppy.etc.Glue: _GLUECLAMP_ = <guppy.heapy.Use interface at 0x-484b8554>
This object is your "starting point", but as you can see the underlying machinery is not giving away any useful usage instructions.
Do everything that allocates some memory but is not the problem you are tracking down now. Then do:
>>> hp.setrelheap()
Everything allocated before this call will not be in the data sets you get later.
Now do your memory-intensive thing:
>>> l = list(x for x in c.repo["portdir"] if x.data)
Keep an eye on system memory consumption. You want to use up a lot but not all of your system ram for nicer statistics. The python process was eating about 109M res in top when the above stuff finished, which is pretty good (for my 512mb ram box).
>>> h = hp.heap()
The fun one. This object is basically a snapshot of what's reachable in ram (minus the stuff excluded through setrelheap earlier) which you can do various fun tricks with. Its str() is a summary:
>>> h Partition of a set of 1449133 objects. Total size = 102766644 bytes. Index Count % Size % Cumulative % Kind (class / dict of class) 0 985931 68 46300932 45 46300932 45 str 1 24681 2 22311624 22 68612556 67 dict of pkgcore.ebuild.ebuild_src.package 2 49391 3 21311864 21 89924420 88 dict (no owner) 3 115974 8 3776948 4 93701368 91 tuple 4 152181 11 3043616 3 96744984 94 long 5 36009 2 1584396 2 98329380 96 weakref.KeyedRef 6 11328 1 1540608 1 99869988 97 dict of pkgcore.ebuild.ebuild_src.ThrowAwayNameSpace 7 24702 2 889272 1 100759260 98 types.MethodType 8 11424 1 851840 1 101611100 99 list 9 24681 2 691068 1 102302168 100 pkgcore.ebuild.ebuild_src.package <54 more rows. Type e.g. '_.more' to view.>
(You might want to keep an eye on ram usage: heapy made the process grow another dozen mb here. It gets painfully slow if it starts swapping, so if that happens reduce your data set).
Notice the "Total size" in the top right: about 100M. That's what we need to compare later numbers with.
So here we can see that (surprise!) we have a ton of strings in memory. We also have various kinds of dicts. Dicts are treated a bit specially: the "dict of pkgcore.ebuild.ebuild_src.package" simply means "all the dicts that are __dict__ attributes of instances of that class". "dict (no owner)" are all the dicts that are not used as __dict__ attribute.
You probably guessed what you can use "index" for:
>>> h[0] Partition of a set of 985931 objects. Total size = 46300932 bytes. Index Count % Size % Cumulative % Kind (class / dict of class) 0 985931<PHONE_NUMBER>2<PHONE_NUMBER>2 100 str
Ok, that looks pretty useless, but it really is not.  The default one (with the crazy name "Clodo" for "Class or dict owner") groups together all objects of the same class and dicts with the same owner. We can also partition the sets by a different equivalence relation. Let's do a silly example first:
>>> h.bytype Partition of a set of 1449133 objects. Total size = 102766644 bytes. Index Count % Size % Cumulative % Type 0 985931 68 46300932 45 46300932 45 str 1 85556 6 45226592 44 91527524 89 dict 2 115974 8 3776948 4 95304472 93 tuple 3 152181 11 3043616 3 98348088 96 long 4 36009 2 1584396 2 99932484 97 weakref.KeyedRef 5 24702 2 889272 1 100821756 98 types.MethodType 6 11424 1 851840 1 101673596 99 list 7 24681 2 691068 1 102364664 100 pkgcore.ebuild.ebuild_src.package 8 11328 1 317184 0 102681848 100 pkgcore.ebuild.ebuild_src.ThrowAwayNameSpace 9 408 0 26112 0 102707960 100 types.CodeType <32 more rows. Type e.g. '_.more' to view.>
As you can see this is the same thing as the default view, but with all the dicts lumped together. A more useful one is:
>>> h.byrcs Partition of a set of 1449133 objects. Total size = 102766644 bytes. Index Count % Size % Cumulative % Referrers by Kind (class / dict of class) 0 870779 60 43608088 42 43608088 42 dict (no owner) 1 24681 2 22311624 22 65919712 64 pkgcore.ebuild.ebuild_src.package 2 221936 15 20575932 20 86495644 84 dict of pkgcore.ebuild.ebuild_src.package 3 242236 17 8588560 8 95084204 93 tuple 4 6 0 1966736 2 97050940 94 dict of weakref.WeakValueDictionary 5 36009 2 1773024 2 98823964 96 dict (no owner), dict of pkgcore.ebuild.ebuild_src.package, weakref.KeyedRef 6 11328 1 1540608 1 100364572 98 pkgcore.ebuild.ebuild_src.ThrowAwayNameSpace 7 26483 2 800432 1 101165004 98 list 8 11328 1 724992 1 101889996 99 dict of pkgcore.ebuild.ebuild_src.ThrowAwayNameSpace 9 3 0 393444 0 102283440 100 dict of pkgcore.repository.prototype.IterValLazyDict <132 more rows. Type e.g. '_.more' to view.>
What this does is:
So now we know that we have a lot of objects referenced only by one or more dicts (still not very useful) and also a lot of them referenced by one "normal" dict, referenced by the dict of (meaning "an attribute of") ebuild_src.package, and referenced by a WeakRef. Hmm, I wonder what those are. But let's store this view of the data first, since it took a while to generate ("_" is a feature of the python interpreter, it's always the last result):
>>> byrcs = _ >>> byrcs[5] Partition of a set of 36009 objects. Total size = 1773024 bytes. Index Count % Size % Cumulative % Referrers by Kind (class / dict of class) 0 36009<PHONE_NUMBER><PHONE_NUMBER> 100 dict (no owner), dict of pkgcore.ebuild.ebuild_src.package, weakref.KeyedRef
Erm, yes, we knew that already. If you look in the top right of the table you can see it is still grouping the items by the kind of their referrer, which is not very useful here. To get more information we can change what they are grouped by:
>>> byrcs[5].byclodo Partition of a set of 36009 objects. Total size = 1773024 bytes. Index Count % Size % Cumulative % Kind (class / dict of class) 0 36009<PHONE_NUMBER><PHONE_NUMBER> 100 str >>> byrcs[5].bysize Partition of a set of 36009 objects. Total size = 1773024 bytes. Index Count % Size % Cumulative % Individual Size 0 10190 28 489120 28 489120 28 48 1 7584 21 394368 22 883488 50 52 2 7335 20 322740 18 1206228 68 44 3 3947 11 221032 12 1427260 80 56 4 3364 9 134560 8 1561820 88 40 5 1903 5 114180 6 1676000 95 60 6 877 2 56128 3 1732128 98 64 7 285 1 19380 1 1751508 99 68 8 451 1 16236 1 1767744 100 36 9 57 0 4104 0 1771848 100 72
This took the set of objects with that odd set of referrers and redisplayed them grouped by "clodo". So now we know they're all strings. Most of them are pretty small too. To get some idea of what we're dealing with we can pull some random examples out:
>>> byrcs[5].byid Set of 36009 <str> objects. Total size = 1773024 bytes. Index Size % Cumulative % Representation (limited) 0 80 0.0 80 0.0 'media-plugin...re20051219-r1' 1 76 0.0 156 0.0 'app-emulatio...4.20041102-r1' 2 76 0.0 232 0.0 'dev-php5/ezc...hemaTiein-1.0' 3 76 0.0 308 0.0 'games-misc/f...wski-20030120' 4 76 0.0 384 0.0 'mail-client/...pt-viewer-0.8' 5 76 0.0 460 0.0 'media-fonts/...-100dpi-1.0.0' 6 76 0.0 536 0.0 'media-plugin...gdemux-0.10.4' 7 76 0.0 612 0.0 'media-plugin...3_pre20051219' 8 76 0.0 688 0.0 'media-plugin...3_pre20051219' 9 76 0.0 764 0.0 'media-plugin...3_pre20060502' >>> byrcs[5].byid[0].theone 'media-plugins/vdr-streamdev-server-0.3.3_pre20051219-r1'
A pattern emerges! (sets with one item have a "theone" attribute with the actual item, all sets have a "nodes" attribute that returns an iterator yielding the items).
We could have used another heapy trick to get a better idea of what kind of string this was:
>>> byrcs[5].byvia Partition of a set of 36009 objects. Total size = 1773024 bytes. Index Count % Size % Cumulative % Referred Via: 0 1 0 80 0 80 0 "['cpvstr']", '.key', '.keys()[23147]' 1 1 0 76 0 156 0 "['cpvstr']", '.key', '.keys()[12285]' 2 1 0 76 0 232 0 "['cpvstr']", '.key', '.keys()[12286]' 3 1 0 76 0 308 0 "['cpvstr']", '.key', '.keys()[16327]' 4 1 0 76 0 384 0 "['cpvstr']", '.key', '.keys()[17754]' 5 1 0 76 0 460 0 "['cpvstr']", '.key', '.keys()[19079]' 6 1 0 76 0 536 0 "['cpvstr']", '.key', '.keys()[21704]' 7 1 0 76 0 612 0 "['cpvstr']", '.key', '.keys()[23473]' 8 1 0 76 0 688 0 "['cpvstr']", '.key', '.keys()[24239]' 9 1 0 76 0 764 0 "['cpvstr']", '.key', '.keys()[3070]' <35999 more rows. Type e.g. '_.more' to view.>
Ouch, 36009 total rows for 36009 objects. What this did is similar to what "byrcs" did: for every object in the set it determined how they can be reached through their referrers, then groups objects that can be reached in the same ways together. Unfortunately it is grouping everything reachable as a dictionary key differently, so this is not very useful.
XXX WTF XXX
It is not likely this accomplishes anything, but let's assume we want to know if there are any objects in this set not reachable as the "key" attribute. Heapy can tell us (although this is very slow... there might be a better way but I do not know it yet):
>>> nonkeys = byrcs[5] & hp.Via('.key').alt('<') >>> nonkeys.byrcs hp.Nothing
(remember "hp" was our main entrance into heapy, the object that gave us the set of all objects we're interested in earlier).
What does this do? "hp.Via('.key')" creates a "symbolic set" of "all objects reachable only as the 'key' attribute of something" (it's a "symbolic set" because there are no actual objects in it). The "alt" method gives us a new symbolic set of everything reachable via "less than" this way. We then intersect this with our set and discover there is nothing left.
A similar construct that does not do what we want is:
>>> nonkeys = byrcs[5] & ~hp.Via('.key')
The "~" operator inverts the symbolic set, giving a set matching everything not reachable exactly as a "key" attribute. The key word here is "exactly": since everything in our set was also reachable in two other ways this intersection matches everything.
Ok, let's get back to the stuff actually eating memory:
>>> h[0].byrcs Index Count % Size % Cumulative % Referrers by Kind (class / dict of class) 0 670791 68 31716096 68 31716096 68 dict (no owner) 1 139232 14 6525856 14 38241952 83 tuple 2 136558 14 6042408 13 44284360 96 dict of pkgcore.ebuild.ebuild_src.package 3 36009 4 1773024 4 46057384 99 dict (no owner), dict of pkgcore.ebuild.ebuild_src.package, weakref.KeyedRef 4 1762 0 107772 0 46165156 100 list 5 824 0 69476 0 46234632 100 types.CodeType 6 140 0 31312 0 46265944 100 function, tuple 7 194 0 11504 0 46277448 100 dict of module 8 30 0 6284 0 46283732 100 dict of type 9 55 0 1972 0 46285704 100 dict of module, tuple
Remember h[0] gave us all str objects, so this is all string objects grouped by the kind(s) of their referrers. Also notice index 3 here is the same set of stuff we saw earlier:
>>> h[0].byrcs[3] ^ byrcs[5] hp.Nothing
Most operators do what you would expect, & intersects for example.
"We have a lot of strings in dicts" is not that useful either, let's see if we can narrow that down a little:
>>> h[0].byrcs[0].referrers.byrcs Partition of a set of 44124 objects. Total size = 18636768 bytes. Index Count % Size % Cumulative % Referrers by Kind (class / dict of class) 0 24681 56 12834120 69 12834120 69 dict of pkgcore.ebuild.ebuild_src.package 1 19426 44 5371024 29 18205144 98 dict (no owner) 2 1 0 393352 2 18598496 100 dict of pkgcore.repository.prototype.IterValLazyDict 3 1 0 6280 0 18604776 100 __builtin__.set 4 1 0 6280 0 18611056 100 dict of module, guppy.heapy.heapyc.RootStateType 5 1 0 6280 0 18617336 100 dict of pkgcore.ebuild.eclass_cache.cache 6 1 0 6280 0 18623616 100 dict of pkgcore.repository.prototype.PackageIterValLazyDict 7 4 0 5536 0 18629152 100 type 8 4 0 3616 0 18632768 100 dict of type 9 1 0 1672 0 18634440 100 dict of module, dict of os._Environ
(Broken down: h[0].byrcs[0] is the set of all str objects referenced only by dicts, h[0].byrcs[0].referrers is the set of those dicts, and the final .byrcs displays those dicts grouped by their referrers)
Keep an eye on the size column. We have over 12M worth of just dicts (not counting the stuff in them) referenced only as attribute of ebuild_src.package. If we include the stuff kept alive by those dicts we're talking about a big chunk of the 100MB total here:
>>> t = _ >>> t[0].domisize 61269552
60M out of our 100M would be deallocated if we killed those dicts. So let's ask heapy what dicts that are:
>>> t[0].byvia Partition of a set of 24681 objects. Total size = 12834120 bytes. Index Count % Size % Cumulative % Referred Via: 0 24681<PHONE_NUMBER>0<PHONE_NUMBER>0 100 "['data']"
(it is easy to get confused by the "byrcs" view of our "t". t[0] is not a bunch of "dict of ebuild_src.package". It is a bunch of dicts with strings in them, namely those that are referred to by the dict of ebuild_src.package, and not by anything else. So the byvia output means those dicts with strings in them are all "data" attributes of ebuild_src.package instances).
(sidenote: earlier we saw byvia say ".key", now it says "['data']". It's different because the previous type used __slots__ (so there was no "dict of" involved) and this type does not (so there is a "dict of" and our dicts are the "data" key in it).
So what is in the dicts:
>>> t[0].referents Partition of a set of 605577 objects. Total size = 34289392 bytes. Index Count % Size % Cumulative % Kind (class / dict of class) 0 556215 92 27710068 81 27710068 81 str 1 24681 4 6085704 18 33795772 99 dict (no owner) 2 24681 4 493620 1 34289392 100 long >>> _.byvia Partition of a set of 605577 objects. Total size = 34289392 bytes. Index Count % Size % Cumulative % Referred Via: 0 24681 4 6085704 18 6085704 18 "['_eclasses_']" 1 21954 4 3742976 11 9828680 29 "['DEPEND']" 2 22511 4 3300052 10 13128732 38 "['RDEPEND']" 3 24202 4 2631304 8 15760036 46 "['SRC_URI']" 4 24681 4 1831668 5 17591704 51 "['DESCRIPTION']" 5 24674 4 1476680 4 19068384 56 "['HOMEPAGE']" 6 24681 4 1297680 4 20366064 59 "['KEYWORDS']" 7 24681 4 888516 3 21254580 62 '.keys()[3]' 8 24681 4 888516 3 22143096 65 '.keys()[9]' 9 24681 4 810108 2 22953204 67 "['LICENSE']" <32 more rows. Type e.g. '_.more' to view.>
Strings, nested dicts and longs, and most size eaten up by the "_eclasses_" values. There is also a significant amount eaten up by keys values, which is a bit odd, so let's investigate:
>>> refs = t[0].referents >>> i=iter(refs.byvia[7].nodes) >>> i.next() 'DESCRIPTION' >>> i.next() 'DESCRIPTION' >>> i.next() 'DESCRIPTION' >>> i.next() 'DESCRIPTION' >>> i.next() 'DESCRIPTION'
Eep!
>>> refs.byvia[7].bysize Partition of a set of 24681 objects. Total size = 888516 bytes. Index Count % Size % Cumulative % Individual Size 0 24681 100 888516 100 888516 100 36
It looks like we have 24681 identical strings here, using up about 1M of memory. The other odd entry is the '_eclasses_' string apparently.
To provide accurate statistics if your code uses extension types you must provide heapy with a way to get the following data for your custom types:
You provide these through a NyHeapDef struct, defined in heapdef.h in the guppy source. This header is not installed, so you should just copy it into your source tree. It is a good idea to read this header file side by side with the following descriptions, since it contains details omitted here. The stdtypes.c file contains implementations for the basic python types which you can read for inspiration.
The NyHeapDef struct provides heapy with three function pointers:
To answer "how large is an instance" you provide a NyHeapDef_SizeGetter function that is called with a PyObject* and returns an int: the number of bytes the object occupies. If you do not provide this function heapy uses a default that looks at the tp_basicsize and tp_itemsize fields of the type. This means that if you do not allocate any extra memory for non-python objects (e.g. for c strings) you do not need to provide this function.
To answer "What objects does an instance contain" you provide a traversal function (NyHeapDef_Traverser). This is called with a pointer to a "visit procedure", an instance of your extension type and some other stuff. You should then call the visit procedure for every python object contained in your object.
This might sound familiar: to support the python garbage collector you provide a very similar function (tp_traverse). Actually heapy will use tp_traverse if you do not provide a heapy-specific traverse function.
An example would be a type that contains a single python string object (that no other code can get a reference to). If this object does not have references to other python objects it cannot be involved in cycles so supporting gc would be useless. However you do still want heapy to know about the memory occupied by the contained string. You could do that by adding that size in your NyHeapDef_SizeGetter function but it is probably easier to tell heapy about the string through the traversal function (so you do not have to calculate the memory occupied by the string).
If the above type would also have a reference to some arbitrary (non-private) python object it should support gc, but it does not need to tell gc about the contained string. So you would have two traversal functions, one for heapy that visits the string and one for gc that does not.
The last function heapy wants tells it in what way your instance refers to some contained object. It is used to provide the "byvia" view. This calls a visit function once for each way your instance refers to a target object, telling it what kind of reference it is.
Once you have the needed function pointers in a struct you need to pass this to heapy somehow. This is done through a standard cpython mechanism called "cobjects".  You can wrap an arbitrary pointer in a CObject, make it available as attribute of your module, then import it from some other module, pull the void* back out and cast it to the original type.
heapy looks for a _NyHeapDefs_ attribute on all loaded modules. If this attribute exists and is a CObject the pointer in it is used as a pointer to an array of NyHeapDef struct (terminated with a struct with only nulls). Example code doing this is in sets.c in the guppy source.


Welcome To My Homepage
[ Bio ] [ Publications ] [ Courses ] [ Links ]
Bio
I am a Lecturer in the College of Computer Science and Technology at Huaqiao University, China. I received my PhD degree in Information Security from Xidian University in 2019, advised by Prof. Yuqing Zhang. I was a visiting PhD student in the Department of Electrical and Computer Engineering at the University of Arizona, advised by Prof. Ming Li. My research interests include Applied Cryptography and Privacy Enhancing Technologies.
Selected Publications
-
Data Inference from Encrypted Databases: A Multi-Dimensional Order-Preserving Matching Approach.
Yanjun Pan, Alon Efrat, Ming Li, Boyang Wang, Hanyu Quan, Joseph Mitchell, Esther Arkin, Jie Gao.
ACM MobiHoc 2020, accepted. -
Public Auditing of Log Integrity for Shared Cloud Storage Systems via Blockchain.
Hui Tian, Jia Wang, Chin-Chen Chang, Hanyu Quan.
Wireless Networks, accepted -
Randex：Mitigating Range Injection Attacks on Searchable Encryption.
Hanyu Quan, Hao Liu, Boyang Wang, Yuqing Zhang, Ming Li.
IEEE CNS 2019, Washington, DC, USA. -
Efficient and Secure Top-k Queries With Top Order-Preserving Encryption.
Hanyu Quan, Boyang Wang, Yuqing Zhang, Gaofei Wu.
IEEE Access, Vol 6, 2018. -
Are Friends of My Friends Too Social? Limitations of Location Privacy in a Socially-Connected World.
Boris Aronov, Alon Efrat, Ming Li, Jie Gao, Joseph S. B. Mitchell, Valentin Polishchuk, Boyang Wang, Hanyu Quan, Jiaxin Ding.
ACM MobiHoc 2018, Los Angeles, CA, USA. -
Publicly Verifiable Inner Product Evaluation over Outsourced Data Streams under Multiple Keys.
Xuefeng Liu, Wenhai Sun, Hanyu Quan, Wenjing Lou, Yuqing Zhang, Hui Li.
IEEE Transactions on Services Computing, Vol 10, 2017. -
SecReach: Secure Reachability Computation on Encrypted Location Check-in Data.
Hanyu Quan, Boyang Wang, Iraklis Leontiadis, Ming Li, Yuqing Zhang.
CANS 2016, Milan, Italy. -
Lightweight Handover Authentication with Location Privacy-Preserving in Mobile Wireless Networks.
Ling Liu, Hanyu Quan, Xuefeng Liu, Yuqing Zhang.
International Journal of Embedded Systems, Vol 7, 2015.
Courses
- Advanced Computer Networking Fall 2019
- Network Security Management Spring 2020
Useful Links
Hanyu Quan
PhD, Lecturer
College of Computer Science and Technology
Huaqiao University
Email Address：
quanhanyu [at] hqu.edu.cn


If you are not redirected automatically, please click the link to continue to the
U.S. Department of the Interior Office of Inspector General.


This site provides a complete historical archive of messages posted to the public mailing lists of the Apache Software Foundation projects. More information about these lists is provided on the projects' own websites, which are linked from the project resources page.
Static mail archive browser


This is a public listing of Mason's to-do items and their statuses.
The code powering this website is completely open-source and available on GitHub.
Some of the listings require authentication to view.
Click any tag to filter it.
Username and password authentication is available to access items that require it.
Tokens are created in order to access the gotodo API. When you log in, you are creating a master-access token, which is then used for other manipulations of the API.
If you would like, you can also create more tokens so that other applications can pretend like they are you and access the gotodo API to perform operations like creating, modifying, and deleting todo items.
This panel allows management of tokens. To create a new token, press the "create token" button. A new token, with the specified permissions, will be created. To invalidate an existing token, paste in a token into the token text field and press the "invalidate token" button.


A Communication Network represents a set of structures and behaviours that connects computer systems or other electronic devices for transmission, routing, and reception of data or data-based communications such as voice and video.
A Communication Network connects two or more Devices. The most basic Communication Network is a single link between two Devices. A Communication Network realizes one or more Paths. It embodies the physical realization of the logical path between Nodes.
A Communication Network can consist of sub-networks. It can aggregate Devices and System Software, for example, to model the routers, switches, and firewalls that are part of the network infrastructure.
Technology. Active Structure.
LAN. Wireless. Wide Area Network.


Step 1: Add Address to appropriate role
If false, try again!
Validate the authenticity of the product
Universal Product Code:
Farmer Produced Product (ONLY FARMER)
Origin Farm Name:
Origin Farm Information:
Origin Farm Latitude:
Origin Farm Longitiude:
Product Notes:
Product Price:
Universal Product Code:
Process Product (ONLY DISTRIBUTOR)
Universal Product Code:
Number of cheese slices:
Package Product (ONLY DISTRIBUTOR)
Universal Product Code:
Sell Product
Universal Product Code:
Product Price:
Purchased Product
Universal Product Code:
Ship Product
Universal Product Code:
Received Product
Universal Product Code:


This page has been replaced
The information on this page is no longer being maintained.
The “calculators” referenced on this page have been replaced by an “analyzer” at IEEE-754.
Old Contents
This page provides some reference material for the IEEE-754 floating-point standard. It is a companion page to the three calculator pages:
- Convert decimal numbers to IEEE-754 representation. Enter a decimal value and see how it would be encoded as a single-precision or double-precision IEEE-754 floating point number.
- Analyze a single-precision IEEE-754 value. Enter a 64-bit value in hexadecimal, and see the corresponding decimal value and the breakdown of all the fields.
- Analyze a double-precision IEEE-754 value. Enter a 64-bit value in hexadecimal, and see the corresponding decimal value and the breakdown of all the fields.
What’s Here
History of the Calculators
These calculators came into being in the fall semester of 1997 when I assigned my Computer Organization course an optional project to write a program that would print the values of the fields of IEEE-754 floating point numbers. One student, Quanfei Wen, decided to do the program as an interactive web page, using Javascript to do the calculations.
I put Quanfei’s pages up on my web site as a resource for other students taking my Computer Organization course, where it was found by Keven Brewer, who was working for Delco Electronics at the time. Kevin noticed some special cases that Quanfei’s calculators didn’t handle, and volunteered to work up the precise versions of the code that the calculators now use. Kevin also did a web search for information on the IEEE-754 standard, which is included in the Kevin’s Report section below. Kevin also prepared some web tables listing the parameters of the standard.
The calculators have turned out to be a popular resource on the web for academics and industry alike. I know of translations into Spanish and German, and they get over 10,000 hits a month on my web server.
In December 2004 I started reworking these pages to improve their appearance and conformance to web standards. The javascript code behind them has been moved to separate files, but interested users can download the code from the js/ directory. The original pages, with embedded javascript code, remain available at my old Computer Organization course web site.
Some References
“In 1976 Intel began to design a floating-point co-processor for its i8086/8 and i432 microprocessors. Dr. John Palmer persuaded Intel that it needed an arithmetic standard to prevent different boxes with “Intel” on the outside from computing disparate results inside. At Stanford ten years earlier, Palmer had heard a visiting professor, William Kahan, analyze commercially significant arithmetics and assess how much their anomalies inflated the costs of reliable and portable numerical software. Kahan had also enhanced the numerical prowess of a successful line of Hewlett-Packard calculators. Palmer, now the manager of Intel’s floating-point effort, recruited Kahan as a consultant to help design the arithmetic for the i432 ( which died later ) and for the i8086/8’s upcoming i8087 coprocessor.” From An Interview with the Old Man of Floating-Point, a short, facinating read on the development of the IEEE-754 Floating-Point standard.
The IEEE-754 Standard for Binary Floating-Point Arithmetic was published in 1985. You can order a copy of the standard from the IEEE. The web site for the IEEE-754 is a good place to go for links to information about IEEE-754 and floating-point in general.
A popular paper on the mathematical properties of floating-point numbers, including the IEEE-754 standard is What Every Computer Scientist Should Know About Floating-Point Arithmetic, which is also available from docs.sun.com
The Q4, 1999 issue of the Intel Technology Journal had an article, IA-64 Floating-Point operations and the IEEE standard for binary floating-point arithmetic, by M. Cornea-Hasegan and B. Norin, which provides a summary of the IEEE-754 standard and includes a table of ten different floating-point formats used by Intel’s 64-bit microprocessors (the IA-64 architecture). Most of the article discusses featues of the IA-64 floating-point instruction set. [2008-11-14: Link updated to point to PDF version of the article.]
A significant floating-point standard, which pre-dates the IEEE-754 standard, is the “hexadecimal encoding” used on IBM mainframes. This format uses sixteen instead of two as the base to which the exponent is raised. The IBM S/390 G5 processor was the first one to integrate IBM’s traditional hexadecimal encoding and IEEE-754 in the same floating-point unit. It is described in the paper, The S/390 G5 floating point unit by E. M. Schwarz and C. A. Krygowski, which appeared in the IBM Journal of Research and Development, vol. 43, No. 5/6, September/November 1999, pp 707-721.
Kevin’s Report
The rest of the material on this page came from Kevin J. Brewer, who worked for Delco Electronics at the time he wrote it. In addition to the material below, Kevin greatly refined the JavaScript code for the IEEE-754 Calculator page originally written by a Queens College student, Quanfei Wen.
At the end of this page are Kevin’s Charts, which summarize the IEEE-754 single and double precision formats.
If you find a broken link in the material below, please let me know, especially if you know where the page has moved. (Send mail to vickery at babbage.cs.qc.edu with “IEEE-754” in the Subject line.) Where there are links that I know are broken in what follows, I put the broken link in [square brackets] and preserved Kevin’s surrounding text.
Kevin suggested, “Scroll up and down from the locations cited below in order to learn other information about the IEEE-754 standard.”
The source which showed me that there were actually positive and negative NaNs and introduced me to a new special number, Indeterminate, was [ this page ] (link updated 2007-10-13). To find the table showing these NaNs and Indeterminate, use the Edit | Find... command on the string “the corresponding values”. Scroll up a little in order to take a look at the “Special Operations” table. And right above that table is the list of special numbers and their meanings.
The source which introduced me to the concepts of “signaling” and “quiet” NaNs was [ http://www.cas.american.edu/~studdard/classes/fall1995/4028201/notes/17oct95/I.html ]. To find the section on “signaling” and “quiet” NaNs, use the Edit | Find... command on the string “NaNs can be signaling or quiet”.
The source which allowed me to distinguish between “signaling” and “quiet” NaNs was [ this page ]. To find the section on NaNs and the encodings of other special numbers, use the Edit | Find... command on the string “The definition of NaNs”.
[ This source ] shows the mathematical equations which define the various IEEE-754 values and ranges.
The source which introduced me to IEEE-754’s four rounding modes and the guard, round, and “sticky” bits was [ this page ]. To find the section on rounding, use the Edit | Find... command on the string “four different rounding modes”.
Some sources on the Web claim that IEEE-754 specifies four floating-point formats in two groups, basic and extended, with a “single-precision” and a “double-precision” format in each of the two groups. To find this information, use the Edit | Find... command on the string “IEEE 754 specifies four” on [ http://www.cas.american.edu/~studdard/classes/fall1995/4028201/notes/17oct95/I.html ] and the Edit | Find... command on the string “The other two formats” on [ this page ].
Upon reading the IEEE-754 standard, one learns from “Table 1, Summary of Format Parameters” on page 9 that the extended formats are very loosely defined with unspecified exponential biases and only lower bounds for precisions and exponents, while the basic formats are specified exactly in terms of field widths and semantics. The extended formats are so loosely defined that particular implementations of these formats may be so different that numerical approximation routines using them could be non-portable.
Other sources on the Web claim that IEEE-754 specifies only three floating-point formats, “single-precision”, “double-precision”, and “quadruple-precision”. One source [ href="http://www.iac.tut.fi/usr/local/doc/Fortran-90/Version-2.0/f9a200_spd.txt"> ] shows the three IEEE-754 formats and their max and min values in DEC’s Fortran-90 documentation. To find the section on the three IEEE-754 formats, use the Edit | Find... command on the string “32-bit IEEE”. [ Another source ] shows the encodings of the special numbers and the number of bits in each field for each of the three IEEE-754 formats. To find the sections on the three IEEE-754 formats, use the Edit | Find... command on the string “For single-precision floating point numbers” and start scrolling down.
When comparing the format parameters of “extended double-precision” in IEEE-754’s Table 1 and those of the so-called “quadruple-precision”, one finds that the “quadruple-precision” format is simply a specific instance of the “extended double-precision” format. Similarly, one will note that “double-precision” is a specific instance of “extended single-precision”.
The 80-bit “extended-precision” format is used “internally” by the Intel 80x87 floating-point math “co-processor” in order to be able to shift operands back and forth without any loss of precision in the IEEE-754 64-bit (and 32-bit) format. To find this information, use the Edit | Find... command on the string “it also implements an “extended-precision” format” on [ http://www.cas.american.edu/~studdard/classes/fall1995/4028201/notes/17oct95/I.html ].
A source which describes the exponential bias of Intel’s 80-bit “extended-precision” format and its usage of the additional bits it contains relative to the “double-precision” format is [ webster.cs.ucr.edu ]. (Link updated 2005-05-03). To find this data, use the Edit | Find... command on the string “In order to help ensure accuracy”.
[ http://webster.cs.ucr.edu/Page_asm/ArtofAssembly/CH14/CH14-3.html ] states that Intel’s “extended-precision” format supports non-normalized numbers (values very close to zero whose most significant mantissa bit is not zero). To find this support information, use the Edit | Find... command on the string “Normalized values provide”.
When one compares these stated and implied format parameters of Intel’s “extended-precision” with those of “extended double-precision” in Table 1, one finds that the “extended-precision” format is a specific instance of the “extended double-precision” format, similarly to the “quadruple-precision” format.
| No. | Parameter | Format | |||||
|---|---|---|---|---|---|---|---|
|
Single |
Single Extended |
Double |
Double Extended |
Quadruple + |
Extended # |
||
| © Copyright 1985 by The Institute of Electrical and Electronics Engineers, Inc | |||||||
| + Although the “quadruple-precision” name and the particular parameters of its format are not specified in the IEEE-754 standard, it is a legally derived IEEE-754 format because its parameters are specific subset elements within the bounds of those specified for the “extended double-precision” format. | |||||||
| # Like the “quadruple-precision” format, Intel’s “extended-precision” format is a legal IEEE-754 format derived from the “extended double-precision” format. | |||||||
| (1) | p (precision, apparent mantissa width in bits) |
24 | ≥ 32 | 53 | ≥ 64 | 113 | 64 |
| (2) | Decimal digits of precision p / log2(10) |
7.22 | ≥ 9.63 | 15.95 | ≥ 19.26 | 34.01 | 19.26 |
| (3) | Mantissa’s MS-Bit | hidden bit | unspecified | hidden bit | unspecified | hidden bit | explicit bit |
| (4) | Actual mantissa width in bits | 23 | ≥ 31 | 52 | ≥ 63 | 112 | 64 |
| (5) | Emax | +127 | ≥ +1023 | +1023 | ≥ +16383 | +16383 | +16383 |
| (6) | Emin | -126 | ≤ -1022 | -1022 | ≤ -16382 | -16382 | -16382 |
| (7) | Exponent bias | +127 | unspecified | +1023 | unspecified | +16383 | +16383 |
| (8) | Exponent width in bits | 8 | ≥ 11 | 11 | ≥ 15 | 15 | 15 |
| (9) | Sign width in bits | 1 | 1 | 1 | 1 | 1 | 1 |
| (10) | Format width in bits (9) + (8) + (4) |
32 | ≥ 43 | 64 | ≥ 79 | 128 | 80 |
| (11) | Range Magnitude Maximum 2Emax + 1 |
3.4028E+38 | ≥ 1.7976E+308 | 1.7976E+308 | ≥ 1.1897E+4932 | 1.1897E+4932 | 1.1897E+4932 |
| (12) | Range Magnitude Minimum 2Emin |
1.1754E-38 | ≤ 2.2250E-308 | 2.2250E-308 | ≤ 3.3621E-4932 | 3.3621E-4932 | 3.3621E-4932 |
| (13) | Range Magnitude Minimum (Denormalized) 2Emin - (4) |
1.4012E-45 | ≤ 1.0361E-317 | 4.9406E-324 | ≤ 3.6451E-4951 | 6.4751E-4966 | 1.8225E-4951 |
| (14) | FORTRAN Language Type | REAL*4 | REAL*8 | REAL*16 | REAL*10 | ||
| (15) | C Language Type | float | double | long double | long double |
Other sources on IEEE-754 include:
- [ http://spectra.eng.hawaii.edu/Courses/EE361.S95/Lectures/Lec38/lec38.3.html ]
- [ http://www.ece.uiuc.edu/~ece291/lecture/l11.html ]
- [ Carleton University ]
- [ Grinnell College ]
- [ http://cch.loria.fr/documentation/IEEE754/index.html#wkahan Papers on Floating-Point by William Kahan -- “The Father of IEEE-754” ] Broken link, but see Prof. Kahan’ home page.
Kevin’s Summary Charts
Storage Layout and Ranges of Floating-Point Numbers
IEEE-754 floating-point numbers require three component fields: the sign, the exponent, and the mantissa. The exponential base is 2 and is never stored in any way with the value in either the registers or memory (it is implied). In order to allow the exponent and mantissa, when taken together, to vary monotonically, the signed exponent is represented in excess-127 unsigned form for single precision and excess-1023 for double precision. This excess-127 (or excess-1023) representation is indicated by the variable “e” below.
Since IEEE-754 floating-point numbers are stored in a signed magnitude form, the ranges and binary patterns of the positive and negative numbers are symmetric about the midpoint of the entire range of values (between the positive and negative zeros). As a result, essentially any statement made in regard to the positive numbers is also true of the negative numbers and vice versa.
The range of positive floating-point numbers is split into normalized numbers (normal numbers) which preserve the full precision of the mantissa, including the hidden bit, (24 bits for single precision and 53 bits for double precision) and denormalized numbers (subnormal numbers, so-called unnormalized numbers) which have from 1 to 23 significant bits for single precision and 1 to 52 bits for double precision.
The number line tables below, which show the layout for single (32-bit) and double (64-bit) precision floating-point numbers and their special values, were inspired by the table on [ this page ] (link updated 2007-10-13). To find the table on which these two are based, use the Edit | Find... command on the string “the corresponding values”. In their column headers, these tables indicate the number of bits in each field along with their bit ranges in square brackets.
The values shown in the Decimal Range column of the tables are the end points of their respective ranges with the IEEE-754 round-to-nearest value mode applied. JavaScript uses IEEE-754 double precision floating-point with round-to-nearest value mode to perform all of its arithmetic operations including its input string to numeric conversion routine. Therefore, by default, double (64-bit) precision conversions are automatically rounded to values matching these tables. In order for single (32-bit) precision conversions to be rounded to values matching these tables, the user must click the Rounded button on those pages where it is present.
32-bit Single Precision
| Range Name | Sign (s) 1 [31] |
Exponent (e) 8 [30-23] |
Mantissa (m) 23 [22-0] |
Hexadecimal Range | Range | Decimal Range § |
|---|---|---|---|---|---|---|
| Quiet -NaN |
1 | 11..11 | 11..11 : 10..01 |
FFFFFFFF : FFC00001 |
||
| Indeterminate | 1 | 11..11 | 10..00 | FFC00000 | ||
| Signaling -NaN |
1 | 11..11 | 01..11 : 00..01 |
FFBFFFFF : FF800001 |
||
| -Infinity (Negative Overflow) |
1 | 11..11 | 00..00 | FF800000 | < -(2-2-23) × 2127 | ≤ -3.4028235677973365E+38 |
| Negative Normalized -1.m × 2(e-127) |
1 | 11..10 : 00..01 |
11..11 : 00..00 |
FF7FFFFF : 80800000 |
-(2-2-23) × 2127 : -2-126 |
-3.4028234663852886E+38 : -1.1754943508222875E-38 |
| Negative Denormalized -0.m × 2(-126) |
1 | 00..00 | 11..11 : 00..01 |
807FFFFF : 80000001 |
-(1-2-23) × 2-126 : -2-149 (-(1+2-52) × 2-150) * |
-1.1754942106924411E-38 : -1.4012984643248170E-45 (-7.0064923216240862E-46) * |
| Negative Underflow | 1 | 00..00 | 00..00 | 80000000 | -2-150 : < -0 |
-7.0064923216240861E-46 : < -0 |
| -0 | 1 | 00..00 | 00..00 | 80000000 | -0 | -0 |
| +0 | 0 | 00..00 | 00..00 | 00000000 | 0 | 0 |
| Positive Underflow | 0 | 00..00 | 00..00 | 00000000 | > 0 : 2-150 |
> 0 : 7.0064923216240861E-46 |
| Positive Denormalized 0.m × 2(-126) |
0 | 00..00 | 00..01 : 11..11 |
00000001 : 007FFFFF |
((1+2-52) × 2-150) * 2-149 : (1-2-23) × 2-126 |
(7.0064923216240862E-46) * 1.4012984643248170E-45 : 1.1754942106924411E-38 |
| Positive Normalized 1.m × 2(e-127) |
0 | 00..01 : 11..10 |
00..00 : 11..11 |
00800000 : 7F7FFFFF |
2-126 : (2-2-23) × 2127 |
1.1754943508222875E-38 : 3.4028234663852886E+38 |
| +Infinity (Positive Overflow) |
0 | 11..11 | 00..00 | 7F800000 | > (2-2-23) × 2127 | ≥ 3.4028235677973365E+38 |
| Signaling +NaN |
0 | 11..11 | 00..01 : 01..11 |
7F800001 : 7FBFFFFF |
||
| Quiet +NaN |
0 | 11..11 | 10..00 : 11..11 |
7FC00000 : 7FFFFFFF |
64-bit Double Precision
| Range Name | Sign (s) 1 [63] |
Exponent (e) 11 [62-52] |
Mantissa (m) 52 [51-0] |
Hexadecimal Range | Range | Decimal Range § |
|---|---|---|---|---|---|---|
| Quiet -NaN |
1 | 11..11 | 11..11 : 10..01 |
FFFFFFFFFFFFFFFF : FFF8000000000001 |
||
| Indeterminate | 1 | 11..11 | 10..00 | FFF8000000000000 | ||
| Signaling -NaN |
1 | 11..11 | 01..11 : 00..01 |
FFF7FFFFFFFFFFFF : FFF0000000000001 |
||
| -Infinity (Negative Overflow) |
1 | 11..11 | 00..00 | FFF0000000000000 | < -(2-2-52) × 21023 | ≤ -1.7976931348623158E+308 |
| Negative Normalized -1.m × 2(e-1023) |
1 | 11..10 : 00..01 |
11..11 : 00..00 |
FFEFFFFFFFFFFFFF :<PHONE_NUMBER>000000 |
-(2-2-52) × 21023 : -2-1022 |
-1.7976931348623157E+308 : -2.2250738585072014E-308 |
| Negative Denormalized -0.m × 2(-1022) |
1 | 00..00 | 11..11 : 00..01 |
800FFFFFFFFFFFFF :<PHONE_NUMBER>000001 |
-(1-2-52) × 2-1022 : -2-1074 (-(1+2-52) × 2-1075) * |
-2.2250738585072010E-308 : -4.9406564584124654E-324 (-2.4703282292062328E-324) * |
| Negative Underflow | 1 | 00..00 | 00..00 |<PHONE_NUMBER>000000 | -2-1075 : < -0 |
-2.4703282292062327E-324 : < -0 |
| -0 | 1 | 00..00 | 00..00 |<PHONE_NUMBER>000000 | -0 | -0 |
| +0 | 0 | 00..00 | 00..00 |<PHONE_NUMBER>000000 | 0 | 0 |
| Positive Underflow | 0 | 00..00 | 00..00 |<PHONE_NUMBER>000000 | > 0 : 2-1075 |
> 0 : 2.4703282292062327E-324 |
| Positive Denormalized 0.m × 2(-1022) |
0 | 00..00 | 00..01 : 11..11 |
0000000000000001 : 000FFFFFFFFFFFFF |
((1+2-52) × 2-1075) * 2-1074 : (1-2-52) × 2-1022 |
(2.4703282292062328E-324) * 4.9406564584124654E-324 : 2.2250738585072010E-308 |
| Positive Normalized 1.m × 2(e-1023) |
0 | 00..01 : 11..10 |
00..00 : 11..11 |
0010000000000000 : 7FEFFFFFFFFFFFFF |
2-1022 : (2-2-52) × 21023 |
2.2250738585072014E-308 : 1.7976931348623157E+308 |
| +Infinity (Positive Overflow) |
0 | 11..11 | 00..00 | 7FF0000000000000 | > (2-2-52) × 21023 | ≥ 1.7976931348623158E+308 |
| Signaling +NaN |
0 | 11..11 | 00..01 : 01..11 |
7FF0000000000001 : 7FF7FFFFFFFFFFFF |
||
| Quiet +NaN |
0 | 11..11 | 10..00 : 11..11 |
7FF8000000000000 : 7FFFFFFFFFFFFFFF |
§ Your least significant digits may differ.
* The minimum magnitude values of denormalized ranges are represented by a single significant bit (a bit whose value is 1) at the right hand end of its format’s mantissa. For single (32-bit) and double (64-bit) precision, these minimum range values are 1.4012984643248170E-45 and 4.9406564584124654E-324 respectively. The values 7.0064923216240862E-46 and 2.4703282292062328E-324 are each a little more than half of these minima. They are represented by one significant bit to the right of their format’s storable mantissa and another 1-bit spaced the double precision’s mantissa width to the right of the first bit. Then, as a result of the IEEE-754 round-to-nearest value mode’s operation, these values are rounded to the denormalized range minimum values.


| Network Working Group | D. Miller |
| Internet-Draft | Tavis Software Inc. |
| Intended status: Informational | December 9, 2015 |
| Expires: June 11, 2016 |
Conference Talk Media Type
draft-miller-conference-talk-01
This draft document is a media type specification for describing a conference talk proposals, presenters and presentations. This format aims to standardize the format of information shared between software components used by conference organizers, speakers and attendees. It is intended to reduce the effort required for speakers to submit session proposals and for conference organizers to process those submissions.
The issues list for this draft can be found at https://github.com/darrelmiller/conference-talk/issues.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 11, 2016.
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
In the technology world, one way we share knowledge is via conferences. In order to have a conference we need speakers to do talks. Conferences commonly go through a process called call for proposals (CFP) where speakers who are interested submit talk proposals to the conference and then the conference organizers sift through these proposals and select the talks they believe will provide the best value to their attendees.
There are a very wide range of methods used by conferences for collecting these proposals: Google docs, Excel spreadsheets, plain text emails, wikis, custom web sites, commercial conference management systems. Each of these systems have slightly different ways of collecting information that is mostly the same.
Many conferences are run by volunteers with minimal budgets and many speakers do so at their own expense. Any possibility to improve the efficiency of the process of submitting proposals and processing them could provide significant value to a large number of conference participants.
Easier for speakers to submit
Easier for conference organizers to process
There are a wide range of scenarios that could be enabled by this common format:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
The canonical model for a conference-talk document is a JSON object as defined in the I-JSON specification [RFC7493]. The properties of the JSON object can be any valid vocabulary term from this specification. Unrecognized vocabulary should be ignored unless a consumer explicitly requests strict processing of the document.
[Note] Add comment about support of http://tools.ietf.org/html/draft-pbryan-zyp-json-ref-03
A minimal submission might look like this:
{ "session" : { "presentation" : { "title" : "An Introduction To Media Type Design", "brief-description" : "Blah Blah Blah", }, "presenters" : [{ "name" : "Darrel Miller" }] } }
A more complete session proposal might look like,
{ "session": { "presentation" : { "title": "An Introduction To Media Type Design", "brief-description": "Blah Blah Blah", "full-description": "Even longer blah Blah Blah", "length": { "preferred": 60, "min": 45, "max": 90 }, "past-sessions": [{ "presentation-date": "20150911", "conference": { "name" : "The Meta Conference" } }] }, "slot-length" : 45, "keywords": ["javascript", "java", "http"], "presenters": [{ "name": "Darrel Miller", "email"<EMAIL_ADDRESS>}, { "name" : "Bob Brown", "email"<EMAIL_ADDRESS>}] } }
This specification is intended primarily to describe a message format to transfer information between two independent systems. Requirements of persistence formats or content creation formats are a secondary concern. JSON is ideal for this purpose. However, it should be fairly straightforward to apply the structure and semantics defined in this document to other formats.
This media type is designed to hold information related to conference presentations, their presenters and the information about presented sessions. However, it imposes minimal structural constraints on the document. This is done in order to support as many scenarios as possible. A document instance may be used to submit a new proposal to a conference. Or it may be used to return a list of presentations that were held at a conference. It can also be used to return a list of presenters who will be speaking at a conference. The overall structure is fairly flexible, but the semantics of the named structures within the document are well defined.
A conference-talk document may be valid, but still incompatible with a particular resource that only accepts conference-talk documents structured in a certain way.
The root of the document MUST be a JSON object, whose properties names are structures defined in this vocabulary.
{ "presenter" : {...} }, "sessions" : [...] }, "presentations" : [...] }, }
There is no fixed structure to the root object. It can contain any number of properties that are either objects or arrays.
Certain structures can contain other structures in a 1:1 relationship. E.g.
Lists of structures can be contained as an attribute of other structures to indicate a relationship between the structures. For example:
All structures defined in this vocabulary can contain a property called links. This property contains an array of link objects. Links are a way to break apart pieces of the document for the purposes of reuse and controlling granularity. Through the use of relative URIs and fragments we can use links with the document to reduce redundancy.
links : [ { "rel" : "", "href" : ""}, { "rel" : "", "href" : ""} ]
Note: There was no need to adopt the HAL convention of using _Links as the allowed vocabulary is explicitly defined for this media type. The array of links was chosen instead of an object to allow multiple link relations of the same type without having to define multiple arrays.
Link relations values defined in the conference-talk conference talk document can be used as simple strings as long as they are prefixed with a period. However, any parsing tool must map them to a URI using the following URI template https://tavis.net/rels/conference-talk/{relname}.
The href property can resolve to a relative URI and use relative fragment identifiers to point to content within the current document. Fragment identifiers follow the scheme defined by the JSON Pointer specification [RFC6901]. This prevents the need to duplicate content within a document.
For example, the sample below has an array of proposals, and each one points to a presenter structure and conference structure.
{ "sessions" : [ { "presentation" : { "title" : "An Introduction To Media Type Design", "brief-description" : "Blah Blah Blah" }, "links" [ { "rel" : ".presenter", "href" : "#presenter"}, { "rel" : ".conference", "href" : "#conference"} ] }, { "presentation" : { "title" : "Crafting Evolvable Representations", "brief-description" : "Double blah" }, "links" [ { "rel" : ".presenter", "href" : "#presenter"}, { "rel" : ".conference", "href" : "#conference"} ] }, ], "presenter" : { "name" : "Darrel Miller", "bio" : "Destined to re-invent RDF" }, "conference" : { "name" : "The Meta Conference", "description" : "The conference about conferences" } }
An array of session structures.
An array of presentation structures.
An array of presenter structures.
An array of conference structures.
The session structure represents a proposal to a conference and a record of the given presentation. The presentation and conference property are required.
This property represents the date that a particular talk was given. The date should be in ISO 8601 format as required by I-JSON.
The physical location where conference is being held. This can simply country or city and country. This is a string value.
This field is a number that provides an approximate quantity of people who attended the presentation.
A presenter structure represents the information about a person who will or who has presented a conference talk.
The name attribute is a string value that contains the name of the present for purposes of displaying the name.
The email property
email = <addr-spec see {{RFC2822}}, Section 3.4.1>
The home airport of the presenter. This information is used to approximate travel costs for speakers and aid in the selection process. This is a string value.
An identifier that is related to a presenter selected from the list of available values as defined by the conference. This is a string value.
An identifier that is related to a presenter selected from the list of available values as defined by the conference. This is a string value.
The presentation structure contains the descriptive details of the presentation to be proposed as a session at a conference. All properties of the presentation structure can be duplicated in a containing session structure to provide conference specific values.
The title property is a single sentence description of the talk, normally used as a heading. This is a required property. Physical limits on the size of descriptive fields like this one are left to the choice of implementers. If a specific implementation chooses to limit titles to 80 characters and it subsequently receives a document with a title that exceeds that amount, the implementation must choose whether to refuse the content, or to truncate it.
Conferences often ask for short descriptions of sessions to be used on web sites or in promotional material. Some conferences insist on brief descriptions to reduce the time it takes for the selection committee to process the proposals. This specification currently does not enforce the size of a brief description and therefore there may be cases where a brief-description submitted to one conference is not accepted to another because they have differing opinions on what brief means. Feedback will drive whether a hard limit is included in this specification.
Sometimes a brief description is sufficient to spark interest in a talk, but the reader wishes to get more details. The full-description of the session can be used to go into detail about the presentation. Implementations can choose whether this description is made public or not.
Conference sessions are often rated based on their technical difficulty.This property is numeric value on the scale of 1 to 5, where 1 indicates no experience is required to benefit from the session, to 5 which indicates the audience require a strong knowledge in the subject matter to fully appreciate the talk.
target-audience : 1
Conference organizers are free to map this range of values to whatever equivalent ranking scheme they use.
Style is an identifier that classifies the type of talk being submitted. This value is a string identifier from a set of valid values as defined by the conference being submitted to.
talk-style : "workshop"
It is common for proposals to have additional information that is only directed at the selection committee. This information would not be made public.
The tags attribute contains an array of strings used for the purpose of classifying talks into categories. Although different conferences may use different sets of tags, in a communication between speaker and conference organizer, only one set of tags is valid. For client applications that might store conference proposals for speakers, it may be necessary to store multiple sets of tags to accomadate submissions to different conferences. However, this specification is not aiming to describe a storage format.
tags : ["testing","performance"]
Different conferences have different sessions lengths. Sometimes the same conference has sessions of different lengths. It is not uncommon for speakers to have some flexibility in how long a particular talk can take. In order to accomodate these different scenarios, the length property is defined using three values : preferred-length,max-length and min-length. All three values are specified in integer minutes. By specifying a range, conferences can determine if a talk can fit into the planned slots.
length : { "preferred" : 45, "max": 60, "min" : 30 }
Some conferences are multi-lingual and sometimes speakers are able to perform talks in multiple languages. The language property contains an array of language codes as described in [RFC5646].
language : ["en","fr"]
This is a free form text field used to communicate to the conference organizers any special hardware, setup, or environmental requirements needed for this talk to be presented. This is a string value.
The conference structure is used to describe its purpose, its location, the timeline of events and the domains of valid values for properties like, tags, talk-style and languages. It also can contain limits such as maximum lengths for brief-description, and full-description.
A set of valid values for the talk-style property. This domain of values is often defined within the conference structure.
talk-style-domain : ["workshop", "session","lightning-talk"]
A set of valid values for the tags property. The domain of values is often defined within the conference structure.
A set of valid values for the languages property. The domain of values is often defined within the conference structure.
A numeric value usually defined within the conference structure to define the maximum length in characters of the brief-description.
A numeric value usually defined within the conference structure to define the maximum length in characters of the full-description.
A set of valid values for the t-shirt property. The domain of values is often defined within the conference structure.
A set of valid values for the dietary-requirement property. The domain of values is often defined within the conference structure.
This is a URL that points to a video recording of the presentation.
This is a URL that points to a the slide deck used in the presentation.
This is a URL that points to the details relating to the presenter of the presentation.
This is a URL that points to a list of presentations.
This is a URL that points to information about a conference.
TK
TK
TK
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC2822] | Resnick, P., "Internet Message Format", RFC 2822, DOI 10.17487/RFC2822, April 2001. |
| [RFC5646] | Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009. |
| [RFC6901] | Bryan, P., Zyp, K. and M. Nottingham, "JavaScript Object Notation (JSON) Pointer", RFC 6901, DOI 10.17487/RFC6901, April 2013. |
| [RFC7493] | Bray, T., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015. |


Reserved.
FILM TITLE: TEMPTRESS MOON DIRECTOR: CHEN KAIGE COUNTRY: CHINA 1996 CINEMATOGRAPHY: CHRISTOPHER DOYLE MUSIC: ZHAO JIPING CAST: Gong Li, Leslie Cheung, Kevin Lin Jianhua, Caifei He, Chang Shih, Liankun Lin, Ziangting Ge, Xian Xie, David Wu, Jie Zhou, WYemang Zhou, Lei Ren, YIng Wang, Kevin Lin. SUPER FEATURES: The design of the film, and story.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
TEMPTRESS MOON, has its good points and bad points.
It is not, on par with previous Chen Kaige films, in that fundamental directing choices regarding this film. Like his close friend and director, Zhang Yimou, Kaige has always been a bit too symmetrical of a film maker, in the sense that the scenes are framed a bit rigidly with the camera, and then shot. TEMPTRESS MOON, shows that some directors in China are seeing other films and that they are getting influenced by them. Chen Kaige made a directorial choice in this film of shooting the whole thing on a steady cam ( by hand ) rather than sitting the camera down every now and then.
It helps, and then it doesn't. When it is challenging to a particular character's wish or desire, it works. When it is looking at the staid, boring, and basically dead old monuments of the Pang family, the elders, it does not work.
It has been said that the success in film, is made because of its ability to make the camera invisible. And although the idea is ok, in this film it was not, totally well defined, or designed. The characters know where the camera is, and are obviously playing to it, which is a bit boring after the first few times. By comparison, Wong Kar-wai shoots his whole films by hand, and one never really notices that the camera is obtrusive, although it does have a breathtaking pace, and a dizzying movement all the time. Kaige's choice, was to move when he had to, and to stop, when his three main characters were at a catharsis, which may have been the best time for him to keep it moving anyway, so one could notice the character scream "in vain" ( so to speak ) , thus making each character's plight that much more important... no one is listening, or paying attention, would be a point, then.
But, if the camera is the main instrument in this film, perhaps, then, we have to let go of something, and that may just be the story... in almost all the films where the camera is "free", the story takes second place, and in fact, is really less important than the point of view that is offered, the veritable stream of consciousness of the extra person that is participating in the "film", the fourth wall visitor/audience/us person. In this film, Kaige never lets go of the story, and tries to enhance it with the close ups. so we end up with a very emotional, strong, and to this reviewer, confusing film, where the style seems to be getting in the way of the whole thing. I might have offered that the youngsters be shot with the moving camera and that the elders with a totally stationary camera, thus adding a statement to the "old" style, versus the "new" style, but perhaps this was already "passe" by the time that Chen Kaige did this film.
Thus, this film comes off as an experiment, but not altogether a bad one. For one thing, it breaks out the acting, which in these films tend to be a bit "formal" by western standards..... in other words, this comes off as a sort of Peter Brook West End performance, probably blazing a trail for the future of character and theme development. Generally, when this happens, the "whole" tends to disappear in the past examples, in favor of the "moment". In this case, the moment makes a statement, but it is not winning the battles, or the war. It may be a start, however.
With some excellent performances by all parties, Gong Li, may not necessarily be the strongest performer of all of them, her physical/sexual moments are weak and terribly self conscious, but nevertheless, she still manages to bring about a strong personage.
It is the story of the Pang family, whose power and strength has been dwindling in the past years ( story starts in 1911 ) and eventually falls apart. It's heirs, are young, and two of them are enjoying the comforts of being rich, by smoking opium. Their relationship is confused, because of the demands that are placed on them. And one day, Ruyi, becomes the leader of the family, and this is a major problem for all the elders, the males, who are afraid that a woman will ruin the family. And the situation creates an interesting triangle, for the three children that were friends, that are now adults, but are, essentially, fighting among themselves for control of the family and its influence.
What is most obvious, is that the family is trapped inside their quarters, and are totally out of touch with the world, another cross over chance where the camera work themes could have been better exploited, since the patterns of life outside the brick walls are decidedly faster, and changeable than within the walls.
All in all, visually, this film is very pretty, although the color design of the film does not get much of a chance to shine, with the camera so intent on staying on the actors, in an attempt to make their plights stronger. In doing one thing, I suppose that one sacrifices another. In this case, I think the film decision was made to do the whole shoot on hand, rather than study its potential and possibilities.
Not a great film, but a very good one. Different by Chinese standards, and a bit more "physical/sexual than previous films. Still, it is self conscious in this department, but that may have more to do with their ability to get past sensors in China with their state run film industry, than it does with the director himself. But ultimately, the way to represent this falls on the director's shoulders.
A good film, not a great one. A changing of ways for Chinese film making, and a sign that shooting styles will begin to vary out of China, which is good. Honk Kong influence is very obvious.
4 GIBLOONS
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


If you have not yet been to the Desolation Wilderness south of Lake Tahoe, you need to move it right to the very top of your todo list, and I mean immediately. Robert, Erick, and I went for a 3 night trip in August and had a great time. The wildflowers were off the hook, and the alpine lakes in the high Sierra are fantastically pure and beautiful.
Day 1: The Approach and Heather Lake
We went to the Desolation Wilderness with the family of a friend from work (Joe), who went up to Tahoe on Wednesday and was in line at the ranger station on Thursday early to get the first-come, first-served permits for our trip. The Lake Tahoe Basin Management limits the number of people in the wilderness according to a zone quota system (
link
). This system requires you to state which zone you will be in for the first night, and after that you can go wherever you want for 2 weeks, all at the cost of $10 per adult.
We planned to start at the Glen Alpine trailhead above Fallen Leaf Lake where we camped last year (
link
), and hike in about 5 miles to Heather Lake for the first night. The first few miles of the day hike that we did last year would be repeated, but there was no snowmelt to cross this time, although we did hit a few patches of snow at the higher elevations.
The boys and I left at the crack of dawn and in about 3.5 hours were at Fallen Leaf Lake campground to meet Joe and family around 9:45. After a short drive up to the trailhead, we headed out.
Here is Erick a mile or so in. Erick brought all his clothes in the pack but I carried his sleeping bag. He also brought stuffed animals, just like his first backpacking trip at Henry Coe last year (
2009.08.29 Henry Coe SP 111.jpg
).
Here is the younger crew at one of the rest breaks. Jovanni, Erick, Robert, and Eliana.
This point is very close to where we turned around when we did the day hike last year. I think we stopped because we could not pass this stream that was flooded with snowmelt.
Starting to get a little bit of elevation now.
Robert and Erick went through a half-dozen walking sticks each. I think the next time my Dad visits we need to make some more permanent ones from better stock.
Here is the first picture of the wildflowers. I thought they were very impressive for this late in the season; but a couple days later when we went up Mt Tallac we were absolutely amazed by the color and the quantity of wilderflowers.
About halfway to the campsite we came across a pack train on the trail. Apparently the rangers and volunteers had a large project going to replace a worn out wooden bridge with stone. The pack train had delivered the heavier equipment needed for the job. The next day we went past the work site, and I didnt see much equipment beyond lots of rigging, crowbars, picks, and shovels
Here is a sequence of hikers as they emerge from a wooded section into one of the alpine meadows.
In the background you can see the meadow and how lush the wildflowers are.
This is Susie Lake, where we spent nights 2 and 3. This first day we continued past and upwards a bit more to Heather Lake.
On the way to Heather Lake we passed a section with two snow fields not yet melted. The kids stopped to slide around, and here is a picture of a large piece of unmelted snow just before Heather Lake.
Heather Lake. At this time in the hike, this was my favorite part of the trip. The walk along the edge of the lake was super cool, plus we we were soon to put down the 50 lb packs for a while.
Here is a sequence of hikers progressively farther away along the shore of Heather Lake. Our destination is at the top left of the last picture.
Preparing dinner the first night. We had pasta and a lb of ground beef fried with an onion and half a head of garlic. Very tasty. This pic is the onion and garlic getting fried up.
Here is Eliana giving Robert a ride.
Robert and Eliana chilling out the first evening. One sad fact of camping in the Desolation is that no campfires are allowed. Having a campfire at night would really make things nice, but I guess wood is pretty scarce up there already, and people would start killing live trees to make fires.
 The boys and I retreated to the tent (that I opted to carry, and paid for every ounce with sweat), but the rest of the party fed the little blighters all night long.
Day 2: A glorious time at Lake Aloha
The next day we headed the short distance to Lake Alohoa, something around 1 mile with not much elevation at all. We passed the area where the rangers were working on the trail and continued up along a small ridge, then turned a corner and saw this:
Amazing place, Lake Aloha. We continued around the shore for another 1/2 mile and found a nice place to go for a swim. There were two small islands less than 100 feet from the shore.
The next several images are screen grabs from a movie, and show people diving into the inviting water of Lake Aloha. I have to tell you that water is so clean and pure that as you are swimming towards the shore, and you think you are arms reach from a rock, you are really still 10 or 20 feet away. There is also no algae on the rocks, zero. It is pretty wicked cool.
Here are Robert and Joe on the 1st larger island. That expression should be found in the dictionary under "exhilaration".
The first island seemed to Erick to be too far to swim, so we decided to be the first explorers on the smaller closer island.
Then of course we had to swim from the smaller island to the larger island, which was farther than just swimming from the shore to the larger island.
Re-united with Robert on the 1st island.
Here is a panoramic view, which in no way does justice to what meets your eyes at Lake Alohoa. Click on the image to go to Picasa web albums, where you can download the full resolution experience.
After several hours of swimming and lounging and lunch (peanut butter and honey sandwiches, or "spoiled brat sandwiches" as Mom used to say), we continued on another mile or so to check out the lay of the land. The landscape is so interesting and beautiful it is kind of surreal.
And the blue of the sky!
Here is an artistic shot that I could not resist of a stunted tree growing on the shoreline. You will see it again later with some people around it.
A group picture from the extra-curricular hike.
We had another opportunity for swimming and Robert and Erick could not resist.
And here is the artistic tree with some people around it.
After the day at Aloha we returned to the campsite, packed up, and re-located back North to Susie Lake. The idea was that in the morning Joe and family would be returning out to make a date for a reunion party in South Lake Tahoe, and the boys and I would bag Mt Tallac. Susie was ideal for both of these goals because it was a mile closer to both.
Here is the guy with the 45 lb pack (call it minus 5 lbs for dinner and breakfast) headed back to Susie Lake.
Susie Lake
Susie Lake was magnificent. A lot of my favorite pictures come from this site. We had the afternoons of the 2nd and 3rd days to hang out at the great site. We had shade, some nice rocks to sit on, and even decent access to the lake for swimming, fishing, and refilling water.
This tree provided shade while cooking and also a place for Erick to scramble around.
Here is the Stefani family chilling out on the afternoon of the second day.
Happy Honeymooner Return
These guys had their honeymoon in the Desolation Wilderness 29 years ago. What a cool picture!
A couple more screen grab images follow. Here is Robert giving Jovanni a fishing lesson.
And Erick's turn on the Eliana ride.
Day 3: Mt Tallac, 9730 feet
The morning of the 3rd day the reflection of the Mountains off Susie Lake was spectacular. We had oatmeal for breakfast: "Why do we have to have oatmean again?", say the boys.
These next couple pictures give you a taste of how awesome that location was.
Right after breakfast Joe and family headed back to the cars. We shared the first mile of the route and then split up.
On the way to Mt Tallac we passed by Gilmore Lake which was pretty heavily infested by mosquitoes. I am glad we had not chosen that as our destination, or been boxed into it by the quota system.
After we passed gilmore we were working up the slopes of open alpine meadows loaded with wildflowers.
Some wildlife. I'm told this is a grouse.
More flowers on the lower slopes. We had about 2000 vertical to make, and it was really pretty easy starting from Susie Lake. If you start from the visitor center down at lake level, you get all that elevation in one trail: 3250 feet.
Sorry if you are getting tired of the flowers, but these pics just dont do justice to them. This one was taken by Erick with a cell phone, but gives a good impression of how varied the colors were.
This is the final bit of climbing, maybe 200 feet of delta Z below the summit.
That is the Crystal Mountain range in the background.
The summit, at 9730 feet.
Looking over the scree field to Fallen Leaf Lake. Our car was parked out of view at the right (south) end of the lake.
Another view of the Crystal Range, with Gilmore (larger) and Susie (smaller) Lakes. Lake Aloha is over the ridge behind Susie Lake.
I just
love
this picture!
More wildlife. Un-identified critter seen in its den on the descent.
Another picture showing the diversity of wildflowers.
Trail fork for Dick's pass. I think on our next trip we will stay at Aloha and do a day trip to Dicks Peak/Pass.
Back at Susie Lake for the rest of the afternoon. The boys tried their luck fishing. We didnt get any fish, but we managed to catch a minnow with a piece of salami and some trickery involving a cooking pot.
Preparing dinner. Supplies were getting down the bottom at this point. From a carrying the bear box standpoint, that is good news. From a hungry kid standpoint, not so much.
We had honey sandwiches for lunch, but still had parmesan cheese and a bit of salami to put on the pasta for dinner.
Here is Robert filtering some water.
A picture of the meadow the tent was pitched in.
And another artistic shot of the Lake seen through the climbing tree.
A panoramic view of Lake Susie. Again, for best experience, download the full resolution picture by clicking on the image and blow it up.
Day 4: hiking out
The final day we packed up, ate the last of the food (corn tortilla sopapillas with honey) and headed for the car. The pack felt great, like it was down to sub-40 lbs where it really belongs. Next time I'm making those kids carry more stuff.
All the way out we discussed what we were having for lunch. The consensus was cheeseburgers, and we discussed if we could live without an red onion or not.
The next five pictures are action backpacking pics.
Erick asked me to take this picture, and because I took roughly 400 he didnt really want me to, I figured I should take it.
This trip really gave me a sparkle in my eye. Here is evidentiary proof.
This is the boundary of the Desolation Wilderness, so we are almost back to the car. Erick was getting really tired, but he did fantastically well on this trip. Way to go Erick!
More wildlife, reptilian variety.
Cheeseburger
As soon as we got out around noon, we headed to the supermarket and bought a pound of free range beef, some tomato, and of course a red onion. We pulled over at the side of the road and cooked them up and man were they
tasty
. The 1/3 lb burgers were so big the kids could barely manage, but they did manage!
Wicked Awesome!
This trip was totally wickedly amazingly awesome. Go get some!
Blogger backup created by Robert Washbourne


If you do not fill this info out you will get errors later in our application
Please Fill this section out that way we know where to mail your winnings to! Thank You!
Thank You for creating an account!


Members
bitly :Bitly
Instantiate Bitly
Type:
- Bitly
- Source:
Methods
checkForThankYouTweets()
Check if any recent tweets addressed directly to the bot are instances of a user thanking the bot
For a supportive action such as tweeting, following, retweeting or generally helping
If valid 'Thank You' tweets addressed to bot are found, seek approval from TimeManager
To post a "You're Welcome" tweet in reply
- Source:
condenseTweet(tweet) → {string}
Convenience function to condense a tweet to a proper size
That will not exceed Twitter's character limit
Anticipates a bitly shortlink will be added, leaving extra space
Based on average length of shortlinks
Parameters:
| Name | Type | Description |
|---|---|---|
tweet |
string | The tweet content body to be shortened |
- Source:
Returns:
tweet - The condensed tweet content body
- Type
- string
determineRetweeters()
Check for Twitter users that have recently retweeted one of the bot's tweet
If valid not-yet-thanked retweeters are found, pass them to thanksForRetweeting method
- Source:
favorite(tweet)
Favorite the passed in tweet
Parameters:
| Name | Type | Description |
|---|---|---|
tweet |
object | The tweet to be favorited |
- Source:
follow()
Follow the user contained in the passed in tweet
- Source:
handleMentionsTimelineResponse(error, data, status)
Parses and handles response from calling mentions timeline. Examines mentions to determine if they are tweets thanking the avatar
Parameters:
| Name | Type | Description |
|---|---|---|
error |
Error | Error calling the mentions REST endpoint |
data |
Object | The response object coming back from Twitter REST API |
status |
Object | REST status object |
- Source:
hashtagifyTweet(tweet) → {string}
Adds dynamic hashtag to tweet text where appropriate
Designed to increase appearance of organic behavior
And increase reach of bot's tweets into new app.get('channel')s
Not specified in settings, but usually still appropriate
To the realm of subject matter the bot is targeting
Parameters:
| Name | Type | Description |
|---|---|---|
tweet |
string | The tweet content body to be 'hashtagified' |
- Source:
Returns:
tweet - The tweet content body with dynamic hashtag added
- Type
- string
init(settings)
Setup database connection
Register event listeners
Parameters:
| Name | Type | Description |
|---|---|---|
settings |
object | Settings object derived from config.json |
app.get('channel') |
object | Main EventEmitter app.get('channel') shared by modules for PubSub |
- Source:
instantiateTwitterREST()
Opens streaming connection to Twitter and saves a handle to the stream object in app namespace
Registers stream event listeners, attaching tweet approval functions to incoming tweets deemed appropriate
- Source:
markAdvertised(id)
Mark the advertisement item record specified by the supplied id as 'tweeted'
Parameters:
| Name | Type | Description |
|---|---|---|
id |
number | The native Mongo ID of the record to be marked as tweeted |
- Source:
markTweeted(id)
Mark the the content record specified by the supplied id as 'tweeted' in Mongo
Prevents duplicate posting of a single item of content
Parameters:
| Name | Type | Description |
|---|---|---|
id |
number | The native Mongo ID of the record to be marked as tweeted |
- Source:
postAdvertisingTweet()
Post an Amazon Associates item-based tweet with affiliate link
Retrieves an untweeted Amazon item from the advertisement collection
Formats and posts tweet
- Source:
postContentRichTweet()
Build and post a content rich tweet based off an article stored in the database
- Source:
postPublicTweet(status_text)
Post the passed in status text to Twitter as a public tweet
Parameters:
| Name | Type | Description |
|---|---|---|
status_text |
string | The content body of the tweet to be posted |
- Source:
prune()
Gathers up all bot followers and all Twitter accounts that bot is following
Selects one account that bot is following who is not following bot back
Destroys the friendship (unfollows) this user
Designed to assist in maintaining positive 'social proof':
The bot is being followed by more people than it is following
Over time, keeps the bot's follower to following ratio looking healthy
- Source:
randomHashtag() → {string}
Convenience function that returns a random hashtag
From the bot's specified target hashtags
Maps to config.json's twitter.tracking_name field
- Source:
Returns:
hashtag - A randomly selected hashtag
- Type
- string
retweet(tweet)
Retweet the passed in tweet
Parameters:
| Name | Type | Description |
|---|---|---|
tweet |
object | The tweet to be retweeted |
- Source:
shortenTweet(tweet, link)
Takes intended tweet body content and a long url
Shortens the url with bitly and adds shortlink to content
Posts tweet body with shortlink to Twitter as a public tweet
Parameters:
| Name | Type | Description |
|---|---|---|
tweet |
string | The intended tweet body content |
link |
string | The url to be Bitly-fied into a shortlink |
- Source:
thanksForRetweeting(retweeters_to_thank)
Gather up usernames that have recently retweeted the bot
Build a group 'Thank You' tweet that includes users who have not already been thanked
Append valid users to thank you tweet up to the character limit
Parameters:
| Name | Type | Description |
|---|---|---|
retweeters_to_thank |
array | Array containing retweet objects which themselves contain users who should be thanked |
- Source:
thankYouTweet(tweet)
Post a 'Thank You' tweet, thanking user who authored passed in tweet
Parameters:
| Name | Type | Description |
|---|---|---|
tweet |
object | The tweet containing the user to be thanked |
- Source:
updateWelcomedUsers(tweet)
Update the collection of users that have already received "You're Welcome" tweets
Parameters:
| Name | Type | Description |
|---|---|---|
tweet |
object | The tweet containing a user who received a "You're Welcome" tweet |
- Source:
youreWelcomeTweet(tweet)
Build a "You're Welcome" tweet and post it, referencing the user in the passed in tweet
Parameters:
| Name | Type | Description |
|---|---|---|
tweet |
object | The tweet containing the user who should receive a "You're Welcome " tweet |
- Source:


| Project Date -- 2018
| Skills Used -- machine learning | R | spatial analysis | statistics | data exploration | data visualisation |
| Full Report / Paper -- Click here
| Repository -- https://github.com/liviajakob/self-organising-maps/
Project Overview | Self-Organising Maps
This project applies the Self-Organising Maps (SOM) machine learning technique to Scottish deprivation data from Edinburgh. SOMs offer insights that can't be explored or displayed with the linear deprivation indices. I used the kohonen package within the software RStudio. Code can be found in my GitHub repository.
I think the data exploration etchnique SOMs is a very powerful technique to analyse spatial data, especially when the data is multi-dimensional.
Read more about Self-organising maps for spatial data in my blog post.
What are SOMs?
Self-Organising Maps (SOMs) are a type of unsupervised Artificial Neural Networks (ANNs). They were developed by Teuvo Kohonen (1982) and are mostly used for clustering, visualisation and data exploration. SOMs reduce n-dimensional data and display it on the two-dimensional map where similar data is placed into the same grid cells.
Training and Clustering
The study uses the 2016 SIMD dataset containing 26 deprivation variables (excluding absolute measures), an overall rank and rankings over each of the 7 domains (ncome, employment, education, health, access to services, crime and housing). To closely monitor deprivation patterns, the study area was reduced to the 597 data zones in Edinburgh. The 26 variables were summed up within each of the themes and the SOM was then trained with seven variables representing the seven themes. After the SOM training seven clusters were created using the hierachical clustering method.
Results
This section will show brief results of the study. For more information read the report.
The component planes show the distribution of each variable in the SOM. Red values indicate high disadvantage, whilst blue values represent low disadvantaged. The planes further show visually that income, health, employment and education are correlated. The numbers represent the seven clusters.
By means of component planes analysis and display of the results on a geographic map, the clusters were characterised to facilitate the interpretation. Note that the cluster descriptions are not purely based on sci- entific knowledge, moreover they aim to tell a narrative backed by common knowledge about the city.
Characteristics of the seven clusters. The node background colours represent the seven clusters. The codes show the seven variable properties for each neuron, with larger symbols indicating higher disadvantage. They are dis- played to visualise similarity and differences between adjacent neurons.
Cluster Charactersitics
-
Cluster 1 (7%) | The Precariats -- The Precariats is a cluster defined by very high disadvantage within the income and employment domain, low education and health issues, whilst access, crime and housing do not seem to be a major issue. The Pre- cariats are the poorest and most deprived cluster.
-
Cluster 2 (23%) | Rough Edinburgh -- The inhabitants of Rough Edinburgh share similarities with The Precariats but are less vulnerable. How- ever, they still score very low within the domains income, employment, education and health. Typical “Rough Edinburgh” districts are areas with social housing such as Dumbiedykes.
-
Cluster 3 (13%) | The Wealthy Commuters -- The Wealthy Commuters are the cluster most disadvantaged by access – but by choice. Apart from the ac- cess domain they show very low disadvantage amongst all the themes. They typically live on the outskirts or in suburban areas where they are house owners and commute to work every day.
-
Cluster 4 (41%) | The Waitrose Shoppers (Edinburgh Posh) -- This cluster is defined by a uniformly low disadvantage across the seven themes. Typical middle class families and professionals with high income and education living in urban and suburban areas belong to this cluster. Areas such as Marchmont and Stockbridge are typical for this cluster.
-
Cluster 5 (3%) | The Urban Intermediates -- This cluster is defined by excellent access and intermediate characteristics amongst the domains income, employment, health and education. It is noticeable that there is a relatively high crime rate and rather low housing conditions.
-
Cluster 6 (1%) | The Crime Triangle (Edinburgh Nightlife) -- The Crime Triangle is defined by very high crime and bad housing. It represents only a very small area in the city centre nearby Princess Street. Data zones within this cluster are not a typical living area but rather an area where people congregate and where young people enjoy the nightlife, which explains the high propor- tions of crime rates per inhabitants.
-
Cluster 7 (12%) | The Hotchpotch -- The Hotchpotch is characterised by very bad housing and excellent access. It encompasses areas in the city centre with a high proportion of students and presumably flat shares, but also more ethnic areas near to the city centre.
Sources
Kohonen, T. 1982. Self-organized formation of topologically correct feature maps. Biological Cyber- netics, 43, 59-69, 10.1007/BF00337288.
Kohonen, T. 2001. Self-Organizing Maps. 3rd ed. Berlin Heidelberg: Springer-Verlag Available at: www.springer.com/gb/book/9783540679219 (Accessed March 29, 2018).
Skupin, A. & Agarwal, P. 2008. Introduction: What is a Self-Organizing Map? In Agarwal, P. & Skupin, A., eds. Self-Organising Maps. Chichester, UK: John Wiley & Sons, Ltd, 1–20., 10.1002/9780470021699.ch1.


{% extends "macros.html"%} {% block content%}
This is an interactive web apllication that facilitate the creation and sharing of information, ideas, career interests, and other forms of blog posts ideas via virtual communities of users


New
User
Email
Is Active
{{user.displayName}}
{{user.name}}
{{user.email}}
There are no users yet. You may want to create the very first one.


[viewBag]
==
{{ result.title | raw }}
{% if __SELF__.showProviderBadge %}
{{ result.provider }}
{% endif %}
{# Some results contain meta information. #}
{# You can access it using result.meta. #}
{# To find out from which plugin the result #}
{# was returned you can use result.identifier #}
{# Some results contain the original model. #}
{# You can access it using result.model #}
{{ result.excerpt | raw }}


Ryu Hoshi (リュウ Ryū)
Résumé
—I do not compete with others , the only competition that challenges me is myself. As a fighter, friend and an employee I am known as contemplative, tortured and driven.
Experience
Now
-
1st January 2019 – present
Fighter at Capcom USA
Back then
-
2018
Amongst many fighters of the past was featured in the movie "Ready Player One" . Ryu ready always!
-
2017
United with unknown until then to me Power Rangers to defeat resurrected M.Bison.Damn good fighters they are, even not knowing karate ways!
-
2016
In "Street Fighter V" once and for all erased M.Bison from earth and tamed my inner Evil Ryu. Also spent some time on a side-project, mini-series "Street Fighter: Resurrection" .
-
2014
Filmed in a martial arts tutorial "Street Fighter: Assassin's Fist" revealing to audience forgotten art of Ansatsuken.
-
2012
The gods of internet concluded me in the animated movie "Wreck-It Ralph" , but rewarded me with a good drink for it!
-
2008
My evil alter ego sneaked out of control and became a boss in "Street Fighter IV" .
-
2006
Borrowed my famous ripped gi to Soki in "Onimusha: Dawn of Dreams" , gods informed me he needed that for the battle.
-
1998
Difficult period
- defeated M. Bison in "Street Fighter Alpha 2" , bastard wanted to use my heroic body for his evil intentions, but retreated with shame.
- also this year I encountered Marvel universe in "Marvel vs. Capcom: Clash of Super Heroes" fighter,loyal to my employer, Capcom, of course.
-
1997
Reunited with Ken, my friend and opponent in "Street Fighter III" . Men's friendship works mysteriously. Also helped with Arika project "Street Fighter EX"
-
1996
-
- took care of villainous Akuma in "Street Fighter Alpha 2"
- as a freelance on "Super Puzzle Fighter II Turbo" tried myself in a new genre, puzzle games. Let the wrath of seven heavens come upon these malicious enigmas, never again!
-
-
1995
Kept fighting in "Street Fighter Alpha: Warriors' Dreams" .
-
1994
Screened in a movie "Street Fighter" , so that the batllesof past would not be forgotten by millenial generation.
-
1991
Was promoted to "Street Fighter II" . Didn't stay there for long, celebrations and office dwelling is not for me!
-
1987
Started working for Capcom project "Street Fighter" . My partner was Ken Masters, the boss'name was Sagat.
Languages
Skills
Achievements
- #1 in "Top 25 Street Fighter Characters" by IGN, who also called me "fancy", "icon" and "a testament to the virtue of simplicity" ❤
- #2 in "Top 20 Street Fighter Characters of All Time" by GameDaily, same council found me worth of #6 place in "Top 25 Capcom Characters of All Time", which I proudly share with my partner Ken
- I was named "5th Most Powerful Street Fighter Character" by Screen Rant-san
- #71 in "Top 100 Heroes of All Time" by UGO Networks, also recognized #2 in their list of "Top 50 Street Fighter Characters"
- In a survey of 4000 online matches for Super Street Fighter IV, I got to be the most popular character, with 16.6% of players choosing my side
Character
Life lesson
Likes😃
Dislikes😞
Wants🥺
Life & education
Publications
- 2011 The true and humble story of me under pseudonim Tyler Wilde in an article"The evolution of Ken and Ryu"
- 2003-2018 For 15 years I have published comic books with Udon Entertainment depicting my adventures, bitter lessons and great victories.