OpenLLM-France/wikimedia huggingface dataset:
# Problem Finding/What do you really want

—Reflecting on the call to action
Problem finding begins by asking the question “What do you want?” Often our initial call to action may be vague, impulsive, unwise, or misdirected. This list of questions can help explore and reassess these nascent urges to discover a wise goal worth pursuing.
Use this list of questions to explore and reassess the motivations for addressing this problem.
The key reassessment questions are: “What do you want to have happen?” and “What is at stake?”
Begin by stating the desired end state—the outcome, goal, or result—and then reflect on the following questions.
* What do you want? (What do you want to have happen?)
** What are your goals?
*** What are your needs?
*** What are your preferences?
*** How did this goal originate?
**** Is this your idea?
**** Did someone else suggest this to you?
**** Did some event, experience, insight, feeling, or new information bring this goal to mind?
** Are you focusing on what matters?
* What is at stake?
** Is this important?
** Why is this important?
** Is this important to you or to someone else?
** What are your fears?
*** What is being threatened?
*** Are your fears physical?
*** Are your fears psychological?
**** Does shame play a role?
**** Does humiliation play a role?
** What opportunities does this create?
** What needs does this address?
*** What physiological needs are at risk?
**** Does this risk your survival?
*** What psychological needs are at risk?
**** How will this affect your prestige?
**** How will that affect your autonomy?
**** How will this exercise or challenge your competency
**** How will this affect your relationships with others?
* How have your answered the Phoenix Checklist questions?
** How has the phoenix checklist helped to better understand this problem?
* Are the assessments based on true beliefs?
** How do you know?
* What outcomes are preferable? Why?
* What outcomes are undesirable? Why?
* Why is it wise to choose this outcome?
** Why is this important?
** Who wants this outcome?
** Who does not want this outcome?
* Why do I want this outcome?
* What alternative outcomes would also be suitable?
* Where is this on the causal chain?
** Is this a symptom, a root cause, or one of many contributing causes?
** What effects are caused by this?
** What are other contributing causes?
** What causes this?
* Can we create more possibilities?
** What thinking tools can help?
* What alternative outcomes would be better?
* How do you know?
* Why?
* What's the problem?
* What's the real problem?
* What's the problem really?
* How do you know?
# Neurosociety Media Centre/Centres/Austria

See also Austrian Neuroscience Association
* Department of Neurology, Medical University Innsbruck
* Medical University of Vienna
* Centre for Brain Research, Medical University of Vienna
* Research Institute of Molecular Pathology, Vienna
# Neurosociety Media Centre/Centres/Bulgaria

See also Bulgarian Academy of Sciences Neuroscience Information Centre
* Bulgarian Academy of Sciences Institute of Biophysics, Institute of Physiology and the Laboratory of Psychophysiology & Neuropsychology
* Central and Eastern European Center for Cognitive Science, New Bulgarian University
* Pleven Medical University
* Medical University
* Sofia Medical University
* Stara Zagora Medical University Trakia
* Medical University
# Neurosociety Media Centre

| Welcome to the Wikiversity pages of the Neurosociety Media Centre. Here you can use and create learning materials about neuroscience and neurotechnologies, beginning with brain imaging. The aim of these wiki pages is for us to collaboratively create resources about the state of the art, the promises and risks linked to these topics. Do contribute to the various discussion events and learning projects that bring together scientists, clinicians, social scientists, patients, lawyers, industrialists, journalists and other citizens around the world. For our first project, which will begin in a few weeks' time, we need you to tell us about your experience of brain imaging. | Welcome to the Wikiversity pages of the Neurosociety Media Centre. Here you can use and create learning materials about neuroscience and neurotechnologies, beginning with brain imaging. The aim of these wiki pages is for us to collaboratively create resources about the state of the art, the promises and risks linked to these topics. Do contribute to the various discussion events and learning projects that bring together scientists, clinicians, social scientists, patients, lawyers, industrialists, journalists and other citizens around the world. For our first project, which will begin in a few weeks' time, we need you to tell us about your experience of brain imaging. |
* News - Events - Neurosociety Guide - Centres - Courses
| Brain Imaging | Tell us about your experience | Learning Resources |
* Research on Neuroscience, the Media and Society
# Neurosociety Media Centre/Centres/Croatia

Croatian Society for Neuroscience
* Croatian Institute for Brain Research, School of Medicine University of Zagreb, Croatia
* Cognitive Science, University of Zagreb
* IBRO in Croatia
# Neurosociety Media Centre/Be An Expert

Investigation 1: How can we improve the experience of brain imaging?
Around a third - and perhaps over a half - of all of the people who have MRI scans find the experience difficult. Many research teams have developed ways of making the process easier, and in tests, some of these methods worked very well indeed.
Please help us find out more about how medical centres prepare you for your scan, by going to the Neurosociety_Media_Centre/My MRI page and telling us about your experience.
# Neurosociety Media Centre/Centres

* Africa
* Asia
* Australia and Oceania
* Europe
* Middle East
* North and Central America
* South America
# Neurosociety Media Centre/Centres/Belgium

See also Belgian Society for Neuroscience
Flanders
* Artificial Intelligence Laboratory at Vrije Universiteit Brussel
* Bioimaging lab, University of Antwerp
* Computational Neuroscience Research Group
* Laboratorium voor Neuro- en Psychofysiologie
* Laboratorium voor Vergelijkende Endocrinologie
* Laboratory of Cell Pharmacology
* Laboratory of Developmental Genetics Independent Research Group
* Laboratory of Neurogenetics
* Laboratory of Neuronal Cell Biology
* Medical image and signal processing
* Molecular Genetics Department
* MR Research Centre
* Katholieke Universiteit Leuven Department of Neurosciences
* Research Unit Neuro-Psychoanalysis
* Theoretical neurobiology
* Vision lab
* Vlaams Interuniversitair Instituut voor Biotechnologie
French speaking
* Centre de Neurobiologie Cellulaire et Moléculaire
* Cyclotron Research Centre
* Département de Psychologie (Neuropharmacologie du comportement)
* Institut de Recherche Interdisciplinaire en Biologie Humaine et Moléculaire
* Laboratoire de Morphologie Fonctionnelle et Evolutive
* Laboratoire de Neurophysiologie (NEFY)
* Laboratory of Neurophysiology
* NMR and Molecular Imaging Laboratory
* Théorie des Circuits et Traitement du Signal Lab
* Unité de Neuropsychologie Cognitive
* Unité de recherche en physiologie moléculaire
* Unité de Recherches en Neuroendocrinologie du Comportement
# Software Design/Observability

Observability is the ability and the degree to how well a function, class, component, or software could be profiled and monitored in runtime, how well the behavior could be reconstructed based on the telemetry and logging data, starting with the very availability of this data.
Fully corresponds to the definition of observability on Wikipedia.

## Relations to other qualities

Observability fosters traceability of behavior.
# Software Design/Make if condition positive

Checklist questions:
All other things being equal with regard to the project's conventions about if-else branch arrangement, prefer
instead of

## Why

If there is a negation, readers of the code have to mentally apply it every time they glance through the code. That is, eliminating a negation helps to reduce the cognitive load.
If the boolean variable used in the conditional expression already has negation embedded into it, for example, if the variable is called notDone, it might be better to convert it to a positive variable first to avoid both expression-level (i. e. using the negation operator) and semantic negation in the conditional expression.

## Why not

Depending on the project's conventions regarding if-else branch arrangement and specifics of the particular if-else block, there might be reasons to arrange branches in a certain way that are more important than keeping the conditional expression positive, for example, keeping the first branch shorter. Other possibilities are listed here: Code organization conventions § Branch arrangement in if-else and switch statements.
A negative condition in an if branch may also allow early exit from the function and thus reducing the nesting of the bulk of the function.

## Related

* Avoid double negation in boolean expressions
* Minimize nesting of if statements
# Software Design/Minimize the accessibility of classes and members

Checklist questions:
* Can the class be private to the package (enclosing class)?
* Can the function be private to the class (class and its subclasses, package)?
* Can the field (constant) be private to the class (package)?
This practice corresponds to rule Minimize exposure of members from C++ Core Guidelines.

## Why

Minimizing the accessibility of classes, functions, and fields is the primary way of increasing encapsulation of a component, that helps to keep the components loosely coupled and the connascence low. This, in turn, makes understanding, change, testing, and debugging of individual components easier.
# Software Design/Naturality

Naturality is a code and interface quality which is the degree of either how much the code reads like prose in a natural language (usually, English), or how directly the code describes the processes and events in the problem domain rather obscures the processes and events behind abstractions or language forms which don't exist in the problem domain.
Naturality as an interface quality is the naturality of the code which uses the interface.

## Examples

Double negation in boolean expressions: !notSomething reads as "not not something" which doesn't happen in natural communication.
dog.bark expresses the process in the problem domain (the dog is barking) more directly than code like barking.do(dog) or dogActionExecutor.submit(Barking(dog)).

## Relations to other software qualities

It may be easier to learn an interface that produces natural code and to use such an interface from memory because people learn and recall phrases in natural language throughout their lives outside of computer programming.
It may be easier to perceive code which reads like natural prose, thus the cognitive load of reading natural code may be lower.
In typical code, naturality closely correlates with clarity. However, there are exceptions: for example, Yoda conditions are exactly as clear as equivalent "normal" conditions (because the only thing different is the order of terms, not the number or complexity of programming language constructs or operators used), but less natural.

## Relevant practices

* Avoid double negation in boolean expressions
* Choose programming language or framework similar to the language of the problem domain
* Transform data with pipeline operator

## Sources

* Boswell, Dustin; Foucher, Trevor (2011). The Art of Readable Code. ISBN 978-0596802295. Chapter 12. "Turning Thoughts into Code"
* Bloch, Joshua (September 22, 2008). "Bumper-Sticker API Design". Every API is a little language, and people must learn to read and write it. If you get an API right, code will read like prose.
# Software Design/Parameterize Function or Class

Parameterize Function (also Parameterize Class) is a refactoring primarily aiming at removing logic duplication in the code as per DRY principle. This corresponds to Parameterize Function refactoring described in Refactoring.

## Example

See an example of this refactoring on Parameterize Function catalog entry.
Parameterize Class is a generalization of Parameterize Function: an additional parameter is stored in a field of the class and is used in one or several functions belonging to the class.

## Why

Parameterizing functions and classes makes them more reusable and thus allows to eliminate repetition in the existing code.

## Why not

It's easier to make a mistake by passing a wrong argument to a parameterized function than to call a wrong function when there several separate ones with different names.
The meaning of the calls to parameterized functions may be less apparent to readers, especially when the new parameter is boolean. Applying practice Use a enum with two values instead of boolean (and, more generally, Use named constants instead of magic values and Use class instead of primitive type) may alleviate this problem. For example, compare the following versions of the same code:

### Mitigation of the drawbacks: keep the delegation layer

A solution for both drawbacks of Parameterize Function is keeping the old functions and make them delegate to the new parameterized functions, but that contributes to the size of the code and makes it more navigation-heavy in turn. The code with more redirection function calls may also be less efficient, especially in interpreted environments.

### Effects on efficiency

Parameterize Function and Parameterize Class might affect the runtime efficiency of the software in a number of contradictory ways.
Positive:
* Parameterizing functions and classes leads to a reduction in the total amount of the code, hence the instruction cache may be used more effectively.
Negative:
* Parameterized code may not be compiled as efficiently as specialized code. For example, immediate values can't be used in parameterized code, or integral division can't be replaced with a bit shift when the divisor (which is a power of two) is turned into a parameter.
* Parameterizing alternative logic leads to additional branches which might be predicted poorly under some circumstances.
* Parameterizing a class with a field means that the field's value should be read from memory when it could have resided a register otherwise.

## Related refactorings and practices

* Don't repeat logic in several places
# Software Design/Log successful function execution inside the function itself

Logging successful function execution inside the function itself means the code like this:
Rather than like this:
Checklist questions:

## Why

DRY: if the function is called in multiple places, logging shouldn't be repeated in all of them.
Keeping client code free of logging of successful execution of called functions makes it clearer. This could also be seen as an instance of separation of concerns between the client code and the function, although exactly the opposite view is also possible: logging inside the function makes it responsible for two things (the logic and the logging) instead of just one.
If there are also some logging statements in the beginning and in the middle of the function's body, the logging statement about successful execution should be kept congruent with the logging above if there is an objective to avoid logging duplicated information and thus reduce the noisiness of the logs, or to increase the performance, e. g. if serializing function's arguments into string form for the purposes of logging takes significant CPU resources. When all logging is confined to the function's body, keeping it deduplicated is less error-prone and requires less navigation than when the logging statements are spread between the function's body and the function's call sites.
Logging inside the function may output some private information, such as values in some private fields in the class containing the function, or some intermediate computation results which are not returned from the function.

## Why not

If the function is pure, or if the class to which the function belongs isn't concerned with logging, passing a logger object into the function or injecting logging in the class makes the code bigger and less clear.
If at different call sites different logging verbosity level is desired for the function, it needs an additional parameter to control this, which also makes the code bigger and less clear.

## Related

* Log failure outside a function
# Software Design/Make function to access its enclosing class more than any of its arguments

Checklist question:
Sometimes a function which accesses one of its object arguments (ArgClass) more than its enclosing class (EnclosingClass) can simply be moved to ArgClass.
At other times, this situation may identify some problem with the decomposition of the state between classes, or with the decomposition of the logic between functions. The parts of the state of ArgClass that are accessed in the subject function may better be moved to EnclosingClass. If the whole state of ArgClass is accessed in the subject function then it might be that ArgClass shouldn't be a separate class and should be merged into EnclosingClass. Alternatively, it may be the case that ArgClass fails to provide a function which computes something based on multiple parts of its state. If such function was available it could have been used in the subject function to reduce the number of accesses to ArgClass.

## Why

If locations for all functions in all classes are chosen according to this practice then the classes are generally more loosely coupled and it's likely that visibility of some members (fields and functions) of some of the classes could be narrower which makes these classes easier to change. See practice Minimize the accessibility of classes and members.

## Why not

Implementations of Visitor pattern, Kent Beck's Self Delegation pattern, and, in some instances, of Strategy pattern are exempt from following this practice. However, all these patterns aim at the same goal of making the change easier by localizing it and thus reducing the change amplification. These patterns are used in the situations when the general rule of thumb that the data and the logic that references that data change together is not the case.

## Related

* Extract solving unrelated subproblems into separate functions
# Software Design/Minimize the diff between implementations of a strategy

Checklist questions:

## Why

* Increases structuredness and thus makes easier to spot bugs, especially during code reviews.

## Why not

Common details between several (but not all) of the classes could be pulled up into another intermediate abstract class to eliminate repetition between the leaf classes. For example, if the class hierarchy looked like this:
Factoring out ScalarAggregate would increase the difference between ScalarAggregate's subclasses (which now would have less code) and HistogramAggregate. The latter would then look more unique than before the refactoring.

## Related

* Always use the same way to do a thing
# Software Design/Mistake tolerance

Mistake tolerance is a software and an interface quality. In the context of Software Design project, it means the software or the interface operates normally even when it is misused: for example, some function is called with an argument outside of the sensible range, or some functions are called in a wrong order. It can be viewed as a specific type of fault tolerance, where the source of errors are humans misusing the software or the interface.
A robust interface is hard or impossible to misuse in the first place. For example, a function may accept a class instead of a primitive type to reduce or eliminate the probability of passing a wrong argument. An interface may enforce the order in which some functions are called by defining the function that has to be called later in the class returned from the function that has to be caller earlier.

## Sources

* Ousterhout, John (2018). A Philosophy of Software Design. ISBN 978-1732102200. Chapter 10 "Define Errors Out Of Existence"
# Software Design/Practice

This page contains a template for practice articles in the Software Design project. This template describes all possible sections, but some sections may be irrelevant for some specific practices. Sections might also be missing because articles are incomplete.
Checklist questions:
* A question that if asked during a code review provokes following the practice
* Another question

## Examples
### Example 1

An example may include code (see also Programming language of examples), or just describe the situation when the practice could be applied in prose.

### Example 2
## Why

This section enumerates the benefits of applying the practice, in terms of software qualities.

## Why not

This section enumerates the drawbacks applying the practice or the benefits of applying a reverse practice if there is no separate article for that reverse practice yet, in terms of software qualities.

## Static enforcement

If the practice can be enforced using some tools for automated code analysis, they are listed in this section.

### Tool 1

Reference to the specific rule (pattern) in the tool checking the practice.

### Tool 2
## Related

* Related practice 1
* Related practice 2
* Related refactoring
* Related convention
# Physics equations/05-Friction, Drag, and Elasticity/Q:thirdLaw

* Solutions to many wikiquiz questions (pdf)
* Physics_equations/Equations#05-Friction.2C_Drag.2C_and_Elasticity
* Testbank
# Physics equations/06-Uniform Circular Motion and Gravitation
## Wikiquizzes

* Q:friction
* Q:derive

## Reading materials

* A:proofs

### Under ACTIVE construction

UPTA STEM

### Under construction

* A:history
* A:device
* Uniform_circular_motion is an old draft that should be edited or discarded
# Physics equations/04-Dynamics: Force and Newton's Laws/Q:forces/Testbank

Study: http://en.wikiversity.org/wiki/Physics_equations/Sheet/All_chapters