Opened 5 years ago

Closed 4 years ago

#195 closed defect (fixed)

Petascope doesn't parse float constants correctly

Reported by: mase@… Owned by: hstamerjohanns
Priority: major Milestone: 8.4
Component: petascope Version: 8.3
Keywords: Cc: pbaumann
Complexity:

Description

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

Attachments (1)

trac195.log (11.8 KB) - added by mase@… 5 years ago.
Tomcat Log

Download all attachments as: .zip

Change History (17)

Changed 5 years ago by mase@…

Tomcat Log

comment:1 Changed 5 years ago by dmisev

Sounds like very related to #38

comment:2 Changed 5 years ago by dmisev

  • Cc pbaumann added

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.

comment:3 Changed 5 years ago by 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.

comment:4 follow-up: Changed 5 years ago by dmisev

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

comment:5 in reply to: ↑ 4 Changed 5 years ago by dmisev

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.

comment:6 Changed 5 years ago by dmisev

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?

comment:7 Changed 5 years ago by mase@…

CentOS release 6.3 (Final)

comment:8 Changed 5 years ago by dmisev

  • Owner changed from dmisev to hstamerjohanns
  • Status changed from new to assigned

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.

comment:9 Changed 5 years ago by mase@…

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

comment:10 Changed 5 years ago by hstamerjohanns

  • Status changed from assigned to accepted

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.

comment:11 Changed 5 years ago by hstamerjohanns

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?

comment:12 Changed 4 years ago by dmisev

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)

comment:13 Changed 4 years ago by dmisev

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

comment:14 Changed 4 years ago by hstamerjohanns

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.

comment:15 Changed 4 years ago by dmisev

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

comment:16 Changed 4 years ago by dmisev

  • Resolution set to fixed
  • Status changed from accepted to closed
Note: See TracTickets for help on using tickets.