Talk:Saturation arithmetic
![]() | This article has not yet been rated on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||
|
Tone of article
[edit]Perhaps this article might be improved by revising wording: "familiar properties ", "This makes it unpleasant to deal with", "easier-to-implement", "However, although more difficult to implement, ", "it's considerably less surprising to get an answer of 127 instead of 130 than to get an answer of −126 instead of 130" ,"In the words of ","modern platforms", " wider versions ", "This helps programmers anticipate and understand the effects of overflow better", "On the other hand, saturation is challenging to implement efficiently in software on a machine with only modular arithmetic operations, since simple implementations require branches that create huge pipeline delays."
DGerman (talk) 21:14, 8 July 2014 (UTC)
I thought so too. I wondered how the articles suggests that saturated arithmetics would be "difficult" or "less modern" although that's wrong today I think. Most "modern" microprocessors built into daily devices (of the last 10 years) fall into the group of ARM + Intel (don't know about AMD but it probably has that too) which do have saturated arithmetics and I think, saturated arithmetics is more widely available in "modern" processors than not, or at least it really should be. The small circuit overhead (which is not difficult at all) really justifies the practical use of saturation and since ALUs allow for much more overhead-operations than just saturated addition, it should take no speed penalty to implement saturated arithmetics. If just Nintendo would have used saturated addition in their games, there would be millions of "bugs" less in their earlier games. Saturated arithmetics just by itself would increase security of software, reduces glitches and increases safety in program behavior. It's strange that it's still considered a "signal-processing" feature although it seems to me as universally better "overflow" handling, at least for 64-bit arithmetics using a positive and negative infinity value. 2001:16B8:C26B:9900:6CAD:8BAF:D589:2E35 (talk) 16:24, 11 April 2021 (UTC)
Citation example
[edit]An citation example might be enough from the next link of the GNU Compiler Collection.
Cafeduke (talk) 07:02, 4 March 2018 (UTC)
Examples missing
[edit]If the valid range of values is from −100 to 100, then at least one example should show negative result (>= -100). As is the examples suggest valid results from 0 to 100 only. (60 + 43) − (75 + 75) → 0. (not the expected −47.) (100 − 100 → 0.) almost led me to claim the example being wrong (it is not, merely a poor choice). There should be some 60 - (75 + 75) = -40 example IMHO. LinguistManiac (talk) 11:21, 23 March 2021 (UTC)