Petascope doesn't parse float constants correctly

[mase@…]

The query

for c in (mean_summer_airtemp)
return
111.0

returns the value 0.0

whereas

for c in (mean_summer_airtemp)
return
111

returns 111 as expected.

The log indicates the queries are being translated into rasql in the expected manner but if I enter the rasql queries from the logs into the rasdaview query box I get the correct answer back for both cases. So I guess there's something in the type translation between rasql and petascope??

RPM 8.3.0-7.el6

[mase@…]

Tomcat Log

[Dimitar Misev]

Sounds like very related to #38

[Dimitar Misev]

Doesn't look like rasdaman returns the right value for that query either

$ rasql -q 'select 111 from mr AS c' --out string
rasql: rasdaman query tool v1.0, rasdaman v8 -- generated on 21.09.2012 08:49:12.
opening database RASBASE at localhost:7001...ok
Executing retrieval query...ok
Query result collection has 1 element(s):
  Result element 1: 1862270976
rasql done.

$ rasql -q 'select 111.0 from mr AS c' --out string
rasql: rasdaman query tool v1.0, rasdaman v8 -- generated on 21.09.2012 08:49:12.
opening database RASBASE at localhost:7001...ok
Executing retrieval query...ok
Query result collection has 1 element(s):
  Result element 1: 7.97311e-41
rasql done.

I think the query doesn't make much sense anyway, did you maybe want to illustrate a wrong answer for a more complicated query? Otherwise I'll close the ticket.

[mase@…]

I tried again on my version:

$ rasql -q 'select 111 from NIR as c' —out string —user xxx —passwd xxx
rasql: rasdaman query tool v1.0, rasdaman v8 — generated on 11.07.2012 18:29:26.
opening database RASBASE at localhost:7001...ok
Executing retrieval query…ok
Query result collection has 1 element(s):

Result element 1: 1862270976

rasql done.

$ rasql -q 'select 111.0 from NIR as c' —out string —user rasadmin —passwd rasadmin
rasql: rasdaman query tool v1.0, rasdaman v8 — generated on 11.07.2012 18:29:26.
opening database RASBASE at localhost:7001...ok
Executing retrieval query…ok
Query result collection has 1 element(s):

Result element 1: 0

rasql done.

which is almost the same as yours; you have a very small float in the second case and my version gives 0. I was wondering why I wasn't getting the same as I reported originally, then I remembered I was using the Query Editor in rasdaview to run the rasql queries. Doing it this way and executing the queries:

select 111 from NIR as c
and
select 111.0 from NIR as c

I get the correct result 111 for both cases with the first having a Type: set< long > and the second a Type: set< float >

So it seems both the rasql command line client and the Petascope WCPS have trouble with floating point numbers. I don't know whether that's from the same cause or by coincidence for different reasons.

Yes I came across this while having problems with a more complex query and narrowed down the cause to the simple illustrative example given showing that it was something to do with interpreting a number with a floating point.

I don't understand why you are proposing to close the ticket.

[Dimitar Misev]

Thanks for checking again! I was suggesting to close the ticket as it seems like a duplicate of #38

Anyway, this behaves very strangely.

• On my local machine, Ubuntu 12.04, 64 bit, the results are right: 111 and 111.0
• On Debian Wheezy 64 bit results are also right
• On ​kahlua (SLES 11, 64 bit) I get 1862270976 and 7.9731E-41

[Dimitar Misev]

Replying to dmisev:

• On my local machine, Ubuntu 12.04, 64 bit, the results are right: 111 and 111.0
• On Debian Wheezy 64 bit results are also right
• On ​kahlua (SLES 11, 64 bit) I get 1862270976 and 7.9731E-41

Running the WCPS queries I mean.

[Dimitar Misev]

Or in more detail:

OS/query	rasql results	WCPS results
Debian 7.0	1862270976 and 7.9731E-41	111 and 111.0
Ubuntu 12.4	111 and 111.0	111 and 111.0
SLES 11	1862270976 and 7.9731E-41	1862270976 and 7.9731E-41

Which OS are you running?

[mase@…]

CentOS release 6.3 (Final)

[Dimitar Misev]

Heinrich, would you look at this issue? Since you're running OpenSuse probably you'll be able to reproduce the bug quickly, but if you can't you can get a CentOS VM (check ​http://212.201.49.163/trac/wiki/VirtualMachine ) for testing.

[mase@…]

For info, I have just upgraded to the 8.3.1-0.el6 RPMs produced last night and get the same behaviour

[Heinrich Stamerjohanns]

It is some big endian / little endian problem.

111 has the following LE encoding: 00000000 00000000 00000000 01101111
while 1862270976 encodes as: 01101111 00000000 00000000 00000000

111.0 is encoded as this on LE systems:
01000010 11011110 00000000 00000000

while 7.9731E-41 is encoded as follows:
00000000 00000000 11011110 01000010

I need to see whether an upcoming patch might already solve the problem. I will
investigate.

[Heinrich Stamerjohanns]

Using the CentOS VM (CentOS 6.0) I cannot yet reproduce the problem.
Are you using Cent OS 6.3 on 64 or 32-bit?
Have you recreated the database?

[Dimitar Misev]

Heinrich, please see comment:10:ticket:38, try maybe with the rasql query. If you can't reproduce on CentOS 6.0 I can give you access to planetserver. That query works fine on SLES 11 (kahlua)

[Dimitar Misev]

I guess if you do upgrade in the VM it will go to CentOS 6.3 btw

[Heinrich Stamerjohanns]

Please check the proposed fix in ticket:38, that should solve this problem as well. This does
not yet explain strange results from rasql queries though.

[Dimitar Misev]

A patch has been submitted, so closing the ticket. Once it's applied I'll propagate it to the RPMs.