Random deletion of matrix vectors

This is a prototype and essentialy a first version from a relatively novice matlab user.

Description

The file uses a function from matlab central exchange and is provided with programme.The programme requires input from the user ie the matrix in which you want to delete rows/columns randomly and the number of random values you need for your matrix vector deletion.

Acknowledgements

The author wishes to acknowledge the following in the creation of this submission:
elmat+ 2.2

• MATLAB release: MATLAB 7 (R14)

[John D'Errico]

This does not offer anything that another user will find even remotely useful in their work. Delmat is taken from another submission, so only hablossrandel.m is new here.

This is a script file that loads an (unsupplied) file with unknown data. It process that data in a way that the author apparently finds useful, but probably to nobody else. No explanation is provided that tells what this code does or why it does that.

So I am sorry, but even if the author wins a Nobel prize based on what this tool does (hardly likely), this code is still of absolutely no value to the rest of the world.

Finally, I did look for the positive aspects of this tool. There are a few comments that explain what some of the variables were, but since nobody has any inkling what data this is supposed to use, those comments were of no real value. I was pleased to see that the author has provided roughly as many lines of comments as lines of actual code. This is a good start.

What could the author have done better?

1. Think of a submitted tool as something that someone else might find useful. You want to make this task as easy as possible. Good help and full explanations are very important, plus the tool should also be useful to others.

2. Write functions instead of scripts. Functions are valuable so that others can easily call your code to solve a problem, without cluttering up their matlab workspace with some randomly named variables. When you use one letter names for variables in a script, you are very probably going to screw up their work if they try to run your code.

3. The website description gives no indication as to what this code actually does. How should anybody know whether to download this code?

4. Provide a tool that helps the user to use it. So provide error checks that return meaningful errors when they use it improperly.

5. When you do write functions, provide an H1 line. This makes the lookfor command work properly on your code. An H1 line is a single descriptive comment line that immediately follows your function declaration statement.

6. Use the mlint tool on your codes before you upload them. Mlint catches many problems with codes, even explaining things that you can do to make your code more efficient. Its built directly into the editor, so its easy to use. Just look for the flags in your editor.

[x y]

Not everyone is a professional programmer like the over zealous reviewer.

[urs (us) schwarz]

dear anonymous
now that we've seen you venting your anger on john d'errico - which, by itself certainly would not warrant an excellent rating for this submission - the FEX community is eagerly awaiting your real assessment of this contribution, which let you to do so.
also, please note, it helps to sign with a real identity - it makes everything immediately much more credible...
just a thought
us

[x y]

The stated requirements for submissions are:
* Contact information must be complete and accurate. This information is displayed on the web site and is used by customers and The MathWorks to communicate with you.
* The Submission must not directly compete with products offered by The MathWorks or its partners.
* The Submission must not violate or infringe on any patent, copyright, or other intellectual property right of any other person.
* The Submission must be offered free of charge.
* The Submission must not be offensive.
* The Submission must not be malicious or destructive in nature.
* The title, abstract, description, requirements, and other information must be accurately completed.
Submission that meet these requirements should NOT receive a 1 star, Poor rating. 1 star ratings based on any other criteria such as those cited by the professional nit-pickers should be deleted because they are irrelevant when compared to the clearly stated requirements.

[urs (us) schwarz]

dear anonymous
thanks for clearly pointing out the basic requirements for SUBMISSIONS - however, in these statements i cannot anywhere see the requirements or guidelines for REVIEWG such products... these are clearly displayed in another pop-up.
going back to john d'errico's in-depth review (signed with his full name and a valid email address), i do not see any point where he would have violated any of those rules - his conclusions and ratings, of course (and i do hope you fully agree), are entirely his...
us

[John D'Errico]

Dear xy,

You posted the qualifications for posting a file on the file exchange. The fact remains that these are only requirements that if a file fails to meet, justifies its removal from the exchange. Merely meeting those broad requirements does not in itself make a file any good though. There is still a wide difference between the tools on this exchange. The review system allows us to show that difference.

Suppose I were to accept your justification of a higher rating than poor. Perhaps you might choose to explain what aspects of this code are indeed good? Please explain how you would justify any given rating? You chose to assign a rating of 5 to this. What rating would you assign to something that is truly spectacular, clearly written and professionally coded?

I'm sorry, but I read the entire contents of this submission, as I do every tool that I download. I made clear suggestions for how to improve it, and explained what was less than adequate. This submission is poor, although I did briefly consider a rating of 2 instead. I might have done so had the submission been a little better.

In the same session when I rated this file, I also rated two other submissions. One I gave a 3 rating to, the other a 5 rating. If my review of those other codes is to mean anything, then I must be as consistent as I can. There are many individuals on the FEX that have come to learn that my reviews are extensive and carefully thought out. I'm sorry that my opinion differs from yours, but it is an opinion freely offered and only an opinion.

Finally, my opinion is one that I stand behind with my name. This is something that xy apparently lacks the moral fiber to do. I'm sorry xy, but you have not offered anything constructive to this process. Had you tried offering truly constructive feedback to the author of this submission, that might be different. It also might have made your rants more credible.

[x y]

"Please explain how you would justify any given rating?" Rating can only be made relative to stated requirements. Anything else is subjective to reviewer and should be discounted as such.
"You chose to assign a rating of 5 to this. What rating would you assign to something that is truly spectacular, clearly written and professionally coded?"
"truly spectacular" is not defined in submission requirements, so it is subjective. "professionally coded" is not defined in submission requirements, so it is subjective. Without definition or appearance in submission guidelines, these areas have no meaning or weight.

Put basis for your reviews put in writing so people can read them before they submit and this does not have to happen. How can you hold people accountable for requirements or practices that are not made public? How can people submit "truly spectacular" code when they are not told about such things in written guidelines? Given written guidelines, this submission is as good as any other that also follows the written guidelines.

[Jos x@y.z]

xy, are you aware of the "Guidelines for Reviewing a Submission"? I quote: "Provide specific information on what you like and dislike about the submission."

I also propose to take this discussion to CSSM ...

[x y]

The submission criteria should reflect the topics reviewers sight in their reviews. Without that knowledge up front the submission and review procedure entices this kind of nit picking by the "professional" reviewers.

[Urs (us) Schwarz]

review discussion copied to CSSM as suggested by jos van der geest
us

[Urs (us) Schwarz]

the below mentioned thread on CSSM is here

http://newsreader.mathworks.com/WebX?[e-mail]4bI179ye@.ef55aea

us

[Roger Stafford]

  Having downloaded and read the file exchange submission, "Random deletion of matrix vectors", I wish to state that I fully concur with John D'Errico's evaluation of it. What John did not point out is that the script in 'hablossranddel.m', the only original part of the submission, involves a process so simple and so obvious that it does not, in my opinion, warrant being placed in the file exchange. It involves techniques matlab users learn in their very earliest studies of the matlab language. There is no need to overload the file exchange entry list with trivial material of this kind. It definitely deserves a "poor" rating in my estimation.

Roger Stafford

[Abhay Krishna]

I am the author of this file,I agree that the file is not upto the standards of matlab experienced users,but central exchange is not only for experts,ItÅ? also a learning platform,I have just started learning matlab.And mark my word ,i will contribute one day a contribution that all experienced users can happily give the highest rating.Harsh comments can be a good motivator.

[John D'Errico]

The author is trying to improve this code. Making some honest effort to improve is enough to push my rating up a notch. (It still needs a lot of improvement, but any journey is taken one step at a time.) I like that there are now more comments that describe what this does.

What can you do better? First, start thinking in terms of functions. Note that every tool that the MathWorks supplies are all functions. This is for a good reason. A function takes a set of inputs, processes them and returns only those variables that you need in the end.

Write help for your functions that clearly describes the inputs and outputs. What does it do? Think about the potential users of this code. Make it as easy as possible for them to use. Pretend that you have never seen your own functions. Would you be able to figure out how to use them?

Look at some sample functions from Matlab, or some from the file exchange that have gotten many good reviews. Look especially carefully at files that are denoted "Select". Consider how you might emulate them in your own help and your code.

[Joseph Hollmann]

Sigh, gone are the days of getting the a high mark for just showing up.

I was tempted to give this submission a '5' rating just to throw a little fuel on the fire.. Anyways, John's comments are pretty much spot on. I'd suggest also employing a subfunction for delmat...just to make things nice and tidy.

Sorry you got caught up in all this.
(signing with my full name)