newRPL: Angles revisited

04032016, 11:05 AM
Post: #21




RE: newRPL: Angles revisited
(04012016 11:15 PM)Claudio L. Wrote: This could be a problem. For example an expression: Suppose we allow powers  positive and negative  of these angle tags. Then: 45D * 45D / 45D is 45D whichever way we associate, and 50G * 2 / 90D is always going to be 1. A rule saying that when adding an angle to a number, the number has an implicit tag corresponding to the current angular mode but that there are no implicit tags for multiplication or division would make me happy, but I expect that you would prefer the tag for addition to come from the first argument. There should be a function that at any point removes a tag, including its powers, leaving a number that depends on the current angular mode. This function will be called if an operation is performed that makes no sense for angles. Does this work? If so, does it introduce new problems that I haven't yet considered? Nigel (UK) 

04032016, 04:27 PM
Post: #22




RE: newRPL: Angles revisited
(03312016 06:13 PM)Claudio L. Wrote: A few months back there was a discussion on how to treat angular values in trig functions. Sorry to enter this thread a little late, but... I START with this conceptual notion; angle is the measure of rotation. I think of rotation as illdefined fundamental unit (#8 of 7), such as temperature, time, etc. related to but separate from length. Thoughts? SlideRule 

04032016, 08:12 PM
(This post was last modified: 04042016 10:56 AM by Vtile.)
Post: #23




RE: newRPL: Angles revisited
(04032016 04:27 PM)SlideRule Wrote:It is also measure of time ie. in EE with phasors (f=constant) if we get philosophical P=U*I*Cos(Phi), as it is there for the difference of the phase of the I and U in timedomain. Now when phasors are mentioned, will there be traditional nontagged method of using angles, by just using bare numbers. I think these two methods can't be separated in discussion they must work together and I go as far as saying that tagging should be more like an option to those who are jumping between O/(decided slicing method).(03312016 06:13 PM)Claudio L. Wrote: A few months back there was a discussion on how to treat angular values in trig functions. Ie. If I'm creating impedance (or any Dance) from capacitor 1/(j*2*Pi*f) etc. edit(.. and adding it ..) to existing impedance in polar representation in degrees I wouldn't want it to be some symbolic mess because of the 2*Pi which is radian representation of on full O. Interesting subject, I like to read these on MoHPC. Would be nice to know what angle is in an eyes of mathematician percentage, direction, factor, way of divide Italian food ?? 

04032016, 11:58 PM
Post: #24




RE: newRPL: Angles revisited
(04032016 08:12 PM)Vtile Wrote: Interesting subject, I like to read these on MoHPC. Would be nice to know what angle is in an eyes of mathematician percentage, direction, factor, way of divide Italian food ?? I'm no mathematician, but I learnt long time ago than angles in radians are the ratio of the arc length to the radius (works on a pizza if you like italian food...). Based on that definition it's a nondimensional unit (m/m). That's why is doesn't play well with a unit system. It's a unit in its own right, but yet it's nondimensional, so it has to be consistent with raw numbers. The current unit system in the 50g or newRPL doesn't achieve this property. 1_r + 1 gives you inconsistent unit error, while in reality the operation should proceed. Angular velocity in r/s times the radius in m should give you linear velocity in m/s, not in m*r/s. So angles are always a pain to handle properly. Then we add several ways to measure angles (deg, grad), and throw in there different ways to represent the same measurement (decimal degrees, vs dms), and you have a perfect storm. Really hard to handle correctly, I thought I had a good idea when I started this thread, now I'm not convinced. 

04042016, 12:04 AM
Post: #25




RE: newRPL: Angles revisited
(04032016 11:05 AM)Nigel (UK) Wrote: Suppose we allow powers  positive and negative  of these angle tags. OK, but that's what the unit system does. It takes space, and a lot of extra overhead to operate because it's not a number, it's a number raised to a power. And after you allow powers, you end up having to handle fractional powers too, and then... you have a full blown unit system, same as using 1_r really, except we have to somehow "guess" when is a good time to drop the unit and convert to a number, and when that unit is needed. 

04042016, 11:52 AM
Post: #26




RE: newRPL: Angles revisited
Since I can't find a way to make things work correctly, I think we should drop the part that doesn't work and simplify:
* Tagged angles could be used for user entry. * Tagged angles could be used for return values of trig functions. * Any operation (I mean any) done on a tagged angle will convert it to the current angle system and remove the tag prior to doing the operation itself. * Commands will exist to convert between all tag formats, and to explicitly tag a number. I know it will eliminate many of the useful features (like directly adding/subtracting angles in DMS), but at least won't introduce any weirdness. 

04062016, 01:58 PM
Post: #27




RE: newRPL: Angles revisited
(04042016 11:52 AM)Claudio L. Wrote: Since I can't find a way to make things work correctly, I think we should drop the part that doesn't work and simplify: I guess there's no harm in adding this: * Addition/subtraction between 2 tagged angles returns a tagged angle with the same system as the left argument. All other operations, or if angles get mixed with numbers, will convert to current angle system units and remove the tag, then operate. 

04072016, 01:04 PM
Post: #28




RE: newRPL: Angles revisited
So, if I understand correctly:
If the current angle mode is DEG, then '∡1r * 2' = 114.59 ? JeanCharles 

04072016, 01:35 PM
Post: #29




RE: newRPL: Angles revisited  
04072016, 01:55 PM
Post: #30




RE: newRPL: Angles revisited
(04062016 01:58 PM)Claudio L. Wrote:(04042016 11:52 AM)Claudio L. Wrote: Since I can't find a way to make things work correctly, I think we should drop the part that doesn't work and simplify: I think this approach should be useful without adding too much complexity either to the code or to what the user has to learn. This discussion made me go back and look at the code for my RPN calculator for Casio machines. There is one feature which I had forgotten: a complex number carries an angle tag (radian or degrees) which specifies the angle display mode when polar display is chosen. So a complex number can be entered as polar, displayed as rectangular, and later displayed as polar still keeping the angle tag that the polar angle was entered with. Is this idea at all useful, or is it making things too complicated  especially as newRPL has to support 3D vectors? Nigel (UK) 

04072016, 05:51 PM
Post: #31




RE: newRPL: Angles revisited
(04072016 01:55 PM)Nigel (UK) Wrote: This discussion made me go back and look at the code for my RPN calculator for Casio machines. There is one feature which I had forgotten: a complex number carries an angle tag (radian or degrees) which specifies the angle display mode when polar display is chosen. So a complex number can be entered as polar, displayed as rectangular, and later displayed as polar still keeping the angle tag that the polar angle was entered with. Is this idea at all useful, or is it making things too complicated  especially as newRPL has to support 3D vectors? I intend to eliminate the "polar" mode altogether. Complex numbers and vectors can be created in polar mode by simply including angles in their definition. Once polar, it's always polar, unless a command is used to convert it to cartesian. Operations will detect this and proceed accordingly (again, keeping the format of the "left" argument to decide the format of the result). Basically you compute with vectors, and you convert to polar the results you want to see in polar form. Or, you operate with everything in polar form and get results directly in polar form. This starts getting weird when you add a vector as a matrix row. In such case polar vectors will have to be converted to cartesian before inserting in a matrix. Also product of matrix*vector will have to convert to cartesian. 

05102016, 04:48 AM
Post: #32




RE: newRPL: Angles revisited
Sorry if this has been explained before but now that angles have been implemented in the current (and previous) firmware version, how can I enter the "angle" prefix symbol or de postfix "degree" symbol on the calculator in order to create a tagged angle value ?
Thank you. 

05102016, 02:52 PM
Post: #33




RE: newRPL: Angles revisited
(05102016 04:48 AM)Francois Lanciault Wrote: Sorry if this has been explained before but now that angles have been implemented in the current (and previous) firmware version, how can I enter the "angle" prefix symbol or de postfix "degree" symbol on the calculator in order to create a tagged angle value ? No need to be sorry, this has never been asked before and is not documented anywhere. The keyboard is mapped as follows: In Alpha mode (L or C): RightShift + 6 = Angle symbol (not rightshifthold, that does superscript numbers on all numbers) LeftShift + 6 (or leftshifthold+6) = Degree symbol LeftShift + 9 (or leftshifthold+9) = Delta symbol for the new temperatures, so it's close to the degree for quick typing. 

« Next Oldest  Next Newest »

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