We Keep Coding

Overflow when inserting an specific arithmetic value

I'm currently working on generating a Word document file from a Word Template using data from a JSON variable in java. I'm using the ASPOSE library.
I have a problem with a specific variable. This variable should print a numeric(float) value. However, when the value is 100.0 ,it is sometimes printed as -2147483648 (-2^31) instead of 100.0.
I have to mention that when the value is a double digit float (for example 35.5 and 99.9),the value of the variable is printed correctly. Also when the input value is integer(e.g 100),the correct value is also printed correctly.
I have also tried to use some format strings(<<[variableName]:"0.##">>) inside the expression tag in the Word Template file, but it didn't fix it.
Here is the DOCX template
This is the input value from JSON file
Here is the generated result

#aggelos991
Using the latest available version of Aspose.Words for Java (i.e. 22.2), I was unable to reproduce the issue. Moreover, we had a similar issue in the past, so it seems like you are using an outdated version of Aspose.Words for Java. Could you please upgrade to the latest version and let us know if the issue is still present?

Float type is in the 32bit format, and 100.0 is in the 64bit format(double). 100.0f must be used for proper use.

Aparapi data types

I have following code for studying.
My calculate function produces unexpected results when runs on aparapi.
Is there any problem with my code, or aparapi?
Results are;
Result Num Expected
2026982348 406816880 40681688012
2026982516 406816881 40681688180
2026982594 406816882 40681688258
2026982662 406816883 40681688326
2026982830 406816884 40681688494
2026982898 406816885 40681688562
2026982966 406816886 40681688630
2026983044 406816887 40681688708
2026983212 406816888 40681688876
2026983280 406816889 40681688944
2026983338 406816890 40681689002
2026983506 406816891 40681689170
2026983584 406816892 40681689248
2026983652 406816893 40681689316
2026983820 406816894 40681689484
2026983888 406816895 40681689552
2026983956 406816896 40681689620
2026984134 406816897 40681689798
2026984202 406816898 40681689866
2026984270 406816899 40681689934
Edit: If I set executionMode JTP or CPU, I get true results (result == expected) but on GPU mode there is a problem. I'm using late 2013 macbook pro retina with windows 10.
Edit2: Return line of my calculate method causes the problem. If I return Long.MAX_VALUE, it works. But (long) tc * 100 (or ((long) tc) * 100) not giving (eg. 40681688900)

I think you should review your code checking against Aparapi Java Kernel Guidelines, expecially paying attention to Other restrictions and Beware Of Side Effects sections.
Remember to keep your code as simpler as you can.
Looking to your code, in the calculate method you make wide use of the modulus (%) operator. I would suggest you to log each calculation in order to be able to compare what you get in JTP mode and what you get in GPU mode, in order to find out if there are some issues with this operator.
EDIT:
In your calculate method you use int variables to hold values, which may hold numbers till 2^31-1, namely 2147483647 as known as Integer.MAX_VALUE.
If you perform int value=2147483647; value++; you will get as a result -2147483648 as known as Integer.MIN_VALUE.
You can alternatively try your program with lower starting numbers or change your variable declarations to long, which may hold Long.MAX_VALUE, namely 2^63-1.
Both long and int values are supported by Aparapi.

Hi I'm the primary maintainer over at the new Aparapi.com and new github repository. We are much more active over at the new project home and even have about a dozen releases in maven central already. You might want to consider moving over to the new Aparapi.
With that said I am a developer at the new Aparapi and ran this test case and confirmed it is a legitimate Aparapi bug. I will look into what is causing the bug and hopefully can get a bug fix in for you before the next release. The issue has been reported here if you would like to track it. Remember this for the new Aparapi project so the bug fix is not likely to show up in the older Aparapi project.

Apache Ignite bus_adraln error during installation of cache

I have developers that came to me with an interesting issue in regards to Apache Ignite and Java. This is on a HPUX 11.31 IA platform with Apache-Ignite version 1.3.0-incubating and our HP-UX Java build is 1.7.0.13-jinteg_2015_05_22_03_42-b00. The below error is what has been passed to me but I can't find that Apache-Ignite is supported or tested on HPUX and the BUS_ADRALN error seems to always result in C++ search hits. Anyway if some light could be shed on what our issue is it would be greatly appreciated as I have spent two days trying to find anything on it.
ERROR
"siginfo:si_signo=SIGBUS: si_errno=0, si_code=1 (BUS_ADRALN), si_addr=1fffffffa98e8fe9"
this is thrown after the call to create the readyQueue cache in Ignite. This fatal exception means there is an "invalid address alignment" when trying to memory during the installation of cache.
The developers also sent me a couple logs if that would be of assistance.
A bug in Ignite's Jira for the same issue has been created, the bug has more detailed information about the setup and stack causing the error.
https://issues.apache.org/jira/browse/IGNITE-1493

Chris,
This looks very interesting. When writting a class during marshalling Ignite first writes an internal byte flag, followed by some other data. Therefore offset 17 at the moment of crash mentioned in the ticket makes sense: 16 + 1 (our byte).
I have several assumptions here:
1) We are out of bounds of the array.
2) Byte array element length is not 1.
3) Something else (alignment problem? JMV bug?).
Can you please do the following if possible:
1) Provide GridUnsafeDataOutput.bytes array length at the moment of crash. From the crash report I see that there is some array of length 4096 on the stack. Most probably this is GridUnsafeDataOutput.bytes, but we need to be 100% sure.
2) Run the following program on affected machine and provide the output:
public static void main(String[] args) {
sun.misc.Unsafe unsafe = org.apache.ignite.internal.util.GridUnsafe.unsafe();
System.out.println(unsafe.arrayBaseOffset(byte[].class));
System.out.println(unsafe.arrayIndexScale(byte[].class));
}
This way we will know runtime JVM array parameters.

What language is this (think it's Java?), and how do I test (using a browser ide) the math is correct in it?

div(1, sum(1, exp(sum(div(5, product(100, .1)), -5))))
I'm using this in a Solr query, and want to verify that it is the same as :
Where x is 5.
Is this language Java?
If it is, why am I getting this output here:
http://ideone.com/LWYWtU
If it isn't, what language is this and how do I test it?
Thanks in advance for your help.
EDIT: To add more of the surrounding code, here is the full boost value I'm sending to Solr:
if(exists(query({!frange l=0 u=60 v=product(geodist(),0.621371)})),div(1, sum(1, exp(sum(div(product(5), product(100, .1)), -5)))),0)
The reason I think it might be Java is because in the docs, it says Most Java Math functions are now supported, including: and then lists the math functions I ended up using for code.

Solr is Java, but that's not relevant since this is a set of functions that Solr parses and evaluate itself (and not related to Java, except that the backing functions are implemented in Java).
As far as I can say from what you've mapped the functions correctly, as long as the 5 in product(5) is the same as X. You shouldn't need product there, as the value can be included in div directly as far as I can see.
A way to validate it would be to use debugQuery in Solr and see what the value is evaluated as, and then compare it to your own value. Remember that floating point evaluation can introduce a few uncertanities.

The code of method specialStateTransition(int, IntStream) is exceeding the 65535 bytes

I have a pretty big grammar I don't want to break it into multiple smaller grammars. But The generated Lexer file is giving the following error:
The code of method specialStateTransition(int, IntStream) is exceeding the 65535 bytes
I am using ANTLR-3.2. Please tell me how to remove this compiler error.
Thanks
Preeti

Method specialStateTransition is not always generated. It may be related to some tokens that share common prefixes with other tokens.
See this question/answer for a case where specialStateTransition completely vanished by reformulating just one such token.

I had the same problem recently and managed to fix it by changing the options for the Antlr code generation tool..
C: java org.antlr.Tool –Xmaxinlinedfastates [a number less than 60] grammar.g
Using this option forces the code generator to create a table of DFA states rather than many nested if statements

You can't: you will have to refactor your code. The limit is inherent to Java class files.
From Section 4.10 (Limitations of the Java Virtual Machine) of the VM specification:
The amount of code per non-native, non-abstract method is limited to
65536 bytes by the sizes of the indices in the exception_table of the
Code attribute (§4.7.3), in the LineNumberTable attribute (§4.7.8),
and in the LocalVariableTable attribute (§4.7.9).