Dirks Personal WiKi - User contributions [en]

Hydrogen Fluoride Buffer Solutions

2024-09-22T10:46:34Z

DirkMittler: Conclusion.

[[Category:Chemistry]]

The subject of Dynamics And Equilibria is more complex than this, and a complete treatment of that subject will not be attempted here.

A "complete" equilibrium constant which honestly describes the state of an HF buffer solution, derives from the chemical reaction:

<math>HF\rightleftharpoons F^{1-}+H^{+}</math>

And takes the form:

<math>K_{c}=\frac{\left[F^{1-}\right]\left[H^{+}\right]}{\left[HF\right]}</math>,

Where the square brackets denote the concentration of the particles enclosed. But, a quantity which is more frequently stated is, the ratio:

<math>K_{a}=\frac{\left[F^{1-}\right]}{\left[HF\right]}</math>,

Which is exact when the solution is neutral, and when the pH of water is (7). Thus, <math display="inline">\left(K_{a}\right)</math> is exact when <math display="inline">\left[H^{+}\right]=10^{-7}</math>. [[wikipedia:Hydrofluoric_acid|Some sources]] have stated <math display="inline">\left(K_{a}\right)=6.6\cdot10^{-4}</math>, which means that its potency logarithm, <math display="inline">\left(pK_{a}\right)=3.18</math>. But what some sources may state is, that it's difficult to measure <math display="inline">\left(K_{a}\right)</math> directly, because as soon as one has added some amount of <math display="inline">\left(HF\right)</math> to the solution, the solution becomes acidic, and <math display="inline">\left[H^{+}\right]>10^{-7}</math>. If we were to assume that <math display="inline">\left(K_{a}\right)==6.6\cdot10^{-4}</math> when <math display="inline">\left[H^{+}\right]=10^{-7}</math>, then it will also follow that...

<math>K_{c}=K_{a}\cdot10^{-7}=6.6\cdot10^{-11}</math>.

<math display="inline">\left(pK_{c}\right)</math> Or <math display="inline">\left(K_{c}\right)</math> can be used to describe the general behavior of the buffer solution. Thus, if it's desired that <math display="inline">\left[H^{+}\right]=10^{-4}</math>, then this value can just be plugged in to the equation for <math display="inline">\left(K_{c}\right)</math>, and the ratio between <math display="inline">\left[F^{1-}\right]</math> and <math display="inline">\left[HF\right]</math> defined. The problem which then remains in preparing the buffer solution is, that neither <math display="inline">\left[F^{1-}\right]</math> nor <math display="inline">\left[HF\right]</math> will equal the amount of the compounds, say, <math display="inline">\left(NaF\right)</math> and <math display="inline">\left(HF\right)</math> that were initially added. The increase of <math display="inline">\left[H^{+}\right]</math> above <math display="inline">\left(10^{-7}\right)</math> may consume some <math display="inline">\left(HF\right)</math> and add to the final concentration of <math display="inline">\left(F^{1-}\right)</math>. In that case, what the lab technicians may do is:

* Rely on the effectiveness of the buffer solution to compensate. Or,
* Assume that acid has been added by itself, restate <math display="inline">\left[HF\right]</math> as a more complex expression which depends on the known amount of that, minus <math display="inline">\left[H^{+}\right]</math>, pretend that <math display="inline">\left[F^{1-}\right]</math> and <math display="inline">\left[H^{+}\right]</math> are equal as the numerator of <math display="inline">\left(K_{c}\right)</math>, and solve the quadratic to determine <math display="inline">\left[H^{+}\right]</math>. Or,
* Subtract <math display="inline">\left[H^{+}\right]</math> from <math display="inline">\left[F^{1-}\right]</math> in order to determine how much conjugate base must be added to the solution. In this case, adding a negative amount of base isn't possible.

If <math display="inline">\left[H^{+}\right]</math> is close to its neutral value, their initial difference may be neglected as part of an approximation (but the buffer solution still offer increased resistance to fatigue as the acid gets used).

Also, it can be explained that if <math display="inline">\left[HF\right]</math> is to be maximized, say, in order to improve its glass-etching performance, then actually adding a strong acid will be helpful, as doing so increases <math display="inline">\left[H^{+}\right]</math>, thereby elevating <math display="inline">\left[HF\right]</math> with respect to <math display="inline">\left[F^{1-}\right]</math>.

The example below is a scratch sheet, for formulating a buffer solution, where it's allowable for <math display="inline">\left[HF\right]</math> actually to be <math display="inline">\left(10\;mol\:/L\right)</math>, and where the target <math display="inline">\left[H^{+}\right]</math> is more realistically <math display="inline">\left(10^{-5}\right)</math>...

----

* <math>
K_{c}=\frac{\left[F^{1-}\right]\left[H^{+}\right]}{\left[HF\right]}=6.6\cdot10^{-11}
</math>
* <math>
\left[H^{+}\right]=10^{-5}
</math>
* <math>
\left[HF\right]=1.0\cdot10^{+1}\;mol\:/L
</math>
* <math>
\frac{\left[F^{1-}\right]}{mol\:/L}=\frac{6.6\cdot10^{-11}}{10^{-5}}\cdot10^{+1}
</math>
* <math>
=6.6\cdot10^{-5}
</math>
* <math>
\frac{\left[F^{1-}\right]}{mol\:/L}-\left[H^{+}\right]=5.6\cdot10^{-5}
</math>

----

A type of conclusion which can be drawn is, that specifically in the case of Hydrogen Fluoride, the buffer solution's main purpose is to reduce the acidity, and thus to reduce the rate at which the solution etches, below the rate at which an uncontrolled acid would etch, and on the basic side of neutrality for water. This has clear applications in, say, IC manufacture.

2024-09-02T07:04:01Z

DirkMittler: Split off serious part.

First Page

2024-09-02T06:59:54Z

DirkMittler: First presentable page.

Main Page

2024-09-02T05:52:59Z

DirkMittler: Regenerate sitemap.

'''This is a personal MediaWiki...'''

== Getting started ==

The [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents User's Guide] will explain how to use the WiKi software, to Dirk.

* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Configuration settings list]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ MediaWiki FAQ]
* [https://lists.wikimedia.org/postorius/lists/mediawiki-announce.lists.wikimedia.org/ MediaWiki release mailing list]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources Localise MediaWiki for your language]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Combating_spam Learn how to combat spam on your wiki]

== Some Experimentation with MediaWiKi ==

=== Basics ===
{{equation|1}} {{spaces|2|emsp}} <math>y=\pm\sqrt{1-x^{2}}</math> {{spaces|2|emsp}} (Equation for circle.)

<tab name="Drop-Down Menu" dropdown>
* <nowiki>[[Plastic Widgets]]</nowiki>
* <nowiki>[[Framistans]]</nowiki>
* <nowiki>[[Pet Rocks]]</nowiki>
* [[#Eq 1|Eq 1]]
* [[#Eq 2|Eq 2]]
* [[#Eq 3|Eq 3]]
* [[#Replacement Code for C++2017|Some Working C++]]
* [[#Eq 4|Eq 4]]
</tab>

=== Inter-WiKi Links ===

The following is a hypothetical exercise...

[[File:Wikipedesketch.png|thumb|left|alt=A cartoon centipede reads books and types on a laptop.|The Wikipede edits ''[[wikipedia:Myriapoda]]''.]] This example is supposed to show how thumbnails can be made to display by default, as well as how inter-WiKi links work.

Some of the links which follow, will not be prefixed with an obvious 'wikipedia:', but are also not of my own origin, as they will point to the English-speaking WiKiPedia.

{{below}}

----

== A Real Coding Issue ==

The following is some reinvented (C++) code which was first suggested in 1999, to compute the reciprocal square root [[wikipedia:Fast inverse square root|using a trick]]. It may not be helpful, because this code requires that the language implementation can already perform multiplication and subtraction in [[wikipedia:Double precision|double-precision, floating-point]] representation, as well as to access such numbers as though they were integers. The fact that so-called 'doubles' have 11 most significant bits that state their power of 2 means that for most purposes, this sort of [[wikipedia:Type punning|type-punning]] computes their logarithm very quickly, which, in turn, is useful to produce a first approximation of their reciprocal square root, of the form...

{{equation|2}} {{spaces|2|emsp}} <math>\ln\left(\frac{1}{\sqrt{x}}\right)-\frac{1}{2}\ln\left(x\right)</math>

Why, exactly, the constants are used as starting values, from which half the punned value of (x) is to be subtracted, is not clear to most people, including This Author. This may have more to do with the binary floating-point format than with the square root of (x). Yet, the fact that Matthew Robertson was able to derive the double-precision version <ref>Matthew Robertson (2012-04-24). "A Brief History of InvSqrt" [https://mrober.io/papers/rsqrt.pdf X] </ref> suggests that he knows. What's being computed more closely resembles...

{{equation|3}} {{spaces|2|emsp}} <math>C-\frac{1}{2}\ln\left(x\right)</math>

What the reader may already have noticed is, that if he or she tries to implement this with C++2020, the standard method of type-punning no longer works, or produces some type of error message from the compiler<ref>GitHub Advice. "Don't use unions or pointer casts..." [https://tttapa.github.io/Pages/Programming/Cpp/Practices/type-punning.html X]</ref>... What this did for me was create a conflict, about whether I should code for the C++2017 installed on most of my boxes, or for C++2020, which I only have installed on one machine. I had the theoretical demand for code that was valid either way.

=== The Legacy Method ===

<syntaxhighlight lang="cpp">
float64_t Q_rsqrt_pun(const float64_t number) noexcept {
uint64_t *temp1 = (uint64_t *) &number;
uint64_t temp2 = 0x5FE6EB50C7B537A9 - (*temp1 >> 1);
float64_t *out = (float64_t *) &temp2;
return *out;
}
</syntaxhighlight>

Notably, this code still works on GNU-C++17 compilers, and there is no compelling reason to think that it would not work under C++2020, except for the possibility that the compiler blocks it, just because it offends some aesthetic standard. As long as the floating-point number still conforms to the [[wikipedia:IEEE 754|IEEE 754]] standard, both methods shown in this article should work.

Another reason why devs might deprecate it at some point in the future, could have to do with forms of optimization which the compilers will carry out, based on unspecified principles.

However, there is the very real fact that on certain hardware architectures, the IEEE 754 standard may no longer define how 'double' floating-point numbers are formatted, and this could be the real reason to drop such practices. In that case, neither of the code versions in this article will work.

=== Replacement Code for C++2017 ===

The rest of the (working) computation applies [[wikipedia:Newton's Method|Newton's Method]] 4 extra times, resulting in precision which reaches the limit of the double-precision floating-point format.

<syntaxhighlight lang="cpp">
/* Fast Inverse Square Root, using Matthew Robertson's
* Magic Number for double-precision floating-point.
*
* Implemented August 2, 2024
* by Dirk Mittler
*
*/

#include <cstring>
#include <cstdint>

typedef double float64_t;

float64_t Q_rsqrt(const float64_t number) noexcept {
const float64_t threehalfs = 1.5;
const float64_t halfnum = 0.5 * number;
uint64_t temp;
float64_t y;
static_assert(sizeof(uint64_t) == sizeof(number),
"`double` has a weird size.");
memcpy(&temp, &number, sizeof(float64_t));
// temp = 0x5f3759df - (temp >> 1); // Original 32-bit fr Quake III
temp = 0x5FE6EB50C7B537A9 - (temp >> 1); // Matthew Robertson's
memcpy(&y, &temp, sizeof(float64_t));
y *= (threehalfs - (halfnum * y * y));
y *= (threehalfs - (halfnum * y * y));
y *= (threehalfs - (halfnum * y * y));
return y * (threehalfs - (halfnum * y * y));
}

</syntaxhighlight>

=== Reason Such Code Was Invented ===

Of course, the original hack had as context that in early 3D games, texture maps were also associated with normal-maps <ref>LearnOpenGL - Normal Mapping [https://learnopengl.com/Advanced-Lighting/Normal-Mapping X]</ref> that only had 8 bits of (signed) precision per coordinate (fetched as R, G and B components of a specially-prepared texture image, at 8 bits per channel), so that even 32-bit, single-precision floating point numbers were overkill for certain parts of the rendering. The game in which this was first exploited was a Quake III Arena version that ran on early PCs, but it can still be played today on Steam <ref>Quake III Arena on Steam (2024-08-31). [https://store.steampowered.com/app/2200/Quake_III_Arena/ X] </ref>. And so, a real speed improvement can be achieved over ''accurate'' computations, by reducing the number of passes of Newton's Method, to 1 or even 0. In this case, precision is truly not equivalent to accuracy.

Although Quake III was surely programmed using some version of DirectX, the practice of normal-mapping is also standard with OpenGL.

In general, Normal Vectors need to be Unit Vectors, which can be derived from arbitrary vectors, such as the per-texel vectors of a normal-map, using the following equation, but requiring that a square root be divided by, which really means that the reciprocal of a square root frequently needs to be scalar-multiplied by...

{{equation|4}} {{spaces|2|emsp}} <math>\widehat{N}=\frac{1}{\left\Vert N\right\Vert }N,\;\left\Vert N\right\Vert =\sqrt{N_{x}^{2}+N_{y}^{2}+N_{z}^{2}}</math>

== Notes ==

<references />

Main Page

2024-09-01T22:01:17Z

DirkMittler: Try to generate sitemap.

'''This is a personal MediaWiki.'''

== Getting started ==

The [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents User's Guide] will explain how to use the WiKi software, to Dirk.

* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Configuration settings list]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ MediaWiki FAQ]
* [https://lists.wikimedia.org/postorius/lists/mediawiki-announce.lists.wikimedia.org/ MediaWiki release mailing list]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources Localise MediaWiki for your language]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Combating_spam Learn how to combat spam on your wiki]

== Some Experimentation with MediaWiKi ==

=== Basics ===
{{equation|1}} {{spaces|2|emsp}} <math>y=\pm\sqrt{1-x^{2}}</math> {{spaces|2|emsp}} (Equation for circle.)

<tab name="Drop-Down Menu" dropdown>
* <nowiki>[[Plastic Widgets]]</nowiki>
* <nowiki>[[Framistans]]</nowiki>
* <nowiki>[[Pet Rocks]]</nowiki>
* [[#Eq 1|Eq 1]]
* [[#Eq 2|Eq 2]]
* [[#Eq 3|Eq 3]]
* [[#Replacement Code for C++2017|Some Working C++]]
* [[#Eq 4|Eq 4]]
</tab>

=== Inter-WiKi Links ===

The following is a hypothetical exercise...

[[File:Wikipedesketch.png|thumb|left|alt=A cartoon centipede reads books and types on a laptop.|The Wikipede edits ''[[wikipedia:Myriapoda]]''.]] This example is supposed to show how thumbnails can be made to display by default, as well as how inter-WiKi links work.

Some of the links which follow, will not be prefixed with an obvious 'wikipedia:', but are also not of my own origin, as they will point to the English-speaking WiKiPedia.

{{below}}

----

== A Real Coding Issue ==

The following is some reinvented (C++) code which was first suggested in 1999, to compute the reciprocal square root [[wikipedia:Fast inverse square root|using a trick]]. It may not be helpful, because this code requires that the language implementation can already perform multiplication and subtraction in [[wikipedia:Double precision|double-precision, floating-point]] representation, as well as to access such numbers as though they were integers. The fact that so-called 'doubles' have 11 most significant bits that state their power of 2 means that for most purposes, this sort of [[wikipedia:Type punning|type-punning]] computes their logarithm very quickly, which, in turn, is useful to produce a first approximation of their reciprocal square root, of the form...

{{equation|2}} {{spaces|2|emsp}} <math>\ln\left(\frac{1}{\sqrt{x}}\right)-\frac{1}{2}\ln\left(x\right)</math>

Why, exactly, the constants are used as starting values, from which half the punned value of (x) is to be subtracted, is not clear to most people, including This Author. This may have more to do with the binary floating-point format than with the square root of (x). Yet, the fact that Matthew Robertson was able to derive the double-precision version <ref>Matthew Robertson (2012-04-24). "A Brief History of InvSqrt" [https://mrober.io/papers/rsqrt.pdf X] </ref> suggests that he knows. What's being computed more closely resembles...

{{equation|3}} {{spaces|2|emsp}} <math>C-\frac{1}{2}\ln\left(x\right)</math>

What the reader may already have noticed is, that if he or she tries to implement this with C++2020, the standard method of type-punning no longer works, or produces some type of error message from the compiler<ref>GitHub Advice. "Don't use unions or pointer casts..." [https://tttapa.github.io/Pages/Programming/Cpp/Practices/type-punning.html X]</ref>... What this did for me was create a conflict, about whether I should code for the C++2017 installed on most of my boxes, or for C++2020, which I only have installed on one machine. I had the theoretical demand for code that was valid either way.

=== The Legacy Method ===

<syntaxhighlight lang="cpp">
float64_t Q_rsqrt_pun(const float64_t number) noexcept {
uint64_t *temp1 = (uint64_t *) &number;
uint64_t temp2 = 0x5FE6EB50C7B537A9 - (*temp1 >> 1);
float64_t *out = (float64_t *) &temp2;
return *out;
}
</syntaxhighlight>

Notably, this code still works on GNU-C++17 compilers, and there is no compelling reason to think that it would not work under C++2020, except for the possibility that the compiler blocks it, just because it offends some aesthetic standard. As long as the floating-point number still conforms to the [[wikipedia:IEEE 754|IEEE 754]] standard, both methods shown in this article should work.

Another reason why devs might deprecate it at some point in the future, could have to do with forms of optimization which the compilers will carry out, based on unspecified principles.

However, there is the very real fact that on certain hardware architectures, the IEEE 754 standard may no longer define how 'double' floating-point numbers are formatted, and this could be the real reason to drop such practices. In that case, neither of the code versions in this article will work.

=== Replacement Code for C++2017 ===

The rest of the (working) computation applies [[wikipedia:Newton's Method|Newton's Method]] 4 extra times, resulting in precision which reaches the limit of the double-precision floating-point format.

<syntaxhighlight lang="cpp">
/* Fast Inverse Square Root, using Matthew Robertson's
* Magic Number for double-precision floating-point.
*
* Implemented August 2, 2024
* by Dirk Mittler
*
*/

#include <cstring>
#include <cstdint>

typedef double float64_t;

float64_t Q_rsqrt(const float64_t number) noexcept {
const float64_t threehalfs = 1.5;
const float64_t halfnum = 0.5 * number;
uint64_t temp;
float64_t y;
static_assert(sizeof(uint64_t) == sizeof(number),
"`double` has a weird size.");
memcpy(&temp, &number, sizeof(float64_t));
// temp = 0x5f3759df - (temp >> 1); // Original 32-bit fr Quake III
temp = 0x5FE6EB50C7B537A9 - (temp >> 1); // Matthew Robertson's
memcpy(&y, &temp, sizeof(float64_t));
y *= (threehalfs - (halfnum * y * y));
y *= (threehalfs - (halfnum * y * y));
y *= (threehalfs - (halfnum * y * y));
return y * (threehalfs - (halfnum * y * y));
}

</syntaxhighlight>

=== Reason Such Code Was Invented ===

Of course, the original hack had as context that in early 3D games, texture maps were also associated with normal-maps <ref>LearnOpenGL - Normal Mapping [https://learnopengl.com/Advanced-Lighting/Normal-Mapping X]</ref> that only had 8 bits of (signed) precision per coordinate (fetched as R, G and B components of a specially-prepared texture image, at 8 bits per channel), so that even 32-bit, single-precision floating point numbers were overkill for certain parts of the rendering. The game in which this was first exploited was a Quake III Arena version that ran on early PCs, but it can still be played today on Steam <ref>Quake III Arena on Steam (2024-08-31). [https://store.steampowered.com/app/2200/Quake_III_Arena/ X] </ref>. And so, a real speed improvement can be achieved over ''accurate'' computations, by reducing the number of passes of Newton's Method, to 1 or even 0. In this case, precision is truly not equivalent to accuracy.

Although Quake III was surely programmed using some version of DirectX, the practice of normal-mapping is also standard with OpenGL.

In general, Normal Vectors need to be Unit Vectors, which can be derived from arbitrary vectors, such as the per-texel vectors of a normal-map, using the following equation, but requiring that a square root be divided by, which really means that the reciprocal of a square root frequently needs to be scalar-multiplied by...

{{equation|4}} {{spaces|2|emsp}} <math>\widehat{N}=\frac{1}{\left\Vert N\right\Vert }N,\;\left\Vert N\right\Vert =\sqrt{N_{x}^{2}+N_{y}^{2}+N_{z}^{2}}</math>

== Notes ==

<references />

Main Page

2024-09-01T21:57:12Z

DirkMittler: Try to generate sitemap.

'''This is a personal MediaWiki'''...

== Getting started ==

The [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents User's Guide] will explain how to use the WiKi software, to Dirk.

* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Configuration settings list]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ MediaWiki FAQ]
* [https://lists.wikimedia.org/postorius/lists/mediawiki-announce.lists.wikimedia.org/ MediaWiki release mailing list]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources Localise MediaWiki for your language]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Combating_spam Learn how to combat spam on your wiki]

== Some Experimentation with MediaWiKi ==

=== Basics ===
{{equation|1}} {{spaces|2|emsp}} <math>y=\pm\sqrt{1-x^{2}}</math> {{spaces|2|emsp}} (Equation for circle.)

<tab name="Drop-Down Menu" dropdown>
* <nowiki>[[Plastic Widgets]]</nowiki>
* <nowiki>[[Framistans]]</nowiki>
* <nowiki>[[Pet Rocks]]</nowiki>
* [[#Eq 1|Eq 1]]
* [[#Eq 2|Eq 2]]
* [[#Eq 3|Eq 3]]
* [[#Replacement Code for C++2017|Some Working C++]]
* [[#Eq 4|Eq 4]]
</tab>

=== Inter-WiKi Links ===

The following is a hypothetical exercise...

[[File:Wikipedesketch.png|thumb|left|alt=A cartoon centipede reads books and types on a laptop.|The Wikipede edits ''[[wikipedia:Myriapoda]]''.]] This example is supposed to show how thumbnails can be made to display by default, as well as how inter-WiKi links work.

Some of the links which follow, will not be prefixed with an obvious 'wikipedia:', but are also not of my own origin, as they will point to the English-speaking WiKiPedia.

{{below}}

----

== A Real Coding Issue ==

The following is some reinvented (C++) code which was first suggested in 1999, to compute the reciprocal square root [[wikipedia:Fast inverse square root|using a trick]]. It may not be helpful, because this code requires that the language implementation can already perform multiplication and subtraction in [[wikipedia:Double precision|double-precision, floating-point]] representation, as well as to access such numbers as though they were integers. The fact that so-called 'doubles' have 11 most significant bits that state their power of 2 means that for most purposes, this sort of [[wikipedia:Type punning|type-punning]] computes their logarithm very quickly, which, in turn, is useful to produce a first approximation of their reciprocal square root, of the form...

{{equation|2}} {{spaces|2|emsp}} <math>\ln\left(\frac{1}{\sqrt{x}}\right)-\frac{1}{2}\ln\left(x\right)</math>

Why, exactly, the constants are used as starting values, from which half the punned value of (x) is to be subtracted, is not clear to most people, including This Author. This may have more to do with the binary floating-point format than with the square root of (x). Yet, the fact that Matthew Robertson was able to derive the double-precision version <ref>Matthew Robertson (2012-04-24). "A Brief History of InvSqrt" [https://mrober.io/papers/rsqrt.pdf X] </ref> suggests that he knows. What's being computed more closely resembles...

{{equation|3}} {{spaces|2|emsp}} <math>C-\frac{1}{2}\ln\left(x\right)</math>

What the reader may already have noticed is, that if he or she tries to implement this with C++2020, the standard method of type-punning no longer works, or produces some type of error message from the compiler<ref>GitHub Advice. "Don't use unions or pointer casts..." [https://tttapa.github.io/Pages/Programming/Cpp/Practices/type-punning.html X]</ref>... What this did for me was create a conflict, about whether I should code for the C++2017 installed on most of my boxes, or for C++2020, which I only have installed on one machine. I had the theoretical demand for code that was valid either way.

=== The Legacy Method ===

<syntaxhighlight lang="cpp">
float64_t Q_rsqrt_pun(const float64_t number) noexcept {
uint64_t *temp1 = (uint64_t *) &number;
uint64_t temp2 = 0x5FE6EB50C7B537A9 - (*temp1 >> 1);
float64_t *out = (float64_t *) &temp2;
return *out;
}
</syntaxhighlight>

Notably, this code still works on GNU-C++17 compilers, and there is no compelling reason to think that it would not work under C++2020, except for the possibility that the compiler blocks it, just because it offends some aesthetic standard. As long as the floating-point number still conforms to the [[wikipedia:IEEE 754|IEEE 754]] standard, both methods shown in this article should work.

Another reason why devs might deprecate it at some point in the future, could have to do with forms of optimization which the compilers will carry out, based on unspecified principles.

However, there is the very real fact that on certain hardware architectures, the IEEE 754 standard may no longer define how 'double' floating-point numbers are formatted, and this could be the real reason to drop such practices. In that case, neither of the code versions in this article will work.

=== Replacement Code for C++2017 ===

The rest of the (working) computation applies [[wikipedia:Newton's Method|Newton's Method]] 4 extra times, resulting in precision which reaches the limit of the double-precision floating-point format.

<syntaxhighlight lang="cpp">
/* Fast Inverse Square Root, using Matthew Robertson's
* Magic Number for double-precision floating-point.
*
* Implemented August 2, 2024
* by Dirk Mittler
*
*/

#include <cstring>
#include <cstdint>

typedef double float64_t;

float64_t Q_rsqrt(const float64_t number) noexcept {
const float64_t threehalfs = 1.5;
const float64_t halfnum = 0.5 * number;
uint64_t temp;
float64_t y;
static_assert(sizeof(uint64_t) == sizeof(number),
"`double` has a weird size.");
memcpy(&temp, &number, sizeof(float64_t));
// temp = 0x5f3759df - (temp >> 1); // Original 32-bit fr Quake III
temp = 0x5FE6EB50C7B537A9 - (temp >> 1); // Matthew Robertson's
memcpy(&y, &temp, sizeof(float64_t));
y *= (threehalfs - (halfnum * y * y));
y *= (threehalfs - (halfnum * y * y));
y *= (threehalfs - (halfnum * y * y));
return y * (threehalfs - (halfnum * y * y));
}

</syntaxhighlight>

=== Reason Such Code Was Invented ===

Of course, the original hack had as context that in early 3D games, texture maps were also associated with normal-maps <ref>LearnOpenGL - Normal Mapping [https://learnopengl.com/Advanced-Lighting/Normal-Mapping X]</ref> that only had 8 bits of (signed) precision per coordinate (fetched as R, G and B components of a specially-prepared texture image, at 8 bits per channel), so that even 32-bit, single-precision floating point numbers were overkill for certain parts of the rendering. The game in which this was first exploited was a Quake III Arena version that ran on early PCs, but it can still be played today on Steam <ref>Quake III Arena on Steam (2024-08-31). [https://store.steampowered.com/app/2200/Quake_III_Arena/ X] </ref>. And so, a real speed improvement can be achieved over ''accurate'' computations, by reducing the number of passes of Newton's Method, to 1 or even 0. In this case, precision is truly not equivalent to accuracy.

Although Quake III was surely programmed using some version of DirectX, the practice of normal-mapping is also standard with OpenGL.

In general, Normal Vectors need to be Unit Vectors, which can be derived from arbitrary vectors, such as the per-texel vectors of a normal-map, using the following equation, but requiring that a square root be divided by, which really means that the reciprocal of a square root frequently needs to be scalar-multiplied by...

{{equation|4}} {{spaces|2|emsp}} <math>\widehat{N}=\frac{1}{\left\Vert N\right\Vert }N,\;\left\Vert N\right\Vert =\sqrt{N_{x}^{2}+N_{y}^{2}+N_{z}^{2}}</math>

== Notes ==

<references />

File:Dirk-fract-3.jpg

2024-09-01T21:56:00Z

DirkMittler: This is a picture of the site owner, that has been compressed with fractal compression (as a WFA File) and then converted back into Jpeg format. The parameters with which WFA Files are usually generated, try to achieve accuracy. But here, the parameters were changed, in order to emphasize the fractal nature of WFA Files.

== Summary ==
This is a picture of the site owner, that has been compressed with fractal compression (as a WFA File) and then converted back into Jpeg format. The parameters with which WFA Files are usually generated, try to achieve accuracy. But here, the parameters were changed, in order to emphasize the fractal nature of WFA Files.

2024-09-01T11:55:46Z

DirkMittler:

'''This is a personal MediaWiki.'''

== Getting started ==

The [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents User's Guide] will explain how to use the WiKi software, to Dirk.

* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Configuration settings list]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ MediaWiki FAQ]
* [https://lists.wikimedia.org/postorius/lists/mediawiki-announce.lists.wikimedia.org/ MediaWiki release mailing list]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources Localise MediaWiki for your language]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Combating_spam Learn how to combat spam on your wiki]

== Some Experimentation with MediaWiKi ==

=== Basics ===
Eq 1: {{spaces|2|emsp}} <math>y=\pm\sqrt{1-x^{2}}</math> {{spaces|2|emsp}} (Equation for circle.)

<tab name="Drop-Down Menu" dropdown>
* <nowiki>[[Plastic Widgets]]</nowiki>
* <nowiki>[[Framistans]]</nowiki>
* <nowiki>[[Pet Rocks]]</nowiki>
* [[#Eq 1|Eq 1]]
* [[#Eq 2|Eq 2]]
* [[#Eq 3|Eq 3]]
* [[#Replacement Code for C++2017|Some Working C++]]
* [[#Eq 4|Eq 4]]
</tab>

=== Inter-WiKi Links ===

The following is a hypothetical exercise...

[[File:Wikipedesketch.png|thumb|left|alt=A cartoon centipede reads books and types on a laptop.|The Wikipede edits ''[[wikipedia:Myriapoda]]''.]] This example is supposed to show how thumbnails can be made to display by default, as well as how inter-WiKi links work.

Some of the links which follow, will not be prefixed with an obvious 'wikipedia:', but are also not of my own origin, as they will point to the English-speaking WiKiPedia.

{{below}}

----

== A Real Coding Issue ==

The following is some reinvented (C++) code which was first suggested in 1999, to compute the reciprocal square root [[wikipedia:Fast inverse square root|using a trick]]. It may not be helpful, because this code requires that the language implementation can already perform multiplication and subtraction in [[wikipedia:Double precision|double-precision, floating-point]] representation, as well as to access such numbers as though they were integers. The fact that so-called 'doubles' have 11 most significant bits that state their power of 2 means that for most purposes, this sort of [[wikipedia:Type punning|type-punning]] computes their logarithm very quickly, which, in turn, is useful to produce a first approximation of their reciprocal square root, of the form...

Eq 2: {{spaces|2|emsp}} <math>\ln\left(\frac{1}{\sqrt{x}}\right)-\frac{1}{2}\ln\left(x\right)</math>

Why, exactly, the constants are used as starting values, from which half the punned value of (x) is to be subtracted, is not clear to most people, including This Author. This may have more to do with the binary floating-point format than with the square root of (x). Yet, the fact that Matthew Robertson was able to derive the double-precision version <ref>Matthew Robertson (2012-04-24). "A Brief History of InvSqrt" [https://mrober.io/papers/rsqrt.pdf X] </ref> suggests that he knows. What's being computed more closely resembles...

Eq 3: {{spaces|2|emsp}} <math>C-\frac{1}{2}\ln\left(x\right)</math>

What the reader may already have noticed is, that if he or she tries to implement this with C++2020, the standard method of type-punning no longer works, or produces some type of error message from the compiler<ref>GitHub Advice. "Don't use unions or pointer casts..." [https://tttapa.github.io/Pages/Programming/Cpp/Practices/type-punning.html X]</ref>... What this did for me was create a conflict, about whether I should code for the C++2017 installed on most of my boxes, or for C++2020, which I only have installed on one machine. I had the theoretical demand for code that was valid either way.

=== The Legacy Method ===

<syntaxhighlight lang="cpp">
float64_t Q_rsqrt_pun(const float64_t number) noexcept {
uint64_t *temp1 = (uint64_t *) &number;
uint64_t temp2 = 0x5FE6EB50C7B537A9 - (*temp1 >> 1);
float64_t *out = (float64_t *) &temp2;
return *out;
}
</syntaxhighlight>

Notably, this code still works on C++2017 -based compilers, and there is no compelling reason to think that it would not work under C++2020, except for the possibility that the compiler blocks it, just because it offends some aesthetic standard. As long as the floating-point number still conforms to the [[wikipedia:IEEE 754|IEEE 754]] standard, both methods shown in this article will work.

However, there is the very real fact that on certain hardware architectures, the IEEE 754 standard may no longer define how 'double' floating-point numbers are formatted, and this could be the real reason to drop such practices. In that case, neither of the code versions in this article will work.

=== Replacement Code for C++2017 ===

The rest of the (working) computation applies [[wikipedia:Newton's Method|Newton's Method]] 4 extra times, resulting in precision which reaches the limit of the double-precision floating-point format.

<syntaxhighlight lang="cpp">
/* Fast Inverse Square Root, using Matthew Robertson's
* Magic Number for double-precision floating-point.
*
* Implemented August 2, 2024
* by Dirk Mittler
*
*/

#include <cstring>
#include <cstdint>

typedef double float64_t;

float64_t Q_rsqrt(const float64_t number) noexcept {
const float64_t threehalfs = 1.5;
const float64_t halfnum = 0.5 * number;
uint64_t temp;
float64_t y;
static_assert(sizeof(uint64_t) == sizeof(number),
"`double` has a weird size.");
memcpy(&temp, &number, sizeof(float64_t));
// temp = 0x5f3759df - (temp >> 1); // Original 32-bit fr Quake III
temp = 0x5FE6EB50C7B537A9 - (temp >> 1); // Matthew Robertson's
memcpy(&y, &temp, sizeof(float64_t));
y *= (threehalfs - (halfnum * y * y));
y *= (threehalfs - (halfnum * y * y));
y *= (threehalfs - (halfnum * y * y));
return y * (threehalfs - (halfnum * y * y));
}

</syntaxhighlight>

=== Reason Such Code Was Invented ===

Of course, the original hack had as context that in early 3D games, texture maps were also associated with normal-maps <ref>LearnOpenGL - Normal Mapping [https://learnopengl.com/Advanced-Lighting/Normal-Mapping X]</ref> that only had 8 bits of (signed) precision per coordinate (fetched as R, G and B components of a specially-prepared texture image, at 8 bits per channel), so that even 32-bit, single-precision floating point numbers were overkill for certain parts of the rendering. The game in which this was first exploited was a Quake III Arena version that ran on early PCs, but it can still be played today on Steam <ref>Quake III Arena on Steam (2024-08-31). [https://store.steampowered.com/app/2200/Quake_III_Arena/ X] </ref>. And so, a real speed improvement can be achieved over ''accurate'' computations, by reducing the number of passes of Newton's Method, to 1 or even 0. In this case, precision is truly not equivalent to accuracy.

In general, Normal Vectors need to be Unit Vectors, which can be derived from arbitrary vectors, such as the per-texel vectors of a normal-map, using the following equation, but requiring that a square root be divided by, which really means that the reciprocal of a square root frequently needs to be scalar-multiplied by...

Eq 4: {{spaces|2|emsp}} <math>\widehat{N}=\frac{1}{\left\Vert N\right\Vert }N,\;\left\Vert N\right\Vert =\sqrt{N_{x}^{2}+N_{y}^{2}+N_{z}^{2}}</math>

== Notes ==

<references />