Talk:Floating-point arithmetic

Lead section edits

I edited the lead section to try to tidy it up in the following ways:

- Previously the opening sentence was "In computing, floating-point arithmetic (FP) is arithmetic using formulaic representation of real numbers as an approximation to support a trade-off between range and precision." I found this opaque (what is "arithmetic using formulaic representation"?) and oblique (it doesn't tell you what a floating-point number is, it only talks about an attempted "trade-off"). I think Wikipedia articles should open by defining the thing at hand directly, rather than talking around it. Therefore, the new opening sentence explicitly describes floating-point representation: "In computing, floating-point arithmetic (FP) is arithmetic that represents real numbers approximately, using an integer with a fixed precisison, called the mantissa, scaled by an integer exponent of a fixed base."

- Both "significand" and "mantissa" are used to describe the non-exponent part of a floating-point number, but "mantissa" is far more common, so I think it's the better choice. (Google: "floating-point mantissa" yields 672,000 results; "floating-point significand" yields 136,000 results).

- Previously, the topic of the large dynamic range of floating-point numbers was mentioned twice separately; these mentions have been merged into a single paragraph.

- The links for examples of magnitude are changed to point to the actual examples mentioned (galactic distances and atomic distances).

Feel free to discuss here. — Ka-Ping Yee (talk) 23:31, 12 October 2022 (UTC)

Schubfach is not WP:OR

I'm not quite sure why some of you consider Schubfach as WP:OR. Several implementations have been around for several years already, in particular it has been already adopted to Nim's standard library a year ago and working fine. It's true that the article is not formally reviewed, but honestly being published in a peer-reviewed conference/journal does not necessarily give that much of credit in this case. For example, one of the core parts (minmax Euclid algorithm) of the paper on Ryu contains a serious error, and this has been pointed out by several people, including Nazedin (a core contributor to Schubfach) if I recall correctly.

The main reason why Schubfach paper has not been published in a peer-reviewed journal, as far as I remember, is not because the work has not been verified, rather simply because the author didn't feel any benefit of going through all the paper works for journal publishing (things like fitting into the artificial page limit). The reason why it is still not accepted in OpenJDK (is it? even if it's not merged yet, it will make it soon) is probably because of lack of human resource who can and are willing to review the algorithm, and submitting the paper to a journal does not magically create such a human resource. (Of course they will do some amount of review, but it is very very far from being perfect, which is why things like the errors in the Ryu paper have not been caught in the review process.)

The point is, Schubfach as an algorithm has already been completed a long time ago, like in 2017 as far as I believe, and at least two implementations (one in Java and one in C++) have been around at least since 2019, and the C++ one has been adopted to the standard library of a fairly popular language (Nim), and you can even find several more places where it has been adopted (Roblox, a very popular game in US, for example). So what really is a difference from Ryu? The only difference I can tell is that Ryu has a peer-reviewed journal paper, but as I elaborated, that isn't that big difference as far as I can tell. You also mentioned about new versions of the paper, and I felt like as if you think Schubfach is sort of a WIP project. If that's the case, then no, the new versions are just minor fixes/more clarifications rather than big overhauls. If Ryu paper were not published in a journal, probably the author of Ryu would have done the same kind of revisions (and fixed the error mentioned).

In summary, I think at this point Schubfach is definitely an established work which has no less credibility compared to Ryu and others. 2600:1700:7C0A:1800:24DF:1B93:6E37:99D2 (talk) 01:09, 10 November 2022 (UTC)

In the mean time, I've learned by e-mail that the paper got a (possibly informal) review by serious people. So, OK to re-add it, but it is important to give references showing that it is used. And please, give the latest version of the paper and avoid typos in the WP text. And instead of "Apparently", try to give facts (i.e., what is really meant by "apparently"). Thanks. — Vincent Lefèvre (talk) 01:26, 10 November 2022 (UTC)

Digits of precision, a confusing early statement

I have removed the portion after the ellipses from the following text formerly found in the article: "12.345 is a floating-point number in a base-ten representation with five digits of precision...However, 12.345 is not a floating-point number with five base-ten digits of precision." I recognize the distinction made (a number with 5 base-ten digits of precision vs. a base-ten representation of a number with five digits of precision) and I suspect the author intended to observe that a binary representation of 12.345 would not have five base-ten digits of precision, but I can't divine what useful thing is intended to have been communicated there, so I've removed it. If I'm missing something obvious in the interpretation of this line, I suspect many others could, and encourage a more direct explanation if it's replaced. john factorial (talk) 18:44, 24 July 2023 (UTC)

The sentence was made nonsensical by this revision by someone who mistook 12.3456 for a typo rather than a counterexample: http://en.wiki.x.io/w/index.php?title=Floating-point_arithmetic&diff=prev&oldid=1166821013

I have reverted the changes, and added a little more verbiage to emphasize that 12.3456 is a counterexample. Taylor Riastradh Campbell (talk) 20:56, 24 July 2023 (UTC)

Computable reals

Concerning Special:Diff/1234874429, I want to thank User:Vincent_Lefèvre for fast response. I agree that mentioning real closed field is off-topic. However, I still have a strong impression that computable reals should be listed as a separate bullet. I believe it is different from symbolic computation. I mean that arithmetic operations are not “aware” of $\pi$ being $\pi$. Should I just propose a new edit? Korektysta (talk) 20:50, 17 July 2024 (UTC)

@Korektysta: Yes, but then, the first sentence of the section (before the list) should avoid the term "representing". It should rather talk about the arithmetic (which is some kind of representation and a way of working with it). BTW, I think that the list of alternatives to floating-point numbers should come later in the article, not in the first section. — Vincent Lefèvre (talk) 11:51, 20 July 2024 (UTC)

I had to think for a moment, but I still believe that computable reals constitute a separate representation. As far as I remember, the CoRN library does not remember the computation tree, but real numbers are represented as functions.

I agree that the subsection could be moved. For example, from the overview to the end of the article, just before See also as a separate section. Korektysta (talk) 22:56, 1 August 2024 (UTC)

Ah, OK. Effectively, the arithmetic builds the computation tree, but it is opaque for the user. I guess that the treatment of leafs in the tree is also different because there is no special constant for $\pi$. $\pi$ is just another function. Korektysta (talk) 04:49, 2 August 2024 (UTC)