Comments for File Exchange Pick of the Week https://blogs.mathworks.com/pick Jiro and Sean share favorite user-contributed submissions from the File Exchange. Wed, 16 Oct 2019 08:55:44 +0000 hourly 1 https://wordpress.org/?v=6.2.2 Comment on Tiled Layout by Naomi Krauzig https://blogs.mathworks.com/pick/2019/09/13/tiled-layout/#comment-29402 Wed, 16 Oct 2019 08:55:44 +0000 https://blogs.mathworks.com/pick/?p=10994#comment-29402 Thank you very much for your useful code! I did change the white space and stacking plots manually with too much effort. Just what I was looking for.

]]>
Comment on New with R2019b – Function Argument Validation by Nikolas B. https://blogs.mathworks.com/pick/2019/09/27/new-with-r2019b-function-argument-validation/#comment-29376 Sat, 05 Oct 2019 20:48:46 +0000 https://blogs.mathworks.com/pick/?p=11026#comment-29376 Are there plans to integrate the arguments block with the help system, by auto-generating nicely formatted function help pages from the information of the arguments block? For this, we would also need to able to add a short description of the purpose of an argument in the arguments block (maybe using end-of-line comments).

It would also be great to introduce an “outputs” block in a function, with a structure similar to the arguments block. This would be useful for auto-generated help. Additionally, this would be a way to specify postconditions of a function in the spirit of the “design-by-contract” programming approach.

]]>
Comment on New with R2019b – Function Argument Validation by Stephen Lien https://blogs.mathworks.com/pick/2019/09/27/new-with-r2019b-function-argument-validation/#comment-29374 Thu, 03 Oct 2019 21:17:26 +0000 https://blogs.mathworks.com/pick/?p=11026#comment-29374 As far as slowness goes… From looking at our professional developers (unlike me who just hacks in languages like Matlab), I see them creating a validate inputs method/routine or validating during object creation, and then having methods that operate on the validated object. This way validation can be as extensive as needed and the “engines” aren’t bogged down and can be as efficient as possible.

]]>
Comment on New with R2019b – Function Argument Validation by Jiro Doke https://blogs.mathworks.com/pick/2019/09/27/new-with-r2019b-function-argument-validation/#comment-29368 Wed, 02 Oct 2019 22:35:55 +0000 https://blogs.mathworks.com/pick/?p=11026#comment-29368 @Todd
There are no plans to remove inputParser. But we would recommend using function argument validation if it can be used.

@Adam
I understand your comment about validateattributes and how it can serve sort of like documentation with its syntax. In that regards, I think the new arguments blocks serve that purpose even more, because of the fact that they come at the very top of the function as the first executable code after the function signature.

Of course, just like with any new functionality, it could take some time to get used to, or you may not be able to use it if your target user audience uses older releases.

]]>
Comment on New with R2019b – Function Argument Validation by Jiro Doke https://blogs.mathworks.com/pick/2019/09/27/new-with-r2019b-function-argument-validation/#comment-29366 Wed, 02 Oct 2019 15:38:18 +0000 https://blogs.mathworks.com/pick/?p=11026#comment-29366 @Joanne,
Thanks for pointing that out. The syntax highlighting issue was with WordPress not rendering the syntax correctly. So I changed the post to include an image of the function in the MATLAB Editor. You can see the correct highlighting.

Regarding the “nbins” example, the validation code actually attempts data type conversion according to standard MATLAB conversion rules. So that means that passing in a single or uint8 would work, since double(uint8(20)) works without error.

]]>
Comment on New with R2019b – Function Argument Validation by Joanne Williams https://blogs.mathworks.com/pick/2019/09/27/new-with-r2019b-function-argument-validation/#comment-29364 Wed, 02 Oct 2019 15:16:19 +0000 https://blogs.mathworks.com/pick/?p=11026#comment-29364 For anyone else utterly baffled by this entry and the mis-matched ends, it makes a bit more sense if you look at the help files where the syntax-highlighting is consistent!

arguments
....
end

is a new block. It’ll probably throw some interesting errors if you pass your code to someone with an older version of matlab! Once that’s sorted it looks fairly neat, but I don’t have 2019 yet, so will carry on with the legacy use of parse_pv_pairs for now.

Also, in the example, nbins is “double”, but since it mustBeInteger what happens if you pass a single or uint8? Can you allow more flexible arguments? One of the nice (though risky!) things about Matlab over the old Fortran days is that you can get away without defining the inputs exactly.

Jo

]]>
Comment on New with R2019b – Function Argument Validation by Todd Schultz https://blogs.mathworks.com/pick/2019/09/27/new-with-r2019b-function-argument-validation/#comment-29362 Tue, 01 Oct 2019 20:47:18 +0000 https://blogs.mathworks.com/pick/?p=11026#comment-29362 Interesting but I definitely see the overlap with the inputParser. What is the recommendation moving forward? Will both the inputParser and the Function Argument Validation features will be continued to be developed or is one slated for the dust bin in the future?

]]>
Comment on New with R2019b – Function Argument Validation by Adam Eckersley https://blogs.mathworks.com/pick/2019/09/27/new-with-r2019b-function-argument-validation/#comment-29360 Tue, 01 Oct 2019 15:31:39 +0000 https://blogs.mathworks.com/pick/?p=11026#comment-29360 I’ve always made heavy use of validateattributes in my code for my input arguments in public functions. I like the fact it acts like documentation as well as actual validation as, since I write OOP code mostly I’m unlikely to easily remember when I come back to my own functions even a month later, exactly what type of input is expected (comments are OK, but how easy it is for them to get out of date!).

I was very interested when I saw this addition to R2019b, although in common with the similar addition for class properties in a recent version I haven’t really got to grips with using it yet. Maybe when I get around to trying it to familiarise with the language it will become my new standard.

As with the previous comment though I have found my over-zealousness to validateattributes in my functions has caused major performance hits in iterative algorithms so I ended up commenting out the validateattributes so it at least stays as documentation, but doesn’t hit performance.

]]>
Comment on New with R2019b – Function Argument Validation by Dave Foti https://blogs.mathworks.com/pick/2019/09/27/new-with-r2019b-function-argument-validation/#comment-29358 Sun, 29 Sep 2019 18:17:50 +0000 https://blogs.mathworks.com/pick/?p=11026#comment-29358 Hi Doug,
Runtime performance has been designed and tested to generally be better than inputParser and will continue to improve over time as optimizations are able to move some work from run-time to JIT-compile time. However, most validation does take run time and especially element-wise validation such as looking for real or positive values. In general validation is most helpful and least expensive at the edge of an interface where values are coming from unknown sources and where there is significant work being done with the inputs.

]]>
Comment on New with R2019b – Function Argument Validation by Doug McMartin https://blogs.mathworks.com/pick/2019/09/27/new-with-r2019b-function-argument-validation/#comment-29356 Fri, 27 Sep 2019 17:25:01 +0000 https://blogs.mathworks.com/pick/?p=11026#comment-29356 Can you talk about the run-time performance of this feature? I’m a fan of inputParser, but I discovered it can have a huge performance impact, especially if your function is called & validated thousands of times.

]]>