Working with incompatible data types

I'm currently working with legacy code (MATLABv2012) with the most current MATLAB version (2013a). In the old code base many calculations of the following form were performed:

c = a + b

where "a" was an uint64 and b was a double. In my MATLAB version this produces following error: Error using + Invalid type of input arguments (should be uint64)

In old MATLAB Versions this was not an error. Is it possible to use the old behavior?

Answer 1

[Walter Roberson]

There is no problem in adding uint64 and double, so there must be something else going on. Please show some lines of code that reproduce the error.

>> uint64(532432234) + 3234.51

ans =

              532435469

[dpb]

Try an array of double and uint64...

[Walter Roberson]

Ah right, "Integers can only be combined with integers of the same class, or scalar doubles." -- though the original question did use the singular on the sizes.

[David]

The line you posted above produces an error:

    >> uint64(532432234) + 3234.51
    Error using  + 
    Invalid type of input arguments (should be uint64)

Here my product info

-------------------------------------------------------------------------------------------------------
MATLAB Version: 8.1.0.604 (R2013a)
Operating System: Microsoft Windows 7 Version 6.1 (Build 7601: Service Pack 1)
Java Version: Java 1.6.0_17-b04 with Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM mixed mode
-------------------------------------------------------------------------------------------------------

Hope this helps.

[dpb]

Contact official tech support for the TMW answer as to "why" (other than the obvious of "Because we can". The most frustrating part of Matlab is the penchant for breaking compatibility willy-nilly.

As noted, I can find nothing in release notes starting from R2012b working backwards wrt uintxx behavior numerically--perhaps it's an unintended change altho that's probably too much to hope for that a patch to revert to your previous behavior will be forthcoming real_soon_now (tm).

W/o that I see two options only --

a) revert to the previous release, or
b) modify the code by either 
  i) inserting the necessary casts or
 ii) implementing the desired functionality for the class

[Walter Roberson]

R2013a on OS-X, the code gives me the expected numeric answer.

Please use

which -all plus

to check to see if you have an interfering plus() routine.

[David]

That was it. I had a eeglab implementation of uint64 in my path. Thanks!

Answer 2

[dpb]

From

help uint64

"You can define your own methods for the uint64 class (as you can for any object) by placing the appropriately named method in an @uint64 directory within a directory on your path.

Type HELP DATATYPES for the names of the methods you can overload."

Answer 3

[David]

I'm sorry but your answer doesn't really answer my question. Are there any method definitions I can use that mimic the old behavior?

[dpb]

If you mean a compatibility switch, afaik, no.

The way to make a method that mimics the previous is to write them it appears. I can find nothing regarding a change in behavior in the release notes and don't have other versions installed to test against for behavior different than 2012b.