30 Reputation

0 Badges

0 years, 163 days

MaplePrimes Activity

These are replies submitted by mugwort

@tomleslie super, thanks mate, it was the assume function I was looking for.

What put me off using displayprecision was that say if it was set to 3, then a value of 0.000234 would be displayed as 0.000. I guess this isn't too much of a problem since the actual value is still stored precisely, though it would be nice if there was a way to make it work on significant figures rather than decimal places.

Cheers though, I appreciate the tidy up


Sorry to bug you again bud, but the original problem has returned.. the only thing I have changed is replacing all of the decimals to rationals in the definition of p in an attempt to make terms cancel as I would like.. this worked, however, now the csgn function has reappeared. Here's the new workspace if you fancy a look


Also just out of curiousity, it would be nice to know why the cancellation of terms only works nicely when using rational representations rather than decimals with the equivalent value, as it would be nice to know that no nasty rounding is going to occur due to them being integer divisions.

Thanks again

@acer will do

@Kitonum Cheers mate, not sure why that fixed that exactly but that did the trick, also made my precision look a lot nicer too, thanks!

@Kitonum I understand that code may be a pain to read so here's the workspace, thanks again!


Cheers, though I should have been more clear, I was expecting a way to declare the variable x as a real indepently, as I'm not calling the csgn directly, it's inserted by one of my functions:

The last kappa function is simply the magnitude of the vector of the line above, when I try 

kappa(p) assuming real; 

I get a division by 0 error for some reason. Not sure where I should place the statement..

@Carl Love That did the trick, thanks a lot.

Then restricting the domain and repeating for the positives:

And I get a lovely double root surface, thanks again!

@acer Great answer, thanks a lot!

@acer Yeah I did, don't think it will take strings as them though, ah well I'll let them be numbers, cheers anyhow.

@Carl Love 
Good to know, thank you


Both useful solutions to the problem!


Yep my bad, it was a functional operator created using unapply on an expression. (Didn't know this was a type of procedure!)

Using an unassigned x was exactly the solution I was looking for and I'm kind of ashamed I didn't think of that myself😪😪😪


Sorry, I forgot to say they're currently in a fractional format, they aren't evaluated to decimals at all, so changing the display precision had no effect:(

Also I've been trying to avoid printf because I prefer maples pretty font and centred printout, but if there's no other option I guess I'll have to learn them.

Thanks though

Both good answers, permutation output is most convenient!

@acer Thanks for the speedy response!

I've updated my badly named variables as yours make more sense.

Also, this NullSpace of the characteristic equation is just moving the RHS of the equations I had over to the left, so I tried that with my equations:
eigsolve := [(eigscale - evals[1]*evecs[1])[1] = 0, (eigscale - evals[1]*evecs[1])[2] = 0, (eigscale - evals[1]*evecs[1])[2] = 0];

and now the solve function works as it should!


>> [e11 = e11, e12 = 4.730757864*e11, e13 = 1.174206729*e11]

I'm not too sure why it wouldn't work before as all I've done is simplify them through subtraction.

Anyway it was a pain to reassign the components back into evecs[1], even when using assign it seemed to not want to replace e11,e12 & e13 even though when I print e12 it would resolve to 4.730757864*e11. For this reason I've decided your solution is much more elegant as it doesnt require any nasty local variables. However I'm glad I sort of solved it how I was hoping to as I think it will be a more general solution in future.

Or maybe I just need to learn how to maniupulate my forms so that these magic subspace functions will always do the trick!


1 2 Page 1 of 2