From 058f485bfd27e292d7e6e9da947f04857f2aaf26 Mon Sep 17 00:00:00 2001 From: snoppy Date: Fri, 19 Apr 2024 15:47:47 +0800 Subject: [PATCH] chore: fix typos Signed-off-by: snoppy --- src/starkware/algebra/fft/multiplicative_group_ordering.h | 4 ++-- src/third_party/poseidon/poseidon.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/starkware/algebra/fft/multiplicative_group_ordering.h b/src/starkware/algebra/fft/multiplicative_group_ordering.h index 2a1ba0e..4798944 100644 --- a/src/starkware/algebra/fft/multiplicative_group_ordering.h +++ b/src/starkware/algebra/fft/multiplicative_group_ordering.h @@ -22,11 +22,11 @@ namespace starkware { For our purpose the interesting ones are NaturalOrder - [1, w, w^2, w^3, ...] and BitReversedOrder [1, -1, w^{N/4}, -w^{N/4} ...] = [w^{bitrev(0)}, w^{bitrev(1)},w^{ bitrev(2), ..] - Diffrent FFT implementations have diffrent ordering requirements on the polynomial evaluations. + Different FFT implementations have different ordering requirements on the polynomial evaluations. This enum can be used to indicate which one is expected. Note that a polynomial evaluation is the output of and FFT and the input to the IFFT. - Since in-place radix2 fft implemenations have the side effect of BitReversal Permuation, + Since in-place radix2 fft implemenations have the side effect of BitReversal Permutation, The order of polynomial coefficents (== ifft output) will typically be the mirror order to the order of the evaluation. However in some cases we might prefer some other ordering, so one should look at the specific diff --git a/src/third_party/poseidon/poseidon.c b/src/third_party/poseidon/poseidon.c index 361155f..6a79a4c 100644 --- a/src/third_party/poseidon/poseidon.c +++ b/src/third_party/poseidon/poseidon.c @@ -254,7 +254,7 @@ void permutation_3_montgomery(felt_t state_in_montgomery_form[]) { } // Convert the state to reduced Montgomery form. If this is not done, values who are permutated - // multiple times might become numericly unstable and overflow from 256-bit, hence the transform + // multiple times might become numerically unstable and overflow from 256-bit, hence the transform // to the minimal representative. for (i = 0; i < 3; i++) { f251_final_reduce(state_in_montgomery_form[i], state_in_montgomery_form[i]);