Posts

Showing posts with the label DCS

Owen Meany from a Category Theory perspective (Spoiler Alert!!!)

If you look at A Prayer for Owen Meany  through the lens of category theory and functional execution, John Irving didn't just write a novel about destiny—he built a strictly commuting diagram evaluated lazily from a terminal object. Stop here if you do not want to know the end or details of the book! FYI: Info is "fuzzed" below to lessen damage. Most novels, and most human lives, execute like an imperative program. They are Markovian. You start at state A, apply a decision, move to state B, and the future is an open, uncomputed tree. Owen Meany’s life operates under completely different mathematical physics. Here is the categorical breakdown of how Owen’s universe functions: 1. The "eventful location" is a Terminal Object In category theory, a terminal object is an object to which there is exactly one morphism from every other object in the category. The "action" in the "eventful location" is the terminal object of Owen’s existence. Every sin...

Typed duck typing in Python with Gemini

Image
Dynamic typing of duck typing The link to the code produced by Gemini and the topic of this blog . Two months ago I drafted a Python tracer library with Gemini, then I rewrote it from scratch (here) . It is however "clunky". Yet I do not worry, as Python is a computer scientist dream language, and in Python one can quickly implement something meta and probably slow, but then use a cache or two to make it fast enough. That is what I did last week: I sat in front of my screen, stared at it for 30m thinking through my options, and then asked Gemini to draft the concept. And while the result is missing some logic, it is however doing what I want: it dynamically wraps "types" around duck-typed operation. I could try to explain what it does... but I do not need to. Instead, I share what I told Gemini. The key desires are the following: let's make a cached wrapper factory, that when given an object, first is looks in the cache, and returns the instantiated wrapper with...

Why the struggle with functional programming?

Slow FP adoption... Why no widespread adoption even though functional programming exists already now for over sixty years? Not so long ago I explained this as: The reason is actually pretty complicated: The strength of FP is much due to its ability to be very strong. This strength in the code weakens the ability of developers to make local changes. Initially, this sounds like something good, yet it creates a new challenge: developers are bound to the constraints of code written by others, and they are not only not happy, they are less productive! You can solve this by bringing your FP to the next level: math. A few companies do this, now a developer is not subject to constraints but to mathematics. If the developer understands the math she/he finds this acceptable. I am simplifying things a bit here, yet FP, or any language that is strong enough, brings in a whole complexity of technical ownership and people dynamics that does not need to be dealt with with OO. The realit...

The future of software development (end 2022)

  My end of 2022 predictions for software development: Structure of code becomes more important than code Partial code becomes more valuable than finalized code Proprietary code gains in value Contextual programming gains in traction IDEs become ever more ML driven And therefore: Dynamic typing gains over static typing Duck-typing grows in value IDE security and spyware become an ever more important topic Functional programming is still the more powerful programming paradigm Proprietary IDE with in-house ML engines will grow in importance All original content copyright James Litsios, 2022. 

Three step research process

Use your brains when developing abstract innovation. It is a game of 'balance': you think-up what is needed, you set goals that take advantage of your thinking, then you work towards your goals. If on the way something does not fit, review your goals or thinking. It is an iterative effort, you try, you repeat, until it works. Here are the three iterative steps in more details: State what you believe is true Express implementation goals that will leverage your beliefs Check consistency of goals with respect to your environment and to underlying beliefs Correct your beliefs if inconsistencies are found between goals and environment Develop towards your implementation goals Check consistency of development with respect to environment and underlying goals and beliefs Correct goals or beliefs if inconsistencies found between development and environment At first, one tends often to 'juggle' and develop just one idea at a time, when developing this way. Yet with experience it ...

Retrospective on "my bookshelf picture"

 My previously shared bookshelf picture got a hit peak and this got me thinking:  Most of my books are more than 20 year old. Some are from my dad and his older brothers. That means they are sixty+ years old! (FYI my dad, Socrates Litsios , recently passed away, had a PhD from MIT (operational research in EE department)). I have never been a linear student (except with audio books). I tend not to read books but to read publications. And even then, I skim the publications, I do not read them. However, I do a lot: I program prototype on prototype during my spare time. I implement software for real professionally, mostly in rocket science areas that rely on math. Therefore most of these books still resonate with me, having used much what is in them. That is why I keep them. Once a year I throw out the books that no longer resonate. A month ago I put 30 of these books on a chair on the sidewalk, including my Collected Algorithms from ACM books (mostly Fortran in print). At th...

From sparse tensor parameter space to orchestrated stream of distributed processes

In 1996, my team adopted a tensor view of its application parameter space. Credit must be given to one of my partners at QT Optec/Actant, who presented the following view of the world: each client could "tie" each parameter to any point/slice in "high-dimensional" cartesian space of primary and secondary keys. It was an advanced concept which took me many years to fully master. The simple statement is: "it ain't easy"! Higher dimensional data views are "all the rage" now, but not in 1996. I'll try to illustrate the concept as follows: Imagine we have a parameter P1 used in formula F that goes from X to Y. Imagine that X can be queried with keys kx0 and kx1 (it is two dimensional) and Y is three dimensional with "axis" ky0, ky1, and ky2. P1 is a parameter, which means that it is a "given value". The question is then: is P1 just one value? Should we use a different P1 for the different values of X tied to its 2d mapping ...

Finding constrained boundary of z-ordered / Morton code regions (pre-2000 coding)

Image
2025 Update:  Wikipedia now states: The BIGMIN problem has first been stated and its solution shown in Tropf and Herzog.[10] For the history after the puplication see [11].  What is below seems to be a variant of BIGMIN, with the advantage of running in log bit length. The original BIGMIN is proportional to the bit length. Many years ago, while doing my thesis, I played a bit with z-order / Morton coding (see   https://en.wikipedia.org/wiki/Z-order_curve ). Therefore I share here a little snippet of code from ~1995, that I happened to fall upon while cleaning up an old laptop. I have not noted that the equivalent logic has already been shared, therefore I took an hour to write it up in Python ( Jupyter notebook style uploaded here ). I would be curious to know if it can be found elsewhere. First a bit of historical context. My first job (before my PhD) had me writing a Design Rule Checker (DRC) for the world's first analog CAD tool, developed at the CSEM   https...