FSDA Bridge Project (follow up)

Read Part B of the attached ProjectFSDA-bridge.docx and try running the existing examples in the language group you prefer (Python, R, or Julia). The issue describes packaging, documentation, examples, and validation goals but does not identify specific files or tests. Done means contributing to a mature, installable package that lets researchers use FSDA from the chosen language with reliable results.

Attached please find a word document (generated by AI) which describes the state of the art so far.

ProjectFSDA-bridge.docx

The work can be organised into three groups of students—or, rather, researchers, because when we work together there is no distinction of roles. The only things that matter are curiosity, commitment, and the willingness to learn.

The three groups will focus respectively on R, Python, and Julia, as described in Part B of the attached document.

Since the document was written with the help of AI and is necessarily rather technical, let me explain in more human terms what we have achieved so far.

First, we studied how the different types of data used in MATLAB can travel correctly to Python, R, and Julia, and then come back without losing their meaning, structure, dimensions, labels, or numerical accuracy. This is less trivial than it may sound: matrices, vectors, tables, structures, text, missing values, and graphical outputs are represented differently in the various languages.

We then created a common bridge that allows the original FSDA functions to be called from these external languages. The important point is that we are not rewriting FSDA in Python, R, or Julia. FSDA remains the orginal MATLAB toolbox, while the bridge takes care of the communication between MATLAB and the other languages.

This means that a researcher can call an FSDA function from Python, R, or Julia, pass data to MATLAB, let FSDA perform the computation, and receive the results back in a natural form for the language being used.

We also introduced systematic checks to make sure that the results obtained through the bridge are identical, within numerical precision, to those obtained directly in MATLAB. In other words, it is not enough for the code to run: it also must return the correct answer.

The Python part is currently the most advanced. A real package called pyfsda has already been created. It can call virtually any FSDA function and now also supports pandas DataFrames, preserving row and column labels when data are transferred to MATLAB tables. This is an important practical improvement for users who work with labelled datasets.

In principle any Name/Value option can be called for any function. However this has to be checked.

As you know, I have never hidden my lack of enthusiasm for Python. Nevertheless, I must admit—reluctantly—that Python is widely used, and making FSDA accessible from Python can greatly increase its visibility and impact. I therefore consider this work a sacrifice made in the name of science.

The next phase is to transform the work already completed into mature, documented, and easy-to-install packages for the three languages:

the Python group will complete and publish pyfsda, enrich the examples, and improve the documentation;
the R group will build an R package around the existing bridge;
the Julia group will build and register a Julia package.

Each group will also prepare practical examples showing how representative FSDA methods can be used from the assigned language. The objective is not simply to create software that works on our computers, but software that other researchers can install, understand, test, and use.

All the 3 groups will be coordinated by @BoschiGiacomo and @qaseem97

Please read the attached document carefully, especially Part B.
First thing to do is to make sure you can run the existing examples

I use VScode to run things with any language

however you can do whatever you like.

Please think about which group you would prefer to join. Do not choose only according to the language you already know best. This project is also an opportunity to learn something new, work with modern software-development tools, contribute to a real open-source research project, and produce results that can be visible to an international community.

The work will be organised through GitHub issues, branches, commits, and pull requests. Nobody is expected to know everything from the beginning. Questions, mistakes, experiments, and failed attempts are part of the process. What we expect is seriousness, regular communication, and the willingness to help one another. Of course this will be recognized (for those who wish to do it) as thesis or internal internship.

Our objective is ambitious but very clear: to make FSDA easily accessible from MATLAB, Python, R, and Julia while preserving the reliability and numerical accuracy of the original toolbox.

---

Do you think we should write inside the issues of https://github.com/UniprJRC/FSDA-bridge or do you prefer to stay inside the issues of https://github.com/UniprJRC/DSwithMATLAB?