fix: f32→f64 precision artifact in temperature causes provider 400 errors

[Boomboomdunce]

Problem

f32 as f64 preserves the binary representation, producing values like 0.699999988079071 instead of 0.7. Some OpenAI-compatible providers (e.g. Zhipu GLM-5) reject these with a 400 error ("API 调用参数有误").

Fix

Added round_f32_to_f64() helper that formats to 6 decimal places before parsing back to f64. Applied to the temperature field in build_rig_request().

Test

Regression test test_round_f32_to_f64_no_precision_artifacts verifies:

• round_f32_to_f64(0.7_f32) == 0.7 (no artifact)
• 0.7_f32 as f64 != 0.7 (confirms the original bug exists)

Impact

This affects all providers using RigAdapter (OpenAI, Anthropic, Ollama, Tinfoil, OpenAI-compatible). The fix is purely cosmetic for providers that tolerate the artifact, and unblocks providers that don't.

[gemini-code-assist]

Summary of Changes

Hello, 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 resolves a critical compatibility issue with OpenAI-compatible providers caused by floating-point precision artifacts during f32 to f64 conversion. By introducing a new helper function to correctly round and convert f32 values for parameters like temperature, it ensures that API requests are properly formatted, preventing 400 errors and improving overall provider interoperability for all RigAdapter users.

Highlights

• Precision Fix: Addressed a floating-point precision issue where direct f32 as f64 conversion resulted in artifacts (e.g., 0.7 becoming 0.699999988079071).
• Provider Compatibility: Resolved 400 errors encountered with certain OpenAI-compatible providers (like Zhipu GLM-5) that rejected these imprecise f64 values for parameters like temperature.
• New Helper Function: Introduced round_f32_to_f64() which formats f32 values to 6 decimal places before parsing them back to f64, ensuring accurate representation.
• Application: Applied the round_f32_to_f64() helper to the temperature field within the build_rig_request() function.
• Regression Test: Included a new test, test_round_f32_to_f64_no_precision_artifacts, to verify the fix and confirm the original precision issue.

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.

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 addresses an issue where converting an f32 temperature value to f64 introduces precision artifacts, causing 400 errors from some LLM providers. The fix introduces a round_f32_to_f64 helper function that rounds the value by formatting it to a string with 6 decimal places and parsing it back to an f64. This is a clever solution to the floating-point representation problem. The change is well-tested. My only suggestion is to make the parsing logic more robust by using expect() instead of unwrap_or(), to ensure any unexpected parsing failures are caught immediately rather than silently falling back to the old, problematic behavior.

[gemini-code-assist]

The use of unwrap_or with a fallback to val as f64 could silently re-introduce the precision artifact issue if s.parse::<f64>() were to fail for some unforeseen reason. Since format!("{:.6}", val) should always produce a string that can be parsed back into a float, it's safer to treat this as an infallible operation. Using .expect() would cause a panic if parsing fails, making any unexpected behavior immediately obvious during development and testing, which is preferable to silently using the incorrect value.

Suggested change

	s.parse::<f64>().unwrap_or(val as f64)
	s.parse::<f64>().expect("formatted f32 should always be parsable to f64")

References

1. Prefer expect() to explicitly fail with a clear message if an operation's setup or expected outcome is not met, especially when unwrap_or() could silently lead to incorrect logic. This principle extends beyond tests to general code robustness, ensuring immediate detection of unexpected behavior.

[ilblackdragon]

Thanks for the work on this, @Boomboomdunce! Great catch on the f32→f64 precision artifact. I've picked up your changes and continued them in #1450.

The new PR includes your original work plus:

• Merge with latest staging
• Fix for the Clippy redundant_closure lint (.map(|t| round_f32_to_f64(t)) → .map(round_f32_to_f64)) which was the sole CI blocker

You're credited as co-author on the commit. Feel free to review the new PR!