David Verrelli - MATLAB Cody - MATLAB Central

David Verrelli

129
Rank
17
Badges
9765
Score
1 – 50 of 2,604

David Verrelli received Quiz Master badge for Solution 12964302

on 26 Dec 2023

David Verrelli submitted a Comment to Solution 3168106

Rafael S.T. Vieira's solution passed all tests in the Test Suite on 11 October 2020. Wall time for 1906 message batches = 3.43 s. (CPU time = 3.68 seconds.)

on 28 Jan 2022

David Verrelli submitted a Comment to Solution 3451468

I'm glad you enjoyed the problem. You're welcome :-) I enjoyed looking at your solution too: it had two things I appreciate, namely a creative solution, and ample explanatory comments in the code :-)

on 28 Jan 2022

David Verrelli submitted a Comment to Solution 2756218

Cheat 'solution' by Raghunadh N.

on 29 Jul 2021

David Verrelli submitted a Comment to Problem 375. N-Dimensional Array Slice

Massimo Zanetti & Kevin Hellemans: in Test 3 the value 10 is entered as the dimension argument (not the index argument, which has a value of 1). Thus in Test 3 the general solution would be A(:, :, :, :, :, :, :, :, :, 1). —DIV

on 29 Jul 2021

David Verrelli submitted a Comment to Problem 44383. Code breaker, Part III: Operation Xiangliu

Hello, Rafael S. T. Vieira. Firstly, thank-you for your constructive feedback. When I wrote the Test Suite — a few years ago — I explored a few options for the timing, including use of the timeit() function. I believe that there was a specific rationale for the choice I ultimately made, although I can't confidently recall all the details off the top of my head. As for the implementation of the timing, I concede that currently it includes some overhead from generating some random strings. However, I doubt that the overhead is 'significant' — I would be *guessing* that it would account for less than 1% of the total time elapsed. So while your proposed amendment could be a nice improvement, it's probably best left as a tip for future Problems: I prefer not to change an existing Test Suite unless there is a compelling reason. Next, let me share with you the basis for the 8-second benchmark. I wrote an unoptimised reference solution and added a small safety margin. My hypothesis was that if my unoptimised code could satisfy the Test, then most likely other (experienced) Cody players could also pass the Test if they avoid slow operations. When the Problem was published, indeed the Cody players who have solved it were able to pass the test using a variety of approaches. Indeed, some advanced Cody players were able to highly optimise their code and deliver impressively quick times. You may notice that I built in an allowance for increasing computational power. This allowance also had a safety margin. In other words, the increased number of iterations is somewhat less than the projected increase (from historical data) that would maintain equity. Of course, even predictions based on data can be wrong, so I have checked my reference solution again (twice). I got the following: "Your wall time to decode 2370 message batches = 7.99 seconds." "Your wall time to decode 2370 message batches = 7.62 seconds." In both cases it passed. The first instance was amusingly close to the limit, but I mention again that this code was not optimised yet it still passed. I can assure you that it has no "hashes". Finally, the subtext is that this is intended to be a difficult Problem: a challenge for experienced Cody players. Some will like that, and will even enjoy challenging themselves to optimise their own code. Others won't be interested, and there are thousands of other Problems on Cody for them to solve. —DIV

on 25 Jul 2021

David Verrelli submitted a Comment to Problem 44631. Make your own Test Suite (part 0)

Rafael, I had not been not aware that the assert() function has been disallowed on Cody. Thank-you for alerting us to that. Previously it was working, and actually it is the function that ideally 'should' be used, so I am not going to alter the problem statement. However I agree that with the current Cody prohibition on players using assert() in their solutions, the error() function will have to be used instead. However, I can confirm that it is *not* necessary to use any dummy variables at all. P.S. I believe assert() was disallowed because of a small number of Cody players who brazenly cheated their way through numerous problems. Ideally there should be a switch in Cody to allow the assert() function to be used for specific individual problems, in which case there are some special measures that can be implemented to prevent such exploits. For example, running the command "! rm -v assert.m" (without quotation marks) in the Test Suite.

on 19 Jul 2021

David Verrelli submitted a Comment to Problem 44691. Comparison of floating-point numbers (singles)

Hello, Rafael. Thank-you for the tip about using try & catch. I have modified the Test Suite accordingly, so it should be possible now for Cody players to call their function either "compareSingles" or "compareDoubles". When formatted neatly this workaround code distracted from the core content of the Test Suite, so I have crammed it onto one individual line in each separate Test. Regarding the problem statement, I think this is like real life, and Cody players can figure it out. Some Cody players will find the conversion obvious, so it won't be a hassle for them; other Cody players might find the conversion less obvious, so it's a small extra challenge and learning opportunity for them. (See also Problem 44690.)

on 19 Jul 2021

David Verrelli submitted a Comment to Solution 3651718

Hello, Rafael. There is definitely some issue. From my perspective in writing the Test Suite a solution should either pass all of the Tests every time, or else fail at least one test every time. I have therefore increased the number of testing iterations in selected Tests, and your solution consistently fails the revamped Tests 4, 5, and 6; it may also fail some other Tests that haven't been amended (e.g. Solution 3651713 failed test 7a). I have also added quite a bit of detail in the rejigged failure messages so that you can identify problematic parameter values. —DIV

on 19 Jul 2021

David Verrelli submitted a Comment to Problem 44692. Is input the global variable z?

"global variable z" was explicitly mentioned in both the problem title and the problem description. Other than that, I trust that your comment and the Test Suite should be sufficient to remove any residual doubts. —DIV

on 18 Jul 2021

David Verrelli submitted a Comment to Problem 44690. Comparison of floating-point numbers (doubles)

Hello, Rafael. Thank-you for the feedback. Each approach has pros and cons. Using the same base for all numbers in the problem statement would make comparison easy at a glance, but the values would not all be exact. The mixture of bases used in the problem statement means that exact values are used for all numbers; although the reader has some inconvenience to perform a conversion in order to compare magnitudes, there may be some more educational value in that, IMHO. —DIV

on 18 Jul 2021

David Verrelli submitted a Comment to Solution 1945956

Richard, please check the problem description. The task is to identify sets of uniformly distributed random numbers. The so-called "normal distribution" (another name for which is the "Gaussian distribution") is not uniformly distributed. This link may help illustrate the difference between those two types of distribution: https://math.stackexchange.com/questions/657254/normally-distributed-random-numbers-vs-uniformly-distributed-random-number —DIV

on 18 Jul 2021

David Verrelli submitted a Comment to Solution 1812151

I agree.

on 24 Dec 2020

David Verrelli received Famous badge

on 6 Sep 2020

David Verrelli submitted a Comment to Solution 1721380

Neat solution using some additional mathematical knowledge.

on 30 Nov 2019

David Verrelli submitted a Comment to Problem 44819. Relative pose in 2D: problem 1

The %% is an issue because it is so poorly documented and hence poorly understood (or even not understood). The following seems to be how it works. [Note: in the following I will use "↲" to indicate the end of a line in the code/output.]       ~~~~~~~~~~ Creator writes this TEST SUITE: ~~~~~~~~~~ ----- commandA↲ commandB↲ ↲ %% test 1↲ commandX↲ ↲ %% test 2↲ commandY↲ -----       ~~~~~~~~~~ Cody RUNS the following tests: ~~~~~~~~~~ Test 1: (i) commandA; (ii) commandB; and (iii) commandX. Test 2: (i) commandA; (ii) commandB; and (iii) commandY.       ~~~~~~~~~~ Cody DISPLAYS the following output: ~~~~~~~~~~ ----- %%commandA↲ commandB↲ ↲ %% test 1↲ commandX↲ ↲ [output from commandX only]↲ ↲ %% test 2↲ commandY↲ ↲ [output from commandY only]↲ ↲ ----- ~~~~~~~~~~       Notice: (i) any commands before the first %% [namely commandA and command] are run at the beginning of every test; (ii) output of any commands before the first %% is suppressed [never displayed]; (iii) for the player, a spurious "%%" is displayed on the first line of the Test Suite if there were any commands before the first "%%".       It is actually a very clever structure for Problem Creators writing a Test Suite. Therefore I'd be keen to retain it. See e.g. https://www.mathworks.com/matlabcentral/cody/problems/44655       The annoyances are: (i) lack of documentation; (ii) suppression of output; and (iii) insertion of a spurious "%%" in the display. Although none of these three issues affect the running, they cause a lot of confusion and misunderstanding.

on 23 Nov 2019

David Verrelli submitted a Comment to Solution 1349348

Nice one :-)

on 3 Jul 2019

David Verrelli submitted a Comment to Solution 1633120

William's solution passed all tests in the Test Suite on 25 September 2018. Wall time for 1080 message batches = 7.30 s. (CPU time = 9.21 seconds.)

on 3 Jul 2019

David Verrelli submitted a Comment to Solution 556220

I agree that it is possible to choose N in such a way as to be practically guaranteed to pass the Test Suite. My point is that in this submission (and BTW also in Solution 188645) N has been chosen smaller than that, and so some luck was needed for this submission to pass — there was a significant risk that it could have failed.

on 27 Jun 2019

David Verrelli submitted a Comment to Problem 43546. Slope of the line passing through two points

Thanks to goc3 for improving the Test Suite and fixing the other issues. Those people interested in developing their own test suites might like to try the series of problems starting with https://www.mathworks.com/matlabcentral/cody/problems/44631

on 27 Jun 2019

David Verrelli submitted a Comment to Solution 1297083

Fair point.

on 27 Jun 2019

David Verrelli submitted a Comment to Solution 1671361

If you describe a problem as simple, William, you'll invite close inspection.... Maybe you'll find a benefit in commenting the code in your next submission.

on 24 Jun 2019

David Verrelli submitted a Comment to Solution 1706081

HH, you get no credit for hacking the problem. Only legitimate solutions gain credit.

on 24 Jun 2019

David Verrelli submitted a Comment to Solution 1669300

Oleksandr Denysenko, you get no credit for hacking the problem. Only legitimate solutions gain credit.

on 24 Jun 2019

David Verrelli submitted a Comment to Solution 1584952

Good job on commenting your code!

on 24 Jun 2019

David Verrelli submitted a Comment to Solution 1576522

An elegant solution.

on 24 Jun 2019

David Verrelli submitted a Comment to Solution 1793400

An elegantly simple solution.

on 24 Jun 2019

David Verrelli submitted a Comment to Solution 1562733

David Verrelli's solution passed all tests in the Test Suite on 18 June 2018. Wall time for 1001 message batches = 7.05 s. (CPU time = 9.01 seconds.)

on 24 Jun 2019

David Verrelli submitted a Comment to Solution 1633126

William's solution passed all tests in the Test Suite on 25 September 2018. Wall time for 1080 message batches = 7.17 s. (CPU time = 9.01 seconds.)

on 24 Jun 2019

David Verrelli submitted a Comment to Solution 1562637

Binbin Qi's solution passed all tests in the Test Suite on 17 June 2018. Wall time for 1001 message batches = 3.81 s. (CPU time = 4.73 seconds.)

on 24 Jun 2019

David Verrelli submitted a Comment to Solution 1582734

Jean-Marie Sainthillier's solution passed all tests in the Test Suite on 13 July 2018. Wall time for 1021 message batches = 6.77 s. (CPU time = 7.09 seconds.)

on 24 Jun 2019

David Verrelli submitted a Comment to Solution 1555446

J. S. Kowontan's solution passed all tests in the Test Suite on 17 June 2018. Wall time for 1001 message batches = 3.36 s. (CPU time = 4.06 seconds.)

on 24 Jun 2019

1 – 50 of 2,604
Go to top of page