BigInteger and BigDecimal expose methods floatValue() and doubeValue().
Add float16Value() to them to support conversions to Float16.
Comments
Yes, if the BigInteger/BigDecimal method weren't public, something like the shared secretes mechanism would be needed to allow the cross-package calls, which is admittedly cumbersome.
30-08-2024
A pull request was submitted for review.
Branch: lworld+fp16
URL: https://git.openjdk.org/valhalla/pull/1228
Date: 2024-08-30 12:48:46 +0000
30-08-2024
The PR has public float16Value() added to BigInteger and BigDecimal because the conversion algorithm needs internal knowledge of these classes.
Float16.valueOf(BigDecimal) justs invokes BigDecimal.float16Value().
Doing the other way round, or without BigInteger and BigDecimal exposing public methods, would be more cumbersome.
30-08-2024
To clarify, I was thinking that for newly added numeric types, the API related to those types would (mostly) be consolidated on the new type, Float16 in this case. That is how external-to-the-JDK types would need to work.
So I was assuming the end-user visible entry point for Float16 -> BigDecimal conversion would be a public method on Float16, even if that called into a non-public method on BigDecimal.
"Put everything in Float16" isn't an iron-clad rule and there are multiple ways the functionality can be provided, etc.
29-08-2024
Float16.valueOf(BigDecimal) would just invoke BigDecimal.float16Value().
Is that what you mean?
29-08-2024
For JDK-8337761, I was thinking the user-callable interface of a BigDecimal -> Float6 conversion would be done via a valueOf(BigDecimal) method on Float16, even if the guts of the implementation was in BigDecimal. It can work either way of course.