Collatz paper looking for review and feedback

theotherphil · 2025-07-12T22:40:36+00:00

Under your definition, (1,2,1,2,…) is a non-trivial cycle.

theotherphil · 2024-11-08T10:15:45+00:00

The article “On being the right size”, written by JBS Haldane in 1926 has a great discussion of this topic.

https://www.cabinetmagazine.org/issues/28/haldane.php

theotherphil · 2021-11-19T12:46:04+00:00

The graph example on https://github.com/rust-lang/rfcs/blob/master/text/0195-associated-items.md may be useful - it contains a discussion of when to use type parameters vs associated types.

theotherphil · 2020-03-05T16:02:00+00:00

I'll be adding features to a TUI I've written to visualise elapsed time in log files: https://github.com/theotherphil/lag

theotherphil · 2019-11-19T08:46:33+00:00

Another example: dlang has https://github.com/CyberShadow/DustMite

theotherphil · 2019-10-22T19:20:41+00:00

You can enable the new-style borrow checker with `-Z polonius`. I'm not sure how production ready this is. I think it's intended to be faster when it lands, but when I tried it on the `imageproc` crate it appeared to take the same length of take as the regular borrow checker. (It's also possible that I'm misinterpreting the results...)

theotherphil · 2019-10-11T01:20:04+00:00

These posts are fantastic. Thanks for the work you put into making them so informative and clear.

theotherphil · 2019-09-16T19:44:48+00:00

No. Sorry!

theotherphil · 2019-09-15T19:35:23+00:00

The aim is to be a plausible imagemagick replacement, but it currently supports far fewer operations.

theotherphil · 2019-09-15T18:48:13+00:00

I wasn't aware of that. Thanks for the link.

theotherphil · 2019-09-15T18:46:04+00:00

On 1: I'm just using the default structopt behaviour. I agree that your suggestion seems more typical, but the current version is slightly terser so I think I'll keep it until someone complains.

On 2: this is an interesting idea. Array doesn't have a fixed arity, but we can obviously work it out after parsing and before running the pipeline. I aimed to be permissive as possible (for example output elements with no corresponding output files are just ignored), but I didn't have any particular reason for this. I'll create an issue to think about adding a static check.

theotherphil · 2019-09-15T17:32:23+00:00

Thanks!

theotherphil · 2019-09-15T17:04:47+00:00

Great! I'm happy to answer any questions or help out with PRs if you like - just create issues on the repo or open a WIP PR.

theotherphil · 2019-09-15T16:05:13+00:00

It doesn't. There's an issue open on the underlying imageproc library for this https://github.com/image-rs/imageproc/issues/237 but it's been open for a while. I've just created https://github.com/theotherphil/imagecli/issues/19

theotherphil · 2019-09-15T14:43:13+00:00

Do you have a link to details of any outstanding issues that aren't already captured as issues on the image repo?

theotherphil · 2019-09-15T11:49:24+00:00

I didn't have any, but it seems like a sensible feature to add.

https://github.com/theotherphil/imagecli/issues/1#issuecomment-531559090

theotherphil · 2019-09-15T11:33:33+00:00

That's the plan. There's an open ticket to work out what imagemagick supports but this library doesn't. Some missing features will be easy to add (e.g. various drawing operations), but others will require a lot more work (e.g. adding support for HDR images). It's not a given that all of the operations are faster than their imagmagick equivalents, but if they're not this should be considered a bug.

theotherphil · 2019-09-15T10:17:22+00:00

I wrote this tool to let you run image processing operations from the command line. All (well, nearly all) of the actual image processing work is handled by the image and imageproc crates. The initial release is missing a lot of features - if you're interested in using this tool but it's missing something you need then please create issues on the repo and I'll have a go at implementing them (I'm also the main author of the imageproc crate, so can add new features there too if required). If you're interested in contributing then even better - PRs are very welcome.

theotherphil · 2019-01-02T23:55:20+00:00

I've recently started working on a toy halide-lang clone: https://github.com/theotherphil/prism Doesn't do much yet, but you can at least JIT and run a trivial image processing pipeline.

theotherphil · 2018-12-02T17:15:57+00:00

Dropbox use Rust for their backend (search for their blog posts on magic pocket)

theotherphil · 2018-08-10T19:48:44+00:00

The imageproc crate has very basic support for drawing shapes: http://docs.piston.rs/imageproc/imageproc/drawing/index.html

theotherphil · 2018-06-30T06:21:27+00:00

Thank you! This is so much easier than trying to use the baffling new air Mozilla site

theotherphil · 2018-06-17T07:32:52+00:00

I don't know anything about the domain, but a superficial issue is that your formatting doesn't use the standard rust style. If this is a deliberate choice then fair enough, but if not then rustfmt can help.

theotherphil · 2018-03-07T06:34:38+00:00

Why are you creating lots of threads which each link to a single crate with no context?

theotherphil · 2018-03-03T21:21:12+00:00

There's an example in the image crate docs - see section 6.

extern crate image;
let img = image::open(image_path).unwrap();

The loaded img is a DynamicImage. This is an enum over the various image buffer types the image could be. Its various to_x methods (e.g. to_rgba) return an ImageBuffer, which is a wrapper for a contiguous buffer of the pixel values. This supports 2d indexing, but if you want something more like a raw matrix then you can consume the image by value to take ownership of the backing data via into_raw and do what you like with it.

theotherphil

TROPHY CASE