Couple of typos in latest RandomX design.md ( https://github.com/tevador/RandomX/blob/1e9d4b2df63fa6edf46b06789486e23c0fcaa55a/doc/design.md )

[willy-b]

Hello RandomX team!

Thanks so much for this project and the excellent documentation.

In case it is useful, I wanted to alert the team to a couple of harmless typos in the design.md that may nonetheless distract some readers and thus may be of interest to correct:

• In the sentence (

  RandomX/doc/design.md

  Line 474 in 1e9d4b2

  1. Hash resuls were calculated and the final scratchpads were written to disk as files with '.spad' extension (source code: [scratchpad-entropy.cpp](../src/tests/scratchpad-entropy.cpp))

  )

  Hash resuls were calculated and the final scratchpads were written to disk as files with '.spad' extension (source code: scratchpad-entropy.cpp)

  "resuls" should be "results"

• In the sentence (

  RandomX/doc/design.md

  Line 487 in 1e9d4b2

  This shows that SuperscalaHash has quite low sensitivity to high-order bits and somewhat decreased sensitivity to the lowest-order bits. Sensitivity is highest for bits 3-53 (inclusive).

  )

  This shows that SuperscalaHash has quite low sensitivity to high-order bits and somewhat decreased sensitivity to the lowest-order bits. Sensitivity is highest for bits 3-53 (inclusive).

  "SuperscalaHash" should be "SuperscalarHash"

---

Also, just FYI, it is not part of this repo, but the Official Monero website page for RandomX ( https://www.getmonero.org/resources/moneropedia/randomx.html ) which links here has a broken article on RandomX:

• On https://www.getmonero.org/resources/moneropedia/randomx.html (archived as is at https://web.archive.org/web/20260601203521/https://www.getmonero.org/resources/moneropedia/randomx.html ), it says

  RandomX specifications and development can be found on the GitHub repository, while an article dedicated to RandomX made by the Outreach workgroup contains more information about the history of RandomX and its relation with Monero.

  where https://www.monerooutreach.org/stories/RandomX.html does not display any content on Firefox 150 on Linux, nor does it show properly in web.archive.org (archived as is at https://web.archive.org/web/20260530195834/https://www.monerooutreach.org/stories/RandomX.html ).

---

Thanks so much!

[willy-b]

Also

• In the sentence (
  

  RandomX/doc/design.md

  Line 166 in 1e9d4b2

  Rotation instructions are split between rotate right and rotate left with a 4:1 ratio. Rotate right has a higher frequency because some architecures (like ARM) don't support rotate left natively (it must be emulated using rotate right).

)

Rotate right has a higher frequency because some architecures (like ARM) don't support rotate left natively (it must be emulated using rotate right).

"architecures" should be "architectures".

Thanks!

[coffnix]

yo @willy-b could you fork the project, update the files, and submit a pull request for us? Thank you for your feedback and for taking the time to review everything.

[willy-b]

Sure!
There will be a short delay as I conduct additional review on my end to try to cover anything I may find in that first PR to the extent possible.

I can cover #339 as well if your team does not have any other objections. Thanks so much!

[willy-b]

Before sending a PR for mostly typos, some questions on content that may also benefit from being updated:

• In the sentences (

  RandomX/doc/design.md

  Line 180 in 1e9d4b2

  The domains of floating point operations are separated into "additive" operations, which use register group F and "multiplicative" operations, which use register group E. This is done to prevent addition/subtraction from becoming no-op when a small number is added to a large number. Since the range of the F group registers is limited to around `±3.0e+14`, adding or subtracting a floating point number with absolute value larger than 1 always changes at least 5 fraction bits.

  )

  RandomX uses five operations that are guaranteed by the IEEE 754 standard to give correctly rounded results: addition, subtraction, multiplication, division and square root. [...]
  The domains of floating point operations are separated into "additive" operations, which use register group F
  and "multiplicative" operations, which use register group E.
  This is done to prevent addition/subtraction from becoming no-op when a small number is added to a large number.
  Since the range of the F group registers is limited to around ±3.0e+14,
  adding or subtracting a floating point number with absolute value larger than 1 always changes at least 5 fraction bits.

  It seems "always changes at least 5 fraction bits" may not be established from the information provided (as for basic IEEE 754 FP64 addition/subtraction it doesn't seem true).

  Wouldn't adding 1, 2, or a small power of 2 change just 1 bit in the fraction/significand part in the example provided?
  E.g. for 3.0e14 (the example you provided), in IEEE 754 FP64, I think adding 2 which has an absolute value larger than 1 would change just 1 significand bit, the 6th least significant significand bit; or adding 1 would change a single bit, the 5th least significand bit:

  3.0e14 (design.md's existing example)     in IEEE 754 FP64: 
  100001011110001000011011001001100010110111011000000000000000000
  3.0e14 + 1 (design.md's existing example) in IEEE 754 FP64 (changes 1 bit, the 5th least fraction bit):
  100001011110001000011011001001100010110111011000000000000010000
  3.0e14 + 2 (design.md's existing example) in IEEE 754 FP64 (changes 1 bit, the 6th least fraction bit):
  100001011110001000011011001001100010110111011000000000000100000
  

  Is it possible it was intended to be "always changes at least the 5th least significant fraction/significand bit"?
  Rationale: the provided range 3e14 is about 2⁴⁸ and IEEE 754 has 53 bits of significand precision (52 bits explicitly, +1 implicit) meaning there are 5 bits (2 to the 5th power, or room to scale 3e14 by 32x more before adding 1 will not be visible), so "always changes at least the 5th least significant fraction/significand bit" would explain in detail why the range you claim ensures adding values with absolute value at least 1 will change at least 1 bit in the significand, and how close to the limit it is; changing in the 5th least significant position of the significand.)

  Or is there some added complexity due to the RandomX VM's 128-bit floating point registers containing a pair of floating points or some other detail not immediately clear here that leads to the "changes at least 5 fraction bits"?

  (If the above is true, then updating the text to say "absolute value at least 1" instead of "absolute value larger than 1" would also be more accurate, so I wouldd propose that in my PR if the above is confirmed.)

• In the sentences (

  RandomX/doc/design.md

  Line 351 in 1e9d4b2

  For `N` chained executions, the chance is only <code>Q<sup>N</sup></code> that all programs in the chain are acceptable. However, during each attempt to find such chain, we will waste the execution of some programs. For `N = 8`, the number of wasted programs per attempt is equal to <code>(1-Q)*(1+2\*Q+3\*Q<sup>2</sup>+4\*Q<sup>3</sup>+5\*Q<sup>4</sup>+6\*Q<sup>5</sup>+7\*Q<sup>6</sup>)</code> (approximately 2.5 for `Q = 0.75`).

  )

  For N chained executions, the chance is only Q^N that all programs in the chain are acceptable.
  However, during each attempt to find such chain, we will waste the execution of some programs.
  For N = 8, the number of wasted programs per attempt is equal to [...]

  should "the number of wasted programs per attempt is equal to" be "the expected number of wasted programs per attempt" as it is subject to chance? (Confirming that to make sure I understand what is being stated as I am double checking the formula you provide for this quantity.)
  (My PR will probably also propose replacing "find such chain" with "find such a chain".)

Thanks so much!