[libre-riscv-dev] div/mod algorithm written in python

[Luke Kenneth Casson Leighton]

On Thu, Jul 25, 2019 at 4:10 PM Jacob Lifshay <programmerjake at gmail.com> wrote:

> >  yehyeh, i got it - i thought about doing that, and how if there was
> > fp128 it could be used for all of them.  hmm...
> >
> I built about half of a quadratic numbers (numbers of form (a+sqrt(b))/c
> where a,b,c are integers) implementation in Rust, decided full general
> algebraic numbers are too complicated to implement now. once that's done,
> since it represents the results of add/sub/mul/div/sqrt/rsqrt exactly, we
> can use it to implement all those fp ops with all the rounding modes pretty
> trivially. will be building rust to python bindings for the quadratic
> numbers lib.

nice.

> > you ran autopep8, didn't you? :)  i like lining up comments, however
> > it's not pep8-compliant.
> >
> i did -- it's on by default for the ide i'm using.

 ok :)

> >
> > couple of spaces have been added (on the end of lines), like the
> > addition of the names (pain in the neck having z$0 z$1 z$2),
> >
> > > Would you consider this good enough to declare the frsqrt, fsqrt, and
> > > fdiv bugs resolved for now?
> >
> >  once the unit tests have been re-run (minimum 20,000 random runs,
> > increase n_vals=1000 on the "coverage" tests), yes.  i can run some of
> > them, if you do others.
> >
> i'll set it up to run them while I sleep, probably 100k. one of the tests
> failed due to a bad import path when using pytest.

 sorted, do a git pull.  doesn't really need to be run, test_div64.py
is the [old] FSM.  i'd kinda like to keep the FSM code around (and
running) because they're way _way_ easier to understand.

> the coverage tests need to be split up into separate top-level test
> functions since that's the level that the tests are parallelised by
> pytest-xdist (see test_core.py for examples). they run several times as
> long as the others and only use a few of my 12 hw threads to do that.

 12!  :)