noamaanMulla-03/transformers-issues huggingface dataset:
fix `train_new_from_iterator` in the case of byte-level tokenizers
Author: SaulLu
Pull request: yes

# What does this PR do?
This PR aims at allowing to use `train_new_from_iterator` when the original tokenizer backend was using a ByteLevel pre-tokenization. Before this fix, the vocabulary learn wasn't correct because the initial bytes were missing.

Fixes #17371


## Before submitting
- [ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
- [x] Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md#start-contributing-pull-requests),
      Pull Request section?
- [ ] Was this discussed/approved via a Github issue or the [forum](https://discuss.huggingface.co/)? Please add a link
      to it if that's the case.
- [ ] Did you make sure to update the documentation with your changes? Here are the
      [documentation guidelines](https://github.com/huggingface/transformers/tree/main/docs), and
      [here are tips on formatting docstrings](https://github.com/huggingface/transformers/tree/main/docs#writing-source-documentation).
- [x] Did you write any new necessary tests?


## Who can review?

Anyone in the community is free to review the PR once the tests have passed. Would love to have the feedback of @LysandreJik and @sgugger on the tokenizer part and @Narsil on the pipeline tests (and also the tokenizer if you have more time!) 

<!-- Your PR will be replied to more quickly if you can figure out the right person to tag with @

 If you know how to use git blame, that is the easiest way, otherwise, here is a rough guide of **who to tag**.
 Please tag fewer than 3 people.

Models:

- albert, bert, xlm: @LysandreJik
- blenderbot, bart, marian, pegasus, encoderdecoder,  t5: @patrickvonplaten, @patil-suraj
- longformer, reformer, transfoxl, xlnet: @patrickvonplaten
- fsmt: @stas00
- funnel: @sgugger
- gpt2: @patrickvonplaten, @LysandreJik
- rag: @patrickvonplaten, @lhoestq
- tensorflow: @LysandreJik

Library:

- benchmarks: @patrickvonplaten
- deepspeed: @stas00
- ray/raytune: @richardliaw, @amogkam
- text generation: @patrickvonplaten
- tokenizers: @n1t0, @LysandreJik
- trainer: @sgugger
- pipelines: @LysandreJik

Documentation: @sgugger

HF projects:

- datasets: [different repo](https://github.com/huggingface/datasets)
- rust tokenizers: [different repo](https://github.com/huggingface/tokenizers)

Examples:

- maintained examples (not research project or legacy): @sgugger, @patil-suraj
- research_projects/bert-loses-patience: @JetRunner
- research_projects/distillation: @VictorSanh

 -->


Comments:
_The documentation is not available anymore as the PR was closed or merged._
TF: Merge PT and TF behavior for Bart when no decoder_input_ids are passed
Author: gante
Pull request: yes

# What does this PR do?

The main model for TF and PT have a different behavior when no `decoder_input_ids` are passed. Because of that, the same model with the same inputs has different outputs in the two platforms, in this specific input case.

Looking at the git blame, it seems like [this](https://github.com/huggingface/transformers/blob/main/src/transformers/models/bart/modeling_bart.py#L1202) `if` branch in PT has added after the TF model was added, and we possibly forgot to port it back.

Notes:
1. All slow tests for Bart were run locally;
2. This was caught with the [updated](https://github.com/huggingface/transformers/pull/17588) `pt-to-tf` CLI, which added much stricter tests.

Comments:
_The documentation is not available anymore as the PR was closed or merged._
CLI: Print all different tensors on exception
Author: gante
Pull request: yes

# What does this PR do?

`pt-to-tf` CLI: instead of printing the maximum error and the corresponding tensor when the maximum error was above the defined threshold, prints ALL errors and their corresponding tensors. 

Here's an example:
![image](https://user-images.githubusercontent.com/12240844/172666736-f0253a21-13a4-4853-9d87-1a7fd0b013e5.png)


Comments:
>  It might make more sense if it were called something like find_pt_tf_differences?

It makes total sense, thanks for the suggestion :D 

_The documentation is not available anymore as the PR was closed or merged._
has_attentions - consistent test skipping logic and tf tests
Author: amyeroberts
Pull request: yes

# What does this PR do?

Two linked changes regarding the control of tests being run: 

**PyTorch and TF consistency**: `has_attentions` flag is used in `test_modeling_common.py` to control some of the logic in tests that are run, only applying them if the model has attention(s). This PR adds equivalent logic to tests in `test_modeling_tf_common.py`

**Skipping tests consistency**: `unittest.skip` is used to skip entire tests if they cannot/do not apply to that model e.g. for [input embedding test in ConvNext](https://github.com/huggingface/transformers/blob/f394a2a50d8729cd1ca9b368e330ec50664c3292/tests/models/convnext/test_modeling_convnext.py#L161). For `test_attention_outputs` this was controlled with an if-else statement. This was changed to be controlled with `unittest.skip` instead for two reasons: 1) consistency with the rest of the code base 2) prevent confusing pytest outputs i.e. models without attention are shown to skip `test_attention_outputs` instead of passing it. 

## Before submitting
- [ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
- [x] Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md#start-contributing-pull-requests),
      Pull Request section?
- [ ] Was this discussed/approved via a Github issue or the [forum](https://discuss.huggingface.co/)? Please add a link
      to it if that's the case.
- [ ] Did you make sure to update the documentation with your changes? Here are the
      [documentation guidelines](https://github.com/huggingface/transformers/tree/main/docs), and
      [here are tips on formatting docstrings](https://github.com/huggingface/transformers/tree/main/docs#writing-source-documentation).
- [x] Did you write any new necessary tests?


Comments:
_The documentation is not available anymore as the PR was closed or merged._

@NielsRogge, @ydshieh, @patrickvonplaten adding you to cover: git blame ownership, test ownership, some git blame and general transformers ownership. I hope that's OK. Feel free to remove yourselves and/or add others you think are more suitable.  

Thanks a lot for cleaning this up @amyeroberts ! 

@NielsRogge  I decide not to remove `has_attentions` in this PR, and would like to focus on making the PT/TF test consistency. If that's OK with you, I'll go ahead and merge.
model google/muril-base-cased has effectively infinite model_max_length
Author: AngledLuffa
Pull request: no
Labels: name: bug

### System Info

```shell
>>> transformers.__version__
'4.18.0'
>>> tokenizers.__version__
'0.12.1'
```


### Who can help?

@LysandreJik
@SaulLu


### Information

- [ ] The official example scripts
- [X] My own modified scripts

### Tasks

- [ ] An officially supported task in the `examples` folder (such as GLUE/SQuAD, ...)
- [X] My own task or dataset (give details below)

### Reproduction

The muril-base-cased model has the model_max_length filled out incorrectly.  For example:

```
>>> from transformers import AutoTokenizer
>>> tokenizer = AutoTokenizer.from_pretrained("google/muril-base-cased")
tokenizer.model_max_length
>>> tokenizer.model_max_length
1000000000000000019884624838656
```




### Expected behavior

I am fairly certain the correct size is 512


Comments:
Thank you for the issue @AngledLuffa ! It's interesting to know that this is an important feature for you.

Unfortunately we can't do much from `transformers` as `transformers` only retrieves the `model_max_length` key from the [`tokenizer_config.json` file](https://huggingface.co/google/muril-base-cased/blob/main/tokenizer_config.json). When the `model_max_length` key is not filled in, a default "infinite" value is filled in.

I tried making a topic here:

https://discuss.huggingface.co/t/muril-base-cased-has-infinity-for-model-max-length/17838

Hi @AngledLuffa,

I think the [new feature](https://huggingface.co/blog/community-update) that has just been deployed on the Hub might solve your problem!

It is now possible to open discussions on a hub model (or even propose a change in the tokenizer configuration!). Would you be interested in trying this out? It should ping the authors and invite them to make the change on the hub!

Thanks, I'll give that a try

Closing as the issue seems to be solved thanks to your message on the hub :confetti_ball:
Fix telemetry URL
Author: sgugger
Pull request: yes

# What does this PR do?

I forgot the `api/` in the URL for the telemetry call. :grimacing: 

Comments:
_The documentation is not available anymore as the PR was closed or merged._

lolz

Did you still get a `200 OK` response?

I don't look at the response since the function never errors out (it's not supposed to screw up the script ;-) )

got it!
Add batchnorm running calc weight to porting script
Author: amyeroberts
Pull request: yes

# What does this PR do?

Add two weight name mappings for PyTorch -> TensorFlow necessary for cross-loading weights for batchnorm layers which have been trained with `tracking_running_stats=True`.

This was necessary for cross-loading weights for the ResNet and RegNet ports. #17536 , #17554 

## Before submitting
- [ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
- [x] Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md#start-contributing-pull-requests),
      Pull Request section?
- [ ] Was this discussed/approved via a Github issue or the [forum](https://discuss.huggingface.co/)? Please add a link
      to it if that's the case.
- [ ] Did you make sure to update the documentation with your changes? Here are the
      [documentation guidelines](https://github.com/huggingface/transformers/tree/main/docs), and
      [here are tips on formatting docstrings](https://github.com/huggingface/transformers/tree/main/docs#writing-source-documentation).
- [ ] Did you write any new necessary tests?
NB. I couldn't find tests corresponding to the current weight loading logic.


## Who can review?

Anyone in the community is free to review the PR once the tests have passed. 

Comments:
_The documentation is not available anymore as the PR was closed or merged._

Closing as the change was added in this PR :https://github.com/huggingface/transformers/pull/17271

@sgugger I'll open a follow-up PR to address your comments. 

Actually, I misread the file where it's modified 😅 
It's fine for the conversion like this, it's the code in modeling_utils that does this I don't want (like [here](https://github.com/huggingface/transformers/blob/9fc34235fa3329c918d5ba67ce09a0cc8f399c59/src/transformers/modeling_utils.py#L432)). Sorry I didn't pay close enough attention.
fix use_amp rename after pr 17138
Author: stas00
Pull request: yes

PR https://github.com/huggingface/transformers/pull/17138 renamed `self.use_amp` to `self.use_cuda_amp` but didn't rename it everywhere so deepspeed tests were failing. This PR fixes a few missed bits.

@sgugger 

cc: @ydshieh who reported this 

Comments:
_The documentation is not available anymore as the PR was closed or merged._

Just add info: There are also 3 files in `examples/research_projects/` also use `self.amp`, but as @sgugger told me before, we should/could leave it.

I'm going to merge this before Sylvain gets a chance to look since it impacts Deepspeed's CI, which currently is failing on our tests.

Deepspeed CI is running our deepspeed tests so that they could catch any breakages caused by their changes quickly, but this requires us that we keep our deepspeed tests working.

Thanks for fixing!
Probable bug with `torch_dtype="auto"`
Author: Narsil
Pull request: no
Labels: name: bug

### System Info

```shell
- `transformers` version: 4.20.0.dev0
- Platform: Linux-5.17.8-arch1-1-x86_64-with-glibc2.35
- Python version: 3.9.10
- Huggingface_hub version: 0.4.0
- PyTorch version (GPU?): 1.10.2+cu113 (True)
- Tensorflow version (GPU?): 2.8.0 (False)
- Flax version (CPU?/GPU?/TPU?): 0.4.0 (cpu)
- Jax version: 0.3.1
- JaxLib version: 0.3.0
- Using GPU in script?: No
- Using distributed or parallel set-up in script?: No
```


### Who can help?

@LysandreJik 

### Information

- [ ] The official example scripts
- [X] My own modified scripts

### Tasks

- [ ] An officially supported task in the `examples` folder (such as GLUE/SQuAD, ...)
- [X] My own task or dataset (give details below)

### Reproduction


Reproducing script:

```python
from transformers import AutoModel


model = AutoModel.from_pretrained("Jeevesh8/lecun_feather_berts-96", torch_dtype="auto")
```

This seems to be a bug since the model does not load with error:
```
ValueError: Can't instantiate BertModel model under dtype=torch.int64 since it is not a floating point dtype
```


And the `config.json` actually defines a different `torch_dtype`.
https://huggingface.co/Jeevesh8/lecun_feather_berts-96
https://huggingface.co/Jeevesh8/lecun_feather_berts-96/blob/main/config.json#L29

### Expected behavior


I would expect the model to load regardless, or at the very least not crash while attempting to load with `torch.int64`.



Comments:
cc @stas00 @sgugger 

`torch_dtype="auto"` does not look at the config, but looks at the first parameter (which is also what the config saves automatically FYI). In both cases we should probably ignore the first parameter if it has an int dtype and loop until we get to a float or to the end (for quantized models which have an int dtype everywhere).

This looks like a wrong assumption on my part. 

@sgugger, would you like me to work on the fix if you haven't done this already?

I haven't started working on it, wanted to make sure my suggested solution seemed good to you. If you want to go ahead and implement it, by all means! Otherwise I'll do it sometime later today :-)

I will work on it. Will diagnose this model and see if we have a tiny model that has a similar arrangement to test with.
[modeling_utils] torch_dtype/auto floating dtype fixes
Author: stas00
Pull request: yes

As reported in https://github.com/huggingface/transformers/issues/17583 not all model's have their first param of floating dtype, which lead to failures like:

```
$ python -c 'from transformers import AutoModel; AutoModel.from_pretrained("hf-internal-testing/tiny-bert-for-token-classification", torch_dtype="auto")'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/mnt/nvme0/code/huggingface/transformers-master/src/transformers/models/auto/auto_factory.py", line 446, in from_pretrained
    return model_class.from_pretrained(pretrained_model_name_or_path, *model_args, config=config, **kwargs)
  File "/mnt/nvme0/code/huggingface/transformers-master/src/transformers/modeling_utils.py", line 2004, in from_pretrained
    dtype_orig = cls._set_default_torch_dtype(torch_dtype)
  File "/mnt/nvme0/code/huggingface/transformers-master/src/transformers/modeling_utils.py", line 980, in _set_default_torch_dtype
    raise ValueError(
ValueError: Can't instantiate BertModel model under dtype=torch.int64 since it is not a floating point dtype
```

1. This PR fixes that by searching for the first floating dtype instead.
2. adds test that failed before this PR

Fixes: https://github.com/huggingface/transformers/issues/17583

------------------------------------

**Possible additional TODO that wasn't part of the original report**

@sgugger, we can sort out the saving side of things here as well - I already added an alternative `get_parameter_dtype` => `get_parameter_first_float_dtype` - but I wanted to check in with you if we replace all instances of `get_parameter_dtype`  or only some.

I didn't go ahead with doing that since we have a method called `dtype` which probably should call `get_parameter_dtype`  and add `float_dtype`? Not sure - let's see what you think is the best way to proceed.

Comments:
_The documentation is not available anymore as the PR was closed or merged._

Probably good to merge now, right?
[utils] torch.cpu didn't exist in pt-1.9
Author: stas00
Pull request: yes

PR https://github.com/huggingface/transformers/pull/17138 introduced another issue: `torch.cpu` didn't exist till pt-1.10

Comments:
Thank you @stas00!

_The documentation is not available anymore as the PR was closed or merged._

the CI errors seem to be related to network failure, so ignoring these and merging.
convert assertion to raised exception in debertav2
Author: sam-h-bean
Pull request: yes

# What does this PR do?

Replaces assert with ValueError as per https://github.com/huggingface/transformers/issues/12789.


## Before submitting
- [ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
- [x] Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md#start-contributing-pull-requests),
      Pull Request section?
- [x] Was this discussed/approved via a Github issue or the [forum](https://discuss.huggingface.co/)? Please add a link
      to it if that's the case.
- [ ] Did you make sure to update the documentation with your changes? Here are the
      [documentation guidelines](https://github.com/huggingface/transformers/tree/main/docs), and
      [here are tips on formatting docstrings](https://github.com/huggingface/transformers/tree/main/docs#writing-source-documentation).
- [ ] Did you write any new necessary tests?


## Who can review?

@sgugger 


Comments:
_The documentation is not available anymore as the PR was closed or merged._
Translation/autoclass
Author: mfumanelli
Pull request: yes

# What does this PR do?

Italian translation of autoclass_tutorial.mdx
See issue: https://github.com/huggingface/transformers/issues/17459


## Before submitting
- [x] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
- [x] Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md#start-contributing-pull-requests),
      Pull Request section?
- [x] Was this discussed/approved via a Github issue or the [forum](https://discuss.huggingface.co/)? Please add a link
      to it if that's the case.
- [x] Did you make sure to update the documentation with your changes? Here are the
      [documentation guidelines](https://github.com/huggingface/transformers/tree/main/docs), and
      [here are tips on formatting docstrings](https://github.com/huggingface/transformers/tree/main/docs#writing-source-documentation).

@omarespejel 


Comments:
_The documentation is not available anymore as the PR was closed or merged._

Hi @mfumanelli this period is a little strange:

Producendo questo codice agnostico ai checkpoint significa che se il tuo codice funziona per un checkpoint, funzionerà anche per un altro checkpoint, purché sia stato allenato per un compito simile, anche se l'architettura è differente.

I think it's clearer this way:

Produrre questo codice agnostico ai checkpoint significa che se il tuo codice funziona per un checkpoint, funzionerà anche per un altro checkpoint, purché sia stato allenato per un compito simile, anche se l'architettura è differente.

@nickprock I absolutely agree with you, I'll edit it right away! 🌈

@mfumanelli thank you for the PR! @nickprock thanks for the review 🚀. Amazing team.

@sgugger LGTM :)
Skip tests relying on RepoNotFound errors until bug is fixed
Author: sgugger
Pull request: yes

# What does this PR do?

There is an (hopefully temporary) bug on the Hub right now not returning the `RepoNotFoundError` when someone tries to hit a wrong repo. This PR skips all the tests relying on it until the bug is fixed so the main branch stays green and community contributors don't start getting strange errors.

Will merge as soon as it's green.

Comments:
_The documentation is not available anymore as the PR was closed or merged._
Enable crop_center method to handle (W, H, C) images
Author: alaradirik
Pull request: yes

- Enables crop_center image utility method to handle (W, H, C) and (C, W, H) images
- Added support to expand 2D / (W, H) image arrays to 3D / (C, W, H) shape


Comments:
_The documentation is not available anymore as the PR was closed or merged._
Add skip logic for attentions test - Levit
Author: amyeroberts
Pull request: yes

# What does this PR do?

Adds logic to skip tests checking attentions as LeViT doesn't take `output_attentions` in its prediction call. 

## Before submitting
- [ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
- [x] Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md#start-contributing-pull-requests),
      Pull Request section?
- [ ] Was this discussed/approved via a Github issue or the [forum](https://discuss.huggingface.co/)? Please add a link
      to it if that's the case.
- [ ] Did you make sure to update the documentation with your changes? Here are the
      [documentation guidelines](https://github.com/huggingface/transformers/tree/main/docs), and
      [here are tips on formatting docstrings](https://github.com/huggingface/transformers/tree/main/docs#writing-source-documentation).
- [ ] Did you write any new necessary tests?

Comments:
_The documentation is not available anymore as the PR was closed or merged._
🐛 Properly raise `RepoNotFoundError` when not authenticated
Author: SBrandeis
Pull request: yes

# What does this PR do?

Reverts #17646

If the user is not authenticated, the Hub now returns a 401 error if a repo is not found (either because it does not exist or it is private).

This PR catches that and properly raises `RepoNotFoundError` in `get_from_cache` to be consistent with the previous behaviour.


Comments:
_The documentation is not available anymore as the PR was closed or merged._

> (Style changes in research_project should go in another PR normally, but why not).

Sorry, these changes were applied automatically by `make style`.
I can remove them if that's better 🙂 



Merging since the CI failure seems unrelated
Unable to reproduce gigawords results from google/pegasus-gigaword
Author: xu1998hz
Pull request: no

@patrickvonplaten

Hi Patrick,

I am trying to reproduce the PEGASUS results for gigaword. I used gigawords in datasets library and directly use its testing portion without further preprocessing. I used PegasusForConditionalGeneration, PegasusTokenizer (I used checkpoint from Google, google/pegasus-gigaword) to decode summary using default setting. However, my ROUGE score is bit deviated from the original paper reported (my results roug1,2,L: 28/12/25 vs 39.65/20.47/36.76). I wondered if my setup was incorrect. 

Comments:
Hey @xu1998hz,

We're trying to keep Transformers issues for bugs in the core library. Could you try to use the forum instead: https://discuss.huggingface.co/ ? :-)

This issue has been automatically marked as stale because it has not had recent activity. If you think this still needs to be addressed please comment on this thread.

Please note that issues that do not follow the [contributing guidelines](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md) are likely to be ignored.