Repository: pykeen/pykeen
Issue: Concerning of margin ranking loss formulation issue
Root cause: Algorithmic Error

### Describe the bug

Following example of ComplEx for triples, the margin ranking loss (MarginRankingLoss) is used.
In pykeen\losses.py, MarginRankingLoss inherits from MarginPairwiseLoss which in turn formulates a margin ranking loss as follows.

https://github.com/pykeen/pykeen/blob/b840fc4cd96f2860c018c33c635baa7256bf887b/src/pykeen/losses.py#L550-L554

which contradicts the statement in class MarginRankingLoss(MarginPairwiseLoss) as follows.
```python
    r"""The pairwise hinge loss (i.e., margin ranking loss).

    .. math ::
        L(k, \bar{k}) = \max(0, f(k) - f(\bar{k}) + \lambda)

    Where $k$ are the positive triples, $\bar{k}$ are the negative triples
```
Also, referring to the other resources (e.g. https://pytorch.org/docs/stable/generated/torch.nn.TripletMarginLoss.html), triples margin ranking loss is formulated consistent with the above statement such as
```
    max{pos_scores−neg_scores+margin,0}
```
So, it seems to me that the implementation is mistaken. Could you please clarify on this?

Best regards

### How to reproduce

It is a concern of formulation issue.
A code review of pykeen\losses.py will do.

### Environment

pykeen==1.9.0

### Additional information

_No response_

### Issue Template Checks

- [X] This is not a feature request (use a different issue template if it is)
- [X] This is not a question (use the [discussions](https://github.com/pykeen/pykeen/discussions/new) forum instead)
- [X] I've read the text explaining why including environment information is important and understand if I omit this information that my issue will be dismissed

For reference, this is the code perma-link:
https://github.com/pykeen/pykeen/blob/b840fc4cd96f2860c018c33c635baa7256bf887b/src/pykeen/losses.py#L550-L554

At first glance, I think you are right, and there is an issue in the code. @chris-opendata , would you mind to open a PR to fix this?




But double check because we use a very cleaver abstraction in the definitions of the Margin activations 

> But double check because we use a very cleaver abstraction in the definitions of the Margin activations

Hi cthoyt,

Thank you for your quick reply. I'll defer a PR action as suggested by mberr until a confirmation from your double check. As I debugged, the default activation is ReLU.

The reason that it caught my attention is that the trials of my modeling variants with the method over a month just kept contradicting what the method supposed. So, I by chance looked into the source code and cross-examined with the explanation of the method from other resources, and noticed the ordering difference. I thought about it for quite a while before lodging the report because I don't usually suspect such a simple bug from well-developed packages. But I guess that mistakes do happen from time to time. From software engineer background, I fully understand that. Anyway, I am looking forward to your double check.
BTW, I really appreciate your package and your document website. It provides me food for thoughts on new ideas.

Best regards