udpate
This commit is contained in:
parent
c8229c56b8
commit
ac0354cb42
7 changed files with 815 additions and 55 deletions
|
@ -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(<Korman2022-KORLFA>, 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(<Korman2022-KORLFA>, 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(<Korman2022-KORLFA>, 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(<Korman2022-KORLFA>, 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()
|
||||
|
||||
|
|
5
2024/documents/by-name/vision-whitepaper/appendix.typ
Normal file
5
2024/documents/by-name/vision-whitepaper/appendix.typ
Normal file
|
@ -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*.
|
524
2024/documents/by-name/vision-whitepaper/checklist.typ
Normal file
524
2024/documents/by-name/vision-whitepaper/checklist.typ
Normal file
|
@ -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.
|
||||
])
|
18
2024/documents/by-name/vision-whitepaper/logo.typ
Normal file
18
2024/documents/by-name/vision-whitepaper/logo.typ
Normal file
|
@ -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$)])
|
||||
})
|
25
2024/documents/by-name/vision-whitepaper/main.bib
Normal file
25
2024/documents/by-name/vision-whitepaper/main.bib
Normal file
|
@ -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}
|
||||
}
|
99
2024/documents/by-name/vision-whitepaper/main.typ
Normal file
99
2024/documents/by-name/vision-whitepaper/main.typ
Normal file
|
@ -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
|
||||
|
||||
|
35
2024/documents/by-name/vision-whitepaper/package.nix
Normal file
35
2024/documents/by-name/vision-whitepaper/package.nix
Normal file
|
@ -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;
|
||||
}
|
||||
)
|
Loading…
Reference in a new issue