Fix two notebooks for script conversion

[danielhanchen]

Summary

These changes make two notebooks run end-to-end when converted to a Python script:

• CodeForces-cot-Finetune_for_Reasoning_on_CodeForces.ipynb
  • Define alpaca_prompt in an executed cell (the inference cell uses alpaca_prompt.format).
• EmbeddingGemma_(300M).ipynb
  • Replace model.dtype usage in torch.autocast with a robust dtype fallback (SentenceTransformer does not always expose .dtype).

Why

The notebook suite runner converts ipynb to py and executes cells as-is. Both of the above cases currently fail after conversion.

Notes

No behavior change to training itself; this only fixes the post-training/inference paths.

[gemini-code-assist]

Summary of Changes

Hello @danielhanchen, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request focuses on improving the robustness of two Jupyter notebooks, CodeForces-cot-Finetune_for_Reasoning_on_CodeForces.ipynb and EmbeddingGemma_(300M).ipynb, specifically when they are converted and executed as Python scripts. The changes address issues where variables were undefined or model dtype attributes were inaccessible, preventing successful end-to-end execution. By making these notebooks more self-contained and resilient to varying model implementations, the PR ensures their compatibility with automated script conversion and execution processes without affecting the core training logic.

Highlights

• Notebook Script Conversion Fixes: Explicitly define alpaca_prompt in CodeForces-cot-Finetune_for_Reasoning_on_CodeForces.ipynb to resolve an undefined variable error during script conversion.
• Robust dtype Handling: Implement a robust dtype fallback for torch.autocast in EmbeddingGemma_(300M).ipynb to handle cases where model.dtype is not directly exposed by certain models like SentenceTransformer.
• End-to-End Execution: Ensure both notebooks run end-to-end when converted to Python scripts, improving the reliability of the notebook suite runner.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Changelog

• nb/CodeForces-cot-Finetune_for_Reasoning_on_CodeForces.ipynb
  • The source field for the initial %%capture cell was updated from a single string to a list of strings, which is a common format for Jupyter notebook JSON.
  • A new code cell was inserted to explicitly define the alpaca_prompt multiline string. This ensures the prompt template is available when the notebook is converted to a script and executed, resolving a previous runtime error.
• nb/EmbeddingGemma_(300M).ipynb
  • The source field for the initial %%capture cell was updated from a single string to a list of strings, aligning with Jupyter notebook JSON formatting.
  • Modified the torch.autocast context manager usage in two places. Instead of directly using model.dtype, a fallback mechanism was introduced: it first attempts getattr(model, 'dtype', None), then next(model.parameters()).dtype, and finally defaults to torch.float32. This handles scenarios where SentenceTransformer models might not expose a dtype attribute directly, preventing runtime errors during inference.

Activity

• No human activity (comments, reviews, etc.) has been recorded on this pull request yet.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request makes two notebooks runnable end-to-end when converted to Python scripts. The changes are sensible and achieve the goal. In CodeForces-cot-Finetune_for_Reasoning_on_CodeForces.ipynb, alpaca_prompt is now defined in a code cell, which is necessary for the subsequent inference cell. In EmbeddingGemma_(300M).ipynb, a robust fallback for model.dtype is added. I've provided a suggestion to make the exception handling in EmbeddingGemma_(300M).ipynb more specific, which will improve code maintainability.

[gemini-code-assist]

Using a broad except Exception: can hide unexpected errors and make debugging more difficult. It's better practice to catch only the specific exceptions you anticipate. In this case, next(model.parameters()) could raise StopIteration if there are no parameters, or an AttributeError could be raised when accessing .dtype.

    except (StopIteration, AttributeError):

[gemini-code-assist]

Similar to my previous comment, it's better to catch more specific exceptions rather than the general Exception. This avoids masking unexpected issues during execution. StopIteration and AttributeError are the likely exceptions to handle here.

    except (StopIteration, AttributeError):