Carl Love

Carl Love

19094 Reputation

24 Badges

7 years, 351 days
Mt Laurel, New Jersey, United States
My name was formerly Carl Devore.

MaplePrimes Activity


These are replies submitted by Carl Love

@J F Ogilvie wrote:

  • If software, such as the Physics Updates, werre properly designed and tested before release, such a 'work-around' would be completely unnecessary.

What if the problem is caused by a change Microsoft made to Windows? I'm not saying that it is, but that certainly seems a not unlikely possibility. In that case, no amount testing at Maplesoft's end would've helped. As has been stated multiple times, the problem is not with Physics Updates per se; the problem is with the installer.

And what are these marginal computers and marginal operating systems that you refer to?

I doubt that solving an equation with "undetermined parameters" could be divided into subtasks which could be run in parallel, either with or without shared memory. Do you have reason to believe that the equation can be solved at all?

@Carl Love There are cases where the max of the discontinuities can't be determined even though the discontinuities themselves can be. Such cases are likely to arise when symbolic parameters are used (as in exp(a*t)). So instead of finding the max, it's better to assume Re(s) is greater than all discontinuities. So change my procedure to this:

Laplace:= proc(f::algebraic, t::name, s::name)
local J:= int(f*exp(-s*t), t);
    limit(J, t= infinity) - limit(J, t= 0, 'right') 
        assuming (Re(s) >~ {0, discont(J, s)[]})[]
end proc
:
Laplace(exp(a*t) + exp(b*t), t, s);

 

@AHSAN I don't have any Maple file for it. How about you type in into Maple?

@nm Your procedure is specific to exponential functions. See the discont command for a more general solution.

@saher You need to assume that Re(s) is "large enough" to avoid any discontinuities in the transform. In the case that you show, the transform is 1/(s-1), so assuming Re(s) > 1 works.

Get rid of the assume command; use assuming.

Laplace:= proc(f::algebraic, t::name, s::name)
local J:= int(f*exp(-s*t), t);
    limit(J, t= infinity) - limit(J, t= 0, 'right') 
        assuming Re(s) > max(discont(J, s));
end proc
:
Laplace(exp(t), t, s);

 

I don't think that it's possible to make a parameterized alias.

Don't check off all the boxes in the Question header. This Question is about Maple alone. Checking extra boxes is rude and angers those who answer the questions.

@AHSAN Okay, I missed that h = 1 + x^2/2. With that, the problem makes sense.

@acer I didn't mean my Answer as a criticism of yours, and I hope that you didn't take it that way. Indeed, your Answer is close to an Answer I posted and then changed to just hints. If solve works (I also checked it on every 3-subset), then surely it's an appropriate first attempt for the OP before wading into the foreboding syntax of modular methods. The OP's posted solution attempt already suggests that they were trying to using modular matrix methods.

By the way, do you have any suggestions to improve my foreboding LinearAlgebra:-Modular syntax?

As far as I can see, none of equations 1, 2, or 3 contain x (without subscript) on their right sides. Thus, the problem doesn't make sense to me.

@a_simsim Today a spammer made an identical copy of @nm's Post from the head of this thread, and you responded to it. In order to delete the spam, I needed to delete your Comment also. Please feel free to put your Comment here.

Nevermind. I just ran my test suite in Maple 2020.1, and I see that the fix has been released. Meanwhile, I think that that recent Questioner has deleted their Question.

@epostma Has your fix been released yet? I ask because this issue has been re-raised in a recent Question, albeit with a header marked "Maple 2019".

@Scot Gould I think that prime notation only works in 2D Input, which is fine. That's the reason that I didn't mention it.

@acer I wonder why you think that there might be a possibility of gaining some efficiency by separating the real and imaginary arithmetic. Is it that you think that you may be able to beat the C-compiler's ability to efficiently separate the arithmetic (does the default C-compiler not know the idiosyncracies of the processors that it generates code for?)? Or is it that the separation may allow for some symbolic simplification specific to Tetration?

1 2 3 4 5 6 7 Last Page 1 of 547