[{"id":246984,"date":"2026-04-23T10:56:02","date_gmt":"2026-04-23T15:56:02","guid":{"rendered":"https:\/\/www.johndcook.com\/blog\/?p=246984"},"modified":"2026-04-23T11:08:47","modified_gmt":"2026-04-23T16:08:47","slug":"solve-an-oblique-triangle","status":"publish","type":"post","link":"https:\/\/www.johndcook.com\/blog\/2026\/04\/23\/solve-an-oblique-triangle\/","title":{"rendered":"Approximation to solve an oblique triangle"},"content":{"rendered":"

The previous post<\/a> gave a simple and accurate approximation for the smaller angle of a right triangle. Given a\u00a0right triangle with sides a<\/em>,\u00a0b<\/em>, and\u00a0c<\/em>, where\u00a0a<\/em> is the shortest side and\u00a0c<\/em> is the hypotenuse, the angle opposite side a<\/em> is approximately<\/p>\n

\"A<\/p>\n

in radians. The previous post worked in degrees, but here we’ll use radians.<\/p>\n

If the triangle is oblique rather than a right triangle, there an approximation for the angle A<\/em> that doesn’t require inverse trig functions, though it does require square roots. The approximation is derived in [1] using the same series that is the basis of the approximation in the earlier post, the power series for 2 csc(x<\/em>) + cot(x<\/em>).<\/p>\n

For an oblique triangle, the approximation is\"A<\/p>\n

where\u00a0s<\/em> is the semiperimeter.<\/p>\n

\"s<\/p>\n

For comparison, we can find the exact value of A<\/em> using the law of cosines.<\/p>\n

\"a^2<\/p>\n

and so<\/p>\n

\"A<\/p>\n

Here’s a little Python script to see how accurate the approximation is.<\/p>\n

from math import sqrt, acos\r\n\r\ndef approx(a, b, c):\r\n    \"approximate the angle opposite a\"\r\n    s = (a + b + c)\/2\r\n    return 6*sqrt((s - b)*(s - c)) \/ (2*sqrt(b*c) + sqrt(s*(s - a)))\r\n\r\ndef exact(a, b, c):\r\n    \"exact value of the angle opposite a\"    \r\n    return acos((b**2 + c**2 - a**2)\/(2*b*c))\r\n\r\na, b, c = 6, 7, 12\r\nprint( approx(a, b, c) )\r\nprint( exact(a, b, c) )\r\n<\/pre>\n
This prints<\/p>\n
0.36387538476776243\r\n0.36387760856668505\r\n<\/pre>\n
showing that in our example the approximation is good to five decimal places.<\/p>\n
[1] H. E. Stelson. Note on the approximate solution of an oblique triangle without tables. American Mathematical Monthly. Vol 56, No. 2 (February, 1949), pp. 84\u201395.<\/p>\n","protected":false},"excerpt":{"rendered":"
The previous post gave a simple and accurate approximation for the smaller angle of a right triangle. Given a\u00a0right triangle with sides a,\u00a0b, and\u00a0c, where\u00a0a is the shortest side and\u00a0c is the hypotenuse, the angle opposite side a is approximately in radians. The previous post worked in degrees, but here we’ll use radians. If the […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[9],"tags":[],"class_list":["post-246984","post","type-post","status-publish","format-standard","hentry","category-math"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.johndcook.com\/blog\/wp-json\/wp\/v2\/posts\/246984","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.johndcook.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.johndcook.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.johndcook.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.johndcook.com\/blog\/wp-json\/wp\/v2\/comments?post=246984"}],"version-history":[{"count":0,"href":"https:\/\/www.johndcook.com\/blog\/wp-json\/wp\/v2\/posts\/246984\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.johndcook.com\/blog\/wp-json\/wp\/v2\/media?parent=246984"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.johndcook.com\/blog\/wp-json\/wp\/v2\/categories?post=246984"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.johndcook.com\/blog\/wp-json\/wp\/v2\/tags?post=246984"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}},{"id":246983,"date":"2026-04-23T07:13:35","date_gmt":"2026-04-23T12:13:35","guid":{"rendered":"https:\/\/www.johndcook.com\/blog\/?p=246983"},"modified":"2026-04-23T11:26:29","modified_gmt":"2026-04-23T16:26:29","slug":"solve-a-right-triangle","status":"publish","type":"post","link":"https:\/\/www.johndcook.com\/blog\/2026\/04\/23\/solve-a-right-triangle\/","title":{"rendered":"Simple approximation for solving a right triangle"},"content":{"rendered":"
Suppose you have a right triangle with sides\u00a0a<\/em>,\u00a0b<\/em>, and\u00a0c<\/em>, where\u00a0a<\/em> is the shortest side and\u00a0c<\/em> is the hypotenuse. Then the following approximation from [1] for the angle A<\/em>\u00a0opposite side a<\/em> seems too simple and too accurate to be true. In degrees,<\/p>\n
A<\/em> \u2248 a<\/em> 172\u00b0 \/ (b<\/em> + 2c<\/em>).<\/p>\n
The approximation above only involves simple arithmetic. No trig functions. Not even a square root. It could be carried out with pencil and paper or even mentally. And yet it is surprisingly accurate.<\/p>\n
If we use the 3, 4, 5 triangle as an example, the exact value of the smallest angle is<\/p>\n
A<\/em> = arctan(3\/4) \u00d7 180\u00b0\/\u03c0 \u2248 36.8699\u00b0<\/p>\n
and the approximate value is<\/p>\n
A<\/em> \u2248\u00a0 3 \u00d7 172\u00b0 \/ (4 + 2\u00d75) = 258\u00b0\/7 \u2248 36.8571\u00b0,<\/p>\n
a difference of 0.0128\u00b0. When the angle is more acute the approximation is even better.<\/p>\n
Derivation<\/h2>\n
Where does this magical approximation come from? It boils down to the series<\/p>\n
2 csc(x<\/em>) + cot(x<\/em>) = 3\/x<\/em> +\u00a0x<\/em>\u00b3\/60 +\u00a0O<\/em>(x<\/em>4<\/sup>)<\/p>\n
where x<\/em> is in radians. When x<\/em> is small, \u00a0x<\/em>\u00b3\/60 is extremely small and so we have<\/p>\n
2 csc(x<\/em>) + cot(x<\/em>) \u2248 3\/x.<\/em><\/p>\n
Apply this approximation with csc(x<\/em>) =\u00a0c<\/em>\/a<\/em> and cot(x<\/em>) =\u00a0b<\/em>\/a<\/em>. and you have<\/p>\n
x<\/em> \u2248 3a<\/em>\/(b<\/em> + 2c<\/em>)<\/p>\n
in radians. Multiply by 180\u00b0\/\u03c0 to convert to degrees, and note that 540\/\u03c0 \u2248 172.<\/p>\n
Discovery<\/h2>\n
It’s unmotivated to say “just expand 2 csc(x<\/em>) + cot(x<\/em>) in a series.” Where did\u00a0that<\/em> come from?<\/p>\n
There’s a line in [1] that says “It can been seen, either from tables or from a consideration of power series that the radian measure of a small angle lies approximately one-third of the way from the sine to the tangent.” In other words<\/p>\n
3x<\/em> \u2248 2 sin(x<\/em>) + tan(x<\/em>).<\/em><\/p>\n
You can verify that by adding the power series and noting that the cubic terms cancel out.<\/p>\n
But that’s just the beginning. The author then makes the leap to conjecturing that if the weighted arithmetic<\/em> mean gives a good approximation, maybe the weighted\u00a0harmonic<\/em> mean gives an even better approximation, and that leads to considering<\/p>\n
2 csc(x<\/em>) + cot(x<\/em>) \u2248 3\/x.<\/em><\/p>\n
Extension<\/h2>\n
See the next post<\/a> for an extension to oblique triangles. Not as simple, but based on the same trick.<\/p>\n
 <\/p>\n
[1] J. S. Frame. Solving a right triangle without tables. The American Mathematical Monthly, Vol. 50, No. 10 (Dec., 1943), pp. 622-626<\/p>\n","protected":false},"excerpt":{"rendered":"
Suppose you have a right triangle with sides\u00a0a,\u00a0b, and\u00a0c, where\u00a0a is the shortest side and\u00a0c is the hypotenuse. Then the following approximation from [1] for the angle A\u00a0opposite side a seems too simple and too accurate to be true. In degrees, A \u2248 a 172\u00b0 \/ (b + 2c). The approximation above only involves simple […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[9],"tags":[],"class_list":["post-246983","post","type-post","status-publish","format-standard","hentry","category-math"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.johndcook.com\/blog\/wp-json\/wp\/v2\/posts\/246983","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.johndcook.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.johndcook.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.johndcook.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.johndcook.com\/blog\/wp-json\/wp\/v2\/comments?post=246983"}],"version-history":[{"count":0,"href":"https:\/\/www.johndcook.com\/blog\/wp-json\/wp\/v2\/posts\/246983\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.johndcook.com\/blog\/wp-json\/wp\/v2\/media?parent=246983"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.johndcook.com\/blog\/wp-json\/wp\/v2\/categories?post=246983"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.johndcook.com\/blog\/wp-json\/wp\/v2\/tags?post=246983"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}},{"id":246930,"date":"2026-04-21T15:14:40","date_gmt":"2026-04-21T20:14:40","guid":{"rendered":"https:\/\/www.johndcook.com\/blog\/?p=246930"},"modified":"2026-04-21T19:31:55","modified_gmt":"2026-04-22T00:31:55","slug":"an-ai-odyssey-part-4-astounding-coding-agents","status":"publish","type":"post","link":"https:\/\/www.johndcook.com\/blog\/2026\/04\/21\/an-ai-odyssey-part-4-astounding-coding-agents\/","title":{"rendered":"An AI Odyssey, Part 4: Astounding Coding Agents"},"content":{"rendered":"
AI coding agents improved greatly last summer, and again last December-January. Here are my experiences since my last post<\/a> on the subject.<\/p>\n
The models feel subjectively much smarter. They can accomplish a much broader range of tasks. They seem to have a larger, more comprehensive in-depth view of the code base and what you are trying to accomplish. They can locate more details in obscure parts of the code related to the specific task at hand. By rough personal estimate, I would say that they helped me with 20% of my coding effort last August and about 60% now. Both of these figures may be below what is possible, I may not be using them to fullest capability.<\/p>\n
This being said, they are not a panacea. Sometimes they need help and direction to where to look for a problem. Sometimes they myopically look at the trees and don’t see the forest, don’t step back to see the big picture to understand something is wrong at a high level. Also they can overoptimize to the test harness. They can also generate code that is not conceptually consistent with existing code.<\/p>\n
They can also generate much larger amounts of code than necessary. Some warn that that this will lead to explosion of coding debt. On the other hand, you can also guide the coding agent to refactor and improve its own code—quickly. In one case I’ve gotten it to reduce the size of one piece of code to less than half its original size with no change in behavior.<\/p>\n
I use OpenAI Codex rather than Claude Code.\u00a0 I’m glad to hear some technically credible people<\/a> think this a good choice. Though maybe I should try both.<\/p>\n
My work is a research project for which the code itself is the research product, so I can’t give specifications of everything in advance; writing the code itself is a process of discovery. Also, I want a code base that remains human-readable. So I am deeply involved in discussion with the coding agent that will sometimes go off to do a task for some period of time. It is not my desire to treat the agent as what some have called a dark software factory<\/a>.<\/p>\n
Some say they fear that using a coding agent will result in forgetting how to write code without one. I have felt this, but from having exercised this muscle for such a very long time I don’t think it is a skill I would easily forget. The flip side of this argument is, you might even learn new coding idioms from observing what the coding agent writes, that is a good thing.<\/p>\n
Some say they haven’t written a line of code in weeks because the coding agent does it for them. I don’t think I’ll ever stop writing code, any more than I will stop scribbling random ideas on the back of an envelope, or typing out some number of lines of code by which I discover some new idea in real time while I am typing. Learning is multisensory.<\/p>\n
My hat\u2019s off to the developers who are able to keep many different agents in flight at the same time. Personally I have difficulty handling the cognitive load of thinking deeply about each one and doing a mental context switch across many agents. Though I am experimenting with running more than one agent so I can be doing something while another agent is working.<\/p>\n
I continue to be astounded by productivity gains in some situations. I recently added a new capability, which normally I think would’ve taken me two months to learn a whole new algorithmic method and library to use. With the coding agent, it took me four days to get this done, on the order of 10X productivity increase. Though admittedly things are not always that rosy.<\/p>\n
In short, the tools are getting better and better. I’m looking forward to what they will be like a few months or a year from now.<\/p>\n","protected":false},"excerpt":{"rendered":"
AI coding agents improved greatly last summer, and again last December-January. Here are my experiences since my last post on the subject. The models feel subjectively much smarter. They can accomplish a much broader range of tasks. They seem to have a larger, more comprehensive in-depth view of the code base and what you are […]<\/p>\n","protected":false},"author":8,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[260,238,16],"tags":[322,274,323],"class_list":["post-246930","post","type-post","status-publish","format-standard","hentry","category-ai","category-productivity","category-software-development","tag-codex","tag-openai","tag-software-tools"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.johndcook.com\/blog\/wp-json\/wp\/v2\/posts\/246930","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.johndcook.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.johndcook.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.johndcook.com\/blog\/wp-json\/wp\/v2\/users\/8"}],"replies":[{"embeddable":true,"href":"https:\/\/www.johndcook.com\/blog\/wp-json\/wp\/v2\/comments?post=246930"}],"version-history":[{"count":0,"href":"https:\/\/www.johndcook.com\/blog\/wp-json\/wp\/v2\/posts\/246930\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.johndcook.com\/blog\/wp-json\/wp\/v2\/media?parent=246930"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.johndcook.com\/blog\/wp-json\/wp\/v2\/categories?post=246930"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.johndcook.com\/blog\/wp-json\/wp\/v2\/tags?post=246930"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}},{"id":246980,"date":"2026-04-20T08:50:33","date_gmt":"2026-04-20T13:50:33","guid":{"rendered":"https:\/\/www.johndcook.com\/blog\/?p=246980"},"modified":"2026-04-20T08:50:33","modified_gmt":"2026-04-20T13:50:33","slug":"newton-diameter-quintic","status":"publish","type":"post","link":"https:\/\/www.johndcook.com\/blog\/2026\/04\/20\/newton-diameter-quintic\/","title":{"rendered":"More on Newton’s diameter theorem"},"content":{"rendered":"
A few days ago I wrote a post on Newton’s diameter theorem<\/a>. The theorem says to plot the curve formed by the solutions to f<\/em>(x<\/em>, y<\/em>) = 0 where f<\/em> is a polynomial in x<\/em> and y<\/em> of degree n<\/em>. Next plot several parallel lines that cross the curve at n<\/em> points and find the centroid of the intersections on each line. Then the centroids will fall on a line.<\/p>\n
The previous post contained an illustration using a cubic polynomial and three evenly spaced parallel lines. This post uses a fifth degree polynomial, and shows that the parallel lines need not be evenly spaced.<\/p>\n
In this post<\/p>\n
f<\/em>(x<\/em>,\u00a0y<\/em>) = y<\/em>\u00b3 + y<\/em> \u2212 x<\/em> (x<\/em> + 1) (x<\/em> + 2) (x<\/em> \u2212 3) (x<\/em> \u2212 2).<\/p>\n
Here’s an example of three lines that each cross the curve five times.<\/p>\n
<\/p>\n
The lines are\u00a0y<\/em> =\u00a0x<\/em> +\u00a0k<\/em> where\u00a0k<\/em> = 0.5, \u22120.5, and \u22123. The coordinates of the centroids are (0.4, 0.9), (0.4, -0.1), and (0.4, -2.6).<\/p>\n
And to show that the requirement that the lines cross five times is necessary, here’s a plot where one of the parallel lines only crosses three times. The top line is now\u00a0y<\/em> =\u00a0x<\/em> + 2 and the centroid on the top line moved to (0.0550019, 2.055).<\/p>\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
A few days ago I wrote a post on Newton’s diameter theorem. The theorem says to plot the curve formed by the solutions to f(x, y) = 0 where f is a polynomial in x and y of degree n. Next plot several parallel lines that cross the curve at n points and find the […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[9],"tags":[],"class_list":["post-246980","post","type-post","status-publish","format-standard","hentry","category-math"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.johndcook.com\/blog\/wp-json\/wp\/v2\/posts\/246980","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.johndcook.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.johndcook.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.johndcook.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.johndcook.com\/blog\/wp-json\/wp\/v2\/comments?post=246980"}],"version-history":[{"count":0,"href":"https:\/\/www.johndcook.com\/blog\/wp-json\/wp\/v2\/posts\/246980\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.johndcook.com\/blog\/wp-json\/wp\/v2\/media?parent=246980"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.johndcook.com\/blog\/wp-json\/wp\/v2\/categories?post=246980"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.johndcook.com\/blog\/wp-json\/wp\/v2\/tags?post=246980"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}},{"id":246976,"date":"2026-04-18T09:49:27","date_gmt":"2026-04-18T14:49:27","guid":{"rendered":"https:\/\/www.johndcook.com\/blog\/?p=246976"},"modified":"2026-04-18T10:28:31","modified_gmt":"2026-04-18T15:28:31","slug":"qlora","status":"publish","type":"post","link":"https:\/\/www.johndcook.com\/blog\/2026\/04\/18\/qlora\/","title":{"rendered":"Gaussian distributed weights for LLMs"},"content":{"rendered":"
The previous post<\/a> looked at the FP4<\/strong> 4-bit floating point format. This post will look at another 4-bit floating point format, NF4<\/strong>, and higher precision analogs. NF4 and FP4 are common bitsandbytes 4-bit data types. If you download LLM weights from Hugging Face quantized to four bits, the weights might be in NF4 or FP4 format. Or maybe some other format: there’s a surprising amount of variety in how 4-bit numbers are implemented.<\/p>\n
Why NF4<\/h2>\n
LLM parameters have a roughly Gaussian distribution, and so evenly spaced numeric values are not ideal for parameters. Instead, you’d like numbers that are closer together near 0. <\/p>\n
The FP4 floating point numbers, described in the previous post, are spaced 0.5 apart for small values, and the larger values are spaced 1 or 2 apart. That’s hardly a Gaussian distribution, but it’s closer to Gaussian than a uniform distribution would be. NF4 deliberately follows more of a Gaussian distribution.<\/p>\n
QLoRA<\/h2>\n
The QLoRA formats [1], unlike FP4, are not analogs of IEEE numbers. The bits are not interpreted as sign, exponent, and mantissa, but rather as integers to be used as indexes. An NFn<\/em> number is an index into a list of 2n<\/em><\/sup> real numbers with Gaussian spacing. To put it another way, the numbers represented by NFn<\/em> have uniformly distributed z<\/em>-scores. <\/p>\n
That makes sense at a high level, but the paper [1] is hard to follow in detail. It says<\/p>\n
More formally, we estimate the 2k<\/em><\/sup> values q<\/em>i<\/em><\/sub> of the data type as follows:<\/p>\n
\"q_i<\/p>\n
where Q<\/em>X<\/em><\/sub>(\u00b7) is the quantile function of the standard normal distribution N<\/em>(0, 1).<\/p><\/blockquote>\n
The paper doesn’t give the range of i<\/em> but it says there are 2k<\/em><\/sup> values, implying that i<\/em> runs from 0 to 2k<\/em><\/sup> \u22121 or from 1 to 2k<\/em><\/sup>. Either way runs into infinite values since Q<\/em>(0) = \u2212\u221e and Q<\/em>(1) = \u221e. We could avoid infinities by letting i<\/em> run from 1 to 2n<\/em><\/sup> \u2212 1.<\/p>\n
The next sentence is puzzling.<\/p>\n
A problem for a symmetric k-bit quantization is that this approach does not have an exact representation of zero, which is an important property to quantize padding and other zero-valued elements with no error.<\/p><\/blockquote>\n
I understand the desire to represent 0 exactly, but the equation above has an exact representation of 0 when i<\/em> = 2n<\/em> \u2212 1<\/sup>. Perhaps the authors had in mind that i<\/em> takes on the values \u00bd, 1 + \u00bd, 2 + \u00bd, \u2026, 2n<\/em><\/sup> \u2212 \u00bd. This would be reasonable, but a highly unusual use of notation. It seems that the real problem is not the lack of a representation of 0 but an unused index, with i<\/em> running from 1 to 2n<\/em><\/sup> \u2212 1.<\/p>\n
To be fair, the first sentence quoted above says “we estimate<\/em> the 2k<\/em><\/sup> values …” and so the equation above may not be intended as a definition but as motivation for the actual definition.<\/p>\n
Reproducing NF4<\/h2>\n
The authors give a procedure for using 2n<\/em><\/sup> values of i<\/em> and obtaining an exact representation of 0, and they give a list of NF4 values in Appendix E. I was not able to get the two to match. I implemented a few possible interpretations of the procedure described in the paper, and each approximates the list of values in the appendix, but not closely.<\/p>\n
The following code, written with the help of ChatGPT, reverse engineers the NF4 values to 8 decimal places, i.e. to the precision of a 32-bit floating point number.<\/p>\n
\r\nfrom scipy.stats import norm\r\n\r\nQ = norm.ppf\r\n\r\n\u03b1  = 0.9677083\r\nZ  = Q(\u03b1)\r\n\u03b41 = (\u03b1 - 0.5)\/7\r\n\u03b42 = (\u03b1 - 0.5)\/8\r\n\r\nq = [0]*16\r\nfor i in range(7):\r\n    q[i] = -Q(\u03b1 - i*\u03b41)\/Z\r\nfor i in range(8):\r\n    q[i+8] = Q(0.5 + (i+1)*\u03b42)\/Z\r\n    \r\n# Values given in Appendix E\r\nNF4 = [\r\n    -1.0,\r\n    -0.6961928009986877,\r\n    -0.5250730514526367,\r\n    -0.39491748809814453,\r\n    -0.28444138169288635,\r\n    -0.18477343022823334,\r\n    -0.09105003625154495,\r\n    0.0,\r\n    0.07958029955625534,\r\n    0.16093020141124725,\r\n    0.24611230194568634,\r\n    0.33791524171829224,\r\n    0.44070982933044434,\r\n    0.5626170039176941,\r\n    0.7229568362236023,\r\n    1.0\r\n]\r\n\r\n# Compare \r\nfor i in range(16):\r\n    print(i, NF4[i] - q[i])\r\n<\/pre>\n
The magic number \u03b1 = 0.9677083 is a mystery. I asked ChatGPT to look into this further, and it said that bitsandbytes uses \u03b1 = 929\/960 = 0.9677083333333333. When I use this value for \u03b1 the precision is about the same, which is fine. However, the values in the paper were given to 16 decimal places, so I thought it might be able to match the values to more precision.<\/p>\n
Quibbles over the exact values of NF4 aside, the NF4 format works well in practice. Models. quantized to 4 bits using NF4 perform better than models quantized to other 4-bit formats on some benchmarks.<\/p>\n
Related posts<\/h2>\n