HP 50G help

[jrmc114064]

I've had my 50G for about a year now and use it heavily, recently I have been working on problems that incorporate variables within the integral and am having trouble as it seems each time I take the antiderivative it throws up a undefined name error. I was hoping to get some help, an example problem would be:

int(ax^2-4,x)

How would you account for the variable a? Thanks for your time, really do appreciate it, and I know my syntax is wrong for my example in advance

[Gilles]

(04-23-2015 04:11 AM)jrmc114064 Wrote:  int(ax^2-4,x)

How would you account for the variable a? Thanks for your time, really do appreciate it, and I know my syntax is wrong for my example in advance

Hi,

INT calculate then antiderivative at a given point . If you want the general solution, you can do (RPL mode, Indep var : X)

'A*X^2-4' INTVX

or

'A*X^2-4' 'X' 'X' INT

Not know about ALG mode but I suppose something like :
INTVX(A*X^2-4)
INT(A*X^2-4,X, X)

->

A.(1/3. X^3)-4.X

Verify that
- there is no 'A' variable already define in the directory you work or in parent directories
- No implicit multiplication with the 50G. AX is not A.X

[jrmc114064]

Thanks, don't know what I've been doing wrong, been trying to solve this problem:

Int(0,a,.3*sin(2*π*x)*(1-1/a),x)=.0191

And haven't had much luck, is there anyway I could do this problem quickly, seems if I use the numerical solver I get nothing for some time.....

[jrmc114064]

Interesting if I run the function through in exactly mode I get the function yet when taking the antiderivative it prompts to change to approx mode, if I start in approx mode though it puts up the undefined name error...

[Tugdual]

Even more disturbing: INTVX on .3 * sin(2*π*X)*(1-1/a)
Returns infinite.
What the heck?

[peacecalc]

Hello Tugdual,

a first short test shows (with the real calc).

a) real exact mode
b) used expression: \[ \frac{3}{10}\cdot\sin(2\cdot N \cdot X) \cdot\ (1 - \frac{1}{A}) \] does not work (internally the command intvx tried to use the partial integration method with u = \[ 1 - \frac{1}{A} \] ) and failed.
c) used expression: \[ \frac{3}{10}\cdot\ (1 - \frac{1}{A})\cdot\sin(2\cdot N \cdot X) \] does work (internally the command intvx tried to use the linearization method of the sin function ) and you get the right result.

I used 3/10 instead of 0.3 because in general it is not a good idea to mix exact numbers with real numbers with symbolic transformations.

greetings peacecalc

[Marcio]

I think that sine inside the integral is going to get you into trouble if you try to solve the problem all at once.

If you solve it by parts, you will get a function f with only "a" as unknown. Give it a good guess and you'll get the answer.

Edit: These are some of the zeros, assuming "a" is positive:

1.344702
1.761940
2.206740

Note some of them are really close to each other.

[Tugdual]

(04-23-2015 10:23 PM)peacecalc Wrote:  Hello Tugdual,

a first short test shows (with the real calc).

a) real exact mode
b) used expression: \[ \frac{3}{10}\cdot\sin(2\cdot N \cdot X) \cdot\ (1 - \frac{1}{A}) \] does not work (internally the command intvx tried to use the partial integration method with u = \[ 1 - \frac{1}{A} \] ) and failed.
c) used expression: \[ \frac{3}{10}\cdot\ (1 - \frac{1}{A})\cdot\sin(2\cdot N \cdot X) \] does work (internally the command intvx tried to use the linearization method of the sin function ) and you get the right result.

I used 3/10 instead of 0.3 because in general it is not a good idea to mix exact numbers with real numbers with symbolic transformations.

greetings peacecalc

Hi Peacecalc, I tried on the emulator and it works.
But the real calc keeps saying this

I have no idea why....

Note: I used smaller case 'a' and Pi instead of 'N' but ultimately it doesn't make any difference.

Edit: I just resetted the 50g F1+F6+ON and now it works fine.
Oh well...

[Marcus von Cube]

(04-24-2015 07:16 AM)Tugdual Wrote:  I have no idea why....

Maybe 'a' did exist and contained 0?

[Tugdual]

(04-24-2015 08:41 AM)Marcus von Cube Wrote:  

(04-24-2015 07:16 AM)Tugdual Wrote:  I have no idea why....

Maybe 'a' did exist and contained 0?

Good catch but I had checked that.
Now I defined 'a'=0 and indeed get the same result.
I don't expect the 50g to search into all directories but the current one right (unless I misunderstood something quite fundamental)?

Now to answer jrmc114064 once the INTVX is done, it becomes easy to solve.
So basically 2 steps operation.

[Marcus von Cube]

(04-24-2015 10:21 AM)Tugdual Wrote:  I don't expect the 50g to search into all directories but the current one right (unless I misunderstood something quite fundamental)?

As far as I know the 50g looks in all directories up the directory tree, at least in the home directory.

[Tugdual]

(04-24-2015 11:08 AM)Marcus von Cube Wrote:  

(04-24-2015 10:21 AM)Tugdual Wrote:  I don't expect the 50g to search into all directories but the current one right (unless I misunderstood something quite fundamental)?

As far as I know the 50g looks in all directories up the directory tree, at least in the home directory.

Now that is something absolutely fundamental I didn't know.
Thanks Marcus.

[DavidM]

(04-24-2015 11:52 AM)Tugdual Wrote:  

(04-24-2015 11:08 AM)Marcus von Cube Wrote:  As far as I know the 50g looks in all directories up the directory tree, at least in the home directory.

Now that is something absolutely fundamental I didn't know.
Thanks Marcus.

From the AUG (Advanced Users Guide) for the RCL command:

Quote:RCL searches the entire current path, starting with the current directory. To search a different path, specify { path name }, where path is the new path to the variable name. The path subdirectory does not become the current subdirectory (unlike EVAL).

Though it's not stated explicitly, this same behavior is applied to many built-in operations where an implicit RCL of a variable is executed. I can't remember the details at the moment, but I'm pretty sure there are at least a couple exceptions to this rule. It all boils down to which SysRPL opcode is used to get a variable's contents onto the stack. Most of the time the parent directories are searched.

Note that this isn't the same as searching all directories. Just the ones in the current path are included.

[Tugdual]

(04-24-2015 04:23 PM)DavidM Wrote:  

(04-24-2015 11:52 AM)Tugdual Wrote:  Now that is something absolutely fundamental I didn't know.
Thanks Marcus.

From the AUG (Advanced Users Guide) for the RCL command:

Quote:RCL searches the entire current path, starting with the current directory. To search a different path, specify { path name }, where path is the new path to the variable name. The path subdirectory does not become the current subdirectory (unlike EVAL).

Though it's not stated explicitly, this same behavior is applied to many built-in operations where an implicit RCL of a variable is executed. I can't remember the details at the moment, but I'm pretty sure there are at least a couple exceptions to this rule. It all boils down to which SysRPL opcode is used to get a variable's contents onto the stack. Most of the time the parent directories are searched.

Note that this isn't the same as searching all directories. Just the ones in the current path are included.

It is indeed something fundamental to understand.
But this being said is that the right way to go? The calculator would naturally feed the root directory with a lot of crap and a purge is tedious; my conception of a directory is precisely to isolate/encapsulate problems in their own context. So when I create a subdir I would expect to start with a blank page.
In my humble opinion, this mechanism totally ruin the concept of directories.

[Han]

(04-24-2015 05:19 PM)Tugdual Wrote:  

(04-24-2015 04:23 PM)DavidM Wrote:  From the AUG (Advanced Users Guide) for the RCL command:

Though it's not stated explicitly, this same behavior is applied to many built-in operations where an implicit RCL of a variable is executed. I can't remember the details at the moment, but I'm pretty sure there are at least a couple exceptions to this rule. It all boils down to which SysRPL opcode is used to get a variable's contents onto the stack. Most of the time the parent directories are searched.

Note that this isn't the same as searching all directories. Just the ones in the current path are included.

It is indeed something fundamental to understand.
But this being said is that the right way to go? The calculator would naturally feed the root directory with a lot of crap and a purge is tedious; my conception of a directory is precisely to isolate/encapsulate problems in their own context. So when I create a subdir I would expect to start with a blank page.
In my humble opinion, this mechanism totally ruin the concept of directories.

I personally think it is the right way to go. If you want to recall or store a value using only the current directory, there is a mechanism to do that:

PATH 'MYVAR' + RCL (or replace RCL with STO)

is the strict way to recall or store values in the current directory. The current mechanism allows one to have a single instance of a variable (in a containing directory) and have it be accessible in all lower subdirectories. Otherwise, we would have a lot of unnecessary redundancy.

[rprosperi]

(04-24-2015 05:19 PM)Tugdual Wrote:  

(04-24-2015 04:23 PM)DavidM Wrote:  From the AUG (Advanced Users Guide) for the RCL command:

Though it's not stated explicitly, this same behavior is applied to many built-in operations where an implicit RCL of a variable is executed. I can't remember the details at the moment, but I'm pretty sure there are at least a couple exceptions to this rule. It all boils down to which SysRPL opcode is used to get a variable's contents onto the stack. Most of the time the parent directories are searched.

Note that this isn't the same as searching all directories. Just the ones in the current path are included.

It is indeed something fundamental to understand.
But this being said is that the right way to go? The calculator would naturally feed the root directory with a lot of crap and a purge is tedious; my conception of a directory is precisely to isolate/encapsulate problems in their own context. So when I create a subdir I would expect to start with a blank page.
In my humble opinion, this mechanism totally ruin the concept of directories.

You can effectively accomplish that by not including variables in the Home (top-most) folder. Create only folders at the top and then you can move into each project folder to do whatever, and the programs running there can only "see" other items in that folder plus the above Home folder, which contains no variables/programs (if you follow this technique). Of course this includes folders in folders, etc.

But you will quicklly find that there are many objects (utilities, etc.) which you really do want to use everyewhere, and these should be stored in Home.

Also, the CUSTOM menu also is (or can be) unique to each folder, so you can can have a set of key assignments unique to the programs, objects, etc in that folder. Just build it and save it to 'CST' within that folder.

Read Bill Wickes purple book on the 48G (included in the MoHPC USB Drive collection) it provides excellent explanations and real world examples of how to use these techniques to build modular tools and programs. Many of his non-trivial tools utilize 3, 4, 5+ different directories (folders). Good Stuff!!

[DavidM]

(04-24-2015 05:19 PM)Tugdual Wrote:  It is indeed something fundamental to understand.
But this being said is that the right way to go? The calculator would naturally feed the root directory with a lot of crap and a purge is tedious; my conception of a directory is precisely to isolate/encapsulate problems in their own context. So when I create a subdir I would expect to start with a blank page.
In my humble opinion, this mechanism totally ruin the concept of directories.

As others are pointing out, there's benefits to this technique and at the same time you can still be more explicit with your own programs if needed.

Note that this is more of an issue for RCL than STO. Consider the following:

- you have an object named 'ABC' in HOME containing the string "ABCDEFGHIJK"
- your current directory is set to { HOME MyVars MyStrings }, and it contains no objects

In this scenario, if you place 'ABC' on the stack and execute RCL, you will end up with "ABCDEFGHIJK" on the stack that was recalled from HOME. Conversely, if you enter "XYZ" and 'ABC' on the stack and press STO, the result will be two different 'ABC' variables in two different locations: { HOME } and { HOME MyVars MyStrings } . The original version in HOME is left unchanged, and a new one is stored in the current directory.

[Tugdual]

(04-24-2015 07:34 PM)DavidM Wrote:  

(04-24-2015 05:19 PM)Tugdual Wrote:  It is indeed something fundamental to understand.
But this being said is that the right way to go? The calculator would naturally feed the root directory with a lot of crap and a purge is tedious; my conception of a directory is precisely to isolate/encapsulate problems in their own context. So when I create a subdir I would expect to start with a blank page.
In my humble opinion, this mechanism totally ruin the concept of directories.

As others are pointing out, there's benefits to this technique and at the same time you can still be more explicit with your own programs if needed.

Note that this is more of an issue for RCL than STO. Consider the following:

- you have an object named 'ABC' in HOME containing the string "ABCDEFGHIJK"
- your current directory is set to { HOME MyVars MyStrings }, and it contains no objects

In this scenario, if you place 'ABC' on the stack and execute RCL, you will end up with "ABCDEFGHIJK" on the stack that was recalled from HOME. Conversely, if you enter "XYZ" and 'ABC' on the stack and press STO, the result will be two different 'ABC' variables in two different locations: { HOME } and { HOME MyVars MyStrings } . The original version in HOME is left unchanged, and a new one is stored in the current directory.

Understood, but root variables are pretty similar to global variables which I tend to avoid since the day I started OOP.

Also the major drawback is that you cannot undefine a variable locally, hence CAS will be confused and would use root variable when you really meant it to be unknown and symbolic. I can't help finding that very misleading.

Finally the VAR button does only show variables of the current directory while there could be much more available at this stage. This I think is the origin of my confusion and somehow this is not consistent with the way the calculator actually operates.

This being said I respect all opinions expressed from people having obviously much more experience than I on this topic. I'll obviously need to dig a little bit more in the user guides. Tx all for feedback.

[Gilles]

(04-23-2015 04:00 PM)jrmc114064 Wrote:  Thanks, don't know what I've been doing wrong, been trying to solve this problem:

Int(0,a,.3*sin(2*π*x)*(1-1/a),x)=.0191

And haven't had much luck, is there anyway I could do this problem quickly, seems if I use the numerical solver I get nothing for some time.....

The precision (and the time to solve !) of the numeric solver depands on "Number format" (MODE FIX 4 for example for a precision of 4 digits)

Are you sure of your equation (the 1/a part) ?

If your equation is OK, the numerical solver returns results with a guess <> 0 (because of 1/a ?) : a=1.3447... a=2.2067... etc.

EDIT : same problem with guess = 0 on the Prime... and same results...

[Marcio]

(04-25-2015 12:48 PM)Gilles Wrote:  The precision (and the time to solve !) of the numeric solver depands on "Number format" (MODE FIX 4 for example for a precision of 4 digits)

Are you sure of your equation (the 1/a part) ?

If your equation is OK, the numerical solver returns results with a guess <> 0 (because of 1/a ?) : a=1.3447... a=2.2067... etc.

EDIT : same problem with guess = 0 on the Prime... and same results...

What function are you calling to find the roots on the Prime? If you're calling solve, fsolve or nSolve from HOME you might get "unpleasantly surprised". Take a look at this thread.
The Solve app will work as expected though.