You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Yes, you're completely right about this. Thank you for spotting this.
I'll admit this is a bit of bad API moment. I think my original intention was to only have geometric to facelet cube conversions. So implementing FaceletCube::from(faces) instead of FaceletCube::from(geometric_cube) was a poor design decision on my part.
But you also make a valid point, a correct implementation of FaceletCube::from(faces) would be necessary to allow solving of arbitrary cubes. So I will try fixing this.
I just ran into the very same problem. :-) If I have a Vec of moves, then the solver works fine, but if I init the facelet cube from a state I have in the real world, then the solver doesn't work.
How do you imagine implementing the conversion from a GeoCube for FaceletCube? Also, once we have that, then GeoCube would also need a way to be initialized from a real world state to resolve this issue, I guess. Thanks!
In cube.rs, the new function initializes as:
Effectively adding the number of the position of the original vec inside as extra info.
While on the from function:
Sets all indices to zero.
As a result, calling cubesim::solve(&cube) will always return None for cubes that are created with the from function instead of new.
This makes impossible to use this library for arbitrary cubes where we don't know the rotations made to get into that position.
The text was updated successfully, but these errors were encountered: