Post Reply 
[request] improve implicit multiplication in some cases
10-11-2016, 12:52 PM (This post was last modified: 10-12-2016 06:46 PM by compsystems.)
Post: #1
[request] improve implicit multiplication in some cases
Hi, as the hpprime do not perform multiplication implicitly in most cases, the following cases should generate a syntax error or make implicitly multiplication

using 2D templates:

with ▣√▣

a∛2 returns a*(3 NTHROOT b) // make implicitly multiplication =)

[Image: implicitlyMultiplication_image0.jpg]

but with √▣

a√2 or √2a [enter] show "error syntax"" =( in this case could interpret it as a*√(2)

[Image: implicitlyMultiplication_image0a.jpg]


with |▣|

a|x| [enter] returns aABS(x) Why ??? -> a*|x| or show "error syntax" but not aABS(x)

[Image: implicitlyMultiplication_image1.jpg]

with Σ▣

aΣ(j,j,1,3) [enter] returns aΣ(j,j,1,3) Why??? -> a*Σ(j,j,1,3) or show "error syntax"

[Image: implicitlyMultiplication_image2.jpg]

[Image: implicitlyMultiplication_image3.jpg]
Find all posts by this user
Quote this message in a reply
10-11-2016, 02:52 PM
Post: #2
RE: [request] improve implicitly multiplication in some cases
I would not wish a sqrt (2) to have an implicit multiplication (where sqrt means the symbol).
It can too easily be misread as a'th root of 2. Insisting on a * or () means less risk of misunderstanding.

(Right now I'm struggling to implement the Vincenty algorithm, full of
Tan (1-f)more
Which looks like you tan 1-f
Except it also has
Cos x y
With no brackets...
It takes a lot of guesswork to guess where the brackets should be, not helped by there being no examples)

Stephen Lewkowicz (G1CMZ)
https://my.numworks.com/python/steveg1cmz
Visit this user's website Find all posts by this user
Quote this message in a reply
10-11-2016, 07:30 PM (This post was last modified: 10-12-2016 03:39 PM by compsystems.)
Post: #3
RE: [request] improve implicitly multiplication in some cases
implicitly multiplication in question is only with templates 2D

something very strange happens with
a[[1,2,▣]] -> at(a,[0,1])
[Image: implicitlyMultiplication_image4.jpg]
Find all posts by this user
Quote this message in a reply
10-12-2016, 03:18 PM (This post was last modified: 10-12-2016 03:19 PM by Han.)
Post: #4
RE: [request] improve implicitly multiplication in some cases
(10-11-2016 07:30 PM)compsystems Wrote:  implicitly multiplication in question is only with templates 2D

something very strange happens with
a[1,2,▣] -> at(a,[0,1]

a[1,2] is a method for referencing entry 2 in row 1 of the (presumably) matrix stored in the variable a. The [] notation for referencing elements is to avoid ambiguity introduced using (). That is, should f(1) mean evaluate the function f at 1? or should it mean the first element in a composite object stored in f?

I am of the opinion that calculators should avoid implicit operations altogether. It's bad practice as far as pedagogy is concerned.

Graph 3D | QPI | SolveSys
Find all posts by this user
Quote this message in a reply
10-12-2016, 03:44 PM (This post was last modified: 10-12-2016 04:01 PM by compsystems.)
Post: #5
RE: [request] improve implicitly multiplication in some cases
(10-12-2016 03:18 PM)Han Wrote:  a[1,2] is a method for referencing entry 2 in row 1 of the (presumably) matrix stored in the variable a.
you're right, is interpreting, extract the (row, col) position, although the output at(a,[0,1]) is very confusing, is not a real pretty print as it appears in math textbooks, the hp-prime development team is not interested in improving this, I think it's too simple to improve history view, 100% pretty-print

a:=[[9,8,7]];
a[[1,2]] -> 8 // ok
or
a[1,2] -> 8 // ok

purge(a)
a[1,2] -> at(a,[0,1]) // ok but incomprehensible to an inexperienced user

... but in other cases as:
a|x| [enter] returns aABS(x) ?? must generate a syntax error or made implicity multiplication, agree?
Find all posts by this user
Quote this message in a reply
10-12-2016, 04:20 PM
Post: #6
RE: [request] improve implicitly multiplication in some cases
(10-12-2016 03:44 PM)compsystems Wrote:  ... but in other cases as:
a|x| [enter] returns aABS(x) ?? must generate a syntax error or made implicity multiplication, agree?

I believe the parser simply translates the templates (in this case to the ABS() command) and then checks the input after the translation. The reason an error is not generated is because (assuming we are in CAS mode), one is allowed to create symbolic input. Thus, aABS(x) gets treated like a custom user function that has not been defined. For example, if nothing is stored in the variable f, typing f(x) would simply place f(x) on the history. In your example, the parser is simply reading aABS(x) in a similar manner. If you place a space in between a and |x| however, it will produce an error (i.e. not allowing implicit multiplication).

Graph 3D | QPI | SolveSys
Find all posts by this user
Quote this message in a reply
10-12-2016, 06:59 PM (This post was last modified: 10-13-2016 02:34 AM by compsystems.)
Post: #7
RE: [request] improve implicit multiplication in some cases
(10-12-2016 04:20 PM)Han Wrote:  If you place a space in between a and |x| however, it will produce an error (i.e. not allowing implicit multiplication).

in the next firmware or updates, I hope some templates to add a space (as prefix), this solves the problem =), but I would like more than the parser is "smarter", ie, to analyze the prefix, and try to realize of the implicit multiplication

in the following cases the hp-prime made implicit multiplication
Code:
{a3/4, a∛2, 3a, 3a3/4} -> { a*(3/4), a*∛2, 3*a, 3*a*(3/4) }

[Image: implicitlyMultiplication_image5.jpg]

Han Wrote:The [] notation for referencing elements is to avoid ambiguity introduced using (),That is, should f(1) mean evaluate the function f at 1? or should it mean the first element in a composite object stored in f?

I think TI-DERIVE use another symbol (↓) to avoid this math computer ambiguity

a:=[[9,8,7]];
a↓(1,2) -> 8
Find all posts by this user
Quote this message in a reply
10-13-2016, 02:25 AM
Post: #8
RE: [request] improve implicit multiplication in some cases
(10-12-2016 11:49 PM)moonbeam Wrote:  ...it costs a single keystroke to add a * when a multiplication is intended and both I and the Prime know exactly what I want.

it costs nothing to the user, adds the multiplication operator to the expression, it should not cost anything also the parser add a space that requires the user to enter an operator =)
Find all posts by this user
Quote this message in a reply
Post Reply 




User(s) browsing this thread: 1 Guest(s)