On Sun, Jun 3, 2012 at 10:33 AM, Jerome BENOIT <[email protected]>wrote:
> Hello: > > > On 03/06/12 12:27, Rhys Ulerich wrote: > >> Having had a chance to review the code a bit... >> >> Indeed I meant these one, but also the other alike ones: >>> >>> int gsl_vector_long_scale (gsl_vector_long * a, const double x); >>> int gsl_vector_long_add_constant (gsl_vector_long * a, const double x); >>> >>> and so forth. >>> >> >> I can see arguments for why gsl_vector_long_scale should take a >> double. Say I want to scale a long by a non-integer factor and coerce >> the result back to long. Multiplying every long by, say, 1.5 is >> reasonable and would give a dramatically different effect versus >> multiplying by ((long) 1.5). Therefore I don't consider "const double >> x" arguments to be a bug in these routines: >> >> int gsl_vector_char_scale (gsl_vector_char * a, const double x); >> int gsl_vector_complex_float_scale (gsl_vector_complex_float * a, >> const gsl_complex_float x); >> int gsl_vector_complex_long_**double_scale >> (gsl_vector_complex_long_**double * a, const gsl_complex_long_double x); >> int gsl_vector_complex_scale (gsl_vector_complex * a, const gsl_complex >> x); >> int gsl_vector_int_scale (gsl_vector_int * a, const double x); >> int gsl_vector_long_scale (gsl_vector_long * a, const double x); >> int gsl_vector_scale (gsl_vector * a, const double x); >> int gsl_vector_short_scale (gsl_vector_short * a, const double x); >> int gsl_vector_uchar_scale (gsl_vector_uchar * a, const double x); >> int gsl_vector_uint_scale (gsl_vector_uint * a, const double x); >> int gsl_vector_ulong_scale (gsl_vector_ulong * a, const double x); >> int gsl_vector_ushort_scale (gsl_vector_ushort * a, const double x); >> >> The only problem appears to be in the following two signatures: >> >> int gsl_vector_float_scale (gsl_vector_float * a, const double x); >> int gsl_vector_long_double_scale (gsl_vector_long_double * a, const >> double x); >> >> The former should probably take "const float x" but no real harm is >> caused by taking a float (other than a small performance hit for >> double FLOPs where float FLOPs would suffice). The latter certainly >> would cause precision loss. I am inclined to change only these two >> signatures as far as scaling vectors are concerned. >> >> >> In contrast, gsl_vector_long_add_constant feels like it should take a >> long as adding 1.5 or ((long) 1.5) to a long gives the same result. >> In cases where double precision values can represent integers exactly >> (a surprisingly large region on the whole number line), there's no >> precision-related harm in the current API. It's just inefficient and >> confusing. In cases where double precision is insufficient, precision >> loss can occur. I believe these routines fall into one camp or the >> other and should be change: >> >> int gsl_vector_char_add_constant (gsl_vector_char * a, const double x); >> int gsl_vector_float_add_constant (gsl_vector_float * a, const double x); >> int gsl_vector_int_add_constant (gsl_vector_int * a, const double x); >> int gsl_vector_long_add_constant (gsl_vector_long * a, const double x); >> int gsl_vector_long_double_add_**constant (gsl_vector_long_double * a, >> const double x); >> int gsl_vector_short_add_constant (gsl_vector_short * a, const double x); >> int gsl_vector_uchar_add_constant (gsl_vector_uchar * a, const double x); >> int gsl_vector_uint_add_constant (gsl_vector_uint * a, const double x); >> int gsl_vector_ulong_add_constant (gsl_vector_ulong * a, const double x); >> int gsl_vector_ushort_add_constant (gsl_vector_ushort * a, const double >> x); >> >> Thoughts? >> > > Your analysis is correct. I think that for integer types, the issue is a > design issue: > if it is let as it is, ``it is just inefficient and confusing'', in other > words inconsistent. > As it sounds confusing or somehow inappropriate to add a long vector to a > double vector, > it is weird to add (or multiply by) a double a long vector: the design > must be fully explicit, > and let the final user/coder to make the dirty tricks. Being explicit help > to make things crystal > clear. > > In fact, I would step further by adding `off diagonal' memcpy functions > that allows to copy > a vector (or matrix) of a given type to a a vector (or matrix) of a > different type: > I think that those kind of functions are actually missing in GSL. > > > > >> After we're in agreement here, the matrix-related cases should follow >> accordingly. >> >> - Rhys >> > > > Jerome > > Is this discussion relevant? http://lists.gnu.org/archive/html/bug-gsl/2008-11/msg00002.html See Brian Gough's answer. Liam
