auto conversion would be nice. for example, you should be able to tag a value as a "log return" and then print it in the form of "arithmetic return". note that this transformation is nonlinear, so "log return" is a "unit", adding one type of unit = multiplying another type.
and the units should themselves be sets or tuples of attribute tags, so that you can have "log inches" and write the code for "log<-->1" conversions and "inch<-->foot" conversions and then autoconverst "log inches<-->feet"
want a standard convention to pass keyword dicts of 'extra' information UP the call chain, info that will not be understood and will be ignored by most passers
multiappend
the Cycle library i wrote should be trivial in Oot, even though it's more list-oriented than graph-oriented
some neat python flow control: break continue next else(else can be applied to loops)
" The break statement, like in C, breaks out of the smallest enclosing for or while loop.
The continue statement, also borrowed from C, continues with the next iteration of the loop.
Loop statements may have an else clause; it is executed when the loop terminates through exhaustion of the list (with for) or when the condition becomes false (with while), but not when the loop is terminated by a break statement. This is exemplified by the following loop, which searches for prime numbers: "
neat syntax for sending messages:
limitTicks.append = findEdgeDispersionWithMinimumReturn(cycle, self._b, edgeIdx)
that is, just reuse the single graph edge traversal/__setitem__ syntax
---
i just fixed an annoying bug of the form:
def handleMessage(self, key, newValues):
blah = sum([self.storage[key].get('quantity',0) for key in self.openOrders[name]['keys']])
...
self.storage[key] = newValuesdo you see it? 'key' is being bound in the for loop in the 'blah' line, so the values will be stored in the wrong key
--- this common pattern should be supported cleanly:
somehash.get(somehashkey, []).append(some_item_to_go_into_the_list_associated_with_that_hash_key)
(perhaps just use defaultdict?)
or even: thelist = somehash.get(somehashkey, []) thelist.append(some_item_to_go_into_the_list_associated_with_that_hash_key) somehash[somehashkey] = thelist
to notify the dict-like object that something has changed (in case its a persistent store, for example)
also this pattern:
if somekey in somedict: do_something_using somedict[somekey]
mb this can be subsumed into a python-like "with"?
list comprehension conditions should short-circutly evaluate and short-circut the evaluation of the main body (i think python does this)
docstrings are awesome
ipython's '?' is awesome
generator comprehensions
too bad you can't mix numpy arrays and comprehensions
just as the columns in a dataframe can be referred to by name or by an integer index, oot edges can have multiple labels, each of which lives in a different universe
python's for..else
---
why not let Python's default keyword argument syntax be used in expressions, too?
---
topic maps
http://www.ontopia.net/topicmaps/materials/tao.html
" Each topic that participates in an association plays a role in that association called the association role. In the case of the relationship “Puccini was born in Lucca”, expressed by the association between Puccini and Lucca, those roles might be “person” and “place”; for “Tosca was composed by Puccini” they might be “opera” and “composer”. It will come as no surprise now to learn that association roles can also be typed and that the type of an association role is also a topic!
Unlike relations in mathematics, associations are inherently multidirectional. In topic maps it doesn't make sense to say that A is related to B but that B isn't related to A: If A is related to B, then B must, by definition, be related to A. Given this fact, the notion of association roles assumes even greater importance. It is not enough to know that Puccini and Verdi participate in an “influenced-by” association; we need to know who was influenced by whom, i.e. who played the role of “influencer” and who played the role of “influencee”.
This is another way of warning against believing that the names assigned to association types (such as “was influenced by”) imply any kind of directionality. They do not! This particular association type could equally well (under the appropriate circumstances) be characterized by the name “influenced” (as in “Verdi influenced Puccini”). (See section 3.4.3. for an example (involving Tosca and Rome) of how the scope feature might be used to make this happen in practice.) "
" Secondly, associations are completely different in structure from RDF statements. They have roles representing the involvement of each topic in the association, and they go both ways. That is, in topic maps saying that I am employed by Ontopia is the same statement as saying Ontopia employs me. This means that the issue of whether to make my employment a property of Ontopia or of me is a non-issue in topic maps; it will always be both. "
" To summarize, a statement in RDF can be a name, an occurrence, or an association in topic maps. Names compare easily to RDF: they are RDF statements where the object is a literal and where the property has name semantics. The remaining RDF statements where the object is a literal are occurrences. However, RDF statements where the object is another resource are either occurrences or associations, depending on the semantics of the statement. If they are associations role types must be supplied. In addition to this comes the cases where in a topic map the association has more than two roles, in which case an intermediate RDF resource must be created. "
" In RDF there are three kinds of nodes:
literals (which we have already discussed).
URI nodes. A URI is just a node that has a URI label on it, where the URI identifies the resource represented by the node. Since the URI directly identifies the resource represented by a node, RDF assumes that nodes with the same URI represent the same resource.
blank nodes. These nodes are called blank, as they have no URI label. (Two examples can be seen in the RDF diagram example in section 2.2..) For blank nodes the only way to discover which resource they represent is to look at the statements made about them. RDF itself provides no standardized way to identify which blank nodes represent the same resources, although higher-level vocabularies like OWL do. (More about this in section 4.1.2..)"
" Let's say we use the URI http://www.ontopia.net/ to identify a thing. Now, what does this actually identify? The information resource we get by resolving the URI? Or the thing described by that information resource? In practice, one finds that URIs are being used in both ways.
Topic maps distinguish these two cases, so that when assigning a URI to a topic as an identifier, the URI can be considered to be a subject address or a subject identifier. In the first case, the subject identified is the resource. In the second case it is whatever is described by the resource. In RDF, however, this distinction does not exist, and given a URI node there is no way to tell a priori which of the two ways the URI should be interpreted.
This is actually quite a thorny problem for interoperability between topic maps and RDF, and is also indicative of differences in the thinking behind the two. RDF practitioners would say that RDF models consist of statements and resources, ignoring the fact that the resources are not really part of the RDF model, but are represented by RDF nodes. In RDF, the distinction between the RDF model and the world it represents is not given much emphasis, whereas in topic maps this distinction premeates the whole model. "
also reification and levels; topic maps are for making a back-of-the-book index of hypertext, and talk about "occurences" of the topic in the referenced hypertext; this should be generalized into a single data model
in fact, should have a separate document for properties of the graph data model:
nLSD RDF OWL RDF Schema
chu spaces
some predefined relations (see also OWL): name inverse type isa subclass (implies?)
these can all have a qualifier 'typically' or 'logically', with 'typically' being the default
XDI
topic maps unify provenance and qualification as 'scope':
" Qualification
Sometimes one wishes to qualify assertions made about things in order to record which authority claims they are true, what the source of the assertion is, or in what context the assertion is true.
In topic maps there is a built-in feature for this: scope. When an assertion is made in a topic map (in the form of a name, an occurrence, or an association) a scope is always attached to it. The default scope is the unconstrained scope, which means that there is no known limit to the validity of the assertion. Topics can be added to the scope to restrict under what circumstances it is considered to be true. Some examples are shown below.
Topic maps are called "topic maps" in English, but in Norwegian they are called "emnekart". This is best represented by creating a single topic with two names, one in the scope English, and one in the scope Norwegian.
There is a topic map with topics for each officially identified issue with the topic map standard, and these have occurrences of type "opinion", which gives an opinion about the issue. Each opinion is scoped with a topic representing the person who held the opinion.
There is a group of people who believe that Francis Bacon wrote Shakespeare's plays, and this might be represented by adding extra authorship associations between the plays and Francis Bacon, and scoping it with a topic representing this group of people.
In RDF there is no built-in feature for this, except that literals may have a language identifier attached to them, which is a kind of qualification. (A language identifier is a string conforming to RFC 3066[RFC 3066], such as en-uk or pt-br.) However, it is possible to achieve this through reification, since this turns the statement into a node about which statements (including qualifying ones) may be made. On the other hand, reification in RDF is, as we noted above, rather awkward in practical use.
Again it should be added that not having direct support for this makes RDF more light-weight, but this is a feature that is quite often needed, especially for internationalization, but also for tracking the sources of assertions. It should be added that although RDF itself does not support this, support for it can be built into individual applications by creating extra resources for assertions.
The key problem here is that statements in RDF have no identity, which means that it is impossible to make resources that represent them (without changing the statements) and since the model does not directly support qualification support for qualification cannot be added through reification. This is one of the most fundamental differences between topic maps and RDF, and one that has so far frustrated all attempts to model topic maps in RDF in a natural way. "
---
" 8. Addressable and non-addressable subjects
The subject of every assertion (or statement) in an RDF model is a resource, identified by a URI. The subject of every assertion in a topic map is a topic, representing a subject, which may be addressable or non-addressable. Addressable subjects are identified by their URIs (as in RDF); non-addressable subjects are identified by the URIs of (one or more) subject indicators. This important distinction is not present in RDF. "
" /* topic types */
[person = "PERSON" @"http://taoriver.net/nLSD/person/"] [parent ; person = "Parent"] [child ; person = "Child"] [childOf : Hidden = "is child of"] /* template provides visualization direction */ childOf([child] : From, [parent] : To ) / Template [sakura : child = "Sakura Kimbro-Juliao" ] childOf(sakura : child, [kitty : parent = "Amber Straub" ] : parent ) childOf(sakura : child, [lion : parent = "Lion Kimbro"] : parent )"
the open annotation spec ( http://www.openannotation.org/ ) has three parts to every annotation (three RDF nodes), the annotation itself, the annotation body. Optionally, the target node itself points to two nodes, the actual target, and another (potentially freeform) node which defines the part of the target which is being addressed.
--- should study this language to learn to be faster:
Topic: Julia: A Fast Dynamic Language For Technical Computing
Speaker: Jeff Bezanson MIT
About the talk:
Julia is a general-purpose, high-level, dynamic language, designed from the start to take advantage of techniques for executing dynamic languages at statically-compiled language speeds. As a result the language has a more powerful type system, and generally provides better type information to the compiler.
Julia is especially good at running MATLAB and R-style programs. Given its level of performance, we envision a new era of technical computing where libraries can be developed in a high-level language instead of C or FORTRAN. We have also experimented with cloud API integration, and begun to develop a web-based, language-neutral platform for visualization and collaboration. The ultimate goal is to make cloud-based supercomputing as easy and accessible as Google Docs.
let's say you had personalized (perspectivized) reputation graphs -- each perspective is essentially a function that maps each node (or some subsets of nodes) to a floating point number (or, 'labels each node with a floating point number')? would oot express this as a "graph overlay"? or another graph that could be 'merged in'? or a function? or all three, with conversion operators?
also, category theory diagrams (maps on the nodes AND edges)
inversed, uniques/injective&surjective as a core feature:
No programming language to date (except possibly haskell) understands whether one function is intended to be the inverse of another, whether items in a list are unique, etc. This would allow clean syntax for things like inverse (^-1 even, or just ^-) and some amount of automated reasoning and type inference.
Colored exceptions nonlocal returns
SPEcify by postconditions, Oot finds a matching library function Or equiv codecoin Oot tries to deduce formal postconditionss
python multiprocessing module
optional output args
datomic data model:
"datom": entity/attribute/value/transaction
(like RDF: subject/attribute/value + scope, except scope is just time)
transactions (time) are totally ordered and are first-class
can get the db as-of, or since or between, any transaction (transactions)
immutable
not good for write-heavy workloads, as everything must go thru the transactor
use simple graph mutation constructs in place of special case for 'before' and 'after' hooks, other AOP stuff <--- CRUCIAL
since this is a homeoiconic language of graphs, type system should mb be a graph constraint language? of course this is (iso?)morphic to logic..
category theory reifies paths
some issues topic maps introduced me to:
reification hypergraphs (needed to cleanly do more than binary relations, also negates the need to use inverse relations so much, e.g. a trinary relation between child, mother, father) distinction between pointing to the hypertext document that can be retrieved at a URI vs. pointing to the concept signified by an URI scope
came up in OAF convo:
justification stance (agree/disagree, mb also the edge labels in argument maps) provenance scope constrained target
further notes of mine:
scope temporal scope vector-clock like temporal scope, e.g. time as a partial order
notion of reference further empowered by constrained target (like empowering it to represent distinction b/t URI and concept signified by URI) constrained target as "add on"; should be able to swap out any part of standard (e.g. target) for "see this node for something that fulfills the semantic role of this, but uses a format not defined in this standard" (in this case, we use an alternative trick which might be even better; the target IS the the constrainedTarget node, which has a way of specifying a new way of finding a target)
constrained target is a way of INTRODUCING a new URI that allows us to talk about the constrained target
from Rob's PDF, a Semantic Tag subclass of Annotation: oac:Reference Target is a reference or citation to the tag resource oac:Description Target is a description or depiction of the tag resource oac:Classification Target is an instance of the tag resource oac:Quality Target has the tag resource as a quality oac:Membership Target is a member of the set identified by the tag resource oac:Relationship Target has a relationship [expressed or not] with the tag resourc
note that hypothes.is style annotations are none of these
"distinction between pointing to the hypertext document that can be retrieved at a URI vs. pointing to the concept signified by an URI"
mb use C-like syntax throughout, letting * and & travel from signifier to signified and vice versa (e.g. travel down a 'meta' edge as contrasted with just traveling down a normal edge -- or should these be the same, with the edge type differentiating?)?
e.g.
bob = 3 print bob
is like
global.'bob'.set(3) print *bob
also seems related to boxing and unboxing... perhaps we have our long-sought general "step down a level/step up a level" concept taking shape? but levels are just special types of edges, are they not? * and & allow a generic language of graph motions that can then be specialized by choosing the special edge type
oot graph motions, oot graph mutations (note how immutable should we be?)
a real-time garbage collector for java:
http://www.ibm.com/developerworks/java/library/j-rtj4/
notes on restrictions:
" Most roots are malleable to some degree during execution in terms of their object references. For this reason, changes to their reference set must be tracked, as we discussed in Write barriers. However, certain structures, such as the stack, can't afford the tracking of pushes and pops without significant penalties incurred on performance. Because of this, certain limitations and changes to scanning stacks are made for Metronome in keeping with the Yuasa-style barrier:
Atomic scanning of stacks. Individual thread stacks must be scanned atomically, or within a single quantum. The reason for this is that during execution, a thread can pop any number of references from its stack -- references that could have been stored elsewhere during execution. Pausing at mid-scan of a stack could cause stores to be lost track of or missed during two partial scans, creating a dangling pointer within the heap. Application developers should be aware that stacks are scanned atomically and should avoid using very deep stacks in their RT applications.
Fuzzy barrier. Although a stack must be scanned atomically, it would be difficult to keep determinism if all stacks were scanned during a single quantum. The GC and JVM are allowed to interleave execution while scanning Java stacks. This could result in objects being moved from one thread to another through a series of loads and stores. To avoid losing references to objects, threads that have not been scanned yet during a GC have the barrier track both the overwritten value and the value being stored. Tracking the stored object, should it be stored into an already processed object and popped off the stack, preserves reachability through the write barrier.
...
Issues to consider when using Metronome
Metronome strives to deliver short deterministic pauses for GC, but some situations arise both in application code and the underlying platform that can perturb these results, sometimes leading to pause-time outliers. Changes in GC behavior from what would be expected with a standard JDK collector can also occur.
The RTSJ states that GC doesn't process immortal memory. Because classes live in immortal memory, they are not subject to GC and therefore can't be unloaded. Applications expecting to use a large number of classes need to adjust immortal space appropriately, and applications that require class unloading need to make adjustments to their programming model within WebSphere? Real Time.
GC work in Metronome is time based, and any change to the hardware clock could cause hard-to-diagnose problems. An example is synchronizing the system time to a Network Time Protocol (NTP) server and then synchronizing the hardware clock to the system time. This would appear as a sudden jump in time to the GC and could cause a failure in maintaining the utilization target or possibly cause out-of-memory errors.
Running multiple JVMs on a single machine can introduce interference across the JVMs, skewing the utilization figures. The alarm thread, being a high-priority RT thread, preempts any other lower-priority thread, and the GC thread also runs at an RT priority. If sufficient GC and alarm threads are active at any time, a JVM without an active GC cycle might have its application threads preempted by another JVM's GC and alarm threads while time is actually taxed to the application because the GC for that VM is inactive.
i guess Haskell's association/binding/precedence rules make sense, except for custom precedence: left-associative, functions bind tight
should we allow infix or not?
stuff on how to write a programming language (for the jvm, or in general):
http://createyourproglang.com/
http://stackoverflow.com/questions/716613/how-to-make-a-net-or-jvm-language
http://stackoverflow.com/questions/3380498/create-a-jvm-programming-language
http://londongeeknights.wetpaint.com/page/Creating+a+language+on+the+JVM
http://www.java-forums.org/advanced-java/29920-creating-new-jvm-language.html
http://londongeeknights.wetpaint.com/page/Creating+a+language+on+the+JVM todo: http://skillsmatter.com/podcast/java-jee/language-on-jvm
some jvm bytecode tools: asm jamaica jasmin
on the beauty of having non-class-related functions in Python:
"
petercooper 21 hours ago
| link |
I notice no mentions of Ruby yet, and I wonder if this discussion is pretty much impossible to have in the Ruby world, given Ruby is solely an object oriented language, even if you try to use it procedurally. Not writing classes would be against so many Ruby conventions and accepted style that it's a non-topic?
Or is it that classes in Python specifically aren't that much of a win over the language's implementation of other paradigms? I sure haven't hit into any problems using classes or objects in Ruby, even when sometimes the use feels a little contrived to begin with, but.. I also have no choice :-) (maybe Rubyists have a Stockholm Syndrome with OO ;-))
reply
ryanf 21 hours ago
| link |
I think part of the reason this doesn't come up in Ruby is that Ruby doesn't have Python's powerful namespacing system.
In Python, it's reasonable to have a package with just functions in it, whereas in Ruby, writing a top-level method means polluting every object in the system. You can write modules that have singleton methods on them, but you still don't have anything as flexible as Python's "from pkg import foo, bar"—the caller needs to either write "ModuleName?.my_function" at every call site, or use "include" and end up with the module's methods as part of the consuming class's interface.
reply
judofyr 21 hours ago
| link |
Implicit self and late binding in Ruby makes it hard to implement a proper namespacing system without breaking other semantics :(
After working with Perl (which has a similar namespacing), I must it's something I really miss when I come back to Ruby.
reply "
gg_ 7 hours ago
| link |
I believe he is referring to this talk: http://tele-task.de/archive/video/flash/14029/
reply
gruseom 2 hours ago
| link |
Yes thanks - and if anyone watches it, be sure also to check out the stuff on Bob Barton that we posted to HN. I learned about a magnificent part of computing history thanks to that talk.
Edit: here you go:
http://news.ycombinator.com/item?id=2855500
http://news.ycombinator.com/item?id=2928672
http://news.ycombinator.com/item?id=2856567
http://news.ycombinator.com/item?id=2855508
The first two are teaser comments. The second two are the important pieces. Also the paper Kay praises at the start of the talk is short and very worth reading.
"
daviddaviddavid 18 hours ago
| link |
I dislike classes but I like bundling data along with methods which operate on that data. I often find that JavaScript?'s classless objects are a great solution. It's just so natural to be able to create an object with object literal syntax without first creating an ad hoc class and then instantiating it:
var o = {
name: 'David',
greet: function () {
console.log('Hi, I am ' + this.name);
}
};reply
jmaygarden 15 hours ago
| link |
Wouldn't this be better?
function greet(name) {
console.log('Hi, I am ' + name);
} var o = function() { greet('David'); };reply
njharman 16 hours ago
| link |
> bundling data along with methods which operate on that data
What can you possibly believe a class is other than exactly that?
reply
daviddaviddavid 4 hours ago
| link |
I realize that is one thing that classes offer. My point is that you can achieve exactly the same thing with objects rather than classes.
Very often when writing Python (or whatever) you'll create a class which is only ever instantiated once and the instantiation is done simply for the benefit of calling one method.
In such cases I find classes to be overkill. What I really want is the object. I don't need to factor the object's behavior out into a class.
Many of my sympathies are expressed much more thoroughly and eloquently in the many papers you can find online by Walter Smith outlining the motivations behind NewtonScript?.
reply
haldean 15 hours ago
| link |
Polymorphism and type hierarchies.
reply "
Python protocols reference: http://www.rafekettler.com/magicmethods.html
https://github.com/RafeKettler/magicmethods
---
in Python if D3_norm_to_D is a list and you mean to do
for (i, gene) in enumerate(D3_norm_to_D):
but you actually do
for (i, gene) in D3_norm_to_D:
you'll get
TypeError?