Re: Naming of the complex diagonal matrix class.

[Jaroslav Hajek]

On Tue, Mar 10, 2009 at 8:25 PM, Jason Riedy <address@hidden> wrote:
> I write:
>> It may be too late to change, but would a patch to make complex
>> diagonal matrices into diagonal complex matrices be accepted?
>
> And John W. Eaton responds:
>> These names are not new, so we should probably not just change
>> them as that would force a lot of code to change.  If we decide to
>> change the names, would typdefs work to preserve the old names?
>
> Those names have been in a released stable version?  It'd be nice to
> have all the names parallel in a stable version...  Sure would help my
> cdm v. dcm typos.
>
>> If we do decide to change the names, I would like to consider a larger
>> renaming, [...]
>
> Now *that* is for later and probably should be evolutionary rather than
> one large change.  I'm just asking for consistency within one stable
> release.
>
> And Jaroslav Hajek responds::
>> Besides, I think that it's the sparse complex matrix that is misnamed,
>> not complex diagonal matrices.
>
> But SparseComplexMatrix and scm have been around for a while now...
>
>> This scheme is consistent throughout the rest of naming, where you can
>> combine, e.g. "scalar" or "matrix" with all prefixes "float_",
>> "complex_", "float_complex_". Similarly for "diag_matrix".
>
> There is no single-precision sparse matrix.  The names that don't fit
> the existing scheme, <structure>-(<element type>-)?(matrix|ndarray) are
> the *new* diagonal matrices.
>

Well, I should have made myself more clear. I only named the
interpreter classes, the diagonal matrix classes in liboctave existed
long before me, and their names haven't changed. Wherever else you
look, "Complex" is always prefixed, not infixed - think ComplexLU,
ComplexRowVector etc. *Only* the sparse complex matrix violates this.


>> I was aware of this when I chose the naming, but changing the sparse
>> matrix naming didn't seem that important.
>
> Thanks.  My external code appreciates not having to change all its
> type names.
>
> Jason, token sparse matrix user
>

Well, there's going to be massive renaming anyway, because we want to
get rid of the CamelCasedNames in favor of lowercase_underscored_names
and also introduce namespaces, simplify the class tree etc.
I think we should create something like compatibility header full of
typedefs, but I expect them to only save the day partially. For
instance, we can't yet rely on template typedefs, so there's no way to
make Array an alias of octave::array.

cheers

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz