IFTE odd behaviour

[BruceH]

Using the PC emulator (2018 10 16 build) in Home:

Code:

IFTE(1,2,3)                2
IFTE({},2,3)               0
IFTE({1},2,3)            {2}

The first is as expected; the second is unexpected but I could live with it; the third is 'interesting'. :-)

Edit: CAS mode using 'when' is nearly as quirky: when({1},2,3) just returns unevaluated which is okay - sort of the CAS saying "I've no idea what you meant here" but if you edit it, the when changes into the ? : form and goes back again when you enter.

[Tim Wessman]

Second may be a bug (not sure, would have to check the code), but the third is perfectly expected and as designed. It is doing list processing on your input.

Try IFTE({1,0,1,0,0),2,3) and what do you get?

[Tim Wessman]

Ok yes, this is specifically testing for an empty list here and returning 0 as a sign that there was no input in the list. I think all 3 case are fine here. Thoughts?

[ijabbott]

(10-11-2019 12:32 PM)Tim Wessman Wrote:  Ok yes, this is specifically testing for an empty list here and returning 0 as a sign that there was no input in the list. I think all 3 case are fine here. Thoughts?

Now you've explained the list processing aspect, perhaps it would be more logical to return an empty list?

[rprosperi]

(10-11-2019 11:09 AM)Tim Wessman Wrote:  Second may be a bug (not sure, would have to check the code), but the third is perfectly expected and as designed. It is doing list processing on your input.

Try IFTE({1,0,1,0,0),2,3) and what do you get?

Assuming this should be IFTE({1,0,1,0,0},2,3), I'd guess {2,3,2,3,3} ?

[BruceH]

(10-11-2019 11:09 AM)Tim Wessman Wrote:  Second may be a bug (not sure, would have to check the code), but the third is perfectly expected and as designed. It is doing list processing on your input.

Try IFTE({1,0,1,0,0),2,3) and what do you get?

Thanks Tim, I'd forgotten about list processing - it wasn't what I was investigating so wasn't uppermost in my mind.

Now you mention it though, what would make sense would be that processing an empty list results in an empty list - because there is nothing to process. (D'uh). Which kinda suggests that IFTE({},2,3) should return an empty list.

The result I was originally looking for (which was some sort of true or false based on there being something in the list) I can get easily enough with IFTE(SIZE({}),2,3)).

[Claudio L.]

It's a tricky one:

IFTE means

IF is_true THEN was_true ELSE was_somethingelse

I would expect to either evaluate to was_true if {} is considered true, or was_somethingelse if it is anything other than true.
I think {} would fall in the "other than true" category, hence it should return was_somethingelse, or perhaps a list with the result of was_somethingelse inside.

Returning 0 doesn't do was_true or was_somethingelse, therefore it's more like this:

IF is_true THEN was_true ELSE was_somethingelse BUTIFNONEOFTHEABOVE do_whaaat?

adding a third possible execution path that does not evaluate either of the 2 statements provided, returning an arbitrary outcome that nobody wants or expects.
My expectation would be that one of the statements would be evaluated at least once.

I think when the list is empty, list processing should be disabled and the empty list should simply be considered an object, and judged either {} = true, or {} = false by (some) definition. Just define it, document it, and done. Definitely not return 0 in my opinion.

[David Hayden]

(10-11-2019 08:36 PM)Claudio L. Wrote:  I think when the list is empty, list processing should be disabled and the empty list should simply be considered an object, and judged either {} = true, or {} = false by (some) definition. Just define it, document it, and done. Definitely not return 0 in my opinion.

But is this consistent with other list processing? I don't have my Prime handy, but what is {} + 1? I suspect it's {}.

To my mind, it would make sense to define list processing such that:
DoSomething(list, other arguments) is the same as:

Code:

result = {}
for each item in list
    temp = DoSomething(item, arguments)
    result = concat(result, temp);

That's easy to remember, defensible, and probably easy to implement. It means that any list processing with an empty list gives an empty list as a result.

[Albert Chan]

(10-11-2019 08:52 PM)David Hayden Wrote:  

Code:

result = {}
for each item in list
    temp = DoSomething(item, arguments)
    result = concat(result, temp);

That's easy to remember, defensible, and probably easy to implement.
It means that any list processing with an empty list gives an empty list as a result.

I agree.

More importantly, the returned result is *always* a list.
This helped the programmer to simplify code without hitting a "0" exception.

[Wes Loewer]

(10-11-2019 08:52 PM)David Hayden Wrote:  It means that any list processing with an empty list gives an empty list as a result.

That seems reasonable, with perhaps one exception. The TrueClause and the FalseClause can also be lists:

IFTE({1,0,1,0,0},{2,4,6,8,10},{1,3,5,7,9}) --> {2,3,6,7,9}

but the lists of course have to all be the same size:

IFTE({1,0,1,0,0},{2,4},{1,3,5}) --> Error: Invalid input

So I'd think the following ought to give the same "Invalid input" error:

IFTE({},{2,4,6},{1,3,5})

since the lists' sizes are not consistent.

[StephenG1CMZ]

Instead of returning Invalid Input instead of a list sometimes - I suggest effectively just using the shortest list length.

[Wes Loewer]

(10-12-2019 08:26 AM)StephenG1CMZ Wrote:  Instead of returning Invalid Input instead of a list sometimes - I suggest effectively just using the shortest list length.

If that were the case, then to be consistent you'd need to change how list processing is handled system wide. Should {1,2}+{3,4,5} return {4,6} or error?

[John Keith]

(10-12-2019 06:38 AM)Wes Loewer Wrote:  The TrueClause and the FalseClause can also be lists:

IFTE({1,0,1,0,0},{2,4,6,8,10},{1,3,5,7,9}) --> {2,3,6,7,9}

but the lists of course have to all be the same size:

This is how IFTE works on the HP48/49/50. Bob's example in post #5 does not work on those calculators however.

[Wes Loewer]

(10-12-2019 11:00 AM)Wes Loewer Wrote:  Should {1,2}+{3,4,5} return {4,6} or error?

Here's an interesting twist. In CAS
{1,2}+{10,20,30} --> {11,22,30} // assumes missing elements are zero
but
{1,2}*{10,20,30} --> {10,40} // uses only first two elements

[John Keith]

(10-12-2019 11:00 AM)Wes Loewer Wrote:  

(10-12-2019 08:26 AM)StephenG1CMZ Wrote:  Instead of returning Invalid Input instead of a list sometimes - I suggest effectively just using the shortest list length.

If that were the case, then to be consistent you'd need to change how list processing is handled system wide. Should {1,2}+{3,4,5} return {4,6} or error?

There is a third option- cycle the contents of the shorter list. The above example would then return { 4, 6, 6}. Some Mathematica commands do this.

Whichever option is chosen, it needs to be consistent and well documented.

[rprosperi]

(10-11-2019 05:36 PM)rprosperi Wrote:  

(10-11-2019 11:09 AM)Tim Wessman Wrote:  Second may be a bug (not sure, would have to check the code), but the third is perfectly expected and as designed. It is doing list processing on your input.

Try IFTE({1,0,1,0,0),2,3) and what do you get?

Assuming this should be IFTE({1,0,1,0,0},2,3), I'd guess {2,3,2,3,3} ?

So I dug out my Prime to check (the suspense was killing me) and have mixed results:

In HOME, my guess was right, {2,3,2,3,3} so I understand that at least;

But in CAS, Prime replies "when({1,0,1,0,0},2,3)", though it also adds the simplify button, daring me to pursue it further. Figuring it can't hurt to try, it then replies "simplify(when({1,0,1,0,0},2,3)) => when({1,0,1,0,0},2,3)"

So, 2 conclusions - In CAS, I guess that is as simple as it gets, and I still don't understand the Prime's split personality.

Can anyone explain:

1. The CAS behavior, and meaning of that result
2. Why they are different? I'd assume IFTE() works the same in both modes - there is no mention of either mode in the online help and this command is not in the manual at all.

[Carsen]

(10-12-2019 01:40 PM)rprosperi Wrote:  1. The CAS behavior, and meaning of that result
2. Why they are different? I'd assume IFTE() works the same in both modes - there is no mention of either mode in the online help and this command is not in the manual at all.

1. I do not know why IFTE is replaced with when so I can't answer that question.
2. They are different because you typed IFTE in capital letters. Type them in lower case & you will get your result.

[rprosperi]

(10-12-2019 06:41 PM)Carsen Wrote:  2. They are different because you typed IFTE in capital letters. Type them in lower case & you will get your result.

Thanks Carsen! I did know that, once, long ago...

So, can anyone explain the real question, which is why Home commands must be in Upper case, while CAS commands must be in Lower case, except for those situations in which it isn't required?

[cyrille de brébisson]

Hello,

Back to the original question. The behavior is linked to list processing.

The handling of the empty list is indeed a return of 0. in hindsight, an error might have been better... I honestly do not remember why I set it to 0...

List processing of IFTE is a wiered thing in it's implementation...
try executing something that does a side effect like IFTE({1,0}, A:=1+2, B:=3+4) to see what I mean...


With regard to the uppser vs lowercase stuff.
first, most home commands work both in lower and upper case... but, for historical reasons (38, 48...) they are written in uppercase...
Second, if allows to distinguish CAS specific functions from others...
Third, functions that are common to CAS and home and do not have different meaning will normally be uppercase even in the CAS. This is also for historical reason comming from the first HP 39GII+ (which used the CAS in home, slightly disguised).

Cyrille

[rprosperi]

(10-16-2019 05:31 AM)cyrille de brébisson Wrote:  With regard to the uppser vs lowercase stuff.
first, most home commands work both in lower and upper case... but, for historical reasons (38, 48...) they are written in uppercase...
Second, if allows to distinguish CAS specific functions from others...
Third, functions that are common to CAS and home and do not have different meaning will normally be uppercase even in the CAS. This is also for historical reason comming from the first HP 39GII+ (which used the CAS in home, slightly disguised).

Cyrille

Thanks for explaining that Cyrille; the history helps to explain how it evolved...

It seems it would have been more clear (and certainly easier to understand when looking at code later) to have required and used:

In HOME: "CAS.Function_Name" when needing a CAS-specific function
In CAS: "HOME.Function_Name" when needing a HOME-specific function
In CAS & HOME: "Function_Name" if it is truly a common function

But this may not have been possible since the CAS code (and presumably it's parser) comes from Parisse already built.

The Prime has such a huge vocabulary, and sooo many functions, it's simply not feasible (IMHO) to recall which functions behave which way, and so forcing the user to consider (or possibly even look-up) which is correct to use in each mode would make it less confusing. Of course, the built-in Help is useful for this, but when looking-up "MAGIC_FN", it does not always suggest "magic_fn" is also available and could in fact be what you wanted.

I don't mean to whine, but I'm caught in a vicious cycle: I don't use the Prime often (ignoring the issue of I also don't need most of what it can do) because it's confusing to me and so I don't become accustomed to the quirks such as discussed above when I try to use it, so I stop using it in frustration, and then the cycle repeats.

But I suspect this could be a bit like when first learning RPN, having used Algebraic machines. You can't go back and forth between Algebraic and RPN while learning it, you need to just make a cold change to the new one and force yourself to learn it. I recall this adventure in a Freshman Physics class in college. I suppose the key difference is I was 18 then, didn't have 40+ years experience using prior systems, and now no longer need to pass Physics.

Thanks again.