How to get consistent scientific notation with limited precision in Bigloo Scheme?

[gurpreetsinghhry]

I'm working with floating-point numbers in Bigloo Scheme, and I encountered a precision issue when performing a simple multiplication:

(* 0.005 1e-9)
;; => 5.0000000000000005e-12
I was expecting the result to be:

5.0e-12
I understand this is due to floating-point imprecision (IEEE 754), but I want to format the output to match what I logically expect—i.e., scientific notation with limited significant digits (e.g., 1 or 2 decimal places after the leading digit).

Expectations:
Output should be as clean as possible, ideally matching how other languages print such numbers (e.g., 5e-12 or 5.0e-12)
I do not want full-precision output like 5.0000000000000005e-12

[svenha]

As you are opening an issue here after the Stackoverflow discussion at https://stackoverflow.com/questions/79676315/ , I guess that the SRFI-48 solution I proposed does not fit your needs. I provided the link above because this might be enough for other users :-)

Maybe we can find a better solution here?

[gurpreetsinghhry]

📝 Follow up

Thanks for the response and the reference to the Stack Overflow discussion.

I wanted to add that this issue did not exist in Bigloo 3.3 — the float formatting output there was clean and as expected (e.g., 5.0e-12). However, in versions after that, we’re seeing outputs like 5.0000000000000005e-12, which breaks formatting consistency across our codebase.

We are using floating-point values in many parts of our code, and while we explored format48, it’s not a viable solution for us due to the volume and scattered nature of these cases.

Could you help identify what might have changed after Bigloo 3.3 that introduced this new behavior in float-to-string conversion?

Also:

1. Is there any in-built functionality in Bigloo that allows us to control floating-point precision (e.g., define number of decimal places or significant digits)?
2. We know Bigloo can be compiled with or without GMP support — does this affect float formatting in any way?
3. Is there any fixed, compiler-level or runtime-level setting that could restore or enforce limited precision formatting (like %.2e style) globally?

We'd really appreciate any guidance or alternative solutions that could minimize manual changes.

Thanks again for your support!

[manuel-serrano]

I guess that this change is due to the introduction in 2011 of a new more efficient algorithm for converting floats into alpha-numeric representation. Here is the reference

@inproceedings{DBLP:conf/pldi/Loitsch10,
  author       = {Florian Loitsch},
  editor       = {Benjamin G. Zorn and
                  Alex Aiken},
  title        = {Printing floating-point numbers quickly and accurately with integers},
  booktitle    = {Proceedings of the 2010 {ACM} {SIGPLAN} Conference on Programming
                  Language Design and Implementation, {PLDI} 2010, Toronto, Ontario,
                  Canada, June 5-10, 2010},
  pages        = {233--243},
  publisher    = {{ACM}},
  year         = {2010},
  url          = {https://doi.org/10.1145/1806596.1806623},
  doi          = {10.1145/1806596.1806623},
  timestamp    = {Mon, 22 Jul 2024 10:17:08 +0200},
  biburl       = {https://dblp.org/rec/conf/pldi/Loitsch10.bib},
  bibsource    = {dblp computer science bibliography, https://dblp.org}
}

How do you print your floats in your code (i.e., which function do you use for printing them)? I don't have any solution on the top of my head to your problem but if you tell us more, maybe we could come up with a solution.

[gurpreetsinghhry]

🧪 More Examples of Float Precision Issues in Output

Thanks for your earlier responses. As requested, here are some specific examples where we are seeing unexpected float formatting in recent versions of Bigloo:

❌ Current Output:

(* 0.005 1e-9)
;; => 5.0000000000000005e-12

(+ 1.0 2.0e-16)
;; => 1.0000000000000002

(+ 0.1 0.2)
;; => 0.30000000000000004

(+ 0.0125 0.025)
;; => 0.037500000000000006

✅ Expected Output:

We expect outputs like:

;; => 5.0e-12
;; => 1.0
;; => 0.3
;; => 0.0375

These long, imprecise float representations are problematic for us in both logs and output files. We would appreciate guidance on:

1. How can we force a clean, rounded float-to-string formatting globally (like %.2e or similar)?
2. Is there a compiler flag or runtime setting that can restore the older Bigloo (v3.3) behavior?
3. Can float output be customized centrally without manually formatting each one?
4. Does GMP support affect this formatting behavior?

Looking forward to any precise recommendations or workarounds.

Thanks again!

[gurpreetsinghhry]

New Examples: Older vs Newer Bigloo Behavior

1. Rounding Negative Zero

• Older Bigloo:

  (round -0.2)   ;; => 0.0

  The result is positive zero.

• Newer Bigloo:

  (round -0.2)   ;; => -0.0

  Now returns negative zero, which is surprising and inconsistent with old versions. This may affect code that expects only positive zero as a result of rounding toward zero.

2. Float Equality Fails Due to Representation

• Older Bigloo:

  (= 5.0e-12  (* 0.005 1e-9))  ;; => #t

  Equality works because both sides produce the same, clean representation.

• Newer Bigloo:

  (= 5.0e-12  (* 0.005 1e-9))  ;; => #f

  Fails equality, likely because (* 0.005 1e-9) is now 5.0000000000000005e-12, not exactly 5.0e-12.

Summary of Compatibility Concerns

• The change in floating-point formatting and equality (plus negative zero output) have introduced subtle but substantial compatibility breaks for codebases relying on Bigloo v3.3-style behavior.
• These differences affect both human-readable outputs (logs, files) and programmatic code logic (e.g., mathematical comparisons and test assertions).

Request for Help

• Is there a recommended way to restore older rounding and equality behavior in newer Bigloo releases (maybe a compatibility mode or flag)?
• Can formatting and numerical output (including zero sign) be globally customized or forced to comply with Bigloo 3.3 conventions, without manually rewriting every instance?
• Are these changes related to how floats are handled internally (such as the switch to the Loitsch algorithm or GMP settings)?
• Any precise recommendations or solutions would be greatly appreciated, especially for minimizing code changes in large or legacy codebases.

[gurpreetsinghhry]

Additional Floating-Point Output and Comparison Issues

Printing Issue
When entering -0.02993, Bigloo displays:

1:=> -0.02993
-0.029929999999999998

Expected: -0.02993 (clean, rounded).

Comparison Oddity

1:=> (> -0.029929999999999998 -0.02993)  ;; #f
1:=> (< -0.029929999999999998 -0.02993)  ;; #f
1:=> ( (= -0.029929999999999998 -0.02993)  ;; #t

Print outputs look different, but equality is true and ordering tests are both false—confusing for code and humans.

Why?

• Due to IEEE 754, -0.02993 can't be exactly represented; the internal value is the long decimal shown.
• = is #t because, at the bit level, the values are the same, though printing shows slight differences.

Request

• Is there any way to globally control float output formatting (for example, limit to 5 decimal digits) to restore old-style, concise output?
• Can a flag or setting restore the legacy (pre-v3.4) printing behavior, to avoid manual formatting everywhere?