Skip to content
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

Convert assert to verify/test in math #259

Conversation

david-eckardt-sociomantic
Copy link
Contributor

I grouped them by topic:

  • Function argument validation and unittests are straight-forward.
  • Internal sanity checking are cases where assert might actually be correct but I'm not perfectly sure.
  • Conversion of assert(0) to static assert(0) is for functions that support x86-64 but had an assert(0) for some other unsupported architecture.
  • Conversion of assert(0) to throw new SanityException for disabled functions is for functions that don't support x86-64. static assert(0) cannot be used because the module wouldn't compile then. These functions are useless for us and should be removed (or fixed/extended to support x86-64 if it's worth it).
  • Extremely unlikely RNG conditions are obscure, take a look yourself.

Copy link

@gavin-norman-sociomantic gavin-norman-sociomantic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@@ -295,13 +295,6 @@ public class Distribution ( T )

auto index = cast(size_t)(fraction * (this.values.length - 1));

assert(index < this.values.length, "index greater than or equal to length of value list");

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Weird code!

@gavin-norman-sociomantic

Travis doesn't like it, though.

@david-eckardt-sociomantic
Copy link
Contributor Author

immutable strikes again.

./src/ocean/math/random/engines/URandom.d(95): Error: function ocean.core.Verify.verify (bool ok, lazy string msg = "", string file = FILE, int line = LINE) is not callable using argument types (bool, char[])

@codecov
Copy link

codecov bot commented Sep 18, 2017

Codecov Report

Merging #259 into v3.x.x will decrease coverage by <.01%.
The diff coverage is 84.32%.

@@            Coverage Diff             @@
##           v3.x.x     #259      +/-   ##
==========================================
- Coverage   71.83%   71.83%   -0.01%     
==========================================
  Files         459      459              
  Lines       38978    38976       -2     
==========================================
- Hits        28001    27999       -2     
  Misses      10977    10977

@codecov
Copy link

codecov bot commented Sep 18, 2017

Codecov Report

Merging #259 into v3.x.x will increase coverage by 0.02%.
The diff coverage is 83.91%.

@@            Coverage Diff            @@
##           v3.x.x    #259      +/-   ##
=========================================
+ Coverage   71.97%     72%   +0.02%     
=========================================
  Files         458     458              
  Lines       38842   38855      +13     
=========================================
+ Hits        27958   27979      +21     
+ Misses      10884   10876       -8

@david-eckardt-sociomantic
Copy link
Contributor Author

Updated.

@@ -321,7 +322,7 @@ private:
tmpval &=0xFFFF_FC00;
asm { ld tmpval, %fsr; }
*/
assert(0, "Not yet supported");
throw new SanityException("Not yet supported");

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shall we simply deprecate these functions? It is weird to keep code that does nothing but throwing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure. We could even just remove them because they are literally dead code, no user code can possibly call them.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's just follow usual procedure, no benefit in making exceptions :) New major should be soon enough for this to not matter.

@david-eckardt-sociomantic
Copy link
Contributor Author

Updated, deprecating functions that don't support x86-64.

@@ -307,6 +307,7 @@ private:
static assert(0, "Not yet supported");
}
}
deprecated
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could someone with x86 assembly language knowledge take a look at resetIeeeFlags(), please ( @don-clugston-sociomantic pr @nemanja-boric-sociomantic )? It seems to me it would work with x86-64 but uses an orphan version identifier.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems that that's still applicable even for x86-64 (as part of x87 FPU).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's right, there's no difference between x86 and x86-64 in this respect

@david-eckardt-sociomantic
Copy link
Contributor Author

Updated, trivially extending resetIeeeFlags to support x86-64.

@don-clugston-sociomantic
Copy link
Contributor

Just an observation: there are two very different things that are replaced with verify here. The ones which are in the BigIntInternalXXX functions are true asserts in the sense that Walter originally intended. They are only supposed to exist while unit tests are running. The ones which were in in contracts are enforce things which are actually expected to happen, and they need to stay in.

It's a nice example of the naivety of D's assert system.

Apart from that, LGTM.

@mihails-strasuns-sociomantic
Copy link
Contributor

@don-clugston-sociomantic yeah we talked about it some time before in core chat - all ocean will really need another pass checking which verify can really be an assert (and some may even be enforce in disguise). Right now agreement is to convert everything blindly to unblock D2 deployment of dhtnode and revisit things later with more educated approach :)

@mihails-strasuns-sociomantic mihails-strasuns-sociomantic merged commit 6302b1b into sociomantic-tsunami:v3.x.x Sep 21, 2017
@david-eckardt-sociomantic
Copy link
Contributor Author

@don-clugston-sociomantic, in addition to what @mihails-strasuns-sociomantic says, to address your concern I put the replacement of the different types of assertions in separate commits. See also my first PR comment.

@david-eckardt-sociomantic david-eckardt-sociomantic deleted the verify-math branch September 21, 2017 10:42
@don-clugston-sociomantic
Copy link
Contributor

Cool, that sounds completely reasonable to me. In fact most of the floating point functions should probably return NaN on invalid input parameters, which would sidestep the issue in a lot of cases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants