Weird behaviour when creating a new BigDecimal from within Enso

[radeusgd]

To reproduce, create a file polyglot/java/foo/foo/Foo.java and compile it:

package foo;

import java.math.BigInteger;
import java.math.BigDecimal;

public class Foo {
    public static BigDecimal generate(BigInteger i) {
        BigDecimal d = new BigDecimal(i);
        System.out.println("In Java " + i + " is mapped thru new BigDecimal() to " + d);
        return d;
    }
}

and then run the following src/Main.enso:

from Standard.Base import all

polyglot java import foo.Foo
polyglot java import java.math.BigDecimal


main =
    x = 2^70

    IO.println (x.to_text + " is " + (Meta.type_of x).to_text)
    
    d = BigDecimal.new x
    IO.println ("In Enso " + x.to_text + " is mapped thru BigDecimal.new to " + d.to_text + " (" + (Meta.type_of d).to_text + ")")

    d2 = Foo.generate x
    IO.println ("which back in Enso is " + d2.to_text + " (" + (Meta.type_of d2).to_text + ")")

    IO.println ("What about smaller numbers? " + (BigDecimal.new 123).to_text)

it yields

1180591620717411303424 is Integer
In Enso 1180591620717411303424 is mapped thru BigDecimal.new to 0 (java.math.BigDecimal)
In Java 1180591620717411303424 is mapped thru new BigDecimal() to 1180591620717411303424
which back in Enso is 1180591620717411303424 (java.math.BigDecimal)
What about smaller numbers? 123

As we can see, surprisingly - when I call BigDecimal.new in Enso, it creates a new BigDecimal of value 0. However, if I call new BigDecimal(_) in Java and then pass the value back to Enso, the value is correctly preserved. Interestingly, if the BigDecimal.new argument is a small number, it correctly creates a new BigDecimal instance of the correct value.

This seems like a bug in the handling of interoperability of Big Integers. I'm not exactly sure if this is a bug directly in Enso or in Truffle interop - this remains to be discovered. If we discover it's a Truffle issue we can create another bug report there, but I wanted a place to track this problem.

[JaroslavTulach]

Quick workaround:

polyglot java import java.math.BigDecimal
main =
    h = 2^70
    BigDecimal.new h 0

[enso-bot]

Jaroslav Tulach reports a new STANDUP for yesterday (2023-09-15):

Progress: - Fixed BigDecimal (not integer) by integrating #7817

• Investigating "type by name": Enso method to get a type/constructor by fully qualified name #7797 (comment)
• Updating Espresso PoC: 2ad2b44
• emails, PRs, standups, reviews
• complains about logging: https://github.com/enso-org/enso/pull/7809/files#r1326856518
• Python interop discussion: numpy numbers aren't reported as numbers oracle/graalpython#354 (comment) It should be finished by 2023-09-16.

Next Day: Get Espresso support into testable/demoable state

GitHub

Reduce extra output in compilation and tests by hubertp · Pull Request #7809 · enso-org/enso

Pull Request Description I couldn't stand the amount of extra output that we got when compiling a clean project and when executing regular tests. We should strive to keep output clean and not p...