Skip to main content

version 10 - What is the status of `::usage` and Templates in Mathematica v11?


Since Mathematica 9, a number of issues concerning the ::usage and templates were raised.


In 9.0, there was a bug first reported here and better diagnosed here, where error messages were generated by simply moving the insertion point somewhere in the argument of a function for which a ::usage was defined. This was fixed in 9.0.1


Starting in version 9.0 and observed through 10.4.1, it was reported here that functions with formatted ::usage needed ?Function to be called twice in order for messages to be rendered properly. A bandaid solution was given here.


Certain inflexibility about the text in the templates was raised here and again here, and inconsistencies reported here (also see here).


The consensus I gather from the discussion in the comments above is that ::usage and templates are implemented in Mathematica in a very kludgy way. This can be a source of major frustration for package developers.


So the question I raise is which of the issues have been addressed in v10 and v11? Are there plans for a major overhaul of the ::usage system?



Answer



1) The complete failure of Make Template with formatted usages is fixed in our next release. I can't promise you it will look 100% beautiful in all cases, but the number of templates will match the number in the usage message and you'll at least recognize it as something related to what you put in there. I'm sorry it's taken so long to be addressed--it really has been on our radar for some time--but the fix required a certain amount of cleanup that was not easy to do.



2) About the need to call information twice, we didn't fix it because it was never reported as a bug. There were a few internal reports, but nothing external. We can't fix what we don't know about. While we do monitor stack exchange, there is no substitute for actual bug reports send to support. This has the greatest chance of being routed to the right developer, and the more people how report it, the more resources might be spent on fixing the issue. I'll respond with more details on the appropriate question, but this issue is also fixed for the next release.


3) It's true that we don't provide the same capabability for developer templates as our own. For many reasons, our internal tooling has been constantly evolving since V9 came out. Deploying it to external developers, when we are not confident it is robust and stable, just hasn't been feasible. Hopefully we will get there, but we're certainly not in a position to promise on any particular schedule. In the mean time, we've dealt with two significant issues in our upcoming release. If there are more point fixes we can make to the current system, send in reports!


Comments

Post a Comment

Popular posts from this blog

mathematical optimization - Minimizing using indices, error: Part::pkspec1: The expression cannot be used as a part specification

I want to use Minimize where the variables to minimize are indices pointing into an array. Here a MWE that hopefully shows what my problem is. vars = u@# & /@ Range[3]; cons = Flatten@ { Table[(u[j] != #) & /@ vars[[j + 1 ;; -1]], {j, 1, 3 - 1}], 1 vec1 = {1, 2, 3}; vec2 = {1, 2, 3}; Minimize[{Total@((vec1[[#]] - vec2[[u[#]]])^2 & /@ Range[1, 3]), cons}, vars, Integers] The error I get: Part::pkspec1: The expression u[1] cannot be used as a part specification. >> Answer Ok, it seems that one can get around Mathematica trying to evaluate vec2[[u[1]]] too early by using the function Indexed[vec2,u[1]] . The working MWE would then look like the following: vars = u@# & /@ Range[3]; cons = Flatten@{ Table[(u[j] != #) & /@ vars[[j + 1 ;; -1]], {j, 1, 3 - 1}], 1 vec1 = {1, 2, 3}; vec2 = {1, 2, 3}; NMinimize[ {Total@((vec1[[#]] - Indexed[vec2, u[#]])^2 & /@ R...
Post a Comment
Read more

functions - Get leading series expansion term?

Given a function f[x] , I would like to have a function leadingSeries that returns just the leading term in the series around x=0 . For example: leadingSeries[(1/x + 2)/(4 + 1/x^2 + x)] x and leadingSeries[(1/x + 2 + (1 - 1/x^3)/4)/(4 + x)] -(1/(16 x^3)) Is there such a function in Mathematica? Or maybe one can implement it efficiently? EDIT I finally went with the following implementation, based on Carl Woll 's answer: lds[ex_,x_]:=( (ex/.x->(x+O[x]^2))/.SeriesData[U_,Z_,L_List,Mi_,Ma_,De_]:>SeriesData[U,Z,{L[[1]]},Mi,Mi+1,De]//Quiet//Normal) The advantage is, that this one also properly works with functions whose leading term is a constant: lds[Exp[x],x] 1 Answer Update 1 Updated to eliminate SeriesData and to not return additional terms Perhaps you could use: leadingSeries[expr_, x_] := Normal[expr /. x->(x+O[x]^2) /. a_List :> Take[a, 1]] Then for your examples: leadingSeries[(1/x + 2)/(4 + 1/x^2 + x), x] leadingSeries[Exp[x], x] leadingSeries[(1/x + 2 + (1 - 1/x...
Post a Comment
Read more

What is and isn't a valid variable specification for Manipulate?

I have an expression whose terms have arguments (representing subscripts), like this: myExpr = A[0] + V[1,T] I would like to put it inside a Manipulate to see its value as I move around the parameters. (The goal is eventually to plot it wrt one of the variables inside.) However, Mathematica complains when I set V[1,T] as a manipulated variable: Manipulate[Evaluate[myExpr], {A[0], 0, 1}, {V[1, T], 0, 1}] (*Manipulate::vsform: Manipulate argument {V[1,T],0,1} does not have the correct form for a variable specification. >> *) As a workaround, if I get rid of the symbol T inside the argument, it works fine: Manipulate[ Evaluate[myExpr /. T -> 15], {A[0], 0, 1}, {V[1, 15], 0, 1}] Why this behavior? Can anyone point me to the documentation that says what counts as a valid variable? And is there a way to get Manpiulate to accept an expression with a symbolic argument as a variable? Investigations I've done so far: I tried using variableQ from this answer , but it says V[1...
Post a Comment
Read more