octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Operations with int and single


From: John W. Eaton
Subject: Re: Operations with int and single
Date: Tue, 18 Sep 2012 11:15:41 -0400

On 18-Sep-2012, Israel Herraiz wrote:

| Excerpts from Thorsten Liebig's message of Thu Sep 13 12:01:57 +0200 2012:
| > I think the goal is that any Matlab code should run in Octave.
| 
| I was asking because there are specific warnings for MATLAB
| incompatibilities in other operations, but not when mixing ints and singles.
| 
| > But the other way around is not the goal I suppose. There are a lot of 
things Octave can, but Matlab does not.
| > So I like it that Octave is smarter than Matlab when it comes to this 
"mixed int-operations"...
| > 
| > Example:
| > linspace(0,2*pi)(1:end-1)
| 
| Sure. But try this
| 
|  octave:1> warning on
|  octave:2> a = "Hello";
|  warning: potential Matlab compatibility problem: " used as string delimiter
| 
| If those operations are not MATLAB compatible (and I insist, I am
| totally fine with that :), why does not Octave show a warning about
| the incompatibility with MATLAB like in the example I show?

Because we are mean and we did it just to spite you.

Seriously though, I think the reason is because no one has implemented
the warnings yet.  Do you want the warnings?  Would you like to work
on implementing them?

| In any case, I was asking because I am not totally sure if the
| behavior with int and single is intended or not (if it is, why not mix
| integers of different classes too?).

Yes, it's intended.

I don't know for sure what the people at TMW were thinking, but here
is my guess:

  The reason mixing integers and doubles works is because constants like
  13 are double values in Matlab.  It would be thoroughly annoying to
  have to cast all constant values to the appropriate integer type just
  to use them in expressions with integers.

Octave extended this to mixing int and single only because it was
relatively easy to do so, and someone wanted to do it.  Do you want us
to remove that capability?

Implementing operators for mixed-type integer operations would be
possible, but in an array language, you don't want to simply cast the
arguments.  Copy and entire matrix to another type then do the
same-type operation?  That wastes memory and time so is not a very
good solution.  So providing all those types means an explosion in
the number of operator functions.  We could do it, but it doesn't seem
worth the effort.

jwe


reply via email to

[Prev in Thread] Current Thread [Next in Thread]