I am attempting putting MATLAB (1982 version) on the Altair-Duino.

Has anyone ever seen a CP/M-80 version of MATLAB?

Thanks
FredW

From fridtjof, Sunday, April 10, 2022:
> I am attempting putting MATLAB (1982 version) on the Altair-Duino.
>
> Has anyone ever seen a CP/M-80 version of MATLAB?
>
> Thanks
> FredW

In addition to the matlab80 project on GitHub for CP/M-80 (you?), matlab is included under /cmd/matlab in at least one distribution of version 10 UNIX that's still out there (on Paul McJones' historical archives page), and the Fortran sources are dated 1983. It has implementation of the system-dependent functions for CDC 6600, IBM CMS, DEC 10 & 20, PRIME 400, IBM TSO, VMS in system-dependent files (the CMS has machine-language code in it, too), as well as a generic UNIX implementation of the functions. It is mostly Fortran. There is a VAX file and a few C files and headers. Most (or, now: all?) the system dependencies pertain to things that are now in the standard libraries for Fortran (or C). It has a script file to turn double precision into single precision, and to turn that 50005 magic number into 5005. The routines FILES, SAVLOD, FORMZ, FLOP, XCHAR, USER, PROMPT, PLOT, EDIT and MAIN are system-dependent; most are now handled by standard library functions; others (like PLOT, PROMPT, USER) now abstract out and generalize to interface-dependent modules (i.e. to different terminal and GUI interfaces).

There are 3 file name changes ({comand,factor,round}m.f versus {comand,factor,round}.f), the CP/M 80 version segregated initializations to init.f and declarations to {common,funcs,matlab}.h, while the UNIX version has the low-level files for {ofault,onbrk,setjmp,sgset} - used in the driver routine, and helper (for the help function). The CP/M 80 version balked on any the driver routine and just runs the MATLAB function. The CP/M 80 version avoids the duplicating of single and double precision, which the UNIX version does, by using conditional definitions in an include file.

They should have waited a few years before doing the translation, and they jumped the gun a bit, since they would have eventually seen that translation to C++ would be better because (1) the large number of reference parameters in the Fortran functions, (2) matrix operations can be more transparently rendered with operator[] and even operator(), (3) equivalences can be better-handled with reference types, (4) the common blocks can be more directly rendered as namespaces, (5) templates to directly translate both single and double precision into a single code base, and (6) the complex arithmetic might be better-handled by the compiler and standard library functions, if the code is put back into complex form ... the same applies to the Fortran version, as well, and even the Fortran source should be lifted back to complex. There's a large amount of code bloating that occurred because of the decimation of complex to component reals (not just variables and parameters, but even whole routines, got real-imaginary part split).

At some point, maybe recently, MathWorks lifted the user interface part of their version of the code to Qt ... which works best with C++.

On Saturday, June 11, 2022 at 3:08:48 PM UTC-5, Rock Brentwood wrote:
> From fridtjof, Sunday, April 10, 2022:
> > I am attempting putting MATLAB (1982 version) on the Altair-Duino.
> > Has anyone ever seen a CP/M-80 version of MATLAB?
> In addition to the matlab80 project on GitHub for CP/M-80 (you?), matlab is included under /cmd/matlab in at least one distribution of version 10 UNIX that's still out there (on Paul McJones' historical archives page), and the Fortran sources are dated 1983.

Some additional notes: the MATLAB projected started off as a small project by a professor over in New Mexico, Cleve Moler. His name is in several places under the larger functions in the Fortran source. It was actually his students who took it and ran with it. Both he and others involved in the projects are with MathWorks -- even now at the time of writing. This is note from 2018 on the history of MATLAB from Moler, himself:

https://blogs.mathworks.com/cleve/2018/02/05/the-historic-matlab-users-guide/

and it lists 1981 as the beginning.

He's still around - his most recent blog is from yesterday. He worked with EISPACK and LINPACK, which also has close entanglements with LAPACK, though he does not seem to have any connection with that. LAPACK is back in full maintenance on GitHub. MATLAB is essentially a front end for the older Fortran packages (which is also why it has that klunky 1960's look and feel.)

Given what he said in the historical note, if this were to be done today, it would actually be done simply as an extensible C++ source-code library, since part of the aim was to have code-extensibility - so that means you want a source code library. I highly suspect that this may have led another package: ALGLIB. It has routines for matrix operations, FFT, neural net routines, optimization, differentiation, integration and other code, but is compiled in as source code (in any of several languages), not as a library. But it has no run-time front-end.

On Saturday, June 11, 2022 at 3:08:48 PM UTC-5, Rock Brentwood wrote:
> They should have waited a few years before doing the translation, and they jumped the gun a bit, since they would have eventually seen that translation to C++ would be better because
[reasons (1) to (6)]

.... but - as another note - one of the main reasons for translation to C++ instead of to C is that (7) the Fortran source is seriously mucked up with all sorts of calls to a routine "FLOP" threaded everywhere in it; and this reduced the transparency and simplicity of the code to the limit of easy maintainability into virtually becoming legacy-code. By the documentation's own admission FLOP is really just a sloppy FLOP counter - in part because of its haphazard threading throughout the code. What the author is really trying to do is put up a continuous monitor on all the floating point operations.

This is best done, either outside the application, in a current thread, or by appropriating and encapsulating all the floating point routines in a class that does the relevant operator counts. The latter cases makes it possible to do more comprehensive stats, while at the same time removing all the threading from the source - if it's done in C++. I don't know if the Fortran source, itself, can be lifted to a class-based version (what's needed are classes and user-definable arithmetic operators, in Fortran, like C++'s "operator+()"). But, it can't be done in C.