strings are incompatible with operators and, or, xor etc

[ChunkyPanda03]

I originally created a procedure that used this logic in idl 6.3 and got this error when testing in gdl 1.0.1, tested this in both in linux and windows (gdl v1.0.5-dirty) both don't know if this has been fixed in the latest version as I haven't tested

pro testing
    print, '\' eq ('/' or '\')

end

[ChunkyPanda03]

I couldn't put a label on this odd.....

[ChunkyPanda03]

@GillesDuvert This was part of procedure where I parse file plus path to pull out the filename. The provided code is an example or check that gdl is doing what it is supposed to, however the provided statement does not work so it has failed the check so this would lead to incompatibilities with genuine IDL code bases. I have to use one of the largest repositories of idl code and I will report discrepancies between IDL (v6.3) and gdl the best I can as it will help with sharing my scientific work under the GNU project.

[GillesDuvert]

@ChunkyPanda03 excellent! Patching this particular bug should be very easy as it is in the C++ code. I made some tests and I think that only 'and' and 'or' are the two operators that need to be patched for strings. ... And that 'and' should return the 2nd string and 'or' the first....

[ChunkyPanda03]

is it incorrectly detecting an escape sequence?

[GillesDuvert]

No, it's just not programmed (yet) I mean, at some point the 'or' operator code sees 2 gdl objects, and since they are of type string, throws an error when it should not.

[ChunkyPanda03]

ighty

[alaingdl]

I try to clarify the title for this bug report

OK, GDL did not implemented the OR and AND for strings

GDL> print, ('b' or 'a')
% Cannot apply operation to datatype STRING.

Thanks for the bug report !

(not clear for me if (&& and AND) and (|| and OR) are equivalent https://www.nv5geospatialsoftware.com/docs/Logical_Operators.html )

[GillesDuvert]

Thank you @ChunkyPanda03, it further appears that there is an inversion between and and or in some cases, independently of being a string or not. This have priority.

[ChunkyPanda03]

@alaingdl I have changed the title to better represent the problem

[ChunkyPanda03]

@alaingdl I see that the eq and ne operators works with strings if you would like me and my colleague @alexbazzi can take a crack at implementing the feature. Or would you prefer working on the feature?

[GillesDuvert]

I'm currently working on it, but it's good to know there are knowledgeable and helpful people around!

[GillesDuvert]

FYI The real problem here is not adding support for strings in AND and OR (done locally), it is that the gdl code for the OR operator in case of non-integers (that do not use C++ bitwise '|' and '&') is just wrong as for optimization reasons it does not care too much about which operand is left and which is right :frowning_face:
Obviously people rarely use a bitwise operator on non integers (and your strings are non-integers) otherwise we would have heard about that much earlier!

[ChunkyPanda03]

I am glad that you got to this so quick however the output is not the same as idl Sorry for the bad quality this is a screenshot from my remote work computer. Is it comparing a string type to a bool to my understanding I think IDL distributes through the or operator

[ChunkyPanda03]

Never mind I guess my code never checked the first case odd nm case closed

[GillesDuvert]

For the record, test_indepth_basic_functions.pro enable testing all and every possible operator cases against IDL --- which is quite complicated due to the numerous programmatic possibilities internal to GDL. The test now passes for strings, too. But nobody's perfect, and omissions should be reported.

[ChunkyPanda03]

@GillesDuvert its not you I thought that idl distributes logical statements it however it just chooses to compare the closest ones the issue is my fault. your update is correct.