This is an automated email from the ASF dual-hosted git repository.
emkornfield pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/parquet-format.git
The following commit(s) were added to refs/heads/master by this push:
new 905c897 minor: fix typos (#536)
905c897 is described below
commit 905c89706004ee13a76c3df0f9fa4b1d583ddf9a
Author: emkornfield <[email protected]>
AuthorDate: Tue Dec 2 16:22:03 2025 -0500
minor: fix typos (#536)
---
BloomFilter.md | 6 +++---
Compression.md | 6 +++---
Encodings.md | 4 ++--
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/BloomFilter.md b/BloomFilter.md
index 2fa24e9..98ec685 100644
--- a/BloomFilter.md
+++ b/BloomFilter.md
@@ -170,7 +170,7 @@ unsigned int32 i = (h_top_bits * z_as_64_bit) >> 32;
```
The first line extracts the most significant 32 bits from `h` and
-assignes them to a 64-bit unsigned integer. The second line is
+assigns them to a 64-bit unsigned integer. The second line is
simpler: it just sets an unsigned 64-bit value to the same value as
the 32-bit unsigned value `z`. The purpose of having both `h_top_bits`
and `z_as_64_bit` be 64-bit values is so that their product is a
@@ -233,14 +233,14 @@ with a seed of 0 and [following the specification version
The `check` operation in SBBFs can return `true` for an argument that
was never inserted into the SBBF. These are called "false
-positives". The "false positive probabilty" is the probability that
+positives". The "false positive probability" is the probability that
any given hash value that was never `insert`ed into the SBBF will
cause `check` to return `true` (a false positive). There is not a
simple closed-form calculation of this probability, but here is an
example:
A filter that uses 1024 blocks and has had 26,214 hash values
-`insert`ed will have a false positive probabilty of around 1.26%. Each
+`insert`ed will have a false positive probability of around 1.26%. Each
of those 1024 blocks occupies 256 bits of space, so the total space
usage is 262,144. That means that the ratio of bits of space to hash
values is 10-to-1. Adding more hash values increases the denominator
diff --git a/Compression.md b/Compression.md
index 4b893c2..c1cad5d 100644
--- a/Compression.md
+++ b/Compression.md
@@ -65,7 +65,7 @@ that writers refrain from creating such pages by default for
better interoperabi
### LZO
A codec based on or interoperable with the
-[LZO compression library](http://www.oberhumer.com/opensource/lzo/).
+[LZO compression library](https://www.oberhumer.com/opensource/lzo/).
### BROTLI
@@ -91,11 +91,11 @@ switch to the newer, interoperable `LZ4_RAW` codec.
A codec based on the Zstandard format defined by
[RFC 8478](https://tools.ietf.org/html/rfc8478). If any ambiguity arises
when implementing this format, the implementation provided by the
-[ZStandard compression library](https://facebook.github.io/zstd/)
+[Zstandard compression library](https://facebook.github.io/zstd/)
is authoritative.
### LZ4_RAW
A codec based on the [LZ4 block
format](https://github.com/lz4/lz4/blob/dev/doc/lz4_Block_format.md).
If any ambiguity arises when implementing this format, the implementation
-provided by the [LZ4 compression library](http://www.lz4.org/) is
authoritative.
+provided by the [LZ4 compression library](https://www.lz4.org/) is
authoritative.
diff --git a/Encodings.md b/Encodings.md
index ea7e4e3..62b4eb9 100644
--- a/Encodings.md
+++ b/Encodings.md
@@ -176,7 +176,7 @@ repetition and definition levels.
Supported Types: INT32, INT64
This encoding is adapted from the Binary packing described in
-["Decoding billions of integers per second through
vectorization"](http://arxiv.org/pdf/1209.2137v5.pdf)
+["Decoding billions of integers per second through
vectorization"](https://arxiv.org/pdf/1209.2137v5.pdf)
by D. Lemire and L. Boytsov.
In delta encoding we make use of variable length integers for storing various
@@ -207,7 +207,7 @@ Each block contains
positive integers for bit packing)
* the bitwidth of each block is stored as a byte
* each miniblock is a list of bit packed ints according to the bit width
- stored at the begining of the block
+ stored at the beginning of the block
To encode a block, we will:
