Category Archives: CTO

Posts from Dyalog Ltd’s CTO

Dyalog ’23 Videos: Week 2 – APL Problem Solving Competition

Posted on by

The section that is dedicated to the annual APL Problem Solving Competition is always one of my own favourite parts of a Dyalog user meeting, and the talks by the two winners this year were no exception. It is always a treat to hear about how the student winners are able to go from zero knowledge about APL to delivering very well designed, array-oriented, solutions in a few weeks, sometimes days!

This year, we were very pleased to have both the student grand prize winner Andrea Piseri and the professional winner Alexander Block present. Andrea is studying mathematics at Università degli Studi di Milano (University of Milan) and Alexander is an actuary at the Viridium Insurance Group in Germany.

Before Gitte Christensen presented the prizes to the winners and they gave their talks, our “Chief Problem Maker” Brian Becker gave us a brief history of the competition and overview of the contest website (which uses Dyalog-grown tools). He also mentioned that we are revising the format of the competition, most likely by running simpler/smaller problem sets at a higher frequency. We’ll be making official announcements about that early in 2024.

Read more about this section of the user meeting in our Dyalog ’23 daily blog post.

——————————————

This week’s videos:

Materials for all presentations can be downloaded from the Dyalog ’23 webpage.

Email, RSS Follow

Welcome to the Dyalog ’23 Videos!

Posted on by

Welcome to the 2023 edition of the Dyalog user meeting presentation recordings. This year, we plan to release a few talks each week until the Winter Solstice – and I will be doing my best to introduce each block of related talks.

Week 1 – A New CEO!

For the 19th year running, the annual Dyalog user meeting started with CEO Gitte Christensen’s Welcome, followed by my own Technical Road Map presentation. However, all is not as it has been: this year, Gitte opened the user meeting with the announcement that she intends to retire from her role as CEO when she turns 70 at the end of this year. The final presentation in this first block is by our incoming CEO, Kirstine Kromberg, and our new Administration Assistant, Jada Andrade, who closed Dyalog ‘23 with a presentation of the vision for the future of Dyalog Ltd.

The similarity between my name and that of the new CEO is not a co-incidence – she is the daughter of the current CEO and CTO. Kirstine (Stine for short) has an MBA in Business Administration and Information Technology from Copenhagen Business School, and everyone believed she was destined to become a manager at one of the large Danish shipping or pharma companies. However, after Stine’s second maternity leave, she discovered that returning to her job as a business consultant would mean twiddling her thumbs until the consulting market picked up again after the Covid pandemic. At the same time, the search for a new CEO for Dyalog Ltd had started.

Stine has been working for Dyalog Ltd for almost four years now, learning how everything works as an accountant and CFO and running several internal projects both on the administrative and technical side of the business. This experience confirmed to us – and to the board, where half of the directors represent our largest clients – that she could strike the right balance between preserving continuity and having the “change management” skills that are required as we grow beyond 25 full-time employees.

As you will see if you watch my presentation, I have a long list of features that I want to see in Dyalog before I retire – and since everything takes longer than I think, I expect to be around for quite some time! Uncharacteristically, both the first and the last talk mention money: Gitte introduces “The APL Fund”, which will allow successful APLers to contribute to the future growth of APL, and Jada speaks about the new prices for Dyalog licences (effective from 01 January 2024). Except for an initial adjustment when Gitte and I joined Dyalog Ltd, the price of a licence has not changed in the 19 years that Gitte and I have been with the company (don’t worry, they are not changing significantly now unless you are still running a 32-bit version!).

I hope you enjoy watching the first set of recordings from Dyalog ’23!

——————————————

This week’s videos:

Materials for all presentations can be downloaded from the Dyalog ’23 webpage.

Email, RSS Follow

11 April 2023 – A Day to Celebrate!

Posted on by

Today we reach two very significant milestones.

40 Years of Dyalog APL

On this day, we have cause for celebration: it is 40 years since the release of Dyalog version 1.0! Geoff Streeter would say that from his perspective we are already in the 42nd year, as he and John Scholes started work on the new interpreter in 1981. On the other hand, Pete Donnelly might argue that the interpreter wasn’t really ready for serious use until a few years after that date. The fact remains that the APL ’83 conference in Washington DC saw the first official release of the product, and is considered to be the “birth” of Dyalog APL.

Farewell Geoff Streeter

On the same day, we also congratulate Geoff Streeter, the last Dyalog developer who will have worked on the interpreter throughout its existence, on the first day of his retirement. We are happy to be able to report that, unlike John Scholes who designed and built version 1.0 together with Geoff but sadly passed away in 2019, Geoff is retiring in good health. We wish him many happy years in retirement in the company of his wife Sarah, children and grandchildren – although we are also hoping that he will pop by the Dyalog office from time to time to let us know how he thinks we are doing, and hopefully also join us at some future user meetings!

Continuity

It is impossible to exaggerate the value of the dedication and continuity that Geoff and John provided to Dyalog over these four decades. In the early days, when company finances were shaky, they sometimes continued work on the interpreter without compensation. Today, we are still blessed with many team members who have worked for Dyalog for most, if not all, of their careers – although we are doing what we can to avoid the need for the extremes of dedication that were required in the early days.

Good Choices

Dyalog APL started its life as a unique combination of what was to become the leading nested array paradigm (APL2/NARS floating arrays) coupled with what John and Geoff (and the rest of the consulting team at Dyadic Systems Ltd) thought were the best “commercial” extensions selected from APL systems developed by STSC and I.P.Sharp Associates (component files and control structures from STSC, error trapping from IPSA, and many other features).

The early choices have stood the test of time, and paved the way for Dyalog to become extremely competitive when Windows 3.1 and John Daintree arrived at the same time – resulting in the extremely easy-to-use Win32 GUI support. In typical fashion, the team did not merely implement a tool for GUI programming, they adopted an approach that led to the very general notion of namespaces, which meant that the same architecture could be used to interface to COM/OLE and subsequently .NET and complete support for object-oriented programming in Dyalog.

UNIX

Geoff was (and is) very much a UNIX man, and the first versions of Dyalog were built for the small UNIX machines that Dyadic Systems expected to take over from the mainframe. Unfortunately, UNIX was slow to gain acceptance and, around 1990 when UNIX was finally starting to take off, Microsoft Windows arrived and the centre of gravity of the commercial business shifted in that direction. Geoff was often heard muttering to himself about how the company was making poor technical choices, driven by what he referred to as “commercial” pressure. He kept his head down, and ensured the UNIX implementations were well supported and that all designs took the needs of these platforms into account.

Users of UNIX-based Dyalog can be grateful for Geoff’s unwavering enthusiasm. And Dyalog too: not only is the IBM AIX version of APL still a significant source of revenue, the ease with which we have been able to add support for Linux and macOS is very much down to our long UNIX history and the goal of maintaining cross-platform compatibility, throughout the history of the product.

Dedication

As a further example of Geoff’s dedication: as a young man with a motorcycle and a keen sense of community, Geoff started riding at night, delivering blood from blood banks to hospitals where it was urgently needed. He started doing this in 1980, just after he started at Dyadic Systems, and, although he is retiring from Dyalog today, Geoff will continue as a volunteer for SERV S&L. Although he no longer rides his bike, he now acts as the controller for the new generation of riders. In October 2021, SERV S&L was presented with The Queen’s Award for Voluntary Service by the Lord Lieutenant of Surrey.

The Future

In the same way that Geoff has not been riding his bike at night, he has not been doing any new development on Dyalog for the last year. Instead, he has been preparing and holding internal presentations to a new generation of Dyalog developers, providing insight into the work that he has done over the last four decades. Ultimately an impossible task of course, but at least they now know where to start digging – and Geoff is still around to answer questions in an emergency if we offer him a cup of coffee and three plain chocolate digestives (his stated minimum requirement to come into the office!).

As Dyalog enters its fifth decade, all parts of Dyalog Ltd. (including the development team) are larger – and broader – than they have ever been. The good choices made by Geoff, John, Pete, and many others in the early years are holding up, and the company continues to grow.

Many thanks to Geoff from everyone at Dyalog Ltd. We will do our best to allow him to relax, enjoy his well-deserved retirement, and look forward to continued dividend payments from the Dyalog shares in his pension fund!

References:

Email, RSS Follow

Structural vs. Mathematical “Under”

Posted on by

The APL Farm has recently hosted discussions about the proposed under operator, asking “why Dyalog hasn’t implemented it a long time ago”. I claimed that an important reason was that Roger Hui wasn’t a big fan of the proposed extension known as “structural under”. Stefan Kruger then asked me why that was so. Since Roger isn’t able to respond himself, I’ll do my best to explain my own understanding of the issues.

For anyone not familiar with the concept of under, or dual as it was known when first implemented in SHARP APL, it is an operator that provides a way to express a common mathematical pattern, where a computation or proof is simplified by first translating the input domain, applying a function, and then performing the inverse transformation. For example, if we use the symbol ⍢ to denote under, have the translation function as the right operand, and the function that applies to the translated domain as the left, then we could use +⍢⍟ to demonstrate that multiplication is equivalent to addition under logarithm, which is why slide rules work:

      1 2 3 4 (× ≡ +⍢⍟) 0.1 1.1 17 100
1

Another example of simplifying multiplication using dual is the use of Fast Fourier Transforms to multiply very large numbers, as explained in the notes about xtimes in the dfns workspace.

It is easy to find examples of dualities outside the mathematical domain, such as midnight snacking: (open refrigerator door, remove food, close door) or Roger’s favourite example of medical surgery: apply anaesthetic to greatly simplify the operation, perform surgery and (very important) back out the anaesthetic.

I believe that Roger was of the opinion that under/dual should be restricted to functions that have well-defined inverses using the “mathematical” definition used in SHARP APL and the J language. We can model this with a defined operator, let us call it Um:

   Um←{⍺←{⍵ ⋄ ⍺⍺} ⋄ ⍵⍵⍣¯1⊢(⍵⍵ ⍺)⍺⍺(⍵⍵ ⍵)}

The extension known as structural under allows the transformation function to be a structural function, even though such functions do not have inverses in the mathematical sense. In this case, the left operand is applied to the subset of items selected from the right argument by the structural function. This is easy to model using a feature of some APLs known as selective specification, in which you can have a function to the left of an assignment whereby the assignment only modifies items selected from an array using so-called “structural” functions – those functions that select or reorder items of an array without doing math, such as ↑ ↓ ⍉ ⌽ ∊.

Let us call this Us:

   Us←{⍺←{⍵ ⋄ ⍺⍺} ⋄ w←⍵ ⋄ ((⍵⍵)w)←(⍵⍵ ⍺)⍺⍺(⍵⍵ ⍵) ⋄ w}

This is very useful, for example, we could negate all items of an array except the first two by writing:

      - Us (2∘↓) ⍳5
1 2 ¯3 ¯4 ¯5

The big question is whether Us and Um can be combined into the same operator, or two separate operators are needed. One problem is that ↓ already has a defined inverse in Dyalog APL, which pads with zeros, so Um returns something different:

      - Um (2∘↓) ⍳5
0 0 ¯3 ¯4 ¯5

If we want to combine the two into one, then we need a rule that allows us to decide which definition to use. Marshall Lochbaum‘s BQN language has a table of structural primitive functions; it performs a structural under when possible (according to an extensively described rule), and otherwise attempts a mathematical under.

Personally, this sort of conditional logic in the definition of a key primitive makes me very uneasy, and I think Roger was struggling with this as well. Unfortunately he passed away before we were able to finish argdiscussing the design. Another reason for feeling that the two operators are different is that, while it often makes sense for the transformation to apply to both arguments in the mathematical case, it is extremely rare for structural under. You cannot do:

       1 + Us (2∘↓) ⍳5

because when you apply (2∘↓) to the left argument, you get an empty vector. Instead, you need to turn the left operand into a monadic function to add one to the three trailing elements:

       1∘+ Us (2∘↓) ⍳5
1 2 4 5 6

This increases my personal unease about combining the two into a single operator. Even though this would work “just fine” most of the time, it would still make it difficult to explain exactly what is going on.

It is my opinion that APL needs to remain a rationalised mathematical notation if it is to remain useful and relevant in the long term. Deciding whether to implement a strict mathematical operator, a combined operator, or two separate operators (or do nothing for a while longer), is one of the key design decisions that we will be faced with in the near future.

Email, RSS Follow

Announcing the Beta Programme for Dyalog APL Version 18.2

Posted on by


I am very pleased to be able to announce the start of the Beta testing of the next release of Dyalog APL! As explained in June, we decided to delay the release of version 18.1 in order to take a closer look at some of the optimisations that had been implemented in 18.0 (and were therefore also present in 18.1).

Our analysis of the optimised code concluded that, due to the nature of many of the new algorithms involving modern vector instructions and code generated from templates, we need significantly more time to create tests that will cover absolutely all the different cases that have been implemented. As a result, we do not feel that it is in the best interests of our users to release v18.1 in its current form.

The good news is that the features of modern source code management systems, combined with our collection of regression tests, have allowed us to create a new version of Dyalog APL that contains all of the new features added to versions 18.0 and 18.1. This includes bug fixes made during these two development cycles, but not the optimisations that make us feel uncomfortable. To differentiate this version from the existing version 18.1, we have decided to call the new version 18.2.

Everyone who was signed up for the v18.1 beta programme should now be able to download v18.2 beta. If you are not signed up as a beta tester already but would like to help us with testing, please get in touch. Under Microsoft Windows, testing should be significantly simpler this year, as we have started producing Microsoft Patch files (MSP) as the delivery mechanism for updates – something I have personally been looking forward to since before I joined Dyalog Ltd!

Version 18.2 Performance

One unavoidable consequence of the above is that the performance of v18.2 is closer to that of v17.1 than to v18.0. Our own tests show that we have not been pushed ALL the way back to “square one”: v18.2 appears to be slightly faster than version 17.1. Once v18.2 has been delivered we will work on carefully re-implementing the most valuable optimisations that have been removed. We welcome your input on which primitives you think we should speed up first, so please participate in testing v18.2 and let us know what you think we should prioritise as we start work on version 19.0!

Recommendations regarding Version 18.0

Over the summer, only one additional defect related to performance optimisation was discovered and fixed. We are not currently aware of any outstanding defects in v18.0 caused by recent optimisations. Dyalog Ltd is committed to providing support for version 18.0 until the arrival of the 3rd release following it, in accordance with normal policy.

However, if you have not yet upgraded to v18.0, Dyalog Ltd strongly recommends remaining on your current version and moving directly to v18.2 when it is released. If all goes well, this will happen at the end of 2021 or very early in 2022. If you are already using v18.0, then we recommend that you make plans to start evaluating v18.2 and moving to it as soon as possible.

Conclusion – and Apology

We are painfully aware that the defects found in v18.0 and the resulting uncertainty have seriously inconvenienced some of our users, and I apologise for this. The root cause is the growth and rejuvenation of the Dyalog development team. Our original processes for quality assurance relied on years of tacit knowledge; when enthusiastic new team members break significant new ground, more explicit planning and QA processes are required to make sure that new approaches are safe and stable.

When we resume work on optimisations following the release of v18.2, this will be done according to new guidelines that require the process to begin with a careful risk/benefit analysis of any enhancement to primitive functions. We will do everything that we can to move forward in a way that will allow us all to eventually look back on the events of 2021 as a significant step towards a more capable and reliable development organisation and product.

After all, in another two years it will be time to celebrate 40 years of Dyalog APL!

Email, RSS Follow

Essays on APL Since 1978

Posted on by

In June, Mikhail Barash and Anya Helene Bagge published a collection of essays written by the students of the seminar course INF328B on History of Programming Languages that was given at the University of Bergen (Norway) in the Spring term 2021. As an author, I wish to start by thanking Mikhail and Anya and the students for this initiative! It is inspiring to those of us who have been in this game for a while to see young computer scientists who are interested in language design studying history – it definitely makes us feel that the effort put in to writing the paper was worthwhile!

Each essay summarised one paper from the HOPL IV conference (part of ACM SIGPLAN’s PLDI 2021). Two students wrote essays on the paper “APL Since 1978”, by Roger Hui and myself. At the end of each essay, students were encouraged to pose questions to the authors of the HOPL IV papers, and this blog post has essentially been written in response to those questions.

Karl Henrik Elg Barlinn asks:
“I wish to know if there are plans to try and popularize APL within the wider community of programming languages. I ask this because I see how it can be very useful for the mathematical community to write papers and be able to execute the notation.”

The APL community has always seen “evangelism” as an important activity, and that remains true to this day. It is a challenging task because the most successful APL users are neither software engineers nor mainstream mathematicians, but various types of domain experts who are able to apply mathematics and learned enough about programming to write high value applications with a lot of domain-specific content. Typical users have been actuaries and financial experts, operations researchers and planners.

Successful APL users are more likely to write papers at an Actuarial or Chemical Engineering conference, and typically lack the vocabulary and the insight into mainstream computer science to present APL to the “community of programming languages”. They also typically work in highly competitive industries and have little time or inclination (or permission) to publish their work.

The situation is improving: the growing interest in functional programming, and the general recognition by the software engineering community that there is value in combining different paradigms (as opposed to the bad old days when everyone thought that the world would soon standardise on C++ or Java), makes it much easier to interest the new generation in APL.

A new generation of APL users is emerging, who have more insight into Computer Science and are more able to bridge the gap. Examples of recent work include:

Dyalog Ltd recently introduced an event aimed at new users; recordings from the first of these meetings can be found at https://www.dyalog.com/apl-seeds-user-meetings/aplseeds21.htm.

In addition to the marketing efforts, Dyalog is working hard to add tooling that will open APL interpreters up to mainstream “devops” workflows, based on text-based source files. Historically, most big APL shops developed their own home-grown management systems (many of them pre-dating tools like SVN or Git by decades), and there has not been a lot of tooling shared by the community.

“Given unlimited influence, where do you wish to see APL be used? If your answer is everywhere, does that mean APL is fit to do everything? On the other hand if your answer is not everywhere, where is not fit to be used and why?”

Given unlimited influence, I would push APL as a tool for education. I think it could be a useful tool for teaching mathematics – and how to use it to solve problems on a computer – starting with children. The simplicity of APL’s syntax means that it is also a good tool for teaching people of all ages and at all levels of education to manipulate data without just feeding it to ready-made packages. Teaching fundamental algorithms in computer science classes is also a good place to use APL, although the CS establishment will probably question that since APL tries to do most things without loops or type declarations, and sort of “skips over” the lowest level of algorithms.

APL is a useful tool for modelling, prototyping and designing solutions to any kind of problem. Obviously, many domains already have tools specifically designed for common types of problems. For example, Mathematica and MatLab have built-in solutions for many different classes of mathematical or engineering problems, TensorFlow for artificial neural networks, and so on. However, when the time comes to perform a major revision or extension, or there are no pre-built solutions, APL will be a good choice for prototyping.

Although APL is perhaps most valuable during analysis and design, the “executable design” is often used in production because APL interpreters are efficient on the relatively dense data structures that results from array orientation and because the ability of domain experts to write code (and tests) eliminates many sources of errors and poor performance due to unnecessary abstractions.

APL is not always an appropriate choice for the final production system. For example, I would not use APL to implement a real-time system, at least not using existing APL interpreters, which will freeze up to do compactions every now and again. For mission-critical systems, the additional safety provided by strong typing or other mechanisms for verifying correctness, and using teams trained to focus on reliability rather than analytics, may have benefits. If the core algorithms are not array-oriented and require a lot of looping or recursion, an interpreter may not be the right solution, and APL compilers are not yet mature technologies.

Even when the final production system is rewritten in another language, the prototype can be useful as a verification system, especially because the implementation is likely to be radically different, and can therefore almost act as a proof of correctness.

For an example of how APL can add significant value even when it is not used in the final implementation, see Martin Janiczek’s presentation at APLSeeds21, on “How an APL Prototype Helped Designing a Service”: https://dyalog.tv/APLSeeds21/?v=qDl3obmOd58.

“Q: Do you think APL with its glyphs is more fit to be taught in school than J, as special equipment is no longer an issue with UTF being widely adopted?”

There are still some problems related to APL symbols, such as many applications rendering the symbol ≢ incorrectly as a ≡ followed by a slightly offset / unless a supporting font is used. I suspect that it may be a while before we have handwriting recognition for APL symbols, or support for APL in writing systems for the visually impaired, and so on. On the other hand, one of the benefits of APL (which also holds true for J) is that it is independent of any particular human language, without needing to be translated from English.

Roger Hui commented in the HOPL IV Slack channel: “I am guessing that if the ecosystem for Unicode was more developed at the time (1990) Iverson would have kept the APL glyphs.”

Sondre Nilsen comments:
“If I would have some feedback it’d be to include an “array programming languages for dummies” appendix that could be used to look up foreign concepts, words and phrases that unfamiliar aspiring APL developers may not know.”

Hopefully the APL Wiki (https://apl.wiki) will be a useful resource, along with the (APLCart https://aplcart.info) and the evolving digital version of Mastering Dyalog APL. Please take a look at let us know if you feel more is required!

Roger and Morten’s HOPL IV paper “APL Since 1978”:

Email, RSS Follow