Skip to content

Releases: mroughan/SurrealNumbers.jl

Prep for a new generation of improvements.

24 Jul 07:26
Compare
Choose a tag to compare

Updated to work with up to Julia version 1.9.1 and removed old requirements. Sees to work now with version 1.1.0-1.9.1, but I haven't tested every minor version in between. Most functionality should work for versions down to 0.7, but I won't certify that, and there are few dependencies that seem likely to cause problems in future releases, so should work with later version too.

Incorporated the new package structures, e.g. Project.toml and Manifest.toml, with separate dependencies for test and examples directories.

Reorganised to make it more obvious where to find things, like the test code, and the output figures.

Cleaned up a few minor issues, such as using BigInts in the DAG stats code for the number of paths, which can become very large.

Otherwise smoothed out some rough edges ready for the next generation of improvements.

Dotting i's

25 Sep 06:20
Compare
Choose a tag to compare

Getting metadata details correct.

Faster again, plus a bug fix in size calculations (v0.0.5/6 reprise + Julia 1.0))

18 Sep 03:47
Compare
Choose a tag to compare

This version supports Julia 0.7 and 1.0.

There were some additional fixes. The main fix here is that caches were all storing their own versions of surreals for each case, e.g., for sums each x+y had a different entry. However, this is wasteful, so created a central list of all surreals, which with index into by the hashes, which are all that are stored in the indivudual caches now. This reduces the memory footprint, but had another side benefit, which is that in some places I was creating two "different" surreal forms, in the sense that different memory was being used even though the surreals were identical. For example 1+3 == 2 + 2 but these would each have resulted in identical sureals, but would have used two separate copies of the same surreal. Indexing with a level of redirection by hash avoids this issue. The results are faster, and use less memory, and calculations of size of resulting DAGs prior to this would have had an error.

Faster again, plus a bug fix in size calculations (v0.0.5 reprise + Julia 1.0))

17 Sep 06:13
Compare
Choose a tag to compare

The main fix here is that caches were all storing their own versions of surreals for each case, e.g., for sums each x+y had a different entry. However, this is wasteful, so created a central list of all surreals, which with index into by the hashes, which are all that are stored in the indivudual caches now. This reduces the memory footprint, but had another side benefit, which is that in some places I was creating two "different" surreal forms, in the sense that different memory was being used even though the surreals were identical. For example 1+3 == 2 + 2 but these would each have resulted in identical sureals, but would have used two separate copies of the same surreal. Indexing with a level of redirection by hash avoids this issue. The results are faster, and use less memory, and calculations of size of resulting DAGs prior to this would have had an error.

  • There was yet another little bug in 0.0.5 where memory wasn't reused properly in one specific case. This is now fixed, and the shorthands now report the operands used to construct a form as a means of tracing such bugs -- but makes it nice to understand the ops that created a surreal.

Faster again, plus a bug fix in size calculations

07 Sep 02:17
Compare
Choose a tag to compare

The main fix here is that caches were all storing their own versions of surreals for each case, e.g., for sums each x+y had a different entry. However, this is wasteful, so created a central list of all surreals, which with index into by the hashes, which are all that are stored in the indivudual caches now. This reduces the memory footprint, but had another side benefit, which is that in some places I was creating two "different" surreal forms, in the sense that different memory was being used even though the surreals were identical. For example 1+3 == 2 + 2 but these would each have resulted in identical sureals, but would have used two separate copies of the same surreal. Indexing with a level of redirection by hash avoids this issue. The results are faster, and use less memory, and calculations of size of resulting DAGs prior to this would have had an error.

0.7 compliant

10 Aug 07:05
Compare
Choose a tag to compare

Lots of change, mostly covered by

  • Julia 0.7 warnings and errors removed, heading towards a version for julia 1.0
  • added a better set of functions for getting metrics on the surreal numbers
  • many speed ups, and reductions in memory usage
  • removal of some old code
  • quite a few new examples, and tables of examples
    But there are quite a few minor changes throughout aiming at getting the code cleaner.

Still quite a few things I want to do here though, including some more hoped speed improvements via getting better at caching partial results.

Faster, better, but still not complete

06 Jun 04:54
Compare
Choose a tag to compare

The main changes in this release are
(1) faster implementations of many pieces, noting that (i) comparison is faster than subtraction, so straight-forward searches are faster than recursively iterating until we find solutions, and (ii) starting to use has tables to store previous results to avoid recomputing things again and again (this can be taken a lot further).
(2) Quite a bit of additional I/O, e.g., routines to read/write surreal numbers in a text (ascii) format similar to the way they are written in books, latex output, and output into DOT format of various graph versions of surreals.
(3) Changed several pieces to conform better to Julia standard style for, e.g., mathematical functions.

Also lots of other small changes and a few bug fixes for subtle problems that don't happen much of the time and a lot more tests.

Clean one

03 May 07:33
Compare
Choose a tag to compare

This is the first release I am reasonably happy is correct, and which includes most of what I plan to add, and has a proper README (which though overlong at least includes most of what I need).