(03-29-2020 03:12 PM)Eddie W. Shore Wrote:  You can file a bug report, see the thread about the Beta thread.

In the mean time, there are two conversion CAS commands that work both in Home and CAS modes:

polar_coordinates( real + imag*i ) -> [ approximate radius, approximate angle ]

polar_coordinates( real, imag ) -> [ radius, angle ]
Approximate at Home, Exact at CAS

rectangular_coordinates( radius, angle ) -> [ real, imag ]
Approximate at Home, Exact at CAS

Both polar_coordinates and rectangular_coordiantes are found in the Catalog.

polar_coordinates is also found in [Toolbox], (App), Geometry, Cartesian, Polar Coordinates

(03-30-2020 09:06 PM)Dands Wrote:  Also, where exactly should I request new features? How does posting them here gets sent to HP?

(03-30-2020 09:56 PM)rprosperi Wrote:  

(03-30-2020 09:06 PM)Dands Wrote:  Also, where exactly should I request new features? How does posting them here gets sent to HP?

Members of the Prime team are quite active MoHPC Forum members and they will see your posts here. That said, if you want to suggest new or modified features, it's best to make a new post with something like "Feature Request" in the title, rather than burying it on some other long or only somewhat related thread.

Also, history has shown that general enhancements that affect lots of users, with detailed explanations and examples of how the new (or modified) feature should (could) work receive the best response.

But also understand that deep inside the Prime, HOME and CAS modes are not tightly integrated, so quite often requests along the lines of "Please make CAS treatment of XYZ act like HOME mode" or vice-versa, can't practically be implemented. There are some areas where they obviously can behave similarly, but others where it either makes no sense, or isn't technically feasible.

(03-31-2020 05:54 AM)Tim Wessman Wrote:  It actually is very hard to implement because there is no such thing as a "complex" object in the CAS. You have expressions that contain complex parts, but those can be in very varying forms and varieties. Whereas in home and numeric parts, the two values are intrinsically linked as a single object. That object has a flag that means "display in rectangular" or "display in polar". Hence nothing changes and it just toggles the bit on that individual object.

Bernard the CAS author could possibly extend the polar_coordinates/rectangular_coordinates to also work with vectors of vectors (there is no MATRIX object in CAS actually either, which is another major difference), but that will depend on him desiring to do so.

It will not be able to use the same display routines and keep the pairs together because that type of object just does not exist in CAS land...

(03-31-2020 12:31 PM)victorvbc Wrote:  This is the code I made for displaying polar coordinates {magnitude,angle}, it works with matrices and lists.

I'm also quite new to the Prime, so I don't know if there's any better way to do it...

Code:


//This program takes an expression or matrix and turns it into polar coordinates
#cas
toPolar(z):= 
BEGIN
LOCAL sizes,j,k;

IF type(z)=DOM_LIST THEN //check if is list/matrix
  sizes:=SIZE(z); //get dimension of rows and columns
  IF size(sizes)=1 THEN //row vector
    FOR j FROM 1 to sizes DO
      z[j]:=convert_polar(z[j]); //convert each element to polar
    END;
  ELSE //column vector or matrix
    FOR j FROM 1 to sizes(1) DO
      FOR k FROM 1 to sizes(2) DO
        z[j,k]:=convert_polar(z[j,k]); //convert each element to polar
      END; 
    END;
  END;
ELSE
  z:=convert_polar(z); //single element
END;

RETURN z;
END;

convert_polar(x):=
BEGIN
  RETURN simplify({ABS(x),ARG(x)}); //conversion formula
END;

#end

Keep in mind that it's purely for display purposes, you can't make any operations with this format.

Also, if you want to convert any expressions that have real-valued variables, you should do something like assume(x,float) before doing the conversion. Otherwise you can have very complicated expressions.

(03-31-2020 04:22 PM)Dands Wrote:  This program works great, however, it's showing angles in radians. It might be because you're using the convert_polar function which is based in rad. Is there a way to modify it so that it uses the system's preferred angle output? I mostly need my angles in degrees.

Thank you!

(03-31-2020 04:38 PM)victorvbc Wrote:  

(03-31-2020 04:22 PM)Dands Wrote:  This program works great, however, it's showing angles in radians. It might be because you're using the convert_polar function which is based in rad. Is there a way to modify it so that it uses the system's preferred angle output? I mostly need my angles in degrees.

Thank you!

The function is defined right under the main program. It uses the modulus and argument commands, which should function according to the system angle setting.

Are you sure you switched it right? The calc. should have a <° symbol on the top right corner. On mine it works as expected, outputs a float in degrees.

If you check the variable 'HAngle', it should return 1.

(03-31-2020 08:14 PM)Dands Wrote:  I think something weird is happening, probably because you used the simplify command in the output. I removed it and it persisted, so I'm clueless. Both of these should provide an angle of 45deg. I think it is not handling it properly when coefficients a and b are not integers.

Also, is it normal to see the terminal showing so many alerts?

(03-31-2020 09:16 PM)victorvbc Wrote:  

(03-31-2020 08:14 PM)Dands Wrote:  I think something weird is happening, probably because you used the simplify command in the output. I removed it and it persisted, so I'm clueless. Both of these should provide an angle of 45deg. I think it is not handling it properly when coefficients a and b are not integers.

Also, is it normal to see the terminal showing so many alerts?

That is quite weird... I guess the CAS doesn't like converting angles from floating point complex numbers to degrees. Anyway, here's a quick & dirty fix:

Code:


//This program takes an expression or matrix and turns it into polar coordinates
#cas
toPolar(z):= 
BEGIN
LOCAL sizes,j,k;

IF type(z)=DOM_LIST THEN //check if is list/matrix
  sizes:=SIZE(z); //get dimension of rows and columns
  IF size(sizes)=1 THEN //row vector
    FOR j FROM 1 to sizes DO
      z[j]:=convert_polar(z[j]); //convert each element to polar
    END;
  ELSE //column vector or matrix
    FOR j FROM 1 to sizes(1) DO
      FOR k FROM 1 to sizes(2) DO
        z[j,k]:=convert_polar(z[j,k]); //convert each element to polar
      END; 
    END;
  END;
ELSE
  z:=convert_polar(z); //single element
END;

RETURN z;
END;

convert_polar(x):=
BEGIN
  IF type(IM(x))=DOM_FLOAT OR type(RE(x))=DOM_FLOAT THEN
    x:=exact(x);
      RETURN approx({ABS(x),ARG(x)});
  ELSE
    RETURN {ABS(x),ARG(x)};
  END;
END;
#end

It works for that case now. I don't know about the errors, I didn't get them.

(04-05-2020 01:35 PM)compsystems Wrote:  Another request

The imaginary unit i is used like z = a+b*i in general mathematics, however, sometimes j is used as an imaginary unit in the electricity or magnetism classroom because the symbol i has the meaning of current. The imaginary unit may be changed to j on the Imaginary Unit setting screen in System application on casio classPad






Even the character i must be free to be used as a counter variable, therefore another unicode character is required to show (i, e), this will help us to use the i, j counters of the for loops