GSOC 2024 -

## 15 May 2024

in 'community bonding period'

* https://developers.google.com/open-source/gsoc/timeline

Weekly meeting every Wednesday
4 pm GMT+2 = 9 am CDT = 10 am EDT.
- Normally Hannah and Kyle, still meet if only 1
- Can skip meeting if not needed
- Extra meeting if needed

Next meeting 29th of May.
For next time:
1. [name=hannah] Announcement
2. [name=Trygve] Blog post
3. [name=Trygve] Make sure everything is ready to start working (compliles, etc.)
4. [name=Trygve] Think about the order in which different aspects need to be reviewed

Keep track of progress

Issue: will be one large commit → cannot be split into separate pieces

1. minimal → techincal (+picture(s) from tutorial)
2. tutorial
3. colormaps
a. bivariate
b. multivariate

pro/con table of new feature
1. Assume we want bivariate colormaps
2. Either new machiner as new pipelines or expand functionality of existing machinery
4. Another level of checks for input
5. New switches inside functions

Tim → API lead
Anthony → Principle Engineer
Tom → Project lead
Jody → Secretary (&documentation(?))

Touching large parts of code → want everyone on board with changing

## 29th of may

Code has been branched → need to resolve conflicts
Fancy rebase?
Split pull request into several steps → also achieved via fancy rebase?

Different ways to merge
→ Just merge
→ Rebase and merge (can't handle conflicts)
→ Suqash and merge → makes commits in branch into a single commit (automated concatenation of commit messages)
(standard procedure to err on not squeezing)

Squeeze out any commits that are broken → particularly important for bisecting the codebase later

Make it three(?) separate PRs
main
↓
↓ → branch 1
↓ ↓
↓ ↓ → branch 2
↓ ↓ ↓
↓ ↓ ↓
etc.
separate PR from each branch

Rebase excersize
% replay commits from current branch on top of current branch
git rebase --onto main main
% --onto <branch> <origin>
% fix file where ther eis conflict
git add lib/matplotlib/__init__.py
git rebase --continue
%etc.

% try git push:
% failes → no shared history
git push --force-with-lease # retain same pr
alternatively
git -i rebase --onto main main
s for squash
Can make new branch to test rebasing

Cherry-pick excersize
% replay commit from some branch onto current branch
select only some commits

% git checkout main
% git switch -c mult_part_1
% git cherry-pick hash
% git cherry-pick hash...hash % multiple
% git rebase --abort

for next meeting:
[name=Trygve] rebase everything
squash what can be squased
reorder into modes
[name=Trygve] make branches

## 29th of may

Comment on the PR about what the different files do
→ Changes to class hierarchy (new classes)
→ Files with colormaps ()
→ Changes to plotting functions (_axes.py)
→ Methods for showing colorbars (figure.py)

turn off code coverage for figure.py functions,
https://stackoverflow.com/questions/64611388/exclude-a-function-from-coverage

Add test for 'scaler' sent to multivariate colormap

Choose behaviour of constant sent to multivariate colormap https://github.com/matplotlib/matplotlib/pull/26307

break PR up more?
→ vectormappable (scatter?)
→ introducing vectormappable to collections
→ make a figure about how changes fit together → also in order to sell the idea

add test for colormap subclassing

norm legend pairing → log norm etc.

### update notes
- For 2D colormaps data passes throught independent norms [logNorm, etc.], before interpolation to a square or circular colormap (handled with a keyword 'square' or 'circle', could be expanded if other use cases are needed)
- For Nd colormaps, allso passes through independent norms before combining in an additive or subractive way in RGB space (keyword 'add' or 'sub').
- other then RGB is slow, also has to be external 'cause colorspacious
- MultiNorm and MultiCmap written to be subclassed

## 12th of june

VectorMappable containing a list of ScalarMappable is strange,
- Share common ancestor?
- VectorMappble base class - SalarMappable subclass that only handles 1D → probably best idea

- complex dtype to store multivariate data?

## 19th of june

Potential problem: If user does a check `isinstance(_, cm.ScalarMappable)` the current version will break their code
- Use a meta class?
- Let it break?
- Lets just have one class (ScalarMappble) → could also work

copys:
- list of arrays, converting to dtype internally is a copy
- extra diminsion
- should the relevant axis be first or last? (if last, can use view)
- axis keyword?

## 3rd on July

good development in disussions on PR
for next time
- resolve issues
- see if can run stubtest
- PR with Vectormappable -- rebase from colormaps
- soon-ish decide if first axis is x or y
- no meeting next week, conference on west cost, reschedule for different time if needed

## 17 of July

- vectormappable waiting on @timhoffman
- bivariate issues resolved, JBarrows's suggestions put on todo list
- https://trygvrad.github.io/designing-multivariate-colormaps/ -> base for new docs
- imshow, pcolor, pcolormesh mostly ready to go but waiting on mappable discussion

### to dos:
- Take a look at colormap union type, see status and add the union
- cleanup colormaps pr for merging
- [x] see if we can schedule a meeting w/ @timhoffm

## 24th of July

- Moving forward on the colormap PR
- on call say intention is to merge/it's in a clean could be refactored state
- possible for a short paper next year https://ieeevis.org/year/2024/info/call-participation/shortpapers
- "Ten simple rules ..." https://collections.plos.org/collection/ten-simple-rules/
- Written blogpost on designing multivariate colormaps https://trygvrad.github.io/multivariate-colormaps-for-n-dimensions/

### to dos:
- [x] Follow up w/ Tim
- Make a draft for a class/method fig.colorbar_nD()
- different combination modes, i.e.:
plt.imshow((A, B, C), cmap='3VarAddA')
plt.imshow((A, B, C), cmap='3VarAddA_lighten')
Versions evaluated at runtime, [1D colormaps should then also be reversed on runtime, i.e 'viridis_r']
- [x] Add tests for wrong bytorder in multi/bivaraite comlormaps

## 30th of July

- [ ] change PR name
- [ ] update PR to new functionality
- [ ] check codecov
- [ ] typing (later?)
- Moving the image pipeline to the mappable is out of scope here, but we could be moved in the future
- maybe open issue sketching out next steps, would potentially help w/ interpolation and aliasing bugs

Things missing after this PR
- tutorials
- fig.colorbar
- colormaps

## August

# Architecture

## new inheritance

graph TD
    ColorizerInterface --parent of--> ColorizerArtist
    Artist--parent of --> ColorizerArtist
    ColorizerInterface --parent of--> ScalarMappable

# Transition

repeat for all artists that inherit the `Mixin(Artist, ScalarMappable)`

## Aug 21st

- [name=story645] create tracking issue for colorizer + bivariate work after pipeline gets merged
- final report: https://trygvrad.github.io/gsoc-2024-bivariate-colormaps-summary/

- finishing touches to pipeline PR
- add colorizer to docs
- add API and whats new (possibly on follow up) notes
- waiting on Tom & correct docs build for merging approval

- bivariatecolormap
- elliot approved
- hannah plans to approve after docs changes

- next step: exposing the new methods in plotting API
- can only trigger multivariate functionality w/ explicit multivariate cmap
- input shape of data for bivariatecmap to process it