[RFC]: add new namespace `@stdlib/optimize` and initialize with linear programming modules

[SergeantQuickscoper]

Full name

Don Roy Chacko

University status

Yes

University name

National Institute of Technology, Warangal

University program

Computer Science and Engineering

Expected graduation

April, 2028

Short biography

My name is Don Roy Chacko and I'm a freshman at National Institute of Technology, Warangal, majoring in Computer Science and Engineering. I've always been really into math and computer science, but I had never combined the two fields until after studying them in unison at my university. Taking Linear Algebra and Differential Calculus in my first semester, followed by Integral Calculus and Optimization Techniques in my second, and understanding implementations of these in code has been an eye opening experience.

I taught myself C++ in middle school to make games and ever since then has been my preferred language to code in. Alongside this I'm fairly experienced in Python and JavaScript, using the former for some machine learning and computation applications and the latter mostly for Web and Mobile development. I'm fairly decent at learning new things quickly and adapting to unexpected changes, so I'm confident that I would be a great fit for GSoC 2025 program at stdlib, despite any challenges that may appear.

Since taking the Optimization Techniques course at university, I developed an interest in the field of soft computing and implementing various optimization algorithms. As of now I've made implementations of the Simplex algorithm for LP, Branch and Bound algorithm for ILP, Newton's Method for root finding, and simple versions of the Genetic Algorithm and Simulated Annealing Algorithms in C++, with the last 3 also being implemented in Python for university grading. To prove my competency in JavaScript, stdlib and my proposal, I decided to an implementation of Newton's Method using stdlib for my showcase which you can read more about in the showcase section. I'm excited to bring my proposal to life and have it live in open source.

Timezone

Indian Standard Time

Contact details

email:donisepic30@gmail.com,github:@SergeantQuickscoper

Platform

Windows

Editor

VSCode is my preferred code editor. I use it because its simple, smooth and extensible, and I prefer it generally unless I'm doing one-off or small changes in a file, in which case I typically use vim as its faster.

Programming experience

I started programming because I wanted to make games in middle school, and I've been hooked since then. During middle school I made small little games using C++, and as I got older tried out Unreal Engine, and later Unity with C#. In between this I've experimented with Python and dabbled with machine learning for a while because I thought it was cool. Eventually I got introduced to JavaScript, which I learnt simply to know how to make functional websites in hopes the skill would pay off in the future. I find it very useful for building stuff I want to showcase like a website or an app, and even for backend APIs, though I'm still attached C++ for whenever I just want to experiment.

The latest cool thing I've built is an app called NITSync, which is an app designed for my college, to enable class representatives to communicate schedules and other information to students, with features like automatic class assignment based on your login, an extensive notification system, and real time updates with socket.io. The app was made to address general student frustration with the current system which was just a WhatsApp channel, and also for me to try out launching an app. As of now around 2 batches in my college use it and user feedback is positive, something which I'm very proud of!

Other than that, I also spend my time implementing algorithms and concepts I learn in my college Math classes in C++ to get a better feel for them and as a bonus seeing tedious and iterative algorithms being computed fast by code when we usually are made to compute them by hand in class is extremely satisfying.

JavaScript experience

I've been using JavaScript for about two years now, and I use it for Web, mobile and API development like I mentioned in previous sections. Overall it's a pretty useful language my toolbelt because it has so many applications. That is probably my favorite thing about JavaScript, the fact that it is so ubiquitous that it runs on the frontend, backend, mobile apps, IoT, and the fact that it has so many frameworks and libraries to choose from. The worst feature would be its dynamic typing, something that even with TypeScript I find awkward, but this is a very small issue to me.

Node.js experience

I've used Node.js nearly as long as I've used JavaScript, using it with Express.js to build pretty much every backend API I've built for my projects. I'm comfortable with it to a good extent and work well with the environment.

C/Fortran experience

While I don't really have any experience with C, most of the experience I have is with C++, so I'm sure I can understand and debug most C code, and will eventually get into the habit of writing C-style code for the purposes of stdlib and my proposal.

As for Fortran, I have no experience at all, but I am willing to put in the time to learn it to analyze other implementations related to my proposal.

Interest in stdlib

While searching for organizations to contibute to for GSoC 2025, I came upon stdlib and read up on you guys. The library resonated with my newfound interest for Maths and its programming implementations, which I first experienced in college and going through the source code made me feel like I could be a part of this too. After reading up the all the documentation and getting a good feel for the package, I decided to jump right in and implement a feature. Not only was this my first time contributing to a public repository like stdlib, it was also the first time I wrote documentation, tests and benchmarks for a feature I wrote, a practice which was pretty much an alien concept to me prior to this.

My favorite feature would have to be the stdlib plot API, which is a great tool for visualizing aspects of optimization algorithms like convergence and gradients, or even LP aspects like a feasible region plot.

Version control

Yes

Contributions to stdlib

As of now, my contribution to stdlib is one PR. This is mostly due to my finals week, which unfortunately coincided with the application period from when I discovered stdlib. My finals do get over on April 13th, from which I've decided to start to work on more PRs and other contributions.

Just by doing this contribution I learnt so much about what it takes to contribute to stdlib. Reading and rereading the guides, conventions and conducts gave an idea of how to contribute efficiently to stdlib. Writing documentation, tests and benchmarks, all while following a style and convention guide gave a whole new sense to writing code for me, and as a proof of concept, to show what I've learnt and to make up for alow PR count, I've written my showcase while following these principles, so please do check it out!

stdlib showcase

As my showcase I decided to formally implement Newton's Method of Root Finding in Real Functions, a project which compliments my proposal nicely. I've made sure to carefully write comments and function descriptions as per the stdlib standard, write testcases with a simple quadratic, the Rosenbrock function, a bowl function and an exponential function, and also some documentation, only thing missing from the stdlib convention is some benchmarks.

Check out the repo and follow the README to run the code yourself. I am also working on a visualizer using stdlib plot API which should be added soon, hopefully by the deadline!

Goals

Solves: #27

My goal for the summer is to have stdlib ready with a good starting point for an optimization suite under the @stdlib/optimize namespace. My primary goal will be to integrate linear programming modelling wrapped around the HiGHS solver, to have stdlib support the following linear programming applications:

• Simplex
• Dual Simplex
• Integer LP and MILP
• Sensitivity analysis

To implement this, I plan to compile the HiGHS C++ library into a WebAssemblymodule using Emscripten, and then create a higher level binding layer via Embind. The resulting WASM module, with the binding layer and adapters will then be integrated into our @stdlib/optimize namespace. Each application (Simplex, Dual Simplex, MILP, etc.) maps to a specific configuration of HiGHS. Users will then define models using objects, similar to SciPy, and then internally the JS adapters will handle data formatting between our higher model interface and the lower WASM module and call the right HiGHS routine for the LP application. Finally, the results will be parsed and returned as output to the user.

This WASM approach provides better cross environment support (supporting both browser and Node.js environments) while retaining HiGHS's native performance and solving capability. Moreover, I also want to implement support for utilities such as visualizers and file exports for each of the applications, in a utility layer. Tests, benchmarks, documentation for the applications would also have to be written out.

Furthermore, if time permits (which I fairly certain wouldn't the case if I'm being conservative) I would want to begin designing our own implementation of minpack and some scalar root finding functions and perhaps in the future, we could still do our own implementations of these algorithms as a pure JS fallback, and to give users that choice. Though please consider this as an extra outlandish plan, which I do not expect would be achieved within the GSoC time frame, and I would probably begin work on it after the summer is over.

Why this project?

What excites me most about this project is the chance to bring together two things I really enjoy: optimization and coding. Like I mentioned in earlier sections: I'm fascinated by how different optimization algorithms work and love implementing them in code. Now, I’m excited to take that knowledge and apply it in JavaScript using stdlib. This project gives me the perfect opportunity to contribute to open source, deepen my skills, and help build a useful optimization tools that others can use too.

Qualifications

I have a good foundation in optimization algorithms, developed through college coursework and C++ algorithm implementations mentioned in previous sections. Alongside my coursework I have continuously referred and studied the book Operations Research: An Introduction by Hamdy A, Taha .

Prior art

After doing some research, I've came across the following notable libraries that incorporate HiGHS in a similar way to how we want to:

• highs-wasm – Emscripten based WebAssembly binary of HiGHS.

• highs.js – Another WebAssembly version of HiGHS compiled using Emscripten.

• SciPy (Python) – Uses HiGHS

• HiGHS.jl (Julia) – Julia wrapper for HiGHS

• MATLAB Optimization Toolbox – Uses HiGHS for LP and MILP by default

While I do believe HiGHS should be what stdlib should use, some implementations that use other solvers are:

• PuLP (Python) – Uses solvers like CBC or GLPK.

• CVXPY (Python) – Uses solvers like ECOS, SCS.

• Clp (C++) – Simplex-based LP solver.

Commitment

I am planning on investing a full-time schedule for a large project (350 hours total), but I am willing to go beyond this as I do not have any prior commitments for the summer, or at least during the GSoC timeframe. I will spend a good chunk of the time before and during the bonding period working on API design and studying in detail the other implementations mentioned in the previous section while discussing this with the mentors, so during the weeks I can purely focus on the implementation of my proposal. After the GSoC program I would like to expand the namespace to the extra mentioned minpack and scalar roots implementation, and the implementation of the pure JS fallback methods for LP without WASM.

Schedule

Assuming a 12 week schedule,

• Community Bonding Period:

  • Do API Design
  • Detailed Study of other implementations

• Week 1, Week 2, Week 3:

  • Integrate HiGHS:
    • Build an WebAssembly Wrapper for the HiGHS Static Library using Emscripten.
    • Test this wrapper on a simple LP solve using Node.js.
    • Write documentation and tests.

• Week 4, Week 5:

  • Standard Simplex and Dual Simplex:
    • Support for Simplex and Dual Simplex in the API
    • Thorough documentation, tests and benchmarks for the above

• Week 6 (midterm), Week 7:

  • Pure Integer LP and MILP:
    • Support for ILP and MILP in the API
    • Thorough documentation, tests and benchmarks for the above

• Week 8 Week 9, Week 10, Week 11:

  • Sensitivity Analysis:
    • Support for Sensitivity Analysis on the algorithms implemented so far
    • Thorough documentation, tests and benchmarks for the above
  • Utilities:
    • Implementing file export utility.
    • Implementing a visualizer.
    • Thorough documentation, tests and benchmarks for the above

• Week 12 and Final Week:

  • Wrapup and Submission:
    • Finalize all deliverables and mergeable PRs.
    • Submit project report
    • Propose clear post-GSoC roadmap for future expansion to the namespace.

Related issues

No issues from what I think the example issue is asking for. I'd like to say in conclusion, thank you for reading my proposal and would appreciate any feedback on it.

Project Idea: #27

Checklist

• I have read and understood the Code of Conduct.
• I have read and understood the application materials found in this repository.
• I understand that plagiarism will not be tolerated, and I have authored this application in my own words.
• I have read and understood the patch requirement which is necessary for my application to be considered for acceptance.
• I have read and understood the stdlib showcase requirement which is necessary for my application to be considered for acceptance.
• The issue name begins with [RFC]: and succinctly describes your proposal.
• I understand that, in order to apply to be a GSoC contributor, I must submit my final application to https://summerofcode.withgoogle.com/ before the submission deadline.

[Planeshifter]

Thanks for this detailed and well-structured proposal! Having an optimize namespace as part of stdlib would be great. My one comment at this point would be that one of our guiding principles is that while we are open to native bindings as applicable, we want to have all our libraries available in pure JavaScript as well as a fallback to run e.g. in a web browser.

Touching on whether it would be feasible to implement the core optimization algorithms in pure JavaScript or port HiGHS to JS would be helpful.

[kgryte]

It's possible to have a WebAssembly build, but that would likely require a fair amount of higher-level glue code for running in web browsers. I'd be interested in knowing what the approach will be for ensuring a browser-compatible implementation of any algorithms and APIs added to stdlib as part of this project.

[SergeantQuickscoper]

Thanks for the feedback @Planeshifter and @kgryte. After giving it some thought, I believe that it would be better for now to go through with the WebAssembly approach, as I see that doing our own implementations, or a port of HiGHS to JS, would take significantly more time, while also possibly introducing the risk of performance issues, inaccuracies and a higher maintenance cost. It is for this reason that libraries like SciPy are deprecating their own solvers and moving towards using HiGHS as their linear optimization solver. A WASM build of HiGHS would resolve these issues and would still align with stdlib's guiding principles of providing robust and performant scientific computing applications, despite not being pure JS. Perhaps in the future, beyond the scope of the GSoC program, we could still do our own implementations of these algorithms as a pure JS fallback, and to give users that choice.

As for the WASM implementation, since Node.js has native support for WebAssembly, we can rely entirely on a WASM version instead of using the node-addon-api. This can be done by compiling HiGHS to WASM via Emscripten and binding its functions to JS via Embind or custom glue code and using the resulting module for both Web and Node.js environments. This change should only replace my implementation plan for Week 1, 2 and 3 in my schedule, so I don't imagine that this change in the plan would affect any of the other planned features of the project.

As it is very close to the deadline, I decided to go ahead and change the proposal submission to reflect this change directly, but I would love to continue to discuss the proposal further and would appreciate any feedback or insights into anything I'm overlooking!