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

Add datatype invalid #193

Closed
wants to merge 22 commits into from
Closed

Add datatype invalid #193

wants to merge 22 commits into from

Conversation

d-lamb
Copy link
Member

@d-lamb d-lamb commented Aug 22, 2016

See comments for commit f06ae90.

d-lamb and others added 22 commits June 7, 2016 07:48
The original regexp took 'unsigned short *' and captured only the
'short'. This changed allows it to capture 'unsigned short'.
Since fitgauss1d[r] has GenericTypes=>[D], it is safe to assume
that everything will be Double, so using fabs is preferred.
The switch statement was written long before those datatypes were
in PDL, and the compiler was nicely complaining about their absense.
Perl's 'warn' function had been undef'd because of problems with the gsl code's
'warn' variable. But PDL::PP inserts code into XS files that calls
Perl's 'warn' function.  To avoid this I removed the #undef warn and
changed the gsl variable name from warn to gslwarn.
Some function prototypes that get generated into SlatecProtos.h
have return types float or double, but most were just missing, and
the compiler assumed them to be int. The function defs all do
return int, so I just made it explicit.
A few functions (SDstart ... SDend) did not have function prototypes
in hdf.h, this other header file was necessary.
The list is generated by Types.pm.PL, but gets put into pdl.h and
pdlsimple.h. This was motivated by code in Bad.c that assigns to
a variable of type pdl_datatypes the value -1 (in some error condition
that is unlikely to be reached). This jives with the ANYVAL_FROM_CTYPE
macro in pdl.h.  Thanks to Chris Marshall and David Mertens for the
pointers.  See pdl-devel 2016-05-05 discussion.
This reverts commit f51309e.

I committed it to the wrong branch. Should be on clang_warnings instead.
If a user mistakenly passed a perl scalar argument to qsort and
its ilk, the SV would be mistaken for a piddle and passed to
the underlying generic_qsort etc routines. Not surprisingly,
those routine's array index tricks would cause a segfault. This
commit causes qsort, qsorti, qsortvec, and qsortveci to barf
if an argument is passed with incorrect dimensions.

Some care is taken to allow trivial sorts.

2 tests for each routine have been added, and some existing
tests labeled.
Hopefully this will compile on Strawberry. Not sure why the original
worked OK on my Mac w/ clang.
The changes in <#188> broke the
build for all cases of `BADVAL_USENAN` xor `BADVAL_PER_PDL`.

This was because the checking for badvalues when copying in
`pdl_kludge_copy_*` did not take into account these variations in
accessing and setting the badvalue.

For example, a simple comparison using `==` is not valid when NaN
values are being compared. Here we need to use `!finite(...)` to make
the comparison if the type can use NaN values.
The example in the docs was using the matrix v directly instead of
the transpose.  Doesn't matter for 2x2 matrices, but does for larger.
Hopefully this clears things up.

I also added some tests for svd: square matrices, and rectangular
matrices where m>n and m<n.
Some comments taken from Nash (1990), some are my own to aid in
understanding this algorithm.
The code to determine whether the output size agreed with the
format string size was only activated when the format string was
input as the first argument, not in the options hash. This change
activates it for both cases.

Added some tests as well.
@coveralls
Copy link

Coverage Status

Coverage remained the same at 62.795% when pulling f4745a0 on add_datatype_invalid into e0c13c8 on master.

@zmughal
Copy link
Member

zmughal commented Aug 23, 2016

This needs to be rebased, right?

@d-lamb
Copy link
Member Author

d-lamb commented Aug 23, 2016

yeah, it turned into a mess. I think when I started that branch I accidentally based it off another one that isn't master. There's really only one commit in there (f06ae90) that is relevant for this branch. Will try again this weekend.

@wchristian wchristian closed this Aug 29, 2016
@wchristian wchristian deleted the add_datatype_invalid branch August 29, 2016 03:31
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