[Solved] Abbreviated conjunction for two-argument relations

[Jan_J]

Which notation is better:
a < b < c
or
(a < b) and (b < c)
In “paper math” they are equivalent. So in Fortran, C and Python, while in Basic
a < b < c
is equivalent to
a < (b < c)
I used to think that spreadsheet formulae work like the last example. So is in Excel, OOo, AOO, Gnumeric, LO < 4.

Today, using LO 4, i reported = 10 <= 11 <= 12 returning TRUE. Amazing! there was no official announcement about change of semanitcs. What about compatibility break to other software? what about broken logic in existing documents?
I like that way of computing more than strict two-argument approach, but it would be honest to give at least a warning. I am involved into AOO/LO society and heard nothing about it. What can tell “ordinary user”, whose calculations abruptly change its semantics?
A shame.

// I tried to recalc the same in AOO 3.4.1. My installation (rpm) crashes after each attempy to program any formula in calc. Need to go back to OOo 3.3.0. But there's another question.

[Villeroy]

RTFM! All spreadsheets provide the same functional programming language since 3 decades.
Regardless of what the LibO fools try to do, AND is still a function as it used to be:
=AND( A1<B1 ; B1<C1 )
returns TRUE if each of the arguments is TRUE.

[Jan_J]

You did not understand the problem, maybe my English is too poor today...

Version with AND is obvious. The problems that in most part of software
a < b < c is treated as right-grouped a < (b < c) with bool to int typecast, but in recent release of LO it seems rather to be an abbreviation for AND clause.

So in AOO and Excel 10<11<12 returns FALSE as shortcut of 10 < (11<12), while in LO 4 we get TRUE (as abbrev. of 10 < 11 \and 11 < 12 ?). Try it yoursef.

I have discovered the bug showing to a student a difference between expression evaluation by Python and by spreadsheet -- old trick, used by me for years. And wondered a lot...

[Villeroy]

No, I can not try out. I won't install LibreOffice 4 because they are so extra smart.
Can you post that issue on a dedicated LibO channel? I'll go and get some pop corn.

[gerard24]

a < b < c is treated as right-grouped a < (b < c) with bool to int typecast, but in recent release of LO it seems rather to be an abbreviation for AND clause.

I think a<b<c is treated as (a<b)<c, not similar to AND.
Try 12>11>10 and you will have FALSE.

[Jan_J]

You probably are right. There is \infty times greater chance that some guys changed parsing direction than that they reinvented syntax. But the problem of compatibility stays open.

@ Villeroy
Have a good taste.
Despite we like LO or not, the forum is open for its users, so I consider the problem worth to be reported. Btw, https://bugs.freedesktop.org/show_bug.cgi?id=60671

[acknak]

I don't know if it's taught as such, but my personal rule is to avoid depending on operator association rules like this. Even if they do what you want without parentheses, you can't "just read" the expression: you have to know the rules (which are arbitrary) in order to know what the expression will do.

So which is the "right" behavior is to me not so important. Better all around to avoid the rule.

All that aside, the ODF standard (http://docs.oasis-open.org/office/v1.2/ ... #refTable0) says that comparison operators are left-associative, meaning that 10<11<12 should be calculated as (10<11)<12 => T.

But the result is still a coincidence of how logicals are represented, no? If I wrote 0.1<0.2<0.3, the answer would be FALSE: (0.1<0.2)<0.3 => (1)<0.3 => F.

As I said, better to avoid it entirely and write out explicitly what you want.

[Jan_J]

I don't know if it's taught as such, but my personal rule is to avoid depending on operator association rules like this.

You are absolutely right. This is the case I point out how easy it is to loss a sense in computations.

[Jan_J]

The thread initialized by me has no sense. I have missed some important facts. Really, I was overloaded today to ant it would be much better not to start any discussion.

The thread is for deletion for me, if the forum's regulation rules allow for this.

[acknak]

We generally don't remove threads unless there is some pressing reason to do so.

It's no problem to leave the thread in case someone else may be interested to read it or maybe follow up with some further information.

And we've all had that sort of day--no worries!