Rocket U2 | UniVerse & UniData

I think this is what's happening. When I compare the two strings above, Universe Basic is detecting that they're numeric strings and is trying to compare them as numbers. As part of the conversion to numbers, it must be rounding them to the nearest 16 digit integer. If you round the above strings to 16 digit integers they are equal.

This is clearly a bug however. If I have two strings I want to compare them as strings. Especially if they're long strings of characters.  I shouldn't have to do anything special to compare two long strings just because they happen to all be made of of characters 0-9.

In this case, the strings are coming from both a file and a scangun.  I'm not performing any math operations against them. They shouldn't be attempting any number conversion before doing the compare.

Are there any $OPTION or account flavor settings that will fix this???

Joe,

Please look at SCMP() which shoudl do what you want I think. Otherwise opening a Support ticket. 

Regards

JJ

Hi John,

It looks like it's a bug then. This code:

A = "108100636331677141"
B = "108100636331677134"
PRINT SCMP(A,B)

Prints "1" so it still thinks those two strings are equal. 

Strangely, "PRINT A+0 = B+0" prints "0" so it knows they're not equal. 

It seems like I knew the answer at one point. The issue is very familiar but I can't find anything in my emails, notes or online posts about it.

I don't have much faith in a Rocket support ticket. We might have to force the compare by prefixing all the the numbers with a character. That would make them all 19 characters but putting an alpha number in the first position avoids this bug. It will require going through all our code that references the number and adjusting it. Not something anyone wants to do right now.

A = "108100636331677141"
B = "108100636331677134"

crt 'A = B = ' : (A = B)

A = INT(A)
B = INT(B)

crt 'A = B = ' : (A = B)

Result:

A = B = 1
A = B = 0

When UniVerse does a comparison of two strings it tries to convert them to floating point numbers before comparing them, which is why it thinks they are the same. If you first coerce them to integers then they will not be the same as of when UniVerse started supporting 64 bit integers some time ago.

Henry

Hi Henry,

That makes sense.  Thinking about it, I've been thinking that forcing a numeric compare against two strings is a bug. I was thinking that if I wanted a numeric compare I would a zero to the string to force a conversion. Maybe that mindset was coming from all the work I've done in other languages.

Thinking about it further I can understand Universe's default. Everything coming from a dynamic array is a string. If you didn't check for a number before comparing values it would screw things up since, for example, 2 would be considered > 10.

I think the problem here is that they're converting to floating point first. I'd say don't do that unless you've got a decimal in the string. That would leave integer strings as integers and keep this specific scenario from happening. Floats are weird anyway.  It's best to avoid them unless you need high precision. In most business applications, you don't.

I wonder if the other MVDB flavors have the same issue?

Anyway, thanks for the help John and Henry. I appreciate it.

Hi Joe

Check out the UniVerse configurable parameter EXACTNUMERIC.

EXACTNUMERIC - Specifies the number of digits of precision before rounding occurs. The maximum is 57 digits and the minimum (default) is 15 digits.

Increasing this should address your problem.

Hi Kurt,

That sounds like what we're looking for but it looks like it can affect a lot of other things. I don't think we can safely use it without a lot of testing of the entire system. That's not practical right now.

This pointed me to the WIDE0 parameter which looks like it directly affects how the double precision numbers are compared. This looks like an even closer match to fix our specific issue. It suffers from the same issue though. It potentially affects other areas that we have no way to effectively test.

We've decided that the safest approach in our case is to append "A" to the numeric strings whenever we use the equal operator. Since the values are all fixed at 18 digits, a string compare will always work even if we're checking GE or LE. It completely avoids Universe's penchant of doing a number conversion first.  Using the INT function would also work but I worry that on a different system it might also have trouble with an 18 digit number so out of precaution, I'm avoiding that also.

Thanks again to everyone who has posted. I appreciate the time you've taken.