From ac0354cb425d12c21ee66c91388658b529f51602 Mon Sep 17 00:00:00 2001 From: Youwen Wu Date: Wed, 20 Nov 2024 14:51:30 -0800 Subject: [PATCH] udpate --- .../by-course/phil-1/paper-2/main.typ | 164 ++++-- .../by-name/vision-whitepaper/appendix.typ | 5 + .../by-name/vision-whitepaper/checklist.typ | 524 ++++++++++++++++++ .../by-name/vision-whitepaper/logo.typ | 18 + .../by-name/vision-whitepaper/main.bib | 25 + .../by-name/vision-whitepaper/main.typ | 99 ++++ .../by-name/vision-whitepaper/package.nix | 35 ++ 7 files changed, 815 insertions(+), 55 deletions(-) create mode 100644 2024/documents/by-name/vision-whitepaper/appendix.typ create mode 100644 2024/documents/by-name/vision-whitepaper/checklist.typ create mode 100644 2024/documents/by-name/vision-whitepaper/logo.typ create mode 100644 2024/documents/by-name/vision-whitepaper/main.bib create mode 100644 2024/documents/by-name/vision-whitepaper/main.typ create mode 100644 2024/documents/by-name/vision-whitepaper/package.nix diff --git a/2024/documents/by-course/phil-1/paper-2/main.typ b/2024/documents/by-course/phil-1/paper-2/main.typ index 41baabe..0d5fb86 100644 --- a/2024/documents/by-course/phil-1/paper-2/main.typ +++ b/2024/documents/by-course/phil-1/paper-2/main.typ @@ -32,10 +32,6 @@ ], [ Word Count: #total-words - #footnote[ - Figure computed programmatically during document compilation. Discounts - content in tables and the AI contribution statement. - ] ], ), ), @@ -43,12 +39,12 @@ = Introduction -The argument Against Fearing Death says that you should not fear being dead +In _Against Fearing Death_, the author argues you should not fear being dead because it is not bad for you. In this paper, I reject this thesis by showing -that the argument from hedonism with which the author supports their premises -forces us to draw incorrect conclusions. +that the argument from hedonism the author relies on forces us to draw the +absurd conclusion that being alive is worse than being dead. -The author states the argument against fearing death as follows on +The author states the argument Against Fearing Death as follows on #cite(, supplement: [p. 74]): #indented-argument( @@ -70,31 +66,35 @@ under anesthesia during a risky surgery, you should not fear that either, as you will painlessly transition from being alive to being dead, and there is nothing to fear about being dead. -The author justifies FD1 by denying the only possibility of rejecting it, which -is the notion that your consciousness continues after the death of your -physical body, perhaps in an afterlife. He rejects this idea by arguing that -you, the consciousness reading this, and your physical human body, are one and -the same (i.e. they are _numerically equivalent_). So, if your physical human -body biologically ceases to be conscious after death (which it does), then you -also cease to be conscious when you die. +The author justifies FD1 on #cite(, supplement: [pp. 79-82]) +by denying the only possibility of rejecting it, which is the notion that your +consciousness continues after the death of your physical body (perhaps in an +afterlife). He rejects this idea by arguing that you, the consciousness reading +this, and your physical human body, are one and the same (i.e. they are +_numerically equivalent_). So, if your physical human body ceases to be +conscious after death (which it does), then you (the conscious being reading +this) also cease to be conscious when you die. -Premise FD3 is the direct result of FD1 and FD2, so its validity is dependent -entirely on FD1 and FD2. We've already shown why FD1 should be accepted. Let us -first examine FD4 before returning to FD2. +Premise FD3 is the direct conclusion of FD1 and FD2, so it depends on the +validity of those premises. We've already shown why FD1 should be accepted. Let +us first examine FD4 before taking a closer look at FD2. -FD4 makes a lot of intuitive sense. Indeed, upon close inspection, there are no -glaring issues. It is rational to fear something if and only if it is bad for -you. Sure, you may fear things that are not bad for you, but these fears are -_irrational_, you should try to resist them. The only things that it is -rational to fear are things that are actually bad for you, such as burning your -hand on a hot stove, or stubbing your toe. +FD4 makes a lot of intuitive sense, and upon closer inspection, there are +indeed no issues which arise. It is irrational to fear something if it is not +bad for you (this does not imply everything bad for you should necessarily be +feared). Sure, you _could_ fear things that are not bad for you, but as the +author states on #cite(, supplement: [pp. 82-83]), these +fears are _irrational_, and you should try to resist them. The only things you +should fear are things that are actually bad for you, such as burning your hand +on a hot stove, or stubbing your toe. -Finally, we return to premise FD2. This is perhaps the most questionable -premise as it is not immediately clear why being unconscious implies that being -dead is not bad. +Finally, we return to premise FD2. This is arguably the most dubious premise as +it is not immediately clear why being unconscious implies that being dead is +not bad. We first need a rigorous account of what exactly characterizes something as -"bad." The author defines the following hedonist principle: +"bad." The author defines the following _hedonist principle_ on +#cite(, supplement: [p. 76]): #pad( left: 16pt, @@ -118,10 +118,9 @@ FD2. $<==>$ (FD2) So, if you cease to be conscious when you die, then being dead isn't bad for you ], ) - I've slightly modified the author's numberings to emphasize that the conclusion AH3 is equivalent to the premise FD2. That is, if the #smallcaps[Argument from -Hedonism] holds, then FD2 must be true. +Hedonism] holds, then FD2 must also be true. We've shown that the author's argument for why you should not fear death is substantiated by what appear to be valid premises. I object in section 2 by @@ -132,15 +131,17 @@ responses to my objection. = Don't kill yourself -I will advance the argument that we should reject HD\* because its logical -conclusion is that you should kill yourself. HD\* implies that being dead is -not bad for you, but it also implies that _being alive_ is bad for you. +I advance the argument that we should reject HD\* because its logical +conclusion is not only that being dead is not bad for you, but _being alive_ is +actually bad for you. Accordingly, this implies that you should kill yourself +to stop being alive because it is bad for you. Of course, this is wrong and we +should not accept HD\*. Consider the following argument: #indented-argument( title: "Argument for Killing Yourself", abbreviation: "KYS", [You are occasionally conscious when you are alive], - [If you are conscious, you experience more pain than you otherwise would have if you were unconscious], + [If you are occasionally conscious, you will experience more pain than you otherwise would have if you were unconscious], [$<==>$ (HD\*) Something is bad for you if and only if it results in more pain than you otherwise would have had], [So, being alive is bad for you], [If you are unconscious when you are dead, then being dead isn't bad for you], @@ -148,37 +149,90 @@ not bad for you, but it also implies that _being alive_ is bad for you. [So, you should stop being alive], ) -In other words, KYS7 plainly states that you should kill yourself to stop being -alive. This is clearly a ridiculous conclusion and one we should not accept. In -order to reject this conclusion, we must reject KYS3, which is HD\*. All of the -other premises can be substantiated easily, as follows. +In other words, KYS7 states that you should find a way to kill yourself in +order to stop being alive. This is an absurd conclusion we should not accept, +and it indicates a serious error with one of our premise. Let us identify +exactly which one went wrong. -KYS1 is trivial. KYS2 is true because you experience no pain when unconscious, -and we certainly experience pain at some point while conscious. So, we must -experience more pain while conscious than we otherwise would have (while -unconscious). +KYS1 is trivial (unless you are unconscious for the rest of your life, which +for our purposes is essentially the same as death). + +KYS2 is true because you experience no pain when unconscious, and we certainly +experience pain at some point while conscious. So, we must experience more pain +while conscious than we otherwise would have (while unconscious). + +KYS5 is equivalent to our conclusion AH3 in the #smallcaps[Argument from +Hedonism]. KYS6 essentially just says that if being alive is bad and being dead is good, then you should take action to stop being alive and start being dead. After -all, why continue doing something that is bad for you when the alternative not -bad for you? +all, why continue doing something that is bad for you when the alternative is +not bad for you? -Clearly, our own avenue forward is to reject HD\* as our principle of hedonism. -Without HD\*, the #smallcaps[Argument from Hedonism] no longer stands, and -therefore the argument for FD2 fails. +Clearly, our only option is to reject KYS3 (which is just HD\*) as our +principle of hedonism. Without HD\*, the #smallcaps[Argument from Hedonism] no +longer stands, and therefore the argument for FD2 fails. + +Note that we do not make a claim as to whether or not death is bad for you. We +simply show the absurdity of an argument that relies on HD\*, which means the +#smallcaps[Argument from Hedonism] fails to justify the premise FD2. Without a +clear justification for why we should accept the dubious claim in FD2, we can +no longer claim that death is definitely not bad and should not be feared. + +// #let hdp = [HD$'$] +// +// Let us formulate a new hedonist principle, denoted #hdp. +// +// #pad( +// left: 16pt, +// [ +// (#hdp) Something is bad for you if and only if it prevents or hinders the achievement of your goals +// ], +// ) +// +// We need to clarify what is meant by "goals". In this case, goals refers broadly +// to all of the things someone needs to feel fulfilled. Someone may have a few +// _fundamental goals_, such as to be fulfilled or to feel happy. +// +// Anything that works against these goals is bad. If someone seeks to be happy, +// then feeling pain is bad for them because they no longer . +// +// The author's hypothetical case of #smallcaps[Unread Mail] shows that this +// HD\*\* wrongfully characterizes some situations as bad, so we should prefer +// HD\*. +// +// However, in my formulation #hdp, we do correctly identify that the situation in +// #smallcaps[Unread Mail] is not bad. #hdp is essentially equivalent to HD\* is +// most cases, but it successfully identifies that being alive is not bad for you. +// Since being = Possible objections One might attempt to object to KYS without rejecting HD\*. The only other -premises to object against are KYS1 and KYS2. In particular, one might raise -the concern that someone could be alive without ever being conscious (as an -objection to KYS1), and that someone may not experience any pain while -conscious (an objection to KYS2). +premises to reasonably object against are KYS1 and KYS2. In particular, one +might raise the following concerns -These criticisms are not substantial enough for us to reject KYS. KYS1 brings -up a valid point, but being unconscious for the rest of your life is not really -substantially different from being dead. Regardless, we could modify our -argument to ++ An objection to KYS1: someone could be alive without ever being conscious. ++ An objection to KYS2: someone may not ever experience any pain while conscious. + +These criticisms are not really substantial enough for us to reject KYS. KYS1 +brings up a valid point, but being unconscious for the rest of your life is not +really a better situation than being dead. Regardless, HD\* still implies that +being conscious is bad while being in a _death-like state_ of permanent +unconsciousness is not. The conclusion then becomes that you should either kill +yourself or place yourself into a death-like state (perhaps a coma), which is +just as absurd as before. + +One may argue from a hypothetical situation in which a human is somehow +modified to be incapable of feeling pain (of any sort). In this situation, HD\* +does not fail, as it does not imply being alive and conscious is worse than +being dead, since being conscious and being dead both result in absolutely no +pain. + +This case fails to present any challenge to our argument. Even though HD\* does +not fail in the hypothetical, it clearly still fails _now_, as it still implies +that being alive is bad for you, the person reading, who almost certainly does +feel pain. #pagebreak() diff --git a/2024/documents/by-name/vision-whitepaper/appendix.typ b/2024/documents/by-name/vision-whitepaper/appendix.typ new file mode 100644 index 0000000..731cf49 --- /dev/null +++ b/2024/documents/by-name/vision-whitepaper/appendix.typ @@ -0,0 +1,5 @@ += Appendix / supplemental material + +Optionally include supplemental material (complete proofs, additional +experiments and plots) in appendix. All such materials *SHOULD be included in +the main submission*. diff --git a/2024/documents/by-name/vision-whitepaper/checklist.typ b/2024/documents/by-name/vision-whitepaper/checklist.typ new file mode 100644 index 0000000..cbf9f1f --- /dev/null +++ b/2024/documents/by-name/vision-whitepaper/checklist.typ @@ -0,0 +1,524 @@ +#import "@preview/bloated-neurips:0.5.1": url + +#let TODO = text(fill: red, [*[TODO]*]) +#let answerNA = text(fill: gray, "[NA]") +#let answerNo = text(fill: red, "[NO]") +#let answerYes = text(fill: blue, "[YES]") + +#pagebreak(weak: true) + +#set heading(numbering: none) + += NeurIPS Paper Checklist + +#let claim( + name: [], + question: [], + answer: [], + justification: [], + guidelines: [], +) = { + set list(indent: 1em, tight: false) + show list: set block(spacing: 10pt) + set par(spacing: 5.8pt) + [ + *#name* + + Question: #question + + Answer: #answer + + Justification: #justification + + Guidelines: + + #guidelines + ] +} + ++ #claim( + name: [Claims], + question: [ + Do the main claims made in the abstract and introduction accurately reflect + the paper's contributions and scope?], + answer: TODO, // Replace by answerYes, answerNo, or answerNA. + justification: TODO, + guidelines: [ + - The answer NA means that the abstract and introduction do not include the + claims made in the paper. + + - The abstract and/or introduction should clearly state the claims made, + including the contributions made in the paper and important assumptions and + limitations. A No or NA answer to this question will not be perceived well + by the reviewers. + + - The claims made should match theoretical and experimental results, and + reflect how much the results can be expected to generalize to other settings. + + - It is fine to include aspirational goals as motivation as long as it is + clear that these goals are not attained by the paper. + ]) + ++ #claim( + name: [Limitations], + question: [ + Does the paper discuss the limitations of the work performed by the + authors? + ], + answer: TODO, // Replace by answerYes, answerNo, or answerNA. + justification: TODO, + guidelines: [ + - The answer NA means that the paper has no limitation while the answer No + means that the paper has limitations, but those are not discussed in the + paper. + + - The authors are encouraged to create a separate "Limitations" section in + their paper. + + - The paper should point out any strong assumptions and how robust the + results are to violations of these assumptions (e.g., independence + assumptions, noiseless settings, model well-specification, asymptotic + approximations only holding locally). The authors should reflect on how + these assumptions might be violated in practice and what the implications + would be. + + - The authors should reflect on the scope of the claims made, e.g., if the + approach was only tested on a few datasets or with a few runs. In + general, empirical results often depend on implicit assumptions, which + should be articulated. + + - The authors should reflect on the factors that influence the performance + of the approach. For example, a facial recognition algorithm may perform + poorly when image resolution is low or images are taken in low lighting. + Or a speech-to-text system might not be used reliably to provide closed + captions for online lectures because it fails to handle technical jargon. + + - The authors should discuss the computational efficiency of the proposed + algorithms and how they scale with dataset size. + + - If applicable, the authors should discuss possible limitations of their + approach to address problems of privacy and fairness. + + - While the authors might fear that complete honesty about limitations + might be used by reviewers as grounds for rejection, a worse outcome + might be that reviewers discover limitations that aren't acknowledged in + the paper. The authors should use their best judgment and recognize that + individual actions in favor of transparency play an important role in + developing norms that preserve the integrity of the community. Reviewers + will be specifically instructed to not penalize honesty concerning + limitations. + ]) + ++ #claim( + name: [Theory Assumptions and Proofs], + question: [ + For each theoretical result, does the paper provide the full set of + assumptions and a complete (and correct) proof? + ], + answer: TODO, // Replace by answerYes, answerNo, or answerNA. + justification: TODO, + guidelines: [ + - The answer NA means that the paper does not include theoretical results. + + - All the theorems, formulas, and proofs in the paper should be numbered + and cross-referenced. + + - All assumptions should be clearly stated or referenced in the statement + of any theorems. + + - The proofs can either appear in the main paper or the supplemental + material, but if they appear in the supplemental material, the authors + are encouraged to provide a short proof sketch to provide intuition. + + - Inversely, any informal proof provided in the core of the paper should be + complemented by formal proofs provided in appendix or supplemental + material. + + - Theorems and Lemmas that the proof relies upon should be properly + referenced. + ]) + ++ #claim( + name: [Experimental Result Reproducibility], + question: [ + Does the paper fully disclose all the information needed to reproduce the + main experimental results of the paper to the extent that it affects the + main claims and/or conclusions of the paper (regardless of whether the code + and data are provided or not)? + ], + answer: TODO, // Replace by answerYes, answerNo, or answerNA. + justification: TODO, + guidelines: [ + - The answer NA means that the paper does not include experiments. + + - If the paper includes experiments, a No answer to this question will not + be perceived well by the reviewers: Making the paper reproducible is + important, regardless of whether the code and data are provided or not. + + - If the contribution is a dataset and/or model, the authors should + describe the steps taken to make their results reproducible or verifiable. + + - Depending on the contribution, reproducibility can be accomplished in + various ways. For example, if the contribution is a novel architecture, + describing the architecture fully might suffice, or if the contribution + is a specific model and empirical evaluation, it may be necessary to + either make it possible for others to replicate the model with the same + dataset, or provide access to the model. In general. releasing code and + data is often one good way to accomplish this, but reproducibility can + also be provided via detailed instructions for how to replicate the + results, access to a hosted model (e.g., in the case of a large language + model), releasing of a model checkpoint, or other means that are + appropriate to the research performed. + + - While NeurIPS does not require releasing code, the conference does + require all submissions to provide some reasonable avenue for + reproducibility, which may depend on the nature of the contribution. For + example + + #set enum(numbering: "(a)") + + + If the contribution is primarily a new algorithm, the paper should make + it clear how to reproduce that algorithm. + + If the contribution is primarily a new model architecture, the paper + should describe the architecture clearly and fully. + + If the contribution is a new model (e.g., a large language model), then + there should either be a way to access this model for reproducing the + results or a way to reproduce the model (e.g., with an open-source + dataset or instructions for how to construct the dataset). + + We recognize that reproducibility may be tricky in some cases, in which + case authors are welcome to describe the particular way they provide + for reproducibility. In the case of closed-source models, it may be + that access to the model is limited in some way (e.g., to registered + users), but it should be possible for other researchers to have some + path to reproducing or verifying the results. + ]) + ++ #claim( + name: [Open access to data and code], + question: [ + Does the paper provide open access to the data and code, with sufficient + instructions to faithfully reproduce the main experimental results, as + described in supplemental material? + ], + answer: TODO, // Replace by answerYes, answerNo, or answerNA. + justification: TODO, + guidelines: [ + - The answer NA means that paper does not include experiments requiring + code. + + - Please see the NeurIPS code and data submission guidelines + (#url("https://nips.cc/public/guides/CodeSubmissionPolicy")) for more + details. + + - While we encourage the release of code and data, we understand that this + might not be possible, so "No" is an acceptable answer. Papers cannot be + rejected simply for not including code, unless this is central to the + contribution (e.g., for a new open-source benchmark). + + - The instructions should contain the exact command and environment needed + to run to reproduce the results. See the NeurIPS code and data submission + guidelines (#url("https://nips.cc/public/guides/CodeSubmissionPolicy")) + for more details. + + - The authors should provide instructions on data access and preparation, + including how to access the raw data, preprocessed data, intermediate + data, and generated data, etc. + + - The authors should provide scripts to reproduce all experimental results + for the new proposed method and baselines. If only a subset of + experiments are reproducible, they should state which ones are omitted + from the script and why. + + - At submission time, to preserve anonymity, the authors should release + anonymized versions (if applicable). + + - Providing as much information as possible in supplemental material + (appended to the paper) is recommended, but including URLs to data and + code is permitted. + ]) + + ++ #claim( + name: [Experimental Setting/Details], + question: [ + Does the paper specify all the training and test details (e.g., data + splits, hyperparameters, how they were chosen, type of optimizer, etc.) + necessary to understand the results? + ], + answer: TODO, // Replace by answerYes, answerNo, or answerNA. + justification: TODO, + guidelines: [ + - The answer NA means that the paper does not include experiments. + + - The experimental setting should be presented in the core of the paper to + a level of detail that is necessary to appreciate the results and make + sense of them. + + - The full details can be provided either with the code, in appendix, or as + supplemental material. + ]) + ++ #claim( + name: [Experiment Statistical Significance], + question: [ + Does the paper report error bars suitably and correctly defined or other + appropriate information about the statistical significance of the + experiments? + ], + answer: TODO, // Replace by answerYes, answerNo, or answerNA. + justification: TODO, + guidelines: [ + - The answer NA means that the paper does not include experiments. + + - The authors should answer "Yes" if the results are accompanied by error + bars, confidence intervals, or statistical significance tests, at least + for the experiments that support the main claims of the paper. + + - The factors of variability that the error bars are capturing should be + clearly stated (for example, train/test split, initialization, random + drawing of some parameter, or overall run with given experimental + conditions). + + - The method for calculating the error bars should be explained (closed + form formula, call to a library function, bootstrap, etc.) + + - The assumptions made should be given (e.g., Normally distributed errors). + + - It should be clear whether the error bar is the standard deviation or the + standard error of the mean. + + - It is OK to report 1-sigma error bars, but one should state it. The + authors should preferably report a 2-sigma error bar than state that they + have a 96% CI, if the hypothesis of Normality of errors is not verified. + + - For asymmetric distributions, the authors should be careful not to show + in tables or figures symmetric error bars that would yield results that + are out of range (e.g. negative error rates). + + - If error bars are reported in tables or plots, The authors should explain + in the text how they were calculated and reference the corresponding + figures or tables in the text. + ]) + ++ #claim( + name: [Experiments Compute Resources], + question: [ + For each experiment, does the paper provide sufficient information on the + computer resources (type of compute workers, memory, time of execution) + needed to reproduce the experiments? + ], + answer: TODO, // Replace by answerYes, answerNo, or answerNA. + justification: TODO, + guidelines: [ + - The answer NA means that the paper does not include experiments. + + - The paper should indicate the type of compute workers CPU or GPU, + internal cluster, or cloud provider, including relevant memory and storage. + + - The paper should provide the amount of compute required for each of the + individual experimental runs as well as estimate the total compute. + + - The paper should disclose whether the full research project required more + compute than the experiments reported in the paper (e.g., preliminary or + failed experiments that didn't make it into the paper). + ]) + ++ #claim( + name: [Code Of Ethics], + question: [ + Does the research conducted in the paper conform, in every respect, with + the NeurIPS Code of Ethics + #url("https://neurips.cc/public/EthicsGuidelines") + ], + answer: TODO, // Replace by answerYes, answerNo, or answerNA. + justification: TODO, + guidelines: [ + - The answer NA means that the authors have not reviewed the NeurIPS Code + of Ethics. + + - If the authors answer No, they should explain the special circumstances + that require a deviation from the Code of Ethics. + + - The authors should make sure to preserve anonymity (e.g., if there is a + special consideration due to laws or regulations in their jurisdiction). + ]) + ++ #claim( + name: [Broader Impacts], + question: [ + Does the paper discuss both potential positive societal impacts and + negative societal impacts of the work performed? + ], + answer: TODO, // Replace by answerYes, answerNo, or answerNA. + justification: TODO, + guidelines: [ + - The answer NA means that there is no societal impact of the work + performed. + + - If the authors answer NA or No, they should explain why their work has no + societal impact or why the paper does not address societal impact. + + - Examples of negative societal impacts include potential malicious or + unintended uses (e.g., disinformation, generating fake profiles, + surveillance), fairness considerations (e.g., deployment of technologies + that could make decisions that unfairly impact specific groups), privacy + considerations, and security considerations. + + - The conference expects that many papers will be foundational research and + not tied to particular applications, let alone deployments. However, if + there is a direct path to any negative applications, the authors should + point it out. For example, it is legitimate to point out that an + improvement in the quality of generative models could be used to generate + deepfakes for disinformation. On the other hand, it is not needed to + point out that a generic algorithm for optimizing neural networks could + enable people to train models that generate Deepfakes faster. + + - The authors should consider possible harms that could arise when the + technology is being used as intended and functioning correctly, harms + that could arise when the technology is being used as intended but gives + incorrect results, and harms following from (intentional or + unintentional) misuse of the technology. + + - If there are negative societal impacts, the authors could also discuss + possible mitigation strategies (e.g., gated release of models, providing + defenses in addition to attacks, mechanisms for monitoring misuse, + mechanisms to monitor how a system learns from feedback over time, + improving the efficiency and accessibility of ML). + ]) + ++ #claim( + name: [Safeguards], + question: [ + Does the paper describe safeguards that have been put in place for + responsible release of data or models that have a high risk for misuse + (e.g., pretrained language models, image generators, or scraped datasets)? + ], + answer: TODO, // Replace by answerYes, answerNo, or answerNA. + justification: TODO, + guidelines: [ + - The answer NA means that the paper poses no such risks. + + - Released models that have a high risk for misuse or dual-use should be + released with necessary safeguards to allow for controlled use of the + model, for example by requiring that users adhere to usage guidelines or + restrictions to access the model or implementing safety filters. + + - Datasets that have been scraped from the Internet could pose safety + risks. The authors should describe how they avoided releasing unsafe + images. + + - We recognize that providing effective safeguards is challenging, and many + papers do not require this, but we encourage authors to take this into + account and make a best faith effort. + ]) + ++ #claim( + name: [Licenses for existing assets], + question: [ + Are the creators or original owners of assets (e.g., code, data, models), + used in the paper, properly credited and are the license and terms of use + explicitly mentioned and properly respected? + ], + answer: TODO, // Replace by answerYes, answerNo, or answerNA. + justification: TODO, + guidelines: [ + - The answer NA means that the paper does not use existing assets. + + - The authors should cite the original paper that produced the code package + or dataset. + + - The authors should state which version of the asset is used and, if + possible, include a URL. + + - The name of the license (e.g., CC-BY 4.0) should be included for each + asset. + + - For scraped data from a particular source (e.g., website), the copyright + and terms of service of that source should be provided. + + - If assets are released, the license, copyright information, and terms of + use in the package should be provided. For popular datasets, + #url("https://paperswithcode.com/datasets") has curated licenses for some + datasets. Their licensing guide can help determine the license of a + dataset. + + - For existing datasets that are re-packaged, both the original license and + the license of the derived asset (if it has changed) should be provided. + + - If this information is not available online, the authors are encouraged + to reach out to the asset's creators. + ]) + ++ #claim( + name: [New Assets], + question: [ + Are new assets introduced in the paper well documented and is the + documentation provided alongside the assets? + ], + answer: TODO, // Replace by answerYes, answerNo, or answerNA. + justification: TODO, + guidelines: [ + - The answer NA means that the paper does not release new assets. + + - Researchers should communicate the details of the dataset/code/model as + part of their submissions via structured templates. This includes details + about training, license, limitations, etc. + + - The paper should discuss whether and how consent was obtained from people + whose asset is used. + + - At submission time, remember to anonymize your assets (if applicable). + You can either create an anonymized URL or include an anonymized zip file. + ]) + ++ #claim( + name: [Crowdsourcing and Research with Human Subjects], + question: [ + For crowdsourcing experiments and research with human subjects, does the + paper include the full text of instructions given to participants and + screenshots, if applicable, as well as details about compensation (if any)? + ], + answer: TODO, // Replace by answerYes, answerNo, or answerNA. + justification: TODO, + guidelines: [ + - The answer NA means that the paper does not involve crowdsourcing nor + research with human subjects. + + - Including this information in the supplemental material is fine, but if + the main contribution of the paper involves human subjects, then as much + detail as possible should be included in the main paper. + + - According to the NeurIPS Code of Ethics, workers involved in data + collection, curation, or other labor should be paid at least the minimum + wage in the country of the data collector. + ]) + ++ #claim( + name: [ + Institutional Review Board (IRB) Approvals or Equivalent for Research with + Human Subjects + ], + question: [ + Does the paper describe potential risks incurred by study participants, + whether such risks were disclosed to the subjects, and whether + Institutional Review Board (IRB) approvals (or an equivalent + approval/review based on the requirements of your country or institution) + were obtained? + ], + answer: TODO, // Replace by answerYes, answerNo, or answerNA. + justification: TODO, + guidelines: [ + - The answer NA means that the paper does not involve crowdsourcing nor + research with human subjects. + + - Depending on the country in which research is conducted, IRB approval (or + equivalent) may be required for any human subjects research. If you + obtained IRB approval, you should clearly state this in the paper. + + - We recognize that the procedures for this may vary significantly between + institutions and locations, and we expect authors to adhere to the + NeurIPS Code of Ethics and the guidelines for their institution. + + - For initial submissions, do not include any information that would break + anonymity (if applicable), such as the institution conducting the review. + ]) diff --git a/2024/documents/by-name/vision-whitepaper/logo.typ b/2024/documents/by-name/vision-whitepaper/logo.typ new file mode 100644 index 0000000..31c6bfc --- /dev/null +++ b/2024/documents/by-name/vision-whitepaper/logo.typ @@ -0,0 +1,18 @@ +#let kern(length) = h(length, weak: true) +#let TeX = style(styles => { + let e = measure(text("E"), styles) + let T = "T" + let E = text(baseline: e.height / 2, "E") + let X = "X" + box(T + kern(-0.1667em) + E + kern(-0.125em) + X) +}) +#let LaTeX = style(styles => { + let l = measure(text(10pt, "L"), styles) + let a = measure(text(7pt, "A"), styles) + let L = "L" + let A = text(7pt, baseline: a.height - l.height, "A") + box(L + kern(-0.36em) + A + kern(-0.15em) + TeX) +}) +#let LaTeXe = style(styles => { + box(LaTeX + sym.space.sixth + [2#text(baseline: 0.3em, $epsilon$)]) +}) diff --git a/2024/documents/by-name/vision-whitepaper/main.bib b/2024/documents/by-name/vision-whitepaper/main.bib new file mode 100644 index 0000000..b11f853 --- /dev/null +++ b/2024/documents/by-name/vision-whitepaper/main.bib @@ -0,0 +1,25 @@ +@article{alexander1994template, + title={Template-based algorithms for connectionist rule extraction}, + author={Alexander, Jay and Mozer, Michael C}, + journal={Advances in neural information processing systems}, + volume={7}, + year={1994} +} + +@book{bower2012book, + title={The book of GENESIS: exploring realistic neural models with the GEneral NEural SImulation System}, + author={Bower, James M and Beeman, David}, + year={2012}, + publisher={Springer Science \& Business Media} +} + +@article{hasselmo1995dynamics, + title={Dynamics of learning and recall at excitatory recurrent synapses and cholinergic modulation in rat hippocampal region CA3}, + author={Hasselmo, Michael E and Schnell, Eric and Barkai, Edi}, + journal={Journal of Neuroscience}, + volume={15}, + number={7}, + pages={5249--5262}, + year={1995}, + publisher={Soc Neuroscience} +} diff --git a/2024/documents/by-name/vision-whitepaper/main.typ b/2024/documents/by-name/vision-whitepaper/main.typ new file mode 100644 index 0000000..04f667e --- /dev/null +++ b/2024/documents/by-name/vision-whitepaper/main.typ @@ -0,0 +1,99 @@ +#import "@preview/bloated-neurips:0.5.1": ( + botrule, + midrule, + neurips2024, + paragraph, + toprule, + url, +) +#import "./logo.typ": LaTeX, LaTeXe, TeX + +#let affls = ( + ucsb: ( + // department: "AI Center", + institution: "University of California, Santa Barbara", + country: "United States", + ), +) + +#let authors = ( + ( + name: "Youwen Wu", + affl: "ucsb", + email: "youwen@ucsb.edu", + equal: true, + ), +) + +#show: neurips2024.with( + title: [Towards More Accessible Scientific Infrastructure: A Neural Vision Pipeline to Interface with Experiments], + authors: (authors, affls), + keywords: ("Machine Learning", "NeurIPS"), + abstract: [ + Scientific instruments are often designed to be operated by humans. As + such, they are outfitted with analog dials and controls which are difficult + for machines to understand. In order to ameliorate the inaccessibility of + experimental equipment in fundamental disciplines such as quantum physics, + we seek a systematic approach to processing existing _analog systems_ into + _digital data_ without invasively augmenting them with sensors. In this + paper, we explore the state of the art in computer vision and their + applications in analyzing experimental instruments through a purely vision + based approach. We train a convolutional neural network to triangulate + visual fiducials and construct a pipeline to apply perspective warp based + corrections to normalize images of measurements. We end by designing + _Dendrite_, an end-to-end vision pipeline that can obtain detailed + digital readings from a video stream of an analog instrument. + ], + bibliography: bibliography("main.bib"), + bibliography-opts: (title: none, full: true), // Only for example paper. + appendix: [ + #include "appendix.typ" + #include "checklist.typ" + ], + accepted: true, +) + += Introduction + +The rise of online resources in scientific pedagogy has become increasingly +prevalent. Around the world, students use virtual labs that simulate physical +phenomena. However, still lacking is the accessibility of real world hardware +to obtain real results. Experimental instruments are expensive and difficult to +justify for many schools and institutions. One solution to this problem is to +provide shared equipment that is accessible and controlled over the internet. +This allows equipment located in a single place to be used from anywhere in the +world. + +One way to build these systems is to augment existing devices with the +capability to be controlled over the internet. However, many scientific +instruments are designed with human operation in mind and contain many analog +dials, readouts, and controls. We seek a way to non-invasively digitize these +devices. Here non-invasively means that we should not perform any irreversible +or drastic changes to the hardware. Digitize refers to obtaining all relevant +outputs as digital data that can be processed by computers, and being able to +operate relevant controls over digital protocols (such as the internet). In +this paper, we focus primarily on obtaining the outputs. + +We propose a system which uses an end-to-end vision pipeline that can scan +readouts and translate them into data. Then, the data can be streamed to +virtual simulations which will react exactly as the real life equipment does. + +== Requirements + +Our end-to-end pipeline will consist of a component to locate the desired +instrument in the image and determine the corrections needed to transform the +image into a point of view where it is directly visible. This may be a neural +network based model that identifies a key fiducial from which we can +extrapolate the perspective transforms needed to bring the image to a +normalized state (here normalized refers to a flattened 2D image that can be +easily analyzed by computer vision). + +We then extrapolate from that data to map out all of the various points of +interest. From that point, we can run specialized models on readouts such as +dials to determine their readings. + += The state of the art + +We first + + diff --git a/2024/documents/by-name/vision-whitepaper/package.nix b/2024/documents/by-name/vision-whitepaper/package.nix new file mode 100644 index 0000000..1c9e4f7 --- /dev/null +++ b/2024/documents/by-name/vision-whitepaper/package.nix @@ -0,0 +1,35 @@ +{ + pkgs, + typstPackagesCache, + typixLib, + cleanTypstSource, + ... +}: +let + src = cleanTypstSource ./.; + commonArgs = { + typstSource = "main.typ"; + + fontPaths = [ + # Add paths to fonts here + # "${pkgs.roboto}/share/fonts/truetype" + ]; + + virtualPaths = [ + # Add paths that must be locally accessible to typst here + # { + # dest = "icons"; + # src = "${inputs.font-awesome}/svgs/regular"; + # } + ]; + + XDG_CACHE_HOME = typstPackagesCache; + }; + +in +typixLib.buildTypstProject ( + commonArgs + // { + inherit src; + } +)