Hi, The proposal is good. It sets out the areas you wish to work on and an initial timeframe. This will probably change due to the nature of discovery as your work proceeds but everyone understands this and the starting plan is sound.
Here are some areas for revision: Qualify this statement: 'Running benchmarks on Java’s ‘SecureRandom’(introductory task) This is not described anywhere else and needs some explanation. What are you going to benchmark and for what purpose? Perhaps summarise by stating that the relative speed performance can be tested of the standard implementations provided by Sun: https://docs.oracle.com/en/java/javase/11/docs/specs/security/standard-names.html#securerandom-number-generation-algorithms <https://docs.oracle.com/en/java/javase/11/docs/specs/security/standard-names.html#securerandom-number-generation-algorithms> Note that some of these are blocking and sources of entropy are system dependent. You should concentrate on non-blocking implementations for benchmarking. It would be good to know how much slower it would be to plug in a secure RNG in place of a non-secure one. In your schedule you state: Coding of implemented PCGs begins along with bug fixing I would remove the ‘bug fixing’. I do not imagine you will have time to introduce bugs within a week then fix them again. Leave it out as it is already covered by the comparison of your Java port to the reference implementation. If you match the implementation then the task is done. If not then carry on trying to implement it. Typos: (Not a problem but I always collate these when proof reading) thes PRNGs Missing spaces: implementations,porting known.Determinism ‘SecureRandom’(introductory task) Extra spaces: “implementation details” , Tortoise SVN performed . DTPS , Dahanu Java , Matlab , July 27th . College You need some consistency with how you introduce lists. You use different punctuation throughout, for example: - end of text : - end of text :- - end of text: - end of text - You switch from Italic to Standard font before a punctuation or sometimes after, for example: - end of text: more - end of text: more You sometimes put your [x] reference insert before or after punctuation, for example: - something good[1]. - something better.[2] You sometimes end bullet points with a full stop and sometimes not. I would either add them all the time or only add them when the bullet point has multiple sentences. Some of your bullet point lists do not have space before or after to the adjacent paragraphs. Hope this helps. Alex > On 28 Mar 2019, at 04:00, Abhishek Dhadwal <dhadwal1...@gmail.com> wrote: > > Hi Sir, > I’ve made the changes that were required, which consisted of updating the > timeline and adding to the deliverables section. Kindly check the document > and let me know of any changes to be made. > Regards, > Abhishek > > Sent from Mail for Windows 10 > > From: Gilles Sadowski > Sent: 27 March 2019 19:40 > To: Commons Developers List > Subject: Re: GSoC 19: Information pertaining to 'Lagged Fibonacci Generators' > > Hi. > > Le mer. 27 mars 2019 à 13:43, Abhishek Dhadwal <dhadwal1...@gmail.com> a > écrit : >> >> >> >> Hello Sir, >> >>> I don't know what are the hard requirements for the schedule, but >>> I would not make such delineation between coding, reviewing and >>> testing. >> The Elements Of A Quality Proposal in Google’s Guide >> (https://google.github.io/gsocguides/student/writing-a-proposal) state the >> following about deliverables and timelines: >> Deliverables >> Include a brief, clear work breakdown structure with milestones and >> deadlines. Make sure to label deliverables as optional or required. You may >> want your plan to start by producing some kind of white paper, or planning >> the project in traditional Software Engineering style. It’s OK to include >> thinking time (“investigation”) in your work schedule. Deliverables should >> include investigation, coding and documentation. > > So, indeed, what I described (quoted below) is referred to here as > "investigation". > Then "coding" could be assumed to include "testing" and "review", > and even "documentation" (as it is a prerequisite to commit that all > codes come with complete Javadoc). > >> I attempted to follow it in my implementation of the milestone timeline. >> What be your advice on improving/altering the timeline provided in the >> documentation ? > > I don't know whether we follow the "traditional Software Engineering style"... > > According to what happens in practice, top-level would be > * investigation (with sub-tasks such as collecting reference implementations) > * coding (with subtasks such as producing numbers from reference > implementations, porting those implementations to Java, write unit tests > and Javadoc) > These two "steps" can be repeated for each RNG which you are going > to contribute. > But as I said there is no strict order: if you are stuck with one (e.g. > missing a reference implementation, or cannot compile it for some > reason), you could start working on another that may prove more > straightforward. > > HTH, > Gilles > >>> You could perhaps also mention that you'll need to compile the >>> "reference" implementations (in C probably), and most importantly >>> devote some time to looking for those (a.o. also compare several >>> implementations of the same algorithm (and with the algorithm >>> description), if there is no "authoritative" origin for the code (i.e. >>> when the person who wrote the code is not the person who >>> designed the algorithm). >>> Depending on when you actually find all the needed resources >>> for a given task, the schedule will be quite different... >> >> I’ll add those tasks and work on the schedule as required. >> >> Thanking You, >> Yours Faithfully, >> Abhishek > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >