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

longlong-double-fix resurrection part 1 #52

Merged
merged 22 commits into from Mar 13, 2015
Merged

longlong-double-fix resurrection part 1 #52

merged 22 commits into from Mar 13, 2015

Conversation

mohawk2
Copy link
Member

@mohawk2 mohawk2 commented Mar 2, 2015

No description provided.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.0%) to 51.84% when pulling fbbfbe8 on lldfp1 into aea6254 on master.

1 similar comment
@coveralls
Copy link

Coverage Status

Coverage increased (+0.0%) to 51.84% when pulling fbbfbe8 on lldfp1 into aea6254 on master.

@mohawk2
Copy link
Member Author

mohawk2 commented Mar 3, 2015

Temporary close because Travis fouls up with race condition when both branch and PR.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 50.23% when pulling ac82533 on lldfp1 into aedd1ea on master.

pdlctype => 'PDL_Anyval',
realctype => 'double',
ppforcetype => 'anyval',
usenan => 0, # chm set this to 1, but then get compile error
Copy link
Member

Choose a reason for hiding this comment

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

This comment needs to be more descriptive or at least the underlying issue should be looked at.

@zmughal
Copy link
Member

zmughal commented Mar 10, 2015

The changes in this look good to me. And it seems to increase the code coverage.

Craig DeForest and others added 18 commits March 13, 2015 15:17
This first implementation has the actual ctype still being double.
The idea is to replace all PDL_Double usages by PDL_Anyval to
make sure nothing breaks.  Then change the implementation of the
PDL_Anyval C type.

Ed J modified chm's code to set new type's "usenan" to 0, not 1
Since PDL_Anyval is currently the same as double,
this should be a no-op...all tests still pass.
generic_qsort, generic_qsortvec, generic_qsort_ind, and
generic_qsortvec_ind needed A added to the list of types to
generate.  For the underlying type-specific pdl_qsort*
routines I used the corresponding pdl_qsort_*_D for now.
This will need modification once the new PDL_Anyval type
is introduced.
This should be consistent with the usage for the
other PDL data types.  What to do with the 8bytes
and endian issues TBD.
WARNING: there are 2 different typemap files in Basic/Core
which is confusing.  It seems that they both need pretty
much the same entries.  The difference being that in the
typemap.pdl file the usage for the PDL specific routines
is given with class syntax (why?)
This is for setting any type of PDL value.  Original
code assumed (double) worked for everything.  Now we
need to handle (64bit ints) as well.
@zmughal
Copy link
Member

zmughal commented Mar 13, 2015

It looks good to me. Just waiting on Travis.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 50.29% when pulling 911ad92 on lldfp1 into 4b77820 on master.

@mohawk2 mohawk2 merged commit 911ad92 into master Mar 13, 2015
@mohawk2 mohawk2 deleted the lldfp1 branch March 13, 2015 17:52
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 this pull request may close these issues.

None yet

4 participants