blakehawkins / zdex

Evaluate Z-order indexing (morton encoding) for types, iterators, and tuples of BitCollections.

Zdex  

Evaluate Z-order indexing for types, iterators, and tuples of BitCollections.

See also morton_encoding.

Example

Here's a basic example using the built-in FromU8 BitCollection - see more examples in the docs.

use zdex::*;

fn main() -> Result<(), std::io::Error> {
  let v1: FromU8 = 0b0011.into();
  let v2: FromU8 = 0b1111.into();

  // Prints "Vob[01011111]".
  println!("{:?}", (v1, v2).z_index()?);

  Ok(())
}

zdex's Issues

API and speed are... problematic.

tl;dr Please, help me make both our crates better.

Hello! I'm John, creator and maintainer of rival crate "morton-encoding".

With the arrival of min-const-generics pretty soon, I wanted to refactor, and so I was doing some snooping around to see if there was anyone else who had implemented the same things. Thus, I chanced upon your crate, and decided to benchmark it. So I ran into...

Problem no. 1: The API is really, really hard to use with primitive types.
OK, time to get results from the crate. First try, [x1, x2].z_index()... No dice.
Maybe [x1, x2].iter().z_index()? Nope, that's not it either.
At this point, I gave up and did it with a tuple just as it shows in the documentation. But seriously, a tuple?! You want the user to input a certain quantity of homogeneous data, and your first idea is to use a generally heterogeneous type?
And don't even get me started on trying to transmute the result to a primitive type. Was result as Key too easy or something? Or was result.unwrap().iter_storage().fold(0 as Key, |acc, a| (acc<<usize_bits) | a as Key) the most ergonomic way you could manage? (Oh, and did I need to put a .rev() there or not? Who knows!)

Okay, fine. We've managed to make a function that takes an input ([u32; 2]) and gives a result (u64). That's something. Until, of course, I ran into...

Problem no. 2: The speed is low. Comically low. Abysmally, inexplicably low.
I ran cargo rustc --release --lib -- --emit asm and took a look at the emitted assembly.
Then, I called a crane to pick my jaw off the floor.
Then I wired it shut and looked again.
The one, single, paltry [u32; 2] -> u64 function ends up emitting three thousand lines of assembly. Half of those are the meat of the function, and several of those are function calls to the other half. I didn't have the courage to benchmark it.
For reference, the naïve implementation, that uses masks to check each bit and copy it to the result? Six hundred instructions. morton-encoding does it in less than 50.

I'd like it if similar crates could somehow be consolidated. For that reason, I have to ask: Sir, what problem are you trying to solve? What needs do you have that morton-encoding cannot cover? Because, from what I can see, it's far superior, and it's, like... right there. You can use it, either directly as a dependency or indirectly as inspiration.

Help me make both our crates better, please?

Vob is not ergonomic to transform into a primitive

See #8

z-indexes over heterogeneous BitCollections

(u16, f32).z_index() is not currently possible.

is_relevant and next_jump_in

From/Into/Deref should work nicely for primitive types into BitCollection<Item=BitU8>

Either (1u16, 1u8).z_index() (better), or (1u16.into(), 1u8.into()).z_index() (still good)

Congratulations, your code has made it to TDWTF

Thanks to #8 , it seems.
See here : https://thedailywtf.com/articles/put-in-order

Correct default BitCollection<Item=BitU8> impls for signed integers and floats

• bool
• char
• i8
• i16
• i32
• i64
• i128
• u8
• u16
• u32
• u64
• u128
• isize
• usize
• f32
• f64

ci: rustfmt + clippy

iterator over sub-ranges (Page Jump Querying heuristic)

add/fix crates.io tags