any() function handles int types wrong...

View: New views
2 Messages — Rating Filter:   Alert me  

any() function handles int types wrong...

by Nicholas Jankowski :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Bug report for Octave 3.0.1 configured for i686-pc-msdosmsvc

Description:
-----------
running the any() function should give 0 only if everything in the
array is a zero.  however, it apparently only works correctly if the
thing you you run it on is type double. uint, int, logical types all
produce erroneous results.  I cut and pasted some input/output
statements below.


Repeat-By:
---------
>blah=[121 1 95 88 77 ; 81 89 83 80 79 ]
blah =

   121   1    95    88    77
    81    89    83    80    79


> class(blah)
ans = double

> any(blah)
ans =

   1   1   1   1   1   *******THIS IS THE CORRECT ANSWER*******

> blah=int16(blah)
blah =

  121  1   95   88   77
   81   89   83   80   79

> any(blah)
ans =

   0   0   0   0   0   *******WRONG. Changing type should not change
answer*******

> blah=logical(blah)
blah =

   1   1   1   1   1
   1   1   1   1   1

> any(blah)
ans =

   1   1   1   1   1

> blah=uint16(blah)
blah =

  1  1  1  1  1
  1  1  1  1  1

> any(blah)
ans =

   0   0   0   0   0


Also:

tried to use the bug_report function. I don't think the windows
compiled version knows how to handle that yet. generates a nice long
text file of what looks like unparsed bug-report code. I tried to use
the included format, and below is what I believe is my machine info
from the file:
config_opts="'--build=i686-pc-msdosmsvc'
'--prefix=/c/Software/VCLibs/local/octave-3.0.1' '--with-zlib=zlib'
'--with-curl=libcurl' 'build_alias=i686-pc-msdosmsvc' 'CC=cc-msvc'
'CFLAGS=-O2' 'CXX=cc-msvc' 'CXXFLAGS=-O2' 'F77=fc-msvc' 'FFLAGS=-O2'"
VERSION="3.0.1"
SED="/usr/bin/sed"
MACHINE="i686-pc-msdosmsvc"
F77="fc-msvc"
FFLAGS="-O2"
FPICFLAG=""
FLIBS="-lhdf5 -lzlib -lf2c -lkernel32"
F2C="@F2C@"
F2CFLAGS="@F2CFLAGS@"
CPPFLAGS="-I.  -Ic:/Software/VCLibs/include"
INCFLAGS="-I. -I. -I./liboctave -I./src -I./libcruft/misc"
CC="cc-msvc"
CC_VERSION=""
CFLAGS="-O2 -MD"
CPICFLAG=""
CXX="cc-msvc"
CXX_VERSION=""
CXXFLAGS="-O2 -EHs -MD"
CXXPICFLAG=""
LD_CXX="cc-msvc"
LDFLAGS=""
LIBFLAGS="-L."
RLD_FLAG=""
LIBS="-lreadline  -lncurses -lhdf5 -lzlib  -lws2_32 -lkernel32"
BLAS_LIBS="-llapack -lblas"
FFTW_LIBS="-lfftw3"
LEXLIB=""
LIBGLOB="-lglob"
DEFS="-DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\"
-DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\"
-DOCTAVE_SOURCE=1 -D_GNU_SOURCE=1 -DSTDC_HEADERS=1
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
-DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_UNISTD_H=1 -DSEPCHAR=';'
-DSEPCHAR_STR=\";\" -D__NO_MATH_INLINES=1
-DCXX_NEW_FRIEND_TEMPLATE_DECL=1 -DCXX_ISO_COMPLIANT_LIBRARY=1
-DCXX_ABI=unknown -DHAVE_QHULL=1 -DHAVE_PCRE=1 -DHAVE_ZLIB_H=1
-DHAVE_ZLIB=1 -DHAVE_HDF5_H=1 -DHAVE_HDF5=1 -DHAVE_H5GGET_NUM_OBJS=1
-D_HDF5USEDLL_=1 -DHAVE_FFTW3=1 -DHAVE_GLPK_H=1 -DHAVE_GLPK=1
-DHAVE_CURL_CURL_H=1 -DHAVE_CURL=1 -DHAVE_IEEE754_DATA_FORMAT=1
-DF77_FUNC(name,NAME)=name ## _ -DF77_FUNC_(name,NAME)=name ## __
-DHAVE_BLAS=1 -DHAVE_SUITESPARSE_UMFPACK_H=1 -DHAVE_UMFPACK=1
-DUMFPACK_SEPARATE_SPLIT=1 -DHAVE_SUITESPARSE_COLAMD_H=1
-DHAVE_COLAMD=1 -DHAVE_SUITESPARSE_CCOLAMD_H=1 -DHAVE_CCOLAMD=1
-DHAVE_SUITESPARSE_CHOLMOD_H=1 -DHAVE_CHOLMOD=1
-DHAVE_SUITESPARSE_CS_H=1 -DHAVE_CXSPARSE=1 -Dmode_t=int -Dpid_t=int
-Duid_t=int -Dgid_t=int -DHAVE_DEV_T=1 -DHAVE_INO_T=1
-DHAVE_LONG_LONG_INT=1 -DHAVE_UNSIGNED_LONG_LONG_INT=1
-DHAVE_SIG_ATOMIC_T=1 -DSIZEOF_SHORT=2 -DSIZEOF_INT=4 -DSIZEOF_LONG=4
-DSIZEOF_LONG_LONG=8 -DHAVE_ALLOCA=1 -DNPOS=std::string::npos
-DHAVE_PLACEMENT_DELETE=1 -DSTDC_HEADERS=1 -DHAVE_ASSERT_H=1
-DHAVE_DIRECT_H=1 -DHAVE_FCNTL_H=1 -DHAVE_FLOAT_H=1 -DHAVE_LIMITS_H=1
-DHAVE_LOCALE_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STDLIB_H=1
-DHAVE_STRING_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TYPES_H=1
-DHAVE_SYS_UTIME_H=1 -DHAVE_UNISTD_H=1 -DHAVE_VARARGS_H=1
-DHAVE_SSTREAM=1 -DHAVE_GLOB_H=1 -DHAVE_FNMATCH_H=1 -DHAVE_CONIO_H=1
-DHAVE_ATEXIT=1 -DHAVE_CHMOD=1 -DHAVE_DUP2=1 -DHAVE_EXECVP=1
-DHAVE_GETCWD=1 -DHAVE_GETPID=1 -DHAVE__KBHIT=1 -DHAVE_MEMMOVE=1
-DHAVE_MKDIR=1 -DHAVE_PUTENV=1 -DHAVE_RAISE=1 -DHAVE_RENAME=1
-DHAVE_RMDIR=1 -DHAVE_SETLOCALE=1 -DHAVE_SETVBUF=1 -DHAVE_STAT=1
-DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRICMP=1 -DHAVE_STRNICMP=1
-DHAVE_TEMPNAM=1 -DHAVE_UMASK=1 -DHAVE_UNLINK=1 -DHAVE_UTIME=1
-DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 -DHAVE_VSNPRINTF=1 -DHAVE__CHMOD=1
-DHAVE__SNPRINTF=1 -DHAVE__UTIME32=1 -DOCTAVE_HAVE_BROKEN_STRPTIME=1
-D_WIN32_WINNT=0x0403 -D_USE_MATH_DEFINES=1 -DHAVE_LOADLIBRARY_API=1
-DENABLE_DYNAMIC_LINKING=1 -DHAVE__FINITE=1 -DHAVE__ISNAN=1
-DHAVE__COPYSIGN=1 -DHAVE_DECL_SIGNBIT=0 -DHAVE_STRUCT_STAT_ST_RDEV=1
-DHAVE_DECL_TZNAME=1 -DHAVE_TZNAME=1 -DCLOSEDIR_VOID=1
-DMKDIR_TAKES_ONE_ARG=1 -DUSE_READLINE=1 -DRETSIGTYPE=void
-DHAVE_DECL_SYS_SIGLIST=0 -DMUST_REINSTALL_SIGHANDLERS=1
-DRETSIGTYPE_IS_VOID=1 -DGNUPLOT_BINARY=\"pgnuplot\""
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave

any() function handles int types wrong...

by John W. Eaton :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On  9-May-2008, Nicholas Jankowski wrote:

| Bug report for Octave 3.0.1 configured for i686-pc-msdosmsvc
|
| Description:
| -----------
| running the any() function should give 0 only if everything in the
| array is a zero.  however, it apparently only works correctly if the
| thing you you run it on is type double. uint, int, logical types all
| produce erroneous results.  I cut and pasted some input/output
| statements below.
|
|
| Repeat-By:
| ---------
| >blah=[121 1 95 88 77 ; 81 89 83 80 79 ]
| blah =
|
|    121   1    95    88    77
|     81    89    83    80    79
|
|
| > class(blah)
| ans = double
|
| > any(blah)
| ans =
|
|    1   1   1   1   1   *******THIS IS THE CORRECT ANSWER*******
|
| > blah=int16(blah)
| blah =
|
|   121  1   95   88   77
|    81   89   83   80   79
|
| > any(blah)
| ans =
|
|    0   0   0   0   0   *******WRONG. Changing type should not change
| answer*******

I think the following patch will fix this problem.  It was applied to
the default branch but somehow missed for the branch used to create
the 3.0.1 release.

jwe


# HG changeset patch
# User John W. Eaton <jwe@...>
# Date 1202417917 18000
# Node ID aab45fbcd71ffed9cdcc91dbd91f857cc38984c4
# Parent  fee437704c672fd165c783f33009ef172f3791a0
fix any(int) bug

diff --git a/liboctave/ChangeLog b/liboctave/ChangeLog
--- a/liboctave/ChangeLog
+++ b/liboctave/ChangeLog
@@ -1,3 +1,7 @@
+2008-02-07  John W. Eaton  <jwe@...>
+
+ * intNDArray.cc (intNDArray<T>::any (int)): Use != for comparison.
+
 2008-02-06  John W. Eaton  <jwe@...>
 
  * Makefile.in ($(OPTS_INC)): Use mv instead of move-if-change.
diff --git a/liboctave/intNDArray.cc b/liboctave/intNDArray.cc
--- a/liboctave/intNDArray.cc
+++ b/liboctave/intNDArray.cc
@@ -135,7 +135,7 @@
 boolNDArray
 intNDArray<T>::any (int dim) const
 {
-  MX_ND_ANY_ALL_REDUCTION (MX_ND_ALL_EVAL (this->elem (iter_idx) == T (0)), false);
+  MX_ND_ANY_ALL_REDUCTION (MX_ND_ANY_EVAL (this->elem (iter_idx) != T (0)), false);
 }
 
 template <class T>

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave