newRPL: all results mode?

[Claudio L.]

Since newRPL swapped the behavior of + and ADD, we have all operators in place for list processing. If all other commands also accept list processing, there's no technical barrier for returning a list of results during evaluation of an expression.
This means for example:

4 √ would return { -2 2 }
XROOT would also return all roots depending on the exponent.

When used within an expression, it would continue to evaluate normally as 2 (or more) different paths.

I wonder if a flag could activate this mode, or we should leave it alone and have new command names that return all roots (√ALL and XROOTALL for example).

This mode is not necessarily good for all cases, I can think of a Newton-Raphson iteration involving a square root, where each iteration would double the number of results and eat all the memory.

Any thoughts?

[rprosperi]

(01-21-2016 12:59 PM)Claudio L. Wrote:  Since newRPL swapped the behavior of + and ADD, we have all operators in place for list processing. If all other commands also accept list processing, there's no technical barrier for returning a list of results during evaluation of an expression.
This means for example:

4 √ would return { -2 2 }
XROOT would also return all roots depending on the exponent.

When used within an expression, it would continue to evaluate normally as 2 (or more) different paths.

I wonder if a flag could activate this mode, or we should leave it alone and have new command names that return all roots (√ALL and XROOTALL for example).

This mode is not necessarily good for all cases, I can think of a Newton-Raphson iteration involving a square root, where each iteration would double the number of results and eat all the memory.

Any thoughts?

I think newRPL should, by default, behave the same as RPL in order to get expected results from existing code. Enhanced results, like this, are very useful for those that understand and expect them, but should IMHO only be enabled by some deliberate action, like setting a flag. I think backward compatibility for a core function such as this will be essential for adoption by many users.

New command names for the enhanced modes is nice as it certainly adds clarity, but could easily get out of control due to likely large number of variations. How many would you expect?

[Nigel (UK)]

I like this idea but not as a default setting: usually only one root is required (e.g., when using Pythagoras). How about using a long press to bring up the function that returns a list?

For trig functions: inverse sine of 0.5 could return {30, 150} in degrees mode, but arbitrary multiples of 2 pi would be needed for complete generality. There's no reason why these couldn't be included, I suppose. Will you have multi-valued logarithms as well?

Nigel (UK)

[Claudio L.]

(01-21-2016 02:52 PM)rprosperi Wrote:  IMHO only be enabled by some deliberate action, like setting a flag.

No question about it. Either a flag or a completely different set of commands, you won't get any nasty surprises.

(01-21-2016 04:14 PM)Nigel (UK) Wrote:  I like this idea but not as a default setting: usually only one root is required (e.g., when using Pythagoras). How about using a long press to bring up the function that returns a list?

Long press can't be used. It is officially "help" when the command is in a menu. But the autocomplete feature would take care of all the different variants.

(01-21-2016 04:14 PM)Nigel (UK) Wrote:  For trig functions: inverse sine of 0.5 could return {30, 150} in degrees mode, but arbitrary multiples of 2 pi would be needed for complete generality. There's no reason why these couldn't be included, I suppose. Will you have multi-valued logarithms as well?

There would have to be a limit on the maximum number of simultaneous paths to be evaluated. These functions would have to return up to a maximum number of solutions to avoid eating all the memory.
Let's say you want sqrt(sin(0.5))
SIN(0.5) would give you the maximum number of solutions, and then sqrt would try to double it. We'd have to discard half of the solutions, but which half?
It would make it useless, as the user would never know which solutions are missing from the list.
Perhaps we should limit to solutions within the first turn in the circle.

[rprosperi]

(01-21-2016 06:59 PM)Claudio L. Wrote:  Perhaps we should limit to solutions within the first turn in the circle.

Sensible limit, as I believe the requirement for further solutions would be needed only for very specialized applications/situations, though I admit to really not knowing this stuff.

[Nigel (UK)]

I have a question: if 4 √ returns {2 -2} and 9 √ returns {3 -3}, then 4 √ 9 √ + would return {5 -5} if list addition acts element-by-element. However, there are four possible answers: {5 1 -1 -5}.

Is it intended that {a b} {c d} + returns { {a+c a+d} {b+c b+d} }?

Nigel (UK)

[emece67]

(01-22-2016 09:13 AM)Nigel (UK) Wrote:  I have a question: if 4 √ returns {2 -2} and 9 √ returns {3 -3}, then 4 √ 9 √ + would return {5 -5} if list addition acts element-by-element. However, there are four possible answers: {5 1 -1 -5}.

Is it intended that {a b} {c d} + returns { {a+c a+d} {b+c b+d} }?

And 4 √ 9 √ * would return {6 6}, 6, {6 -6} or even {{6 -6} {-6 6}}?

I guess that this interesting construct can give rise to many traps.

[Claudio L.]

(01-22-2016 09:13 AM)Nigel (UK) Wrote:  I have a question: if 4 √ returns {2 -2} and 9 √ returns {3 -3}, then 4 √ 9 √ + would return {5 -5} if list addition acts element-by-element. However, there are four possible answers: {5 1 -1 -5}.
Is it intended that {a b} {c d} + returns { {a+c a+d} {b+c b+d} }?

You found a big hole in my all-solutions idea. In order for this to work, the +,*,^ operators (any binary operator, actually) should distribute the operation throughout the solutions, rather than work element by element. That would mean breaking the list processing operations when the "all-solutions" flag is enabled.
Not difficult to implement, but if you need to do any list processing (likely when you just received a list of results), you'd have to disable the all solutions mode before doing so.
This also means that using different names rather than a flag has to be discarded. A flag is the only way those binary operators can change behavior transparently.
Big question is: is it worth going there?

(01-22-2016 10:44 AM)emece67 Wrote:  And 4 √ 9 √ * would return {6 6}, 6, {6 -6} or even {{6 -6} {-6 6}}?
I guess that this interesting construct can give rise to many traps.

The ideal behavior should be:

• Flattened list of results: { a b } { c d } + --> { a+c b+c a+d b+d }
• No automatic collapsing of paths: Your example would return { 6 -6 -6 6 }
  

The first is self explanatory: if there's 4 results, they should all be treated equally, dealing with nested lists is a pain. A complicated expression could end up with numbers nested very deeply otherwise.
The second is more debatable: you could argue that if the results are the same, then it is not a separate solution path at all. But I think it's reassuring for the user to know that all paths were explored, even if they produce the same result.
This means 4 √ SQ --> { 4 4 }

[Claudio L.]

I came up with a different approach to solve this. No flags needed.
We'd need a new object type, a solution list, or solution path, however you want to call it. For now let's use \\ and \\ as brackets for this object (any other suggestions there?).
Commands would only return a solution path object if one of the inputs is a solution path object.

So 4 √ would behave exactly as it does now.
But \\4\\ √ would give you \\ -2 2 \\

The operators, being overloadable, are easily redefined for the new object to distribute the operations throughout the solutions.

Writing constants in an expression would be tricky.

'√2*SIN(0.5)' would give you a single solution

You'd have to write explicitly:

'√\\2\\*SIN(\\0.5\\)' in order to get all possible solutions

It gives user more control:
'√2*SIN(\\0.5\\)' would give you all the SIN solutions, as the square root will only take the positive result.

[Nigel (UK)]

I like this approach. With a function that finds the minimum and maximum values between the \\ delimiters it could be used for interval arithmetic as well as for its intended purpose.

It might be an idea to combine this approach with the following. Instead of returning \\...\\ directly, operators could return variables representing signs and/or integers as part of an expression. So \\4\\ sqrt would return 2*s1; \\9\\ sqrt would return 3*s2. Adding them would give 2*s1 + 3*s2. Then s1 and s2 could be substituted with lists, \\..\\ structures, or even just 1 or -1, using SUBST or the | operator.

This would also work with inverse trig functions. \\0.5\\ ASIN could return

Code:

\\ 30+360*n1 150+360*n2 \\ instead of just \\ 30 150 \\.

Is this too much complication?

Nigel (UK)

[Claudio L.]

(01-24-2016 07:08 PM)Nigel (UK) Wrote:  I like this approach. With a function that finds the minimum and maximum values between the \\ delimiters it could be used for interval arithmetic as well as for its intended purpose.

It might be an idea to combine this approach with the following. Instead of returning \\...\\ directly, operators could return variables representing signs and/or integers as part of an expression. So \\4\\ sqrt would return 2*s1; \\9\\ sqrt would return 3*s2. Adding them would give 2*s1 + 3*s2. Then s1 and s2 could be substituted with lists, \\..\\ structures, or even just 1 or -1, using SUBST or the | operator.

This would also work with inverse trig functions. \\0.5\\ ASIN could return

Code:

\\ 30+360*n1 150+360*n2 \\ instead of just \\ 30 150 \\.

Is this too much complication?

Nigel (UK)

Returning expressions, using SUBST or the | operator are all CAS features. As of right now, I'm not developing the CAS. There's plain simple expression evaluation, but nothing more (roughly at the level of the 48 series).
While your approach is good and won't be discarded, it will be a while before those math functions return symbolic expressions.
Let's analyze sqrt(asin(\\0.5\\))
The square root would have to return all four solutions in a symbolic way, like this:

\\ '√(30+360*n1)' '-√(30+360*n1)' '√(150+360*n2)' '-√(150+360*n2)' \\

If you want numeric (approximated solutions), then you'd have to use approximated inputs:

'√(ASIN(\\0.5.\\))' EVAL --> \\ 30. 150. \\

Let's also see what would happen with symbolic expressions that cannot be evaluated numerically:

'√\\4\\+√\\3\\' --> \\ 2 -2 \\ \\ '√3' '-√3' \\ + --> \\ '2+√3' '-2+√3' '2-√3' '-2-√3' \\

I think your idea would work just fine, except for one thing:

\\ 0.5 \\ ASIN \\0.5\\ ASIN +

would evaluate to:
\\ '30+360*n1' '150+360*n2' \\ \\ '30+360*n1' '150+360*n2' \\ +
In both cases, the solution paths contain identical pseudo integer variables that would collide when the + operation is done.
How would the + operator know which variables were automatically created and which ones were not to avoid that collision?

\\ 'n1' \\ ASIN \\0.5\\ ASIN +

This would evaluate to:
\\ 'ASIN(n1)' '180-ASIN(n1)' \\ \\ '30+360*n1' '150+360*n2' \\ +

And then? How would you distinguish between the n1 in the first group and on the other group?

[Nigel (UK)]

(01-25-2016 02:31 PM)Claudio L. Wrote:  I think your idea would work just fine, except for one thing:

\\ 0.5 \\ ASIN \\0.5\\ ASIN +

would evaluate to:
\\ '30+360*n1' '150+360*n2' \\ \\ '30+360*n1' '150+360*n2' \\ +
In both cases, the solution paths contain identical pseudo integer variables that would collide when the + operation is done.
How would the + operator know which variables were automatically created and which ones were not to avoid that collision?

\\ 'n1' \\ ASIN \\0.5\\ ASIN +

This would evaluate to:
\\ 'ASIN(n1)' '180-ASIN(n1)' \\ \\ '30+360*n1' '150+360*n2' \\ +

And then? How would you distinguish between the n1 in the first group and on the other group?

In the first case, the calculator would have to keep track of which 'n' variables have already been used and use the next in a sequence. If this sequence is reasonably long - n00 to n99, for example - wrapping around wouldn't be a major issue.

The second case could be got around by making the 'n' variables unusual in some way - put an unusual character in their name and make sure that users know that such variables are reserved for this purpose.

I understand that implementing this idea has to wait until a rudimentary CAS is in place. I think that the multiple execution path \\...\\ scheme would be excellent for the most common cases of square roots and inverse trig functions between 0 and 360 degrees and is well worth running with for now.

Nigel (UK)