What to study? Machine learning vs Computer Science vs Cyber Security vs Financial Engineering

Today I helped a student review his study options (Bachelor level).

We discussed and looked at the courses the university offered in four areas: machine learning, computer science, cyber security, financial engineering. Debating the 'deeper analytical learnings', I mentioned the following:

• Machine Learning
• ML is much about models of models in a very mathematical sense.
• No one knows how to teach it that way (yet).
• One tends to learn more about ML tools and technics than theory.
• Computer Science
• Few model in computer science because expensive, very hard to manage and hard 'get right'. 
• However, applied math and crypto/blockchain domains are easier to approach in a 'modelled CS approach'. Functional programming is a highly effective way to be successful in doing that. 
• The CSL language from Elevence, a functional language, was a rare 'purely modelled CS effort' (inspired by complementary higher-order type properties, now named DAML). It was also a rare effort in covering all of the four domains of this post!
• Cyber Security
• In cyber security, we model the present and the past. We adjust our current state when we detect a security breach in the past.
• Financial Engineering
• In financial engineering, we model the present and future. We adjust our current state to be optimal in the 'modelled' future. 

Talking about job opportunities, I drew the following:

The figure above is meant to convey the following:

• Machine Learning
• Much demand as had a broad application and quick return on investment.
• Computer Science
• Good demand but by fewer companies as there is a certain truth that writing software takes time and is expensive. 
• Cyber Security
• Much demand as has a 'quick' return on investment, but only applicable on IT solutions.
• Financial Engineering
•  Lesser demand. Applicability is more limited. When 'finance' is accounting you do not need 'engineering' or 'complex math'. 

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:

1. State what you believe is true
2. 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
3. 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 becomes clear that it is the iterations that take much time, and therefore it is often worthwhile to think-up more than one idea, and bring them forward in parallel until the environment gives feedback, and one idea turns out to be better than another. Lean is therefore not always agile when working with abstract development.

All original content copyright James Litsios, 2022.

A laptop, desk, beamer and flip chart is all you need!

July 1 2015,  I moved into a single office room at the Zurich Technopark as the sole founding employee of Elevence Digital Finance (11ce). I assembled my sit-stand-desk. I used my personal laptop to write the specs for an 'authenticated contract logic database'. Also, I setup my beamer and flip chart stand! I mention this because I found the following note today dated July 1, 2015, where I 'sold' those objects to 11ce:

We used this beamer internally, yet more importantly, we used it to pitches the contract modelling language we developed that year. 11ce was crazy successful and acquired by Digital Asset in 2016.

All original content copyright James Litsios, 2022.

Some favorite early programs I wrote

These are all pre-2000, and in chronological order:

1. A 'Hunt the Wumpus' like maze adventure program on my Commodore P100 programable calculator.
• Given the max of 72 program steps and 10 memory cells of the P100, this was probably the first time I used a rudimentary hash noise function (in this case to generate the maze 'on the fly', and not need to store it).
2. A primitive LISP like eval loop on my HP-41C, with symbolic derivatives and simplification.
• The integer part of the memory cells were the 'car' part, and the fractional part being the 'cdr' part (with an appropriate scaling).
3. A Fortran 2d finite element solver, 'mesher' and plotter on my schools 'new' VAX/VMS.
• The only early program that I still have, as it is printed as an appendix to my 'hand typed' BS EE thesis.
• A bridge calculation:
  
  
  
  
4. A two player 3d wireframe helicopter against tank simulator/shooter game (C and assembly, on my 4MHz Intel 8088 Cannon AS-100
• The screen and keyboard were split in two,. The game animated a bit more than 100 segments for both the helicopter and the tank. "Space dots" were projected in front of each 'camera' to improve the feeling of motion. Frame rate was about 4 frames per second.
• Fun fact: the 3d rotations matrix was 'compiled' in real-time to shift and add/sub instructions, as this was faster than using the CPU's multiply instructions.
5. A Warnock algorithm to render only spheres on my Canon AS-100. Example, 3d triangles were many small spheres, cubes were a recursion of well placed spheres of various sizes.
• The resulting rendering where very 'organic' because of all those 'spheres' meant that everything looked 'soft',
• The 'radius testing' code was somewhat similar to the (later) doom distance calculation code, as it was one table lookup of the scaled argument, plus one fix-point iteration to refine the result.
6. A scan line based design rule checker and layout 'compactor' (at the CSEM, for the analog CAD system we built)
• Initially Manhattan (orthogonal) geometries, then 45'' angles too, then any 2d geometry.
• It implemented 'boolean' and 'sizing' operators on 2d polygon geometries which my colleague Thomas Schwarz used to implement a window manager 'for fun' on the serial Tektronix color terminal.  (Slow but ultra-cool effect!)
• Mentor Graphics integrated this CSEM development into their ECAD suite: 
• 
7. A symbolic determinants simplifier using minimum weighted matching, used to symbolically extract dominant poles and zeros out of analog circuit sizings.
• The better algorithm came out the same year and worked on weighted matroids. 
• It is this type of experience in applied math that gives you a 'bottom-up' understanding of  Laplacian matrices. 
8. A multi-model hybrid-grid-graph simulator (as part of my PhD). 
• The generic sparse matrix assembly based on priority queues meant that all sparse matrix formats and parallelization schemes were supported efficiently for very large systems (think supercomputers). As a by-product, compact models could efficiently be extracted from large grid based simulations, which ensured the simulator's and ISE AG's commercial success.
• Grid properties could be computed using Jean-Bernard Lasserre's recursive simplex volume algorithm.  This generic n-dimensional algorithm was a bit slow but quite useful as many meshing systems provided incorrect volume/area/length values to the simulator for difficult mesh geometries.
• Some early ISE AG goodies (ISE was later acquired by Synopsys): 
  
  
  
9. A distributed object protocol with futures in C++ (early Actant).
• Prior to Eurex only VMS and AIX based APIs existed to quote options on Deutsche Börse. I had a good experience in serializing C++ objects to files (for my PhD). I adapted this code to make a remote object socket protocol to allow our Windows based option quoting system talk to VMS and we used this until Eurex became live (1998 I believe).
• Remote calls could be chained as a 'future protocol'.  While 'cool', I later disabled the 'futures' functionality having learned that too much generality is sometimes too expensive to maintain. 
• Some Actant AG goodies: 
  
  
  

All original content copyright James Litsios, 2022.