External Content not shown. Further Information.
Popular Culture:
Nerd Culture:
Science, Software, Hardware:
Zeroth World:
Comics/Images/Audios/Videos:
Quotes:
(Sorry, this one is a German pun. Does not work in English.)
External Content not shown. Further Information.
And again no comic :/
Popular Culture:
Nerd Culture:
Science, Software, Hardware:
Zeroth World:
Comics/Images/Audios/Videos:
Quotes:
External Content not shown. Further Information.
Liebe Anbieter des mobilen Zwischennetzes. Ihr habt das Netz wunderbar mit LTE ausgebaut. Wohl nicht unerheblich mit Steuergeldern, dennoch honoriere ich das sehr, denn das Internet ist ein wichtiger kultureller Faktor geworden, und jeder sollte Zugriff darauf haben.
Aber: Ihr alle drosselt. Eine Drosselung nach 10 Gigabyte mag ok klingen, doch ich als Mensch der oft pendelt würde ich zum Beispiel gerne in Remote-Desktop-Sessions arbeiten, ohne danach auf das Trafficniveau meines Geburtsjahres gedrosselt zu werden. Nun ist es ja so, dass in den meisten Verträgen steht, dass die Verfügbarkeit von Hochgeschwindigkeitsinternet keineswegs gesichert ist. Technische Gründe, sowie lokale Überlastungen, können immer entstehen, die Verfügbarkeit des Notrufs muss sichergestellt werden, und sicherlich lohnt sich Ihr Geschäft nicht ohne Overcommitting. Dafür habe ich (eigentlich kein, aber ich will mal nicht so sein) Verständnis.
Ich kann mir allerdings nicht vorstellen, dass der Traffichunger in Zukunft abnehmen wird. Was ich mir dementsprechend wünschen würde, wäre ein Tarif nach Vorrang-Modell: Für eine bestimmte Datenmenge (10GB scheinen momentan der Standard zu sein) hat man Vorrang, wie bisher auch, und erhält im Rahmen der technischen Möglichkeiten die hohen Geschwindigkeiten. Danach kann man, wie jetzt ebenfalls, gedrosselt werden (aber vielleicht nicht gleich auf 32k, wenn das möglich wäre, sondern auf irgendwas, mit dem zumindest einfache Dinge noch funktionieren – aber das nur am Rande). Allerdings wird man nur soweit gedrosselt, wie es notwendig ist, um den Kunden mit Vorrang ihr schnelleres Internet zu ermöglichen. Sollte sich also Beispielsweise in einer Funkzelle nur eine Person befinden, so bekommt diese die volle Geschwindigkeit trotz Trafficverbrauch. Nun bin ich technisch nicht hinreichend informiert um sagen zu können, ob dies wirklich ins Gewicht fällt, aber ich würde einfach mal ins Blaue vermuten, dass gewisse ungenutzte Reserven vorhanden sind. Ich persönlich wäre durchaus bereit, einen gewissen realistischen Aufpreis für so einen Service zu zahlen, und ich bin sicher, dass es einen Markt dafür gäbe. Das Fehlen echter Flatrates im mobilen Bereich ist für mich ein großes Manko.
External Content not shown. Further Information.
So much work. No comic. Sry.
Popular Culture:
Nerd Culture:
Science, Software, Hardware:
Zeroth World:
Comics/Images/Audios/Videos:
Quotes:
External Content not shown. Further Information.
Popular Culture:
Nerd Culture:
Science, Software, Hardware:
Zeroth World: - German gadget clamps down on Nutella thieves ~ Deutschland! Fick ja!
Comics/Images/Audios/Videos:
Quotes:
External Content not shown. Further Information.
Sorry, too much work, again no comic this week.
Popular Culture:
Nerd Culture:
Science, Software, Hardware:
Zeroth World:
Comics/Images/Audios/Videos:
Quotes:
Using state monads works well with Haskell, but as soon as you try to actually verify your software, it gets a lot harder. I am a fan of uniqueness types – they fit well into the framework of MLTT, and can be statically checked. Idris has experimental support. However, it can be undesirable to have purely syntactical extensions that lie outside of the scope of the type system. Extending the type system is possible but not the method of choice – in my opinion, the type system should be as simple as possible.
DiffArrays follow a different pattern: They are destructively modified in the backend, but their interface is referentially transparent: Old versions of the destructively modified array can be recreated. In theory, the overhead is limited to changing an old reference, as long as the array is used in a linear fashion. Native Coq uses them. Their definition is:
type 'a t = ('a kind) ref
and 'a kind =
| Array of 'a array
| Updated of int * 'a * 'a t
That is, a diffarray is a (mutable) reference to an object that is either an array, or a key-value-diffarray-triple. Changing the value of an index in a diffarray "feels" like creating a modified copy of it. As soon as an old version of the array is modified, the array is copied; in this case, the algorithm will be slow.
There is a canonical equivalence relation between two diffarrays, namely the one that relates diffarrays which map the same key-value-pairs. As long as we are only using the interface for creating modified pseudo-copies of an array and reading its elements, there is no way to distinguish between arrays that are equal modulo this relation. If we forget for a moment that every diffarray is a mutable reference that points to an array or another such reference, we get the following algebraic definition of diffarrays:
Looking up the nth element would become
The equivalence would become . Any function that only uses our defined lookup function
to access our array structure cannot distinguish equivalent
diffarrays. We could as well work with
.
Especially, we could even replace an occurence of one representation
of an array by another one, without significantly changing that term's
behavior – but replacing one term with another is the same as
destructively modifying a reference. And that is exactly what a
diffarray is: Destructively modifying parts of terms, but in a way
that cannot change the term's behavior.
And I assume that most uses of Haskell's unsafePerformIO
are of this
kind: They implement some stateful operation, but encapsulate it into
a referentially transparent interface that makes different states
indistinguishable.
Maybe by using the above construction, it would be possible to encapsulate some of such use cases into a dependently typed framework. Maybe in the form of quotient types, or in the form of higher inductive types.
Update: There appears to be a paper about basically the same thing. It might be even more useful than I thought, persistent arrays can be implemented better with mutable state. And furthermore, I was thinking about how this kind of thing could be used for memoization. I think it is undoubtedly useful.