Added option to use the inner product as a dissimilarity measure.

[johnmarktaylor91]

Added an option to use the inner product as a dissimilarity measure. This may or may not be useful for users so feel free to discard this pull request, but it would sometimes be handy as a comparison with other methods when experimenting with new analysis options.

[JasperVanDenBosch]

Thanks for this @johnmarktaylor91 ! We talked about this briefly last Tuesday and one thing that came up was how to deal with the diagonal. When you're done on your end, maybe we can have a quick chat to talk about this and tests, docs etc.? Otherwise if you prefer I can also write more here.

[johnmarktaylor91]

Apologies for the slow response, was out of town this weekend! Good point about the diagonals. My first instinct is to only include the off-diagonals (for symmetry with the other dissimilarity metrics), but could be worth thinking more about... I am free to chat between 12-3pm tomorrow (Thursday), or tomorrow afternoon, if that would be the fastest way to figure things out.

[jdiedrichsen]

Hi John,
I think it would be great to find a way of dealing with Second-moment matrices (i.e. matrices of dot-products) as similarities within the RSA toolbox. The implementation is not 100% straightforward, given the diagnonal. I've been mostly working with those through the PCM toolbox (which has utilities for inner-product matrices), or by reconstructing the second-moment matrices from the crossnobis (or square Eucledian) distances, assuming that the mean patttern is removed.

I would be happy to join the conversation tomorrow if you guys are meeting 12-1pm (EST)....

Let me know!

Joern

[JasperVanDenBosch]

Hi both, I'm afraid I can't meet Thursday or Friday. I can write down my comments later or meet next week. Feel free of course to meet without me. Thanks Jasper

…

Message ID: ***@***.***>

[johnmarktaylor91]

Hi Jasper and Joern, thanks for the comments and glad you think this could be a useful idea--maybe we can start async and if there's something that requires more discussion we can plan a Zoom meeting? Happy to handle the coding end for this.

[johnmarktaylor91]

Thanks again for the chat Joern--just to keep folks updated, our current thought is implement a subclass of the RDMs class (called KMs for "kernel matrix" or some such thing; name can be discussed) that inherits the functions and interface of the RDMs class, with appropriate modifications for the handling of the diagonal (for example, using the entire vectorized kernel matrix), keeping all the various "quality of life" functions for subsetting/subsampling the matrix and so forth. An alternative would be to devise an abstract base class from which both RDMs and KMs inherit, but this might be overkill. Happy to do the plumbing work for implementing this.

[JasperVanDenBosch]

Thanks again for the chat Joern--just to keep folks updated, our current thought is implement a subclass of the RDMs class (called KMs for "kernel matrix" or some such thing; name can be discussed) that inherits the functions and interface of the RDMs class, with appropriate modifications for the handling of the diagonal (for example, using the entire vectorized kernel matrix), keeping all the various "quality of life" functions for subsetting/subsampling the matrix and so forth. An alternative would be to devise an abstract base class from which both RDMs and KMs inherit, but this might be overkill. Happy to do the plumbing work for implementing this.

This seems like the right approach; the inner product matrix is a different beast therefore it should be represented by a separate class. Not to discourage you but I think this could a fair amount of work though; think about the optimized code (cython), unbalanced, and all the downstream functions; presumably some of those would support the KM, and may have to be modified?

Aside from the separate class idea; here's some suggestions for the functionality currently in the PR:

1. It'd be great to have unit tests for the new functionality; of the type that actually tests the computation, i.e. a very small sample of (random or simple) data, compute the expected values, run the API code, then compare the results.
2. We should update the docs, narrative and reference, but obviously this should wait until a decision is made on the interface.
3. If we keep the current interface we should also test (i.e. add an integration test here and there) some of the downstream functions to see what happens when they are fed the new inner product "RDMs". If they are meant to fail we should have some meaningful error message (i.e. "this operation is not supported for inner product matrices"). Maybe with TestCase.assertRaises().

I don't mean to just drop a ton of work on you, happy to help out, talk in more detail, or split this up into multiple PRs if that's more convenient. What do you think?

[nkriegeskorte]

I don’t have strong opinion on the implementational avenues. However, I’m wondering if a superclass for a broader range of “representational summary statistics” might be the most conceptually sound and future proof way. I’m thinking RDM and kernel matrices are unlikely to cover all we will eventually want.We are already working on the D0 and D01 RDMs with all-0 and all-1 patterns included, where the frame has a special status. This one is a special case of RDM. But what if we wanted to use the regional-mean activity profile? Or the regional-mean profile and the RDM? What about noncentered Gaussian and non-Gaussian models of the activity profiles distribution?It would be nice to be able to slot such ideas in and be able to use the model-comparative inference machinery simply by defining a new subclass of a representational descriptor class with associates methods.Sent from my iPhoneOn Jun 21, 2024, at 12:47, Jasper J.F. van den Bosch ***@***.***> wrote: Thanks again for the chat Joern--just to keep folks updated, our current thought is implement a subclass of the RDMs class (called KMs for "kernel matrix" or some such thing; name can be discussed) that inherits the functions and interface of the RDMs class, with appropriate modifications for the handling of the diagonal (for example, using the entire vectorized kernel matrix), keeping all the various "quality of life" functions for subsetting/subsampling the matrix and so forth. An alternative would be to devise an abstract base class from which both RDMs and KMs inherit, but this might be overkill. Happy to do the plumbing work for implementing this. This seems like the right approach; the inner product matrix is a different beast therefore it should be represented by a separate class. Not to discourage you but I think this could a fair amount of work though; think about the optimized code (cython), unbalanced, and all the downstream functions; presumably some of those would support the KM, and may have to be modified? Aside from the separate class idea; here's some suggestions for the functionality currently in the PR: It'd be great to have unit tests for the new functionality; of the type that actually tests the computation, i.e. a very small sample of (random or simple) data, compute the expected values, run the API code, then compare the results. We should update the docs, narrative and reference, but obviously this should wait until a decision is made on the interface. If we keep the current interface we should also test (i.e. add an integration test here and there) some of the downstream functions to see what happens when they are fed the new inner product "RDMs". If they are meant to fail we should have some meaningful error message (i.e. "this operation is not supported for inner product matrices"). Maybe with TestCase.assertRaises(). I don't mean to just drop a ton of work on you, happy to help out, talk in more detail, or split this up into multiple PRs if that's more convenient. What do you think? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[jdiedrichsen]

Jasper, marieke and I had a discussion on this.
The vote is to introduce a superclass (Representational Matrices) that implements the common behaviors, and having the REpresentational Dissimilarity Matrices and a Representational Kernel Matrices class inherited from this

Naming suggesitons are:

Superclass: RMs
Inherited: RMDs and RKMs

Does this sound good?
J

[HeikoSchuett]

Hi! I only just noticed this discussion, sorry for being late to the party!

Overall your discussions all seem reasonable to me. To support different summary matrices, a superclass seems to be the clean approach.

One thing to note is that this will most likely entail separate implementations of some of the convenience functions like extracting vectors/matrices subsetting etc., because variables like the diagonal, distances to 0 and/or 1 and so on will need a different treatment than RDMs. Nothing to be afraid of, I think and if we get this right the bootstrap methods and many of the comparison techniques should keep working, but I think this is good to note.

[nkriegeskorte]

the superclass of representational descriptors makes sense to me. the naming convention you proposed seems like a good start. RMs - RDMs - RKMs regarding "representational matrix" (RM), one could argue that "matrix" is not terribly informative, and perhaps we want non-matrix descriptors like the mean-activity vector and the RDM. but RD for "representational descriptor" is confusing because the D is associated with dissimilarity. an alternative may be: representational_descriptors - RDMs - RKMs or representations - RDMs - RKMs an alternative to representational kernel matrices (RKMs) would be representational similarity matrices (RSMs). the latter is imperfect for kernel matrices, because the diagonal reflects the squared norms rather than some number encoding identity. are there other examples where RSM seems preferable? representational_descriptors - RDMs - RSMs we could start with RKMs for now and if the need arises we can still add alternative subclasses. i think we're on a good track and these are really details. niko

…

On Tue, Jul 2, 2024 at 7:42 PM Heiko Schütt ***@***.***> wrote: Hi! I only just noticed this discussion, sorry for being late to the party! Overall your discussions all seem reasonable to me. To support different summary matrices, a superclass seems to be the clean approach. One thing to note is that this will most likely entail separate implementations of some of the convenience functions like extracting vectors/matrices subsetting etc., because variables like the diagonal, distances to 0 and/or 1 and so on will need a different treatment than RDMs. Nothing to be afraid of, I think and if we get this right the bootstrap methods and many of the comparison techniques should keep working, but I think this is good to note. — Reply to this email directly, view it on GitHub <#395 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALWMWYBUAJGE7Q77CEVQRQTZKM3GPAVCNFSM6AAAAABJAL3YBSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMBUGY4TQMJYGA> . You are receiving this because you commented.Message ID: ***@***.***>