Re: [CHANGESET]: First attempt at a single precision type.

[Jaroslav Hajek]

On Mon, Apr 28, 2008 at 11:09 AM, David Bateman
<address@hidden> wrote:
> Jaroslav Hajek wrote:
>  > I suggest to think twice, however. You've implemented the most
>  > "normal" or "obvious" behaviour, IMHO. That single+double = single in
>  > Matlab was a surprise for me. Is there anyone who considers the Matlab
>  > behaviour as normal? I mean, I think that almost all other languages
>  > or math systems do it the other way around - promote single to double.
>  > Perhaps even Matlab users are unsatisfied with this behaviour (I think
>  > I've never used single in Matlab, but if I did, certainly I'd have
>  > been disappointed).
>  > Octave has a chance here to go the right way from the beginning, if
>  > this is the case.
>  >
>  >
>
>  I implemented most of this over the weekend with a few nights last week
>  and didn't have access to matlab to test its behavior, and did what I
>  thought was the obvious thing to do.. I'd be happy to keep it the way it
>  is as then we also get "single OP int" operators defined for nothing.
>  The reasoning for the matlab way of doing it is that if the user chose a
>  single precision type for one variable in an expression its because they
>  think they don't need the precision, and the matlab behavior allows
>  single precision to be kept in an expression even if some of the
>  underlying code hasn't been converted to accept single precision
>  arguments... I see some sense with this behavior in terms of what the
>  user would want, as they have to explicitly call "single" on an argument
>  to get it to be single precision in the first place, though I completely
>  agree its the wrong thing to do in terms of precision...

There is also an alternative view: a user may be used to do
calculations in double precision
(most users are), but he may get a single-precision result from
external data read or calculation that just uses single precision, and
the lower precision will then "infect" a whole chain of calculations,
and things may break up (for instance, Infs may suddenly appear in a
calculation).
For instance, I dislike the idea of ppval called with double
coefficients on single input converting first the coefficients into
single; that's not what I would expect it to do.
(and it will be much slower

>
>  Another things I did which promotes to double that matlab demote is
>  something like
>
>  a = zeros (1, 5, 'single');
>  a(1) = 1;
>
>  we need to be consistent there as well. I'm happy to go either way, but
>  looking through the matlab news groups, in fact it seems that most of
>  their users are happy with the current behavior. See
>
>  
> http://groups.google.com/group/comp.soft-sys.matlab/browse_thread/thread/ed16a8f1bda1893f/0b001535bc8c23de?lnk=gst&q=single+precision+promotion#0b001535bc8c23de
>
>  for example. And in fact the behavior of
>
>  A(idx) = object
>
>  is documented as "object" is always promoted to the type of A. Thus
>
>  a = zeros(1,5)
>  a(1) = single(1)
>
>  should have "a" as double and
>
>  a = zeros (1, 5, 'single');
>  a(1) = 1;
>
>  should have "a" as single, which is even less consistent with the
>  behavior I expected, as I would have though that "a" should either be
>  promoted to double or demoted to a "single" for consistency with the
>  other operations..
>

This seems logical to me. In indexed assignment, the type of lhs
should not be changed,
because you expect the non-indexed elements to remain intact.

But it leads to another interesting point:
unlike Matlab, Octave has +=, -= etc.
In the following expressions with A double matrix and x single scalar,
what should the type of A be?
A += x; % A = A + x  ==> single ???
A(:,1) += x; % A(:,1) = A(:,1) + x   ==> double, due to the indexing ???


>  So what should we do? Do promotion of "single" to "double" for all mixed
>  operations as I currently implemented it? Change only the subsasgn
>  operator for consistency with matlab? Or go the whole way and duplicate
>  matlab's behavior? I suspect we'll probably have to duplicate matlab's
>  behavior in something as basic as this otherwise we'll end up with a lot
>  of odd differences between the behavior of a script run in Matlab or in
>  Octave.. John whats your opinion?
>
>  Regards
>  David
>
>  --
>
> David Bateman                                address@hidden
>
>
> Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph)
>  Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob)
>  91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax)
>
>  The information contained in this communication has been classified as:
>
>  [x] General Business Information
>  [ ] Motorola Internal Use Only
>  [ ] Motorola Confidential Proprietary
>
>



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