Hello,

I came across the following strange behaviour both at CX CAS handheld and in CAS Teacher Software (v3.6.0.550):

I wrote a function that, based on input data, builds a linear system of equations and gives its solution at its output.

I ran it three times (the input data is the same in all the three runs), each times changing Display Digits in Document Settings only.
The systems to solve and the obtained solutions are visible in the attached figures.

In case of "Float 8" and "Float 4" I get the correct solution (although displayed in different precision), in case of "Float 6" not.

When I say "not" I mean the following:

The source of the problem is a difference in matrix coefficients (7,6) and (6,7): the mathematically correct magnitude of both coefficients should be 2.4E-6 (see P.S.), what I get in case of "Float 4" (2.4E-6) and "Float 8" (0.0000024) runs (therefore the correct solution x(1)=x(4)=1.2)

In "Float 6" case the magnitudes are represented as 0.000002, but the problem is that this value not just the representation of number 0.0000024 in "Float 6" precision, the math engine seems work with exactly 0.000002 instead of 0.0000024 (like it truncated the value) and solves a different system corectly, giving actually the "wrong" solution x(1)=x(4)=1.

Seems very strange to me. Or maybe I misunderstand something regarding math engine precision vs numbers representation?

Regards,
Goran

P.S.

The function can solve the system symbolically, too: when symbolic values are supplied, the corresponding coefficients' value is k*sqrt(L1*L2)*omega*imaginary_unit; substituting the numerical values for the described cases  one gets -0.4*sqrt(1E-6*9E-6)*2*imaginary_unit =
= -2.4E-6*imaginary_unit = (2.4E-6 @< -90 deg) in polar notation, what you get in "Float 4" and "Float 8" cases.

Hello,

I ran into this error on Nspire CX CAS, but saw already that this error message also exists on other TI calcs like 89, 92 and Voyage200.

I got as a result of my program/function a complex function, let's say z(omega), that was calculated correctly and also was shown correctly in e.g. calc application.

But when I want to play with the function further (e.g. getting it's real or imag part, or even to show in again in calculator by typing z(omega)<ENTER>,
I get "Invalid polar complex" error.

On CX CAS you can reproduce the problem if you define a complex function in polar format as e.g.

   z(omega):=(sqrt(omega) @< 90)

On the other hand, if you define the function as

   z(omega):=(abs(sqrt(omega)) @< 90)

everything works fine.

So I thought (as TI says: complex numbers must be properly defined) the problem is that sqrt() function has two solutions (+/-sqrt(x))
and therefore the magnitude of the function internaly is not a scalar value but a two-items entity (e.g. a list), and therefore the error,

but if you define

   z(omega):=(sqrt(4) @< 90)

it works ok as well (sqrt(4) gives 2, not {-2,2}, so I get confused again)

My goal is to understand the cases/circumstances that produce "invalid polar complex" error, in order to circumvene such
problems, if possible (idea: by decomposing the calculation to steps that can be given constraints in order to
force/help engine to yield intermediate results that will in the end result in a valid polar complex).

Thanks for any help and regards,
Goran

 
   

Hello again,

I am still trying a functionality that works in software, to be also working on handheld. I guess the problem is due to
a bias in my thinking/developing in terms of a desktop and "classic" mouseDown/mouseUp events, compared to handheld's additional grabDown/grabUp events.

(I am aware of handling these events in ETK versions incorporated into FormulaPro (mouseUp/mouseDown) and ETK_Demo_New (grabDown added),
but for now I would like first to understand the bare event sequence both in software and on handheld.)

My goal is either to:
a) to select an object, drag it across the screen and release it at some different location, or
b) to select a point of one object, drag a line across the screen and connect it to a point of another object on release.

This is exactly what we do in Graph app when grabbing a function graph, translate/rotate it by dragging, and release it at different position/orientation,
or when using the slider widget in ETK_Demo_New script.

So,

1) in software (where it works as planned):
 
I implemented the corresponding mouseDown() and mouseUp() handlers, what is for software enough: When I press down and hold the left mouse button, mouseDown(x1,y1) is triggered,
then I drag an object or draw a line by keeping left mouse button pressed, and on the release of the left mouse button mouseUp(x2,y2) is triggered. Nice, works, and cannot be simplier.

2) on the handheld (CX CAS with touchpad):

the most similar (and only possible?) operation is to "grab" the first object (by selecting, holding for a while and releasing the central touchpad button), drag it across the screen
(by dragging across the touchpad) and releasing the object (by clicking shortly on the central touchpad button again).

So, in order to work on handheld, I guess I have to implement additional grabDown(/grabUp?) handler(s).

Based on reading Lua Scripting API manual and some experimenting, I came to the following conclusions (which are not necessarily correct):

a) when I press and hold for a while the central touchpad button, grabDown(0,0) event is created, preceeded by mouseDown(x1,y1) event.
b) on the release of the central touchpad button, grabUp(0,0) event is created (by now, the object is selected/grabbed and ready to be moved around)
c) the manual says that both grabDown() and grabUp() events actively suppress creation of mouseUp() event

To summarize, up to here, grabing my object creates:
   mouseDown(x1,y1)
   grabDown(0,0)
   grabUp(0,0)

Then, dragging the object is done by implementing mouseMove() event.

In the end, if I press shortly the central touchpad button again (to release the object), I guess I'll produce another mouseDown() event.
But my experience shows that:
   i) on pressing shortly the central touchpad button, mouseUp(x,y) handler is used
   ii) the x,y coordinates correspond to the "grabbing" point x1,y1, no matter that I clicked the button at "dragged" position x2,y2.

All this is really puzzling me (to be honest: making a mess in my head)?

Can someone please explain me step by step what really goes on at handheld platform during select-drag-release operation
with regard to events?

Thanks in advance,
Goran

Hello,

Is there any API documentation for ETK?

I currently go through the code itself, I made a cetrain progress in using it, but anyway I have some doubts that can be removed in this way only after I go 100% through to grasp all the concepts.

Best regards,
Gooran

Hello,

Firstly, sorry if this question has been answered already (link please).

I want to change the menu content during lua script execution.
I found in "Lua Scripting API Reference Guide" the following sentence:

"Beginning with platform.apiLevel = '2.0', the names of the tool palette items
can be changed dynamically while the program is running."

but I am missing an example.

Any help would be appreciated.

Thanks,
Goran

Hello,

I am delighted with ability to specify my own menu for a script page using toolpalete:register() call.
I followed the example given in the Lua Scripting API Reference Guide.

Everything worked as described, except for separation lines (section dividers), specified by hyphen ("-"):
Instead of some kind of separation line, I get in the menu a disabled menu item (gray text) saying: "<number>: English (U.S.)".

Did anyone else experienced such a behavior?

Best regards,
Goran