Carl Love

Carl Love

28025 Reputation

25 Badges

12 years, 313 days
Himself
Wayland, Massachusetts, United States
My name was formerly Carl Devore.

MaplePrimes Activity


These are answers submitted by Carl Love

The only official help for it that I can find is on page ?type,structure:

  • The type specfunc(t, n) matches the function n with 0 or more arguments of type t.  Thus, type(f, specfunc(t, n)) is equivalent to the logical conjunction type(f, function) and op(0,f) = n and type([op(f)], list(t)). Instead of a single name n, a set of names may be passed as the second parameter to the specfunc type constructor.  In this case, an expression matches if it is a function call with any of the names in the set as the 0-th operand. Thus, type(f,specfunc(t,{n1,n2,...,nk})) is equivalent to type(f,specfunc(t,n1)) or type(f,specfunc(t, n2)) or ... or type(f,specfunc(t,nk)).

That's pretty dense material, but if you have any specific questions about it, I have an expert-level understanding of it, so fire away.

The only thing that I can imagine that you're failing to see about it is that all arguments of the function must be of the specified type(s). So, consider your F: Because of the j, there is no occurence of u with all arguments of type `+`.

If you're only interested in type-checking u's first argument, we can work on that; there are a few options. Also note that specfunc does nothing to control the number of arguments; u() will pass through all of your typespecs, and the transformer will then fail because it requires op(1, ...).

And I suppose that you already know that {type1, type2} is the union of those types.

Unrelated issue: You could (I'm not saying should) replace your transformer that uses subsop with

f-> applyop(`+`, 1, f, 1);

There's no efficiency benefit (as of Maple 2018) to doing this, since applyop simply translates it back to what you had with subsop, which you can see via showstat(applyop). I just think that it's a bit cleaner with applyop.

 


 

There are two ways to get the name, strictly speaking: evaln(x) or 'x'. Those are forward single quotes, and they're known in Maple as unevaluation quotes or delayed evaluation quotes. They're very commonly used, but evaln is not. There's a slight distinction between the two: The quotes can be used on anything, but evaln requires an underlying name.

The way that you posted (using double quotes) indicates that you might want the name as a string. In that case, you still need to use one of the options from the first paragraph, and then convert to a string:

convert('x', 'string');
or
convert(evaln(x), 'string');

The quotes on string are not strictly necessary in this case. I just wanted to show you how unevaluation quotes are commonly used. They protect against the possibility that you've assigned a value to string (probably unintentionally).

I'll suppose that the above set is named Sols. Then all you need to do is eval with respect to Sols and then use assign, like this:

Sols:= {R = 7.339698158, S = 2.378491488, W = 2.512047349}:
assign(eval([X=R, Y=S], Sols));

The assign command displays no output, but if you look at X and Y, you'll see that they're the desired numbers.

The commands printf and print cause stuff to be displayed on your screen. In a trivial sense, this could be considered "output", but, as you've noted, it's not usable. Ordinarily, this is a common rank-newbie error, but considering the way that the exercise's instructions are given on RosettaCode, the author made a reasonable choice. A procedure's true output, or return value, is set by a return statement, or more usually as the last expression evaluated. Here's a procedure that does what you want:

splitChange:= proc(str::string) 
local start, i:= 1, len:= StringTools:-Length(str), R:= table();
   while (start:= i) <= len do
      for i from start to len do until str[i] <> str[start]; 
      R[start]:= str[start..i-1]
   end do;
   [entries(R, 'indexorder', 'nolist')]
end proc:

 

That's a very interesting discovery. The strange thing to me is not that the bond is lost in the second case, but that the bond exists in the first case. If the bond continued to exist in the second case, that would be a mystery akin to quantum entanglement.[*1]

I notice that you're saving to Maple-internal-format .m files. Apparently, that format retains the information that items share a memory address. If you change to a plain-text format by using any filename other than *.m, then the strange bond disappears.

But the issue has absolutely nothing to do with tables or eval, so it'd be helpful if you retitled this Question. Here's an illustration using simple name variables:

restart:
A:= B: B:= x:
currentdir("C:/Users/CarlJ/Desktop"):
save B, A, "FC.m"; #Note: B, A; not A, B!
restart:
currentdir("C:/Users/CarlJ/Desktop"):
read("FC.m");
B:= y:
A;
                               y

[*1]Come to think of it, suppose that this were being run on two quantum computers. The files containing A and B, respectively, are created on computer Q1. File B is sent to computer Q2, and it's read there. Is it possible that the bond could be maintained?

Change cat(elemt) to parse(elemt). The help page does not say that the element name / symbol can be a string, although I'd agree that a string should be allowed.

f:= (t,y)-> -y + t*y^(1/2);
diff(f(t, y(t)), t);

It simply can't be done for an Array (note the distinction with array), and I don't see why you'd want to do it. An Array's entries always have a value. That value may be NULLundefined, etc., but those are still values.

Look at the last few characters of your description:

 `digits"`;  

If this doesn't make the problem obvious already, then I'll explain further.

You didn't show your failed attempts, so I can't really diagnose what you were doing wrong. But the most-obvious command works for me:

subs(sqrt((n__x^2 + n__y^2 + n__z^2)*c^2)= phi, X);

Perhaps you entered n[x], etc., instead of n__x?

The simplest thing that you can do is use a higher value of Digits, which will affect the accuracy of all internal computations. The following gives a perfect plot. A lower value of Digits might also work, but I didn't try.

f:= x-> exp(x)*HeunC(2*x, 1/2, -1/2, -x^2, 1/8, 99/100):
Digits:= 30:
plot(f(x), x= 0..40);

Of course, using more Digits takes more time. If you need a way to do repeated high-speed computations with this function, we can work on that.

I have two issues with your worksheet, one major and one minor.

You have already hinted at the major issue by what you said about your variable cool. All output which will be re-used should be assigned to a variable, and all future references should be through that variable, not by re-entering the output as input. I'll state it as a maxim of programming in a command-line environment: Never re-enter output as input.

The minor issue is that there's no point to showing the value of kk, and certainly not its decimal value.

The VIEW component of the graph can be extracted by 

indets(a, specfunc(VIEW))[];

Thus, one doesn't need to remember the magic position number. It's not even clear that it's always in the same position.

I can anticipate your next two questions, so i might as well answer the first now: Even from my phone I can see that you have 3 dependent variables and only 2 ODEs. You need one more ODE. And you'll need a number of new BCs equivalent to the highest differential order of phi in the 3 ODEs.

It can be done by 

{evalindets(expression, set, op)};

This may re-arrange the order of the terms. The user cannot control the order of items in a set.

And, although it doesn't happen in this case, if some of the embedded sets have a number of elements other than 1, it's likely that the resulting expression will no longer be syntactically valid. So, I'd recommend against creating arithmetic expressions with embedded sets. A much better form of encapsulation can be achieved with functions, which, of course, interact with arithmetic operators in all the normal ways.

And, if you want the encapsulated expressions to prettyprint as if they were sets, using the { }, even though they're internally represented as functions, that's also easy.

First 161 162 163 164 165 166 167 Last Page 163 of 395