Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Subtraction fails for large numbers #51

Open
seanmkauffman opened this issue May 29, 2020 · 2 comments
Open

Subtraction fails for large numbers #51

seanmkauffman opened this issue May 29, 2020 · 2 comments

Comments

@seanmkauffman
Copy link

Applying a numeric function (at least subtraction, possibly others) to numbers large enough to overflow an int will fail. The following code should output 10.0 but actually outputs 0.0.

import ca.uqac.lif.cep.util.Numbers;
import ca.uqac.lif.cep.functions.Function;

public class TestDiff {
	public static void main(String[] args) {
		Function negation = Numbers.subtraction;
		Object[] out = new Object[1];
		negation.evaluate(new Object[]{1590785415514L, 1590785415504L}, out);
		System.out.println("The return value of the function is: " + out[0]);
	}
}
@sylvainhalle
Copy link
Contributor

sylvainhalle commented May 29, 2020

This is "expected", in the sense that the Numbers utility class converts everything into float internally. See for example in the case of Subtraction:

return x.floatValue() - y.floatValue();

Sadly, Java does not allow operations directly on instances of Number, so a conversion to some concrete type must be done. I chose float out of a (sparsely justified) belief that operations on floats are faster than on doubles. A possible solution would be simply to switch all functions in the Number class to doubles internally.

Is there a specific use case that requires you to use such large numbers?

@seanmkauffman
Copy link
Author

The use case is to calculate the difference between millisecond-granularity timestamps, such as those returned by System.currentTimeMillis(). In my case, there is a workaround, because I know that the timestamps in question will fall within a certain period. So, I can just mask off everything except the lower several bits. However, I could foresee circumstances where this isn't possible.

If there was a warning that told the user they lost information from the cast, that might be a helpful solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants