Skip to content

Commonizing code between Fixed and Normed #139

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
kimikage opened this issue Nov 18, 2019 · 5 comments · Fixed by #224
Closed

Commonizing code between Fixed and Normed #139

kimikage opened this issue Nov 18, 2019 · 5 comments · Fixed by #224

Comments

@kimikage
Copy link
Collaborator

kimikage commented Nov 18, 2019

Fixed and Normed have evolved independently. Therefore, some functions are specialized even though they do not need specialization.

cf. ee5bd54...kimikage:commonize PR #151

I'm going to refactor the codes by taking the following 3 steps.

  1. Commonize the existing implementation code
  2. Add the functions which are implemented only in either (e.g. rounding functions for Fixed)
  3. Commonize the test codes

Although "test-first" is a good practice, the step 3. requires major renovations. Please give me your advice if you have any ideas.

@kimikage

This comment has been minimized.

kimikage added a commit that referenced this issue Dec 30, 2019
Commonize code between `Fixed` and `Normed` (the first part of #139)
@kimikage
Copy link
Collaborator Author

Steps 1 and 2 are almost complete. Step 0 (the coding guidelines) is partially unfinished. Step 3 has not been started yet. I will keep this issue open until we have a concrete work plan.

@kimikage
Copy link
Collaborator Author

kimikage commented Jul 26, 2020

I thought the test code was difficult to commonize. However, as I'll add tests for arithmetic operations, I am not very satisfied with the current test code.

A practical problem is the long testing times. It's not fatal at the moment, but it should be an obstacle to supporting signed Normed in the future.
We spend the most part of the testing time compiling. Therefore, except the reduction of memory allocation, optimization techniques for "run-time" speed has almost no effect. So it's important to reduce the number of test cases, or target types.
Currently, 128-bit/64-bit types are tested, even though they are rarely used in practice. I believe that the reduction of the target type can be abstracted. For example, the following API can be considered:

julia> target(Normed, (:i8, :i16), :light)
(N7f1, N1f7, N0f8, N15f1, N9f7, N8f8, N7f9, N6f10, N5f11, N1f15, N0f16)

@kimikage kimikage reopened this Jul 26, 2020
@kimikage
Copy link
Collaborator Author

We can use include to do things like mix-in, but the unit of common reusable test sets are per file. That is incompatible with ”partially" commonizable test sets. @includetests of TestSetExtensions.jl also have the same problem.

I devised (ugly) small macros like this:
https://github.com/kimikage/CommonTests.jl

The pair of macros @common and @runcommon use the names of the test sets to map the caller to the callee. However, I think there is a more elegant way.

@kimikage
Copy link
Collaborator Author

The support for checked basic four operations is almost complete. Now that I know that those 100% tests are common to Fixed and Normed, I would like to commonize their codes. However, I'm not going to introduce any tricky macros, but simply write functions.

This was referenced Aug 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant