TIP-697: Migrate Floating-Point Calculations from Math to StrictMath

[halibobo1205]

tip: 697
title: Migrate Floating-Point Calculations from Math to StrictMath	
author: halibobo1205@gmail.com
discussions to: https://github.com/tronprotocol/TIPs/issues/697
status: Draft
type: Standards Track
category: Core
created: 2024-10-30

Simple Summary

   This TIP proposes migrating Java-Tron's floating-point calculation library from java.lang.Math to java.lang.StrictMath while keeping data consistent and preparing for future JDK version upgrades and multi-platform support.

Motivation

   Up to GreatVoyage-v4.7.6(Anaximander), Java-Tron has utilized the class Math for floating-point calculations. However, the class Math may yield varying calculation results for identical inputs across different hardware platforms and JDK versions. As Java-Tron's released versions have exclusively supported JDK8 and x86 environments, data inconsistency issues related to the class Math have not yet emerged.
   Looking ahead to potential cross-platform support and broader JDK version compatibility, Java-Tron needs to transition from java.lang.Math to a mathematical library that ensures consistent calculation results across platforms and newer JDK versions.
   This TIP also examines maintaining data consistency throughout the TRON network during the migration process without impacting consensus dating back to the genesis block.

Specification

   As noted above, the class java.lang.Math may produce different calculation results across platforms and multiple JDK versions. Although this hasn't affected Java-Tron's data consistency due to limited platform and JDK version support, replacing the java.lang.Math class is essential for future cross-platform and multi-JDK version support.
   According to Java's official documentation, class java.lang.StrictMath provides the equivalent functions of class java.lang.Math can produce the same results across different hardware platforms and the JDK versions. This makes java.lang.StrictMath is an ideal replacement for the java.lang.Math class in this scenario.
   Hence, we propose implementing a uniform replacement of the java.lang.Math class with java.lang.StrictMath class throughout Java-Tron via this proposal.
   It's important to note that the java.lang.StrictMath class may exhibit slight variations in calculation results compared to the java.lang.Math library in certain scenarios. This TIP will list all relevant differences in Java-Tron and analyze their potential impact on consensus. Any changes affecting consensus will only be implemented network-wide after proposal approval, ensuring the Math class migration does not compromise data consistency.

Rationale

   StrictMath guarantees reproducible results, independent of the JDK version, hardware implementation, etc. To help ensure the portability of Java programs, the numeric functions in this class require that they produce the same results as certain published algorithms. These algorithms are available from the well-known network library Netlib as the package "Freely Distributable Math Library."
   Key differences between Math and StrictMath:

• Determinism:
  • StrictMath guarantees reproducible results across all platforms
  • Math may use platform-specific optimizations for better performance
• Performance:
  • Math is generally faster as it can use platform-specific implementations
  • StrictMath might be slightly slower but provides better reproducibility
• Usage considerations:
  • Use StrictMath when you need exact reproducibility across different platforms
  • Use Math when performance is more important than exact reproducibility
  • The numerical differences between Math and StrictMath results are usually very small

Backwards Compatibility

   Since consensus-affecting changes will only be activated post-proposal approval, this migration maintains backward compatibility and preserves consensus from the genesis block onward.

Implementation

TBD.

[endiaoekoe]

This TIP will list all relevant differences in Java-Tron and analyze their potential impact on consensus. Any changes affecting consensus will only be implemented network-wide after proposal approval, ensuring the Math class migration does not compromise data consistency.

Could you make the above descriptions clearer? eg: what kind of potential impacts it will have when this proposal is approved?

[tomatoishealthy]

It's important to note that the java.lang.StrictMath class may exhibit slight variations in calculation results compared to the java.lang.Math library in certain scenarios. This TIP will list all relevant differences in Java-Tron and analyze their potential impact on consensus. Any changes affecting consensus will only be implemented network-wide after proposal approval, ensuring the Math class migration does not compromise data consistency.

Can you show which modules will be affected?

So that the community can confirm whether the change will affect their own interests

[halibobo1205]

Currently the Bancor trading and DynamicEnergy are known to use the math.pow method for floating point calculations. @endiaoekoe @tomatoishealthy