mtommila / apfloat Goto Github PK

In the discussion chat for the library Symja, we discussed an problem that occured when I tried to use the library mentioned in an Elasticsearch plugin. We noticed that the issue originates from ApfloatContext.java. The problem is that ApfloatContext seems to set the property cleanupAtExit to true all the time. This leads to the following error:

[2021-05-14T18:30:37,109][WARN ][stderr                   ] [TIM] java.lang.ExceptionInInitializerError
[2021-05-14T18:30:37,109][WARN ][stderr                   ] [TIM]       at org.matheclipse.core.expression.F.<clinit>(F.java:599)
[2021-05-14T18:30:37,110][WARN ][stderr                   ] [TIM]       at org.matheclipse.core.eval.ExprEvaluator.<clinit>(ExprEvaluator.java:133)
...
[2021-05-14T18:30:37,120][WARN ][stderr                   ] [TIM] Caused by: org.apfloat.ApfloatConfigurationException: Error setting property "cleanupAtExit" to value "true"
[2021-05-14T18:30:37,120][WARN ][stderr                   ] [TIM]       at org.apfloat.ApfloatContext.setProperty(ApfloatContext.java:1025)
...
[2021-05-14T18:30:37,122][WARN ][stderr                   ] [TIM] Caused by: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "shutdownHooks")
...
[2021-05-14T18:30:37,124][WARN ][stderr                   ] [TIM]       ... 31 more

Since I'm not allowed to have the RunTimePermission shutdownHooks, I would like to not set cleanupAtExit to true. @axkr from Symja noticed that he cannot

[...] find a properties file in the apfloat's JAR itself.

How are the properties to be set in order to avoid the stuff mentioned above to happen?

Add info about which signing keys will be used for published artifacts.

For security purposes, it would be great if you were able to publish details (in the project docs) about gpg public keys that are "valid" for use when verifying signing artifacts uploaded to maven central.

This allows for "out of band" verification of the expected signing key.

Some examples of other libs publishing their signing keys:

https://square.github.io/okhttp/security/security/#verifying-artifacts

https://github.com/eclipse/jetty.project/blob/jetty-10.0.x/KEYS.txt
https://downloads.apache.org/commons/KEYS
https://downloads.apache.org/logging/KEYS

Hello,

While building with Maven 3.6, I encountered issues related to the type test-jar in the pom files. Replaging those type lines with tests solved the issue. You may find my patch proposal enclosed.

All the best,
Pierre

managing_test_dependency.txt

java.lang.Math implements max and min methods which help API consumers reduce boilerplate and not having to reinvent the wheel. It would certainly be helpful to also offer this option for at least the Apfloat and Apint types; the worst case execution times shouldn't be more than O(n), where n is digit count.

Assumed API call would look as such: ApfloatMath.max(apfloatOne, apfloatTwo);

An arbitrary number of arguments could also be supported, but then the algorithm time becomes O(n^2) in the worst case; this would likely not be of much use to the majority of consumers.

We often need to sort values in a list in a "canonical order" therefore we use the compareTo method of the Comparableinterface.

Can we also define a Comparable method compareTo as "canonical order" in Apcomplex?

• https://github.com/mtommila/apfloat/blob/main/apfloat/src/main/java/org/apfloat/Apcomplex.java

  public int compareTo(final Apcomplex that) {
    int c = real().compareTo(that.real());
    if (c != 0) {
      return c;
    }
    if (that.imag().signum() == 0) {
      if (imag().signum() != 0) {
        return 1;
      }
    } else if (imag().signum() == 0) {
      return -1;
    }
    return imag().compareTo(that.imag());
  }

See also similar issue in the hipparchus project:

• Hipparchus-Math/hipparchus#274

Can you please add support for Mathematica input syntax:

• https://reference.wolfram.com/language/tutorial/InputSyntax.html#7977

maybe not as constructor like here to avoid incompatibilties:

• apfloat/apfloat/src/main/java/org/apfloat/Apfloat.java

  Line 116 in ca0384d

  public Apfloat(String value, long precision)

but in a static "valueOf...()" method?

Please add Erf, ERfi functions and inverse implementations.

See:

• https://mathworld.wolfram.com/Erf.html
• https://mathworld.wolfram.com/Erfi.html
• https://mathworld.wolfram.com/Erfc.html

I'd like to bring forth the aforementioned methods as convenience wrappers for the rather unwieldy and space-consuming compareTo(). Since we already have convenience methods min() and max()

I can also take care of this implementation if necessary, just wanted to post this as a suggestion to know what others think.

The methods would be instance-based and take a single Apcomplex / Apint / Apfloat etc as their argument, returning a boolean.

System.out.println(ApcomplexMath.acos(new Apcomplex(new Apfloat("-2", 30))));

should return (3.1415926535897932384626433832, -1.3169578969248167086250463473), but returns a positive imaginary part.

• https://www.wolframalpha.com/input/?i=N%5BArcCos%5B-2%5D%2C30%5D

When converting double to Apfloat there is an unexpected precision loss:

long P = 60;

double x = Math.nextUp(Double.MIN_NORMAL) * Math.pow(2, 1022); // 1 + 2**(-52)
BigDecimal bx = new BigDecimal(x);
Apfloat ax = new Apfloat(x, P, 10);

// calculate (x-1)*8 => should be 2**(-49)
double r = Math.pow(2.0, -49); // expected value for comparison
double br = bx.subtract(new BigDecimal(1.0)).multiply(new BigDecimal(8)).doubleValue();
double ar = ax.subtract(new Apfloat(1.0, P, 10)).multiply(new Apfloat(8.0, P, 10)).doubleValue();

System.err.println("r:  "+r);  // 1.7763568394002505E-15
System.err.println("br: "+br); // 1.7763568394002505E-15
System.err.println("ar: "+ar); // 1.7763568394E-15

Radix change from 2 to 10 is lossless (as demonstrated by the BigDecimal calculation). Therefore, the result of the calculation (ar) should not be truncated to 10 digits, but have the full 16 digit precision.

The calculator should support more assignment operators:

+=
-=
*=
/=
%=
^=

(Note: ^= means exponentation)

Example:

  hypergeometricU(3.0, 1.0, 0.0);

Should return Infinity

Can we have some special values for this case or a specialized exception?

Same for "ArithmeticException" with "Division by zero" text?

The semantic of the intValueExact method doesn't follow the behaviour in Java standard classes, because it doesn't check for a "nonzero fractional part":

• apfloat/apfloat/src/main/java/org/apfloat/Apcomplex.java

  Line 686 in 6b5e670

  public int intValueExact()

In BigDecimal.html#intValueExact() or especially BigDecimal.html#longValueExact() this check is implemented:

• https://docs.oracle.com/javase/6/docs/api/java/math/BigDecimal.html#intValueExact%28%29

I have written a binary splitting Pi calculator. It calculates a million, ten million, even 100 million digits. However when I try to calculate a 1 billion digits, one of the multiplications exceeds the MAX_TRANSFORM_LENGTH and thus throws a TransformLengthExceededException.
Is that a purely mathematical limit, as the docs assert, or is there some way to extend that limit?

We are planning our next non-snapshot Maven release for the middle of November.

Do you have a next release schedule planned?

Is there a similar method like Math.nextUp and Math.nextDown for Apfloat numbers?

• https://docs.oracle.com/javase/8/docs/api/java/lang/Math.html#nextUp-double-
• https://docs.oracle.com/javase/8/docs/api/java/lang/Math.html#nextDown-double-

Is the hypergeometricPFQ method also already available for calls from outside apfloat library?

• apfloat/apfloat/src/main/java/org/apfloat/HypergeometricHelper.java

  Line 447 in 6e3088c

  public static Apcomplex hypergeometricPFQ(Apcomplex[] a, Apcomplex[] b, Apcomplex z)

HypergeometricHelper is package private.

Is there is no definition for a NaN or INF value in apcomplex?

I would have expected something like this, there the negative real part of the exponent gives an Infinity value?

	public void testApfloatZeroZero() {
		// 0.0 ^ 0.0
		Apcomplex c = ApcomplexMath.pow(Apcomplex.ZERO, Apcomplex.ZERO);
		assertEquals(c.toString(), "NaN");
	}
	
	public void testApfloatNan() {
		// 0.0 ^ (0.0 + I)
		Apcomplex c = ApcomplexMath.pow(Apcomplex.ZERO, new Apcomplex(new Apfloat(0.0, 30), Apfloat.ONE));
		assertEquals(c.toString(), "NaN");
	}
	
	public void testApfloatInfinity() {
		// 0.0 ^ (-1.0 + I)
		Apcomplex c = ApcomplexMath.pow(Apcomplex.ZERO, new Apcomplex(new Apfloat(-1.0, 30), Apfloat.ONE));
		assertEquals(c.toString(), "INF");
	}

  besselJ(-1.9999999999998,3.0)

gives 0.486084660895966 for precision 17.

Should be 0.4860912605858912

Can the method return an overflow exception?

Example Apcomplex parameters s,a:

(-8.384883669867978e17, 0.0)
(-8e-1, 1.199999999999999)

Using a

FixedPrecisionApfloatHelper(17)

precision.

For exact numbers the ulp() method returns 0. This is a problem in combination with the new calculus field interface in the hipparchus library.

@mtommila can you please comment this issue:

• Hipparchus-Math/hipparchus#139

How can we disable using disk storage?

Can you please review my fresnelC, fresnelS implementations:

• https://github.com/axkr/symja_android_library/blob/3bf9f61f8dcc83b75ea2919d7ac2f6e10863ba25/symja_android_library/matheclipse-core/src/main/java/org/matheclipse/core/expression/ApcomplexNum.java#L222
• https://github.com/axkr/symja_android_library/blob/3bf9f61f8dcc83b75ea2919d7ac2f6e10863ba25/symja_android_library/matheclipse-core/src/main/java/org/matheclipse/core/expression/ApcomplexNum.java#L245

Is it worth to move these algorithms to the apfloat library?

hypergeometric2F1(-3.0, -1, -2, 1.0) should return -0.5 but returns an exception with message "Division by zero"

There are several problems with the real and complex agm() functions, at least:

• E.g. complex agm(-1.2, -1.2) does not converge and hangs forever
• Does not check if a = -b (or if a = b)
• For complex values in general, does not choose the "correct" branch of the square root (always chooses the positive square root)
• Real agm unnecessarily rejects arguments that are both negative
• Calculation of the target precision and working precision are buggy

For choosing the "correct" branch of the complex square root, google for "complex arithmetic geometric mean" or see e.g. https://homepage.univie.ac.at/tomack.gilmore/papers/Agm.pdf for an algorithm.

In the Symja project I have the following problem with Bitbucket Maven pipeline.
See this commit for the JUnit test case

This JUnit test gives different results for Windows and other systems:

	public void testApfloat() {
		// simulate Symja expr: N(Pi, 30) + E
		Apfloat f = ApfloatMath.pi(30).add(new Apfloat(Math.E, 30));

		assertEquals(f.toString(), "5.85987448204883829099102473027");
	}

Is this an apfloat bug or a JVM dependent problem?

testApfloat(org.matheclipse.core.system.NumberTest)  Time elapsed: 0 sec  <<< FAILURE!
junit.framework.ComparisonFailure: expected:<5.859874482048838[358462643383]27> but was:<5.859874482048838[290991024730]27>
	at junit.framework.Assert.assertEquals(Assert.java:100)
	at junit.framework.Assert.assertEquals(Assert.java:107)
	at junit.framework.TestCase.assertEquals(TestCase.java:269)
	at org.matheclipse.core.system.NumberTest.testApfloat(NumberTest.java:24)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)

The following code throws an ArithmeticException:

Apfloat re = new Apfloat(1.0);
Apfloat im = new Apfloat(-6.123233995736766e-17);
Apcomplex z = new Apcomplex(re, im);
ApcomplexMath.w(z);

a x a should be faster than a x b, so I suggest creating a new square function that can have better performance.

Create a harmonicNumber() function for real and complex arguments

• https://en.wikipedia.org/wiki/Harmonic_number
• https://medium.com/cantors-paradise/the-celebrated-harmonic-numbers-and-how-to-approximate-them-b8747a4efeec

Can apfloat please support the Catalan constant:

• https://fungrim.org/topic/Catalan%27s_constant/
• https://functions.wolfram.com/Constants/Glaisher/introductions/ClassicalConstants/

Is the "generalized Riemann zeta function" zeta(s,a) also implemented?

The generalized Riemann zeta function is identical to the hurwitz zeta function for Re(a)>0

for Re(a)<0 it is defined as:
$$\sum_{k=0}^{\infty} { ((k+a)^2)^{-s/2} }$$

See:

• https://reference.wolfram.com/language/ref/Zeta.html

toDegrees(0) and toRadians(0) unnecessarily fail as the result is trivially zero.

gcd with a negative number and zero returns the negative number; the absolute value should be returned instead, e.g. gcd(-3, 0) = 3

There is a constructor for double:

  Aprational(double value)

is it also possible to have a constructor (or valueOf method) which converts an approximate number Apfloat to a "nearby" rational Aprational?

  Aprational(Apfloat value)

Can apfloat please support the Glaisher constant:

• https://functions.wolfram.com/Constants/Glaisher/02/0001/

Please provide Gamma(z) function for Apfloat and Apcomplex number argument.

See:

• Wikipedia - Gamma function
• Abramowitz and Stegun - Gamma function