bugGNU Octave - Bugs: bug #31974, Interpreter fails to create...

 
 

bug #31974: Interpreter fails to create complex numbers with Inf complex parts

Submitter:  Rik <rik5>
Submitted:  Sat 25 Dec 2010 03:53:34 PM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Matlab Compatibility
Status:  Wont Fix Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 11 Apr 2023 06:53:21 PM UTC, comment #38: 

See discussion and voting by Octave Maintainers on this thread: https://octave.discourse.group/t/should-octave-support-special-case-code-for-val-i-where-val-inf-nan-for-matlab-compatibility/4341

The conclusion is that Octave will not implement this feature because it introduces an inconsistency between scalar multiplication and vector/matrix multiplication which is deemed confusing.  In addition, the current behavior is only a problem with NaN/Inf construction of complex imaginary values and that has a very low incidence rate which can be worked around by calling complex (xxx, Inf).

Marking as "Won't Fix" and closing report.

Rik <rik5>
Group administrator
Fri 09 Dec 2022 08:48:15 PM UTC, comment #37: 

bug report is now really just a status check, not a Need Info. switching back to Confirmed.

Nicholas Jankowski <nrjank>
Group Member
Fri 30 Sep 2022 03:50:23 PM UTC, comment #36: 

update: checked in v7.2.0, v8.0.0 hg id 8b75954a4670, and matlab 2022a.
no change from comment #29

also, for easier copy/paste next time:


1+Inf*i
str2double('1 + Inf*i')
complex(1,Inf)
1+Inf*j
1 + Inf*j
1 + Infj
str2num('1+Inf*j')
123*j
NaN*j
Inf * 4j
x = Inf;x*j
j = complex(0,1);Inf*j


Nicholas Jankowski <nrjank>
Group Member
Mon 07 Dec 2020 07:42:22 PM UTC, comment #35: 

Just updating .... 6.1.0
(checked ...)
(it's my turn now)

Avinoam Kalma <avinoam>
Group Member
Tue 18 Feb 2020 09:22:07 PM UTC, comment #34: 

Just updating that the outputs from Comment #29 are still the same in Octave 5.2.0 (checked in Win-10)

Nicholas Jankowski <nrjank>
Group Member
Sat 18 Aug 2018 07:16:18 PM UTC, comment #33: 

Just updating that the outputs from Comment #29 are still the same in Octave 4.4.1 (checked in Win-10)

Avinoam Kalma <avinoam>
Group Member
Thu 08 Dec 2016 03:39:24 AM UTC, comment #32: 

just updating that the outputs from Comment #29 are still the same in Octave 4.2.0 and Matlab 2016b

Nicholas Jankowski <nrjank>
Group Member
Wed 05 Oct 2016 03:35:25 PM UTC, comment #31: 
Carnë Draug <carandraug>
Group Member
Mon 03 Oct 2016 06:23:42 PM UTC, comment #30: 

I have distilled the comments on this bug report and made those tests. I will add them to data.cc (under the function complex) but maybe they should be somewhere else?


%!error <undefined> 1+Infj
%!error <undefined> 1+Infi

%!test <31974>
%! assert (Inf + Inf*i, complex (Inf, Inf))
%!
%! assert (1 + Inf*i, complex (1, Inf))
%! assert (1 + Inf*j, complex (1, Inf))
%!
%! ## whitespace should not affect parsing
%! assert (1+Inf*i, complex (1, Inf))
%! assert (1+Inf*j, complex (1, Inf))
%!
%! assert (NaN*j, complex (0, NaN))
%!
%! assert (Inf * 4j, complex (0, Inf))

%!test <31974>
%! x = Inf;
%! assert (x * j, complex (0, Inf))
%! j = complex (0, 1);
%! assert (Inf * j, complex (0, Inf))

%!test <31974>
%! exp = complex (zeros (2, 2), Inf (2, 2));
%! assert (Inf (2, 2) * j, exp)
%! assert (Inf (2, 2) .* j, exp)
%! assert (Inf * (ones (2, 2) * j), exp)
%! assert (Inf (2, 2) .* (ones (2, 2) * j), exp)

%!test <31974>
%! assert ([Inf; 0] * [i, 0], complex ([NaN NaN; 0 0], [Inf NaN; 0 0]))
%! assert ([Inf, 0] * [i; 0], complex (NaN, Inf))
%! assert ([Inf, 0] .* [i, 0], complex ([0 0], [Inf 0]))

%!test <31974>
%! m = @(x, y) x * y;
%! d = @(x, y) x / y;
%! assert (m (Inf, i), complex (0, +Inf))
%! assert (d (Inf, i), complex (0, -Inf))


Carnë Draug <carandraug>
Group Member
Fri 01 Jul 2016 08:01:01 PM UTC, comment #29: 

hmmm.... the test output came through on email but isn't shown below. trying again:


>> 1+Inf*i
Octave:  NaN + Infi
Matlab:  1 + Infi

>> str2double('1 + Inf*i')
O: 1 + Infi
M: 1 + Infi

>> complex(1,Inf)
O: 1 + Infi
M: 1 + Infi

>> 1+Inf*j
O: NaN + Infi
M: 1+Infi

>> 1 + Inf*j
O: NaN + Infi
M: 1+Infi

>> 1 + Infj
O: error Infj undefined
M: error: Infj undefined

>> str2num('1+Inf*j')
O: NaN + Infi
M: 1 + Infi

>> 123*j
O: 0 + 123i
M: 0 + 123i

>> NaN*j
O: NaN + NaNi
M: NaN + NaNi

>> Inf * 4j
O: NaN + Infi
M: 0 + Infi

>> x = Inf;x*j
O: Nan + Infi
M: 0 + Infi

>> j = complex(0,1);Inf*j
O: NaN + Infi
M: 0 + Infi


Nicholas Jankowski <nrjank>
Group Member
Fri 01 Jul 2016 07:28:46 PM UTC, comment #28: 

I decided to sort through "Need Info"s and saw this old bug as still open.  I noticed the original complaint still produces the same result in Octave 4.0.2, different from Matlab 2016a.

The referenced related bug 32053 was closed as fixed. So, is this a Need Info?, should it become a Won't fix? A 'Matlab is wrong'...? I couldn't find a maintainers list thread to follow, but it's 5 years old so...

For posterity, here's are some simpler tests I culled from below with current output:


>> 1+Inf*i
Octave:  NaN + Infi
Matlab:  1 + Infi

>> str2double('1 + Inf*i')
O: 1 + Infi
M: 1 + Infi

>> complex(1,Inf)
O: 1 + Infi
M: 1 + Infi

>> 1+Inf*j
O: NaN + Infi
M: 1+Infi

>> 1 + Inf*j
O: NaN + Infi
M: 1+Infi

>> 1 + Infj
O: error Infj undefined
M: error: Infj undefined

>> str2num('1+Inf*j')
O: NaN + Infi
M: 1 + Infi

>> 123*j
O: 0 + 123i
M: 0 + 123i

>> NaN*j
O: NaN + NaNi
M: NaN + NaNi

>> Inf * 4j
O: NaN + Infi
M: 0 + Infi

>> x = Inf;x*j
O: Nan + Infi
M: 0 + Infi

>> j = complex(0,1);Inf*j
O: NaN + Infi
M: 0 + Infi

and many more...

Nicholas Jankowski <nrjank>
Group Member
Thu 06 Jan 2011 07:37:24 PM UTC, comment #27: 

BTW, the other bug report is https://savannah.gnu.org/bugs/?32053

As with that report, I think we should move any further discussion about this issue to the maintainers list since that will maybe get more people involved in the discussion.

John W. Eaton <jwe>
Group administrator
Thu 06 Jan 2011 07:28:38 PM UTC, comment #26: 

If you really want to find out, then I think you might be able to cast an mxArray* to char* and look at the bytes, then look at the values returned by mxGetPr and mxGetPI and compare.  That and a little more digging might uncover something about the layout of the mxArray object and when things are allocated.  I don't really care to do that myself as those details don't really matter to me.

What does matter is whether we should treat complex values with zero real part as pure imaginary values so we don't generate NaNs when multiplying a complex value with zero real part by Inf.  Apparently this surprises some people because they don't realize that there are no pure imaginary values, just real and complex.  The MathWorks apparently made this choice for Matlab, for all cases, not just the ones Jaroslav has suggested.  So should we be fully compatible, partly compatible, or not at all with regard to this feature?

I'm getting feedback on another bug report about complex numbers that is arguing against automatic narrowing of complex values that have a zero imaginary part (which is compatible behavior).  So if we narrow there, why not (appear to) narrow for the opposite case of zero real part?  Or why do either, even if it means incompatibility, if not ignoring the zero part is the right thing to do?

Whatever we do, I'm sure someone will not be happy about it.

I don't see the point of just being partly compatible here, and I don't really like the idea that internal computations can have different results from ones that are implemented in the interpreter operators themselves.  But whatever we decide, I don't plan to make any changes in this until after 3.4 is released, so can we stop wasting time on this issue now?


John W. Eaton <jwe>
Group administrator
Thu 06 Jan 2011 07:00:25 PM UTC, comment #25: 

If we're betting, I think lazily creating and destroying the real and imaginary parts would be a very easy optimization for them.

Perhaps you're right though that Matlab's coders wouldn't have stumbled onto this, but I guess they have had 40+ years... maybe they didn't even intentionally do it and their JIT is just that good(TM) and comes up with it on its own ;)

Judd Storrs <judd>
Thu 06 Jan 2011 06:46:47 AM UTC, comment #24: 

Yes, it's possible that Matlab creates the real part when asked, but I'd bet that is not how things really work.  In any case, the point is that the behavior at the scripting language level is a special case that is not present in the complex type in Fortran or C++, so there will be inconsistencies between what happens for the scripting language and operations in the BLAS (for example).  That was the point I was trying to make with the example of


[Inf, 0] * [i; 0]


John W. Eaton <jwe>
Group administrator
Wed 05 Jan 2011 08:05:17 PM UTC, comment #23: 

After I tested this in an old Matlab version (R2007b), I realized that R2007b doesn't behave the way R2010a is reported to below:


R2007b>> x = Inf;
R2007b>> x * j
ans = NaN + Infi


But below it is claimed


R2010a>> x = Inf;
R2010a>> x * j
ans = 0 + Infi


So, Matlab seems to have changed since the version I have access to.

FWIW this is what I see in the old Matlab version:


$ matlab -nojvm

                              < M A T L A B >
                  Copyright 1984-2007 The MathWorks, Inc.
                         Version 7.5.0.338 (R2007b)
                               August 9, 2007


  To get started, type one of these: helpwin, helpdesk, or demo.
  For product information, visit www.mathworks.com.

>> foo(i)
real part is allocated; its value is 0
imaginary part is allocated, its value is 1
>> foo(1)
real part is allocated; its value is 1
>> foo(complex(1,0))
real part is allocated; its value is 1
imaginary part is allocated, its value is 0


So, after mxGetPr is called, the real part exists. It may of course be that Matlab creates that field on demand either before mxGetPr() or before handing off any value to MEX.

As for the rest, this is what I see in R2007b, but I doubt it is helpful because of the difference I noted above.


>> x = 1+i
x = 1.0000 + 1.0000i
>> y = -1+i
y = -1.0000 + 1.0000i
>> z = x+y
z = 0 + 2.0000i
>> Inf * z
ans = NaN +    Infi


Judd Storrs <judd>
Wed 05 Jan 2011 07:06:29 PM UTC, comment #22: 

Oops, in my previous comment, I wrote

Do you still see the special treatment of the zero imaginary part here, or do you get NaN + Infi?

That should have been "special treatment of the zero REAL part..."

John W. Eaton <jwe>
Group administrator
Wed 05 Jan 2011 07:04:12 PM UTC, comment #21: 

Judd, I think that Matlab always allocates storage for the real part.  If you have access to Matlab, try this mex file:


#include "mex.h"

void
mexFunction (int nlhs, mxArray* plhs[], int nrhs,
             const mxArray* prhs[])
{
  double *pr = mxGetPr (prhs[0]);
  double *pi = mxGetPi (prhs[0]);

  if (pr)
    mexPrintf ("real part is allocated; its value is %g\n", pr[0]);


  if (pi)
    mexPrintf ("imaginary part is allocated, its value is %g\n", pi[0]);
}


and call it with


foo (i)
foo (1)
foo (complex (1, 0))


etc.  Can you come up with a way to make Matlab not allocate the real part of a numeric value?  That would be interesting, because it would mean that implemented pure imaginary values.  But I don't think they have done that.  Instead, I think there are some limited number of places where values with zero real parts are treated as if they are pure imaginary.  Unfortunately, I think this special treatment also applies to computed values, not just ones explicitly defined with the special values "i" or "j".  For example, what happens with


x = 1 + i
y = -1 + i
z = x + y
Inf * z


Do you still see the special treatment of the zero imaginary part here, or do you get NaN + Infi?

This topic of having a pure imaginary type has come up before.  If it is really important to have this behavior for pure imaginary values, then I think we need to have it consistently in Fortran, C++, C, etc., not just in some portions of programs like Octave or Matlab.  Do we really want that kind of inconsistent behavior?

John W. Eaton <jwe>
Group administrator
Mon 03 Jan 2011 04:14:52 PM UTC, comment #20: 

It seems like this may result from the differences in complex number representation in Matlab and in Octave?  Matlab stores the real and imaginary components separately whereas octave interleaves them.

If the components are stored separately, it would be trivial to get Matlab's behavior based on the states of the pointers to the real and imaginary memory chunks.  i.e. NaN*j would create a complex number that only has memory for the imaginary field allocated.  In some cases when Matlab passes the value off to the blas or whatever in some cases it will be forced to first allocate both components of the complex value, losing the internal state and resulting in identical behavior as octave.

So for the "1+Inf*j" Matlab could simply do "(1,unallocated)" + "(unallocated,Inf)" by letting allocated fields simply replace unallocated fields.  This would work without a special parser rule and copy-on-write means there is essentially no penalty for behaving this way.

Approaching this from the interleaved representation (used in octave) it's more difficult because both the real and imaginary parts are allocated simultaneously as a single region of memory that cannot be separated--i.e. octave can't hide state inside allocation patterns.

One approach would be to add a state variable to the complex values that labels the status of the (real,imaginary) components to obtain the semantics of the separate real/imag representation.  Another option would be to add a pure-imaginary array similar to the pure-real arrays we already have.

Judd Storrs <judd>
Mon 03 Jan 2011 08:13:32 AM UTC, comment #19: 

Matlab gives me:

>> f (Inf, i)


ans =

        0 +    Infi


ans =

        0 -    Infi

Søren Hauberg <hauberg>
Mon 03 Jan 2011 07:02:17 AM UTC, comment #18: 

What does Matlab do for


function f (x, y)
  x * y
  x / y
end

f (Inf, i)


If it produces 0+Infi and 0-Infi, then this is not limited to constant folding, so we have to implement the special case in the operators that might be affected.  I would guess this includes , ., /, ./, \, and .\ for mixed real and complex cases for scalar by scalar and scalar by array operations for both double and single values.  Or, we can use a class derived from std::complex that implements the special cases we want.  Using a derived class like this would probably require fewer changes to Octave since we already have Complex and FloatComplex typedefs, but then it would mean that anywhere the class is used, we get the special behavior, and I'm not sure that's really what we want.

In any case, I think this change should wait until after 3.4 is released.

John W. Eaton <jwe>
Group administrator
Sun 02 Jan 2011 11:57:07 AM UTC, comment #17: 

It is also possible that Matlab changed the behavior of real*complex just to make this thing work. I would advise to avoid doing such a general (and kinda stupid) change and only implement the constant folding optimization as suggested by JWE, i.e. a+b*i  -> complex(a, b) where a, b are scalar constants, because that's what most people mean. Don't change anything else.
It does mean a sort of inconsistency, but not quite, because we can say that the expression is simply parsed as a constant.

Jaroslav Hajek <highegg>
Thu 30 Dec 2010 03:45:43 PM UTC, comment #16: 

Sorry, I was thinking inner product, but your tests show that the outer product does the same.  The key thing is that then the operation is done by the BLAS library which doesn't have the special case code.

Also, my intro text was mangled by the rich markup feature...

John W. Eaton <jwe>
Group administrator
Thu 30 Dec 2010 03:32:39 PM UTC, comment #15: 

I was a bit unsure about the test from JWE (one of vectors needs a transposition), but I get:

>> [Inf; 0] * [i, 0]


ans =

      NaN +    Infi      NaN +    NaNi
        0                  0         

>> [Inf, 0] * [i; 0]


ans =

      NaN +    Infi

>> [Inf, 0] .* [i, 0]


ans =

        0 +    Infi        0         


Søren Hauberg <hauberg>
Thu 30 Dec 2010 03:20:46 PM UTC, comment #14: 

In mixed complex/real element-by-element operations (either explicit .*, ./, etc., operations, or scalar by matrix operations) we can intercept the operation and pretend that a complex value with 0 real part is a pure imaginary number and skip the 0 * Inf operation.  This should be done in the function that implements the operator.  This may appear to do the "right" thing in some cases, but will be inconsistent with anything that doesn't use our special functions for these mixed ops.  For example, I think the test you want is


[Inf, 0] * [i, 0]


This operation should use the BLAS, so the Inf*i won't be subject to a special definition of a mixed real by complex multiplication operator.

I'm not convinced this is something we should "fix", but if we do, and we are doing it for Matlab compatibility, I think we need to determine exactly how deeply this special case should be handled.  Should it just be done in the operator function(s)?  Should we replace <complex> with our own class that has the special cases?  Do we only have to change the behavior of multiplication or also division?  Other operators?

John W. Eaton <jwe>
Group administrator
Thu 30 Dec 2010 02:25:04 PM UTC, comment #13: 


>> Inf (ones(2,2) j)


ans =

        0 +    Infi        0 +    Infi
        0 +    Infi        0 +    Infi

>> Inf(2,2) .* (ones(2,2) * j)


ans =

        0 +    Infi        0 +    Infi
        0 +    Infi        0 +    Infi

Søren Hauberg <hauberg>
Thu 30 Dec 2010 01:56:14 PM UTC, comment #12: 

As j(2,2) doesn't work in matlab one final test. What does

Inf (ones(2,2) j)
Inf(2,2) .* (ones(2,2) * j)

give in matlab? I'm desperately hoping there is a NaN in the real part, as then we'd only have to check if a scalar is purely imaginary.

D.

David Bateman <dbateman>
Group Member
Thu 30 Dec 2010 11:48:11 AM UTC, comment #11: 

I get

>> Inf(2,2) * j


ans =

        0 +    Infi        0 +    Infi
        0 +    Infi        0 +    Infi

>> Inf(2,2) .* j


ans =

        0 +    Infi        0 +    Infi
        0 +    Infi        0 +    Infi

>> Inf * j(2,2)

??? Error using ==> j
Too many input arguments.
 

>> Inf(2,2) .* j(2,2)

??? Error using ==> j
Too many input arguments.
 

>> Inf * sparse(j(2,2))

??? Error using ==> j
Too many input arguments.
 

>> Inf * sparse(1)


ans =

   (1,1)      Inf


Søren Hauberg <hauberg>
Thu 30 Dec 2010 11:37:42 AM UTC, comment #10: 

Frankly, what the hell was mathworks thinking when they implemented this exception to IEEE754..... What a mess..

Does this behavior also hold for matrices or is it particular to scalars? What about sparse matrices? or even scalars stored in sparse matrices? What does

Inf(2,2) * j
Inf(2,2) .* j
Inf * j(2,2)
Inf(2,2) .* j(2,2)
Inf * sparse(j(2,2))
Inf * sparse(1)

give in matllab? If the same behavior holds for matrices, then we are going to take a serious performance hit to special case the imaginary by infinity or NaN case.

D.

David Bateman <dbateman>
Group Member
Thu 30 Dec 2010 12:35:12 AM UTC, comment #9: 

In Matlab I see:

>> x = Inf;
>> x * j


ans =

        0 +    Infi

>> j = complex (0, 1);
>> Inf * j           


ans =

        0 +    Infi

>> fcn * j


ans =

        0 +    Infi


Søren Hauberg <hauberg>
Wed 29 Dec 2010 11:11:29 PM UTC, comment #8: 

I had a look at coding this as it seemed to me that everything could be treated in the function

oct-parse.yy (static tree_expression fold (tree_binary_expression ))

but the problem is harder than I thought.. We need to treat not just "Inf j" but also "Inf 1j" as the parser treats the first as two identifiers and the second as an identifier times a constant. However identifier can be overloaded by user functions and variables, so

Inf = pi;
Inf * j

should return "0 + pi * j" so a simple test of the identifier in the parser can work. A solution for the above I looked at however is stymied by the case

for i = 1 : 10
  d(i) = Inf * j;
  Inf = pi;'t
endfor

as d(1) should be "0 + Inf j" but d(2:10) should be "0 + pi j".

Also another test case for matlab is

x = Inf;
x * j

Does this return "0 + j"  or "NaN + j"? And what about

j = Complex (0, 1);
Inf * j

does it return "0 + j" or "NaN + j"? And finally what about if you create a user function

function y = fcn ()
  y = Inf;
end

and then run

fcn * j

does it return "0 + j" or "NaN + j"? If the above three cases all return "0 + j" then the problem should be treated in ov.cc (do_binary_op) rather then in the parser and the problems above would go away.

D.

David Bateman <dbateman>
Group Member
Wed 29 Dec 2010 08:42:43 PM UTC, comment #7: 

I get

>> Inf * 4j


ans =

        0 +    Infi

Søren Hauberg <hauberg>
Wed 29 Dec 2010 08:18:44 PM UTC, comment #6: 

One final test for matlab I propose is

Inf * 4j

If that equal "0 + Inf" then the special case in the parser might be simpler as then we probably only need to special case the cases

Inf * constant
NaN * constant
constant * Inf
constant * NaN

where "constant" is already defined in the parser. As I don't know much yacc I hope John steps forward and looks at this.

D.

David Bateman <dbateman>
Group Member
Wed 29 Dec 2010 07:49:44 PM UTC, comment #5: 

In Matlab I get:

>> NaN*j


ans =

        0 +    NaNi

Søren Hauberg <hauberg>
Wed 29 Dec 2010 07:21:36 PM UTC, comment #4: 

So Matlab seems to have a special case for Inf*[complex unit].  One additional test is to see whether Matlab behaves correctly for XXX*[complex unit] where XXX is any value or whether 'Inf' is actually special.  My guess is that the parser does something like this.


XXX*j  is translated to function call complex (0, XXX)

rather than translating to XXX * complex (0, 1) as Octave does.

Final test case:
NaN*j

I think this will yield 0 + NaNi in Matlab


Rik <rik5>
Group administrator
Tue 28 Dec 2010 11:30:57 PM UTC, comment #3: 

Using Matlab 7.10.0.499 (R2010a) I see

>> 1+Inf*j


ans =

   1.0000 +    Infi

>> 1+Infj

??? Undefined function or variable 'Infj'.
 

>> 1 + Inf*j


ans =

   1.0000 +    Infi

>> 1 + Infj

??? Undefined function or variable 'Infj'.
 

>> str2num('1+Inf*j')


ans =

   1.0000 +    Infi

>> 1 + Inf*i


ans =

   1.0000 +    Infi

>> str2double ('1 + Inf*i')


ans =

   1.0000 +    Infi

>> complex(1, Inf)


ans =

   1.0000 +    Infi

Søren Hauberg <hauberg>
Tue 28 Dec 2010 10:18:43 PM UTC, comment #2: 

I know what Octave is doing, I'm just not sure it's the best interface to present to the user.  There are a number of possible ways to create a number with infinite complex magnitude, but most of them fail with Octave.  Whoever can run Matlab to check its behavior should also try some of these other corner cases.


1+Inf*j
1+Infj
1 + Inf*j // to see whether spaces affect parsing
1 + Infj  // ditto
str2num("1+Inf*j")


Rik <rik5>
Group administrator
Tue 28 Dec 2010 08:29:42 PM UTC, comment #1: 

Just "Inf i" is sufficient to show this behavior. However, I'm not sure this is a bug. Read carefully what you've written and how Octave will treat it. That is "1 + Inf*i". Octave will parse this as "(1) + (Inf (i))". The "(i)" equals "0 + i", which when multiplied by "Inf" has "Inf 0" in the real part and guess what "Inf 0" is "NaN"

What does Matlab do in this case? I suspect it does the same as Octave. If it does I propose to mark this bug as invalid.

D.

David Bateman <dbateman>
Group Member
Sat 25 Dec 2010 03:53:34 PM UTC, original submission:  

The code below shows the problem.


1 + Inf*i
ans = NaN + Infi

str2double ("1 + Inf*i")
ans =    1 + Infi

complex(1, Inf)
ans =    1 + Infi


Rik <rik5>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Carbon-Copy List
  • -email is unavailable- added by avinoam (Posted a comment)
  • -email is unavailable- added by nrjank (Posted a comment)
  • -email is unavailable- added by judd (Posted a comment)
  • -email is unavailable- added by highegg (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by hauberg (Posted a comment)
  • -email is unavailable- added by dbateman (Posted a comment)
  • -email is unavailable- added by rik5 (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-04-11 rik5 StatusConfirmed Wont Fix
        Open/ClosedOpen Closed
    2023-04-07 rik5 Item GroupIncorrect Result Matlab Compatibility
    2022-12-09 nrjank StatusNeed Info Confirmed
    2022-09-30 nrjank Operating SystemGNU/Linux Any
    2022-04-21 mmuetzel Dependencies- bugs #62342 is dependent
    2018-03-26 mtmiller Dependencies- bugs #53462 is dependent
    2016-10-02 rik5 Dependencies- bugs #49242 is dependent
    2010-12-28 dbateman StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code