Nabble - Octave - Bugs

Re: octave-3.0.2: compilation error csparse.cc

2008-10-10T11:05:06Z

Dear Jaroslav,

thanks for your help.

I applied the patch but the compilation error message is still the same.

Shouldn't the Csparse.cc file also be changed because the compilation error appears there?

Please advice.

Best,

Ciao, Juergen

Apparently there has been a subtle API change in SuiteSparse between
3.1 and 3.2. I believe the attached patch should solve the problem. I
pushed this to the development sources; if nobody reports a compiler
choking on this (IMHO it's standard C++, but a subtle issue), I'll
transplant this into 3-0-x, so that it will appear in 3.0.4.

regards

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

Re: octave-3.0.2: compilation error csparse.cc

2008-10-10T07:51:02Z

On Fri, Oct 10, 2008 at 4:18 AM, JuergenNeubauer
<jneubauer@...> wrote:

>
> Hi,
>
> I get an error during compilation of octave-3.0.2.
>
> Architecture: Linux localhost.localdomain 2.6.18-92.1.13.el5 #1 SMP Wed Sep
> 24 16:44:34 EDT 2008 i686 i686 i386 GNU/Linux
>
> gcc: version 4.1.2
> g++: version 4.1.2
>
> make[2]: Entering directory `/opt/octave/octave-3.0.2/liboctave'
> g++ -c -I/usr/include/suitesparse -fPIC -I. -I.. -I../liboctave -I../src
> -I../libcruft/misc -DHAVE_CONFIG_H -mieee-fp -Wall -W -Wshadow
> -Wold-style-cast -g -O2 CSparse.cc -o pic/CSparse.o
> CSparse.cc: In member function 'ComplexMatrix
> SparseComplexMatrix::fsolve(MatrixType&, const Matrix&, octave_idx_type&,
> double&, void (*)(double), bool) const':
> CSparse.cc:5769: error: invalid conversion from 'void (*)(int, char*, int,
> char*)' to 'void (*)(int, const char*, int, const char*)'
> CSparse.cc: In member function 'SparseComplexMatrix
> SparseComplexMatrix::fsolve(MatrixType&, const SparseMatrix&,
> octave_idx_type&, double&, void (*)(double), bool) const':
> CSparse.cc:6012: error: invalid conversion from 'void (*)(int, char*, int,
> char*)' to 'void (*)(int, const char*, int, const char*)'
> CSparse.cc: In member function 'ComplexMatrix
> SparseComplexMatrix::fsolve(MatrixType&, const ComplexMatrix&,
> octave_idx_type&, double&, void (*)(double), bool) const':
> CSparse.cc:6303: error: invalid conversion from 'void (*)(int, char*, int,
> char*)' to 'void (*)(int, const char*, int, const char*)'
> CSparse.cc: In member function 'SparseComplexMatrix
> SparseComplexMatrix::fsolve(MatrixType&, const SparseComplexMatrix&,
> octave_idx_type&, double&, void (*)(double), bool) const':
> CSparse.cc:6525: error: invalid conversion from 'void (*)(int, char*, int,
> char*)' to 'void (*)(int, const char*, int, const char*)'
> make[2]: *** [pic/CSparse.o] Error 1
> make[2]: Leaving directory `/opt/octave/octave-3.0.2/liboctave'
> make[1]: *** [liboctave] Error 2
> make[1]: Leaving directory `/opt/octave/octave-3.0.2'
> make: *** [all] Error 2
>
> I attached the config.log here:
> http://www.nabble.com/file/p19910718/config.log config.log
>
> I need help to resolve this issue. Please let me know if you need more
> information.
>
> Thanks for your help and advice.
>
> Ciao, Juergen
> --

Apparently there has been a subtle API change in SuiteSparse between
3.1 and 3.2. I believe the attached patch should solve the problem. I
pushed this to the development sources; if nobody reports a compiler
choking on this (IMHO it's standard C++, but a subtle issue), I'll
transplant this into 3-0-x, so that it will appear in 3.0.4.

regards

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

# HG changeset patch
# User Jaroslav Hajek <highegg@...>
# Date 1223649861 -7200
# Node ID 60b4c75287a13ed3a16e414c466802c2549ba93c
# Parent 0168d22e6bba2c24342079e49cc65a9a3afef693
fix for SuiteSparse 3.2

diff --git a/liboctave/ChangeLog b/liboctave/ChangeLog
--- a/liboctave/ChangeLog
+++ b/liboctave/ChangeLog
@@ -0,0 +1,6 @@
+2008-10-10 Jaroslav Hajek <highegg@...>
+
+ * sparse-util.h (SparseCholPrint): Change char * argument to const
+ char *.
+ * sparse-util.cc (SparseCholPrint): Likewise.
+
diff --git a/liboctave/sparse-util.cc b/liboctave/sparse-util.cc
--- a/liboctave/sparse-util.cc
+++ b/liboctave/sparse-util.cc
@@ -30,8 +30,15 @@
#include "lo-error.h"
#include "sparse-util.h"

+// FIXME this overload is here due to API change in SuiteSparse (3.1 -> 3.2)
void
SparseCholError (int status, char *file, int line, char *message)
+{
+ SparseCholError (status, file, line, message);
+}
+
+void
+SparseCholError (int status, const char *file, int line, const char *message)
{
(*current_liboctave_warning_handler)("warning %i, at line %i in file %s",
status, line, file);
diff --git a/liboctave/sparse-util.h b/liboctave/sparse-util.h
--- a/liboctave/sparse-util.h
+++ b/liboctave/sparse-util.h
@@ -24,7 +24,11 @@
#if !defined (octave_sparse_util_h)
#define octave_sparse_util_h 1

-extern OCTAVE_API void SparseCholError (int status, char *file, int
line, char *message);
+// FIXME this overload is here due to API change in SuiteSparse (3.1 -> 3.2)
+extern OCTAVE_API void SparseCholError (int status, char *file,
+ int line, char *message);
+extern OCTAVE_API void SparseCholError (int status, const char *file,
+ int line, const char *message);
extern OCTAVE_API int SparseCholPrint (const char *fmt, ...);

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

Re: io package, dlmread

2008-10-10T06:05:50Z

hi,

I have a problem with io package, and dlmread
i want to use dlmread, but i don't find it in the /usr/share/octave/2.1.57/m/io directory

do any one know from where the problem comes?

Re: seperate multiple filenames by non-space character in pkg.m

2008-10-10T02:20:12Z

On Thu, Oct 2, 2008 at 9:02 PM, John W. Eaton <jwe@...> wrote:

> On 2-Oct-2008, John W. Eaton wrote:
>
> | Shouldn't we also do the same thing for the .m files? Should we try
> | to avoid putting a trailing colon at the end of filenames?
> |
> | Or, instead of
> |
> | m = dir (fullfile (src, "*.m"));
> | oct = dir (fullfile (src, "*.oct"));
> | mex = dir (fullfile (src, "*.mex"));
> | archdependent = "";
> | archindependent = "";
> | filenames = "";
> | if (length (m) > 0)
> | filenames = sprintf (fullfile (src, "%s "), m.name);
> | endif
> | if (length (oct) > 0)
> | filenames = cstrcat (filenames, " ",
> | sprintf (fullfile (src, "%s "), oct.name));
> | endif
> | if (length (mex) > 0)
> | filenames = cstrcat (filenames, " ",
> | sprintf (fullfile (src, "%s "), mex.name));
> | endif
> | filenames = split_by (filenames, " ");
> |
> | maybe we could simplify all of this by doing something like
> |
> | m = dir (fullfile (src, "*.m"));
> | oct = dir (fullfile (src, "*.oct"));
> | mex = dir (fullfile (src, "*.mex"));
> |
> | ## FIXME -- we should not need the tests on size here, but there is
> | ## a bug in concatenation with { } when an expression like oct.name
> | ## produces nothing.
> |
> | if (isempty (m)) mnames = { }; else mnames = { m.name }; endif
> | if (isempty (oct)) octnames = { }; else octnames = { oct.name }; endif
> | if (isempty (mex)) mexnames = { }; else mexnames = { mex.name }; endif
> |
> | filenames = cellfun (@(x) fullfile (src, x), [mnames, octnames, mexnames],
> | "UniformOutput", false);
> |
> | Of course this could be further simplified if the bug is fixed, so I'll
> | take a look at doing that.
> |
> | Also, why are archdependent and archindependent even set in this
> | block? They appear to be set unconditionally just below.
>
> I checked in a bug fix so now things like
>
> x = dir ("nonexistent-file");
> {x.name}
>
> does the right thing and produces an empty cell array instead of a
> cell array containing an undefined value.
>
> Then I also checked in a fix for pkg.m as outlined above (but without
> the isempty checks).
>

I transplanted both of them to 3.0.x.

--
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

Re: quote directory names in pkg.m

2008-10-10T02:14:56Z

On Thu, Oct 2, 2008 at 7:26 PM, John W. Eaton <jwe@...> wrote:

> On 2-Oct-2008, Benjamin Lindner wrote:
>
> | Benjamin Lindner wrote:
> | > Hello,
> | >
> | > Using the package manager in octave 3.0.2 to install forge-packages
> | > currently fails in win32 if the directories used in the build process
> | > contain spaces (like TMP does by default on win32).
> | >
> | > The attached patch fixes this
> |
> | I realized, I should have attached a changeset against current HG
> | sources, sorry.
>
> I applied this change.
>
> Your ChangeLog entry shoudl have been added to the scripts/ChangeLog file.
>

I transplanted it to 3.0.x.

--
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

Re: [OctDev] A Bug in Octave-OdePkg

2008-10-09T19:49:28Z

On Wed, 2008-10-08 at 21:33 +0200, Thomas Treichl wrote:

> Wang Long schrieb:
> > Hi Thomas,
> >
> > Thank you very much in helping me with this problem! The solution in
> > your email solved the problem I mentioned before, but when I tried some
> > other t_in's, for example,
> > t_in_2=[0.00 0.10 0.23 0.38 0.63 1.21 1.97];
> > t_in_3=[0.00 0.03 0.05 0.11 0.17 0.25 0.38 0.47 0.68 0.91 1.38 1.98];
> > it seems that the same problem comes out again in the 0.6.0 release of
> > odepkg :(
> >
> > I examined the improper t_out's, and found that every element in them is
> > identical to t_in's, respectively, except those at ``t_out(end-1)'',
> > which is created by ode45. Therefore, can we simply make ode45 check the
> > length of t_out, and delete certain elements of t_out (and ``y'', of
> > course) if the length of t_out is larger than t_in?
> >
> > Thanks!
> >
> > Regards,
> > Wang Long
>
> Hi Wang,
>
> there seems to be another problem in the 0.6.0 solver file(s), I can't see that
> with the current sources. I'll send you a snapshot of the latest solver files
> offside this mailing list in a few minutes (because of the sizes of these
> files). Please try once again with these files...
>
> Thomas

Hi Thomas,

The problem was solved by the snapshot of latest version, thank you very
much!

At first, your latest snapshot of ode45, ode78 and other ode-solvers
does not work at all but complained:
error: structure has no member `OutputSave'
error: evaluating argument list element number 1
error: if: error evaluating conditional expression
error: evaluating if command near line 166, column 3
error: called from `ode45' in file `ode45.m'

I think this is due to the mismatch between `odeset' version 0.6.0 and
the latest snapshot. Then I downloaded the latest version (0.6.4) of
odepkg released at http://octave.sf.net/odepkg/ and tried with my
t_in's, only got another error:
Solving has not been successful. The iterative integration
loop exited at time t = 1.470000 before endpoint at
tend = 1.780000 was reached. This may happen if the
stepsize grows smaller than defined in vminstepsize. Try
to reduce the value of "InitialStep" and/or "MaxStep" with
the command "odeset".

Fortunately, everything works after the ode45 and other ode-solvers in
odepkg version 0.6.4 were overwritten with your latest version. Thank
you for your continuously help!

Best wishes and regards!

Wang Long

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

octave-3.0.2: compilation error csparse.cc

2008-10-09T19:18:13Z

Hi,

I get an error during compilation of octave-3.0.2.

Architecture: Linux localhost.localdomain 2.6.18-92.1.13.el5 #1 SMP Wed Sep 24 16:44:34 EDT 2008 i686 i686 i386 GNU/Linux

gcc: version 4.1.2
g++: version 4.1.2

make[2]: Entering directory `/opt/octave/octave-3.0.2/liboctave'
g++ -c -I/usr/include/suitesparse -fPIC -I. -I.. -I../liboctave -I../src -I../libcruft/misc -DHAVE_CONFIG_H -mieee-fp -Wall -W -Wshadow -Wold-style-cast -g -O2 CSparse.cc -o pic/CSparse.o
CSparse.cc: In member function ‘ComplexMatrix SparseComplexMatrix::fsolve(MatrixType&, const Matrix&, octave_idx_type&, double&, void (*)(double), bool) const’:
CSparse.cc:5769: error: invalid conversion from ‘void (*)(int, char*, int, char*)’ to ‘void (*)(int, const char*, int, const char*)’
CSparse.cc: In member function ‘SparseComplexMatrix SparseComplexMatrix::fsolve(MatrixType&, const SparseMatrix&, octave_idx_type&, double&, void (*)(double), bool) const’:
CSparse.cc:6012: error: invalid conversion from ‘void (*)(int, char*, int, char*)’ to ‘void (*)(int, const char*, int, const char*)’
CSparse.cc: In member function ‘ComplexMatrix SparseComplexMatrix::fsolve(MatrixType&, const ComplexMatrix&, octave_idx_type&, double&, void (*)(double), bool) const’:
CSparse.cc:6303: error: invalid conversion from ‘void (*)(int, char*, int, char*)’ to ‘void (*)(int, const char*, int, const char*)’
CSparse.cc: In member function ‘SparseComplexMatrix SparseComplexMatrix::fsolve(MatrixType&, const SparseComplexMatrix&, octave_idx_type&, double&, void (*)(double), bool) const’:
CSparse.cc:6525: error: invalid conversion from ‘void (*)(int, char*, int, char*)’ to ‘void (*)(int, const char*, int, const char*)’
make[2]: *** [pic/CSparse.o] Error 1
make[2]: Leaving directory `/opt/octave/octave-3.0.2/liboctave'
make[1]: *** [liboctave] Error 2
make[1]: Leaving directory `/opt/octave/octave-3.0.2'
make: *** [all] Error 2

I attached the config.log here: config.log

I need help to resolve this issue. Please let me know if you need more information.

Thanks for your help and advice.

Ciao, Juergen

Re: plot with gnuplot and scite

2008-10-09T10:38:23Z

SUBE Samuel wrote:

When i use Scite to execute a octave script, "go" command, the plot
disappear after around one second.
I use octave 3 under windows XP installed using the windows setup file
named "octave-3.0.0-setup.exe".
I choose Gnuplot and i launch Scite with "Edit" command.

Just add the "pause;" command at the end of your matlab/octave script and the screen will stay up until you hit a key. Enjoy!

Re: fileparts / fullfile inconsistency

2008-10-08T11:10:55Z

On 3-Oct-2008, Søren Hauberg wrote:

| fre, 03 10 2008 kl. 16:25 +0200, skrev Francesco Potorti`:
| > octave> [a b c]=fileparts("/file.ext"), fullfile(a,[b c])
| > a =
| > b = file
| > c = .ext
| > ans = file.ext
|
| Matlab sets a = '/' here, which I guess makes sense. So, I'd say this is a bug in Octave.

I checked in the following changes.

Thanks,

jwe

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

Re: test failures

2008-10-07T23:04:32Z

On Tue, Oct 7, 2008 at 9:33 PM, Kai Habel <kai.habel@...> wrote:

> Jaroslav Hajek schrieb:
>> On Tue, Oct 7, 2008 at 9:09 PM, Kai Habel <kai.habel@...> wrote:
>>
>>> Jaroslav Hajek schrieb:
>>>
>>>> On Tue, Oct 7, 2008 at 8:34 PM, Kai Habel <kai.habel@...> wrote:
>>>>
>>>>
>>>>> Jaroslav Hajek schrieb:
>>>>>
>>>>>
>>>>>> On Tue, Oct 7, 2008 at 8:13 PM, Kai Habel <kai.habel@...> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Jaroslav Hajek schrieb:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Tue, Oct 7, 2008 at 7:44 PM, Kai Habel <kai.habel@...> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> With today's checkout, I see the following problem:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>> processing /home/kai/hg-octave/octave/liboctave/oct-inttypes.cc
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>> 63 ***** assert(int64(2**63),intmax("int64"))
>>>>>>>>> 64 !!!!! test failed
>>>>>>>>> 65 assert (int64 (2 ^ 63),intmax ("int64")) expected
>>>>>>>>> 66 9223372036854775807
>>>>>>>>> 67 but got
>>>>>>>>> 68 -9223372036854775808
>>>>>>>>> 69 values do not match ***** assert(uint64(2**64),intmax("uint64"))
>>>>>>>>> 70 !!!!! test failed
>>>>>>>>> 71 assert (uint64 (2 ^ 64),intmax ("uint64")) expected
>>>>>>>>> 72 18446744073709551615
>>>>>>>>> 73 but got
>>>>>>>>> 74 0
>>>>>>>>> 75 values do not match>>>>> processing
>>>>>>>>> /home/kai/hg-octave/octave/scripts/audio/wavwrite.m
>>>>>>>>>
>>>>>>>>> using ./run-octave I get:
>>>>>>>>>
>>>>>>>>> octave:7> int64(2**63)
>>>>>>>>> ans = -9223372036854775808
>>>>>>>>> octave:8> int64(2^63)
>>>>>>>>> ans = -9223372036854775808
>>>>>>>>> octave:9> intmax ("int64")
>>>>>>>>> ans = 9223372036854775807
>>>>>>>>> octave:10> intmax ("uint64")
>>>>>>>>> ans = 18446744073709551615
>>>>>>>>> octave:11> uint64(2**64)
>>>>>>>>> ans = 0
>>>>>>>>> octave:12> uint64(2^64)
>>>>>>>>> ans = 0
>>>>>>>>>
>>>>>>>>> This is on a X86, 64bit system.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Can you please check your config.h for these macros?
>>>>>>>> (and tell me whether they're defined and if yes, to what)
>>>>>>>> HAVE_FAST_INT_OPS
>>>>>>>> SIZEOF_LONG_DOUBLE
>>>>>>>> HAVE_RANDL
>>>>>>>>
>>>>>>>> thanx
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> Sure,
>>>>>>>
>>>>>>> 248 /* Define if signed integers use two's complement */
>>>>>>> 249 #define HAVE_FAST_INT_OPS 1
>>>>>>>
>>>>>>> 956 /* The size of `long double', as computed by sizeof. */
>>>>>>> 957 #define SIZEOF_LONG_DOUBLE 16
>>>>>>>
>>>>>>> I have no string "HAVE_RANDL" in config.h
>>>>>>>
>>>>>>> Kai
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Huh, sorry. It should have been HAVE_ROUNDL. I guess you probably have
>>>>>> it. Still, the part that is failing should work independently of
>>>>>> whether
>>>>>> you have long double (apparently you do, so you should be benefitting
>>>>>> of the faster mixed int64 arithmetics)
>>>>>>
>>>>>> Would you mind if I send you a patch adding a couple of debug prints
>>>>>> that should try to reveal what is wrong? (You will need to recompile
>>>>>> Octave).
>>>>>>
>>>>>> The int64 arithmetics is fresh stuff, so bugs can be expected; still,
>>>>>> I don't really see what can be wrong here. I hope the debug prints
>>>>>> could illuminate me.
>>>>>>
>>>>>> regards
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> O.k. I have
>>>>>
>>>>> 575 /* Define to 1 if you have the `roundl' function. */
>>>>> 576 #define HAVE_ROUNDL 1
>>>>>
>>>>> Yes I am happy to assist you with some tests, but only tonight or again
>>>>> next week (sorry I am very busy for the time being).
>>>>>
>>>>>
>>>>>
>>>> OK, then please try the following patch (the simplest way is via
>>>> mercurial queues),
>>>> recompile, the run octave in place (./run-octave), type
>>>> int64(2^63)
>>>> uint64(2^64)
>>>> and please report the output...
>>>>
>>>>
>>>>
>>>>
>>>>> Kai
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>> After applying your patch recompiling and running ./run-octave
>>> I get:
>>>
>>> octave:1> int64(2^63)
>>> check1: 2048
>>> check2: -9.22337e+18
>>> check3: -2048
>>> ans = -9223372036854775808
>>> octave:2> uint64(2^64)
>>> check1: 9.22337e+18
>>> check2: 4096
>>> check3: 9.22337e+18
>>> ans = 0
>>> octave:3>
>>>
>>> Kai
>>>
>>>
>>
>> Thanks. I guess compiler optimization is interfering in
>> octave_base_int<T>::compute_threshold.
>> Do you use GCC or something else? I'll try to code up something more
>> robust. If I can have another bit of your time,
>> I'd like to know the output of the following small program using, if
>> possible, the same compiler & flags as those you
>> compile Octave with, and then using no optimization (-O0).
>>
>> Many thanks.
>>
>> #include <iostream>
>> #include <limits>
>> #include <inttypes.h>
>>
>> int main ()
>> {
>> int64_t orig_val = std::numeric_limits<int64_t>::max ();
>> double val = orig_val;
>> if (static_cast<int64_t> (val) != orig_val)
>> std::cout << "!=\n";
>> else
>> std::cout << "==\n";
>> }
>>
>>
>>
>>
>>
>>
>>
>
> kai@linuxpc:~$ cat int64_test.cc
> #include <iostream>
> #include <limits>
> #include <inttypes.h>
>
> int main ()
> {
> int64_t orig_val = std::numeric_limits<int64_t>::max ();
> double val = orig_val;
> if (static_cast<int64_t> (val) != orig_val)
> std::cout << "!=\n";
> else
> std::cout << "==\n";
> }
>
> I see already a difference for -O0 and -O2
>
> kai@linuxpc:~$ g++ -O2 int64_test.cc
> kai@linuxpc:~$ ./a.out
> ==
> kai@linuxpc:~$ g++ -O0 int64_test.cc
> kai@linuxpc:~$ ./a.out
> !=
>
>
> kai@linuxpc:~$ g++ --version
> g++ (SUSE Linux) 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision
> 135036]
> Copyright (C) 2008 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
>
> Kai
>

Hi Kai,

the changes are now committed into development tree. Please let me
know if your problem persists. Thanks for your cooperation.

regards

--
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

Re: [OctDev] A Bug in Octave-OdePkg

2008-10-07T19:23:17Z

On Tue, 2008-10-07 at 23:01 +0200, Thomas Treichl wrote:

> Wang Long schrieb:
> > Hi,
> >
> > When I was running this in octave:
> >
> > t_in = [0 0.05 0.13 0.19];
> > [t_out, y] = ode45 (@(t,x) x, t_in, 1);
> >
> > I got t_out=[0.00000 0.05000 0.10000 0.15000 0.19000]. While the
> > length of t_in is 4, I found that of t_out is 5 instead of 4. However
> > the length of t_in and t_out should be identical. This bug also exists
> > in ode23, ode54, ode78, etc.
> >
> > I'm using octave on Ubuntu, and the file "ode45.m" belongs to the
> > package "octave-odepkg" version 0.6.0-1.
> >
> > Any ideas? Thank you all.
> >
> > Regards,
> > Wang Long
>
> Hi Wang,
>
> please change line number 406 (file ode45.m) originally from
>
> vstepsize = vslot(1,vcntloop-1) - vslot(1,vcntloop-2);
>
> into
>
> vstepsize = vslot(vcntloop) - vslot(vcntloop-1);
>
> Does this fix the ode45 problem for the 0.6.0 release of the package? At least
> it seems to fix the problem for the latest sources and the next package that
> will become available.
>
> Thomas

Hi Thomas,

Thank you very much in helping me with this problem! The solution in
your email solved the problem I mentioned before, but when I tried some
other t_in's, for example,
t_in_2=[0.00 0.10 0.23 0.38 0.63 1.21 1.97];
t_in_3=[0.00 0.03 0.05 0.11 0.17 0.25 0.38 0.47 0.68 0.91 1.38 1.98];
it seems that the same problem comes out again in the 0.6.0 release of
odepkg :(

I examined the improper t_out's, and found that every element in them is
identical to t_in's, respectively, except those at ``t_out(end-1)'',
which is created by ode45. Therefore, can we simply make ode45 check the
length of t_out, and delete certain elements of t_out (and ``y'', of
course) if the length of t_out is larger than t_in?

Thanks!

Regards,
Wang Long

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

Re: test failures

2008-10-07T12:43:36Z

On Tue, Oct 7, 2008 at 9:33 PM, Kai Habel <kai.habel@...> wrote:

Just what I expected. Many thanks.

> kai@linuxpc:~$ g++ --version
> g++ (SUSE Linux) 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision
> 135036]
> Copyright (C) 2008 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
>
> Kai
>

--
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

Re: test failures

2008-10-07T12:33:40Z

Jaroslav Hajek schrieb:

> On Tue, Oct 7, 2008 at 9:09 PM, Kai Habel <kai.habel@...> wrote:
>
>> Jaroslav Hajek schrieb:
>>
>>> On Tue, Oct 7, 2008 at 8:34 PM, Kai Habel <kai.habel@...> wrote:
>>>
>>>
>>>> Jaroslav Hajek schrieb:
>>>>
>>>>
>>>>> On Tue, Oct 7, 2008 at 8:13 PM, Kai Habel <kai.habel@...> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Jaroslav Hajek schrieb:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Tue, Oct 7, 2008 at 7:44 PM, Kai Habel <kai.habel@...> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> With today's checkout, I see the following problem:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>> processing /home/kai/hg-octave/octave/liboctave/oct-inttypes.cc
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>> 63 ***** assert(int64(2**63),intmax("int64"))
>>>>>>>> 64 !!!!! test failed
>>>>>>>> 65 assert (int64 (2 ^ 63),intmax ("int64")) expected
>>>>>>>> 66 9223372036854775807
>>>>>>>> 67 but got
>>>>>>>> 68 -9223372036854775808
>>>>>>>> 69 values do not match ***** assert(uint64(2**64),intmax("uint64"))
>>>>>>>> 70 !!!!! test failed
>>>>>>>> 71 assert (uint64 (2 ^ 64),intmax ("uint64")) expected
>>>>>>>> 72 18446744073709551615
>>>>>>>> 73 but got
>>>>>>>> 74 0
>>>>>>>> 75 values do not match>>>>> processing
>>>>>>>> /home/kai/hg-octave/octave/scripts/audio/wavwrite.m
>>>>>>>>
>>>>>>>> using ./run-octave I get:
>>>>>>>>
>>>>>>>> octave:7> int64(2**63)
>>>>>>>> ans = -9223372036854775808
>>>>>>>> octave:8> int64(2^63)
>>>>>>>> ans = -9223372036854775808
>>>>>>>> octave:9> intmax ("int64")
>>>>>>>> ans = 9223372036854775807
>>>>>>>> octave:10> intmax ("uint64")
>>>>>>>> ans = 18446744073709551615
>>>>>>>> octave:11> uint64(2**64)
>>>>>>>> ans = 0
>>>>>>>> octave:12> uint64(2^64)
>>>>>>>> ans = 0
>>>>>>>>
>>>>>>>> This is on a X86, 64bit system.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> Can you please check your config.h for these macros?
>>>>>>> (and tell me whether they're defined and if yes, to what)
>>>>>>> HAVE_FAST_INT_OPS
>>>>>>> SIZEOF_LONG_DOUBLE
>>>>>>> HAVE_RANDL
>>>>>>>
>>>>>>> thanx
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Sure,
>>>>>>
>>>>>> 248 /* Define if signed integers use two's complement */
>>>>>> 249 #define HAVE_FAST_INT_OPS 1
>>>>>>
>>>>>> 956 /* The size of `long double', as computed by sizeof. */
>>>>>> 957 #define SIZEOF_LONG_DOUBLE 16
>>>>>>
>>>>>> I have no string "HAVE_RANDL" in config.h
>>>>>>
>>>>>> Kai
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> Huh, sorry. It should have been HAVE_ROUNDL. I guess you probably have
>>>>> it. Still, the part that is failing should work independently of
>>>>> whether
>>>>> you have long double (apparently you do, so you should be benefitting
>>>>> of the faster mixed int64 arithmetics)
>>>>>
>>>>> Would you mind if I send you a patch adding a couple of debug prints
>>>>> that should try to reveal what is wrong? (You will need to recompile
>>>>> Octave).
>>>>>
>>>>> The int64 arithmetics is fresh stuff, so bugs can be expected; still,
>>>>> I don't really see what can be wrong here. I hope the debug prints
>>>>> could illuminate me.
>>>>>
>>>>> regards
>>>>>
>>>>>
>>>>>
>>>>>
>>>> O.k. I have
>>>>
>>>> 575 /* Define to 1 if you have the `roundl' function. */
>>>> 576 #define HAVE_ROUNDL 1
>>>>
>>>> Yes I am happy to assist you with some tests, but only tonight or again
>>>> next week (sorry I am very busy for the time being).
>>>>
>>>>
>>>>
>>> OK, then please try the following patch (the simplest way is via
>>> mercurial queues),
>>> recompile, the run octave in place (./run-octave), type
>>> int64(2^63)
>>> uint64(2^64)
>>> and please report the output...
>>>
>>>
>>>
>>>
>>>> Kai
>>>>
>>>>
>>>>
>>>
>>>
>>>
>> After applying your patch recompiling and running ./run-octave
>> I get:
>>
>> octave:1> int64(2^63)
>> check1: 2048
>> check2: -9.22337e+18
>> check3: -2048
>> ans = -9223372036854775808
>> octave:2> uint64(2^64)
>> check1: 9.22337e+18
>> check2: 4096
>> check3: 9.22337e+18
>> ans = 0
>> octave:3>
>>
>> Kai
>>
>>
>
> Thanks. I guess compiler optimization is interfering in
> octave_base_int<T>::compute_threshold.
> Do you use GCC or something else? I'll try to code up something more
> robust. If I can have another bit of your time,
> I'd like to know the output of the following small program using, if
> possible, the same compiler & flags as those you
> compile Octave with, and then using no optimization (-O0).
>
> Many thanks.
>
> #include <iostream>
> #include <limits>
> #include <inttypes.h>
>
> int main ()
> {
> int64_t orig_val = std::numeric_limits<int64_t>::max ();
> double val = orig_val;
> if (static_cast<int64_t> (val) != orig_val)
> std::cout << "!=\n";
> else
> std::cout << "==\n";
> }
>
>
>
>
>
>
>

kai@linuxpc:~$ cat int64_test.cc
#include <iostream>
#include <limits>
#include <inttypes.h>

int main ()
{
int64_t orig_val = std::numeric_limits<int64_t>::max ();
double val = orig_val;
if (static_cast<int64_t> (val) != orig_val)
std::cout << "!=\n";
else
std::cout << "==\n";
}

I see already a difference for -O0 and -O2

kai@linuxpc:~$ g++ -O2 int64_test.cc
kai@linuxpc:~$ ./a.out
==
kai@linuxpc:~$ g++ -O0 int64_test.cc
kai@linuxpc:~$ ./a.out
!=

kai@linuxpc:~$ g++ --version
g++ (SUSE Linux) 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision
135036]
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

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

Re: test failures

2008-10-07T12:26:40Z

On Tue, Oct 7, 2008 at 9:09 PM, Kai Habel <kai.habel@...> wrote:

> Jaroslav Hajek schrieb:
>> On Tue, Oct 7, 2008 at 8:34 PM, Kai Habel <kai.habel@...> wrote:
>>
>>> Jaroslav Hajek schrieb:
>>>
>>>> On Tue, Oct 7, 2008 at 8:13 PM, Kai Habel <kai.habel@...> wrote:
>>>>
>>>>
>>>>> Jaroslav Hajek schrieb:
>>>>>
>>>>>
>>>>>> On Tue, Oct 7, 2008 at 7:44 PM, Kai Habel <kai.habel@...> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> With today's checkout, I see the following problem:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>> processing /home/kai/hg-octave/octave/liboctave/oct-inttypes.cc
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>> 63 ***** assert(int64(2**63),intmax("int64"))
>>>>>>> 64 !!!!! test failed
>>>>>>> 65 assert (int64 (2 ^ 63),intmax ("int64")) expected
>>>>>>> 66 9223372036854775807
>>>>>>> 67 but got
>>>>>>> 68 -9223372036854775808
>>>>>>> 69 values do not match ***** assert(uint64(2**64),intmax("uint64"))
>>>>>>> 70 !!!!! test failed
>>>>>>> 71 assert (uint64 (2 ^ 64),intmax ("uint64")) expected
>>>>>>> 72 18446744073709551615
>>>>>>> 73 but got
>>>>>>> 74 0
>>>>>>> 75 values do not match>>>>> processing
>>>>>>> /home/kai/hg-octave/octave/scripts/audio/wavwrite.m
>>>>>>>
>>>>>>> using ./run-octave I get:
>>>>>>>
>>>>>>> octave:7> int64(2**63)
>>>>>>> ans = -9223372036854775808
>>>>>>> octave:8> int64(2^63)
>>>>>>> ans = -9223372036854775808
>>>>>>> octave:9> intmax ("int64")
>>>>>>> ans = 9223372036854775807
>>>>>>> octave:10> intmax ("uint64")
>>>>>>> ans = 18446744073709551615
>>>>>>> octave:11> uint64(2**64)
>>>>>>> ans = 0
>>>>>>> octave:12> uint64(2^64)
>>>>>>> ans = 0
>>>>>>>
>>>>>>> This is on a X86, 64bit system.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Can you please check your config.h for these macros?
>>>>>> (and tell me whether they're defined and if yes, to what)
>>>>>> HAVE_FAST_INT_OPS
>>>>>> SIZEOF_LONG_DOUBLE
>>>>>> HAVE_RANDL
>>>>>>
>>>>>> thanx
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> Sure,
>>>>>
>>>>> 248 /* Define if signed integers use two's complement */
>>>>> 249 #define HAVE_FAST_INT_OPS 1
>>>>>
>>>>> 956 /* The size of `long double', as computed by sizeof. */
>>>>> 957 #define SIZEOF_LONG_DOUBLE 16
>>>>>
>>>>> I have no string "HAVE_RANDL" in config.h
>>>>>
>>>>> Kai
>>>>>
>>>>>
>>>>>
>>>> Huh, sorry. It should have been HAVE_ROUNDL. I guess you probably have
>>>> it. Still, the part that is failing should work independently of
>>>> whether
>>>> you have long double (apparently you do, so you should be benefitting
>>>> of the faster mixed int64 arithmetics)
>>>>
>>>> Would you mind if I send you a patch adding a couple of debug prints
>>>> that should try to reveal what is wrong? (You will need to recompile
>>>> Octave).
>>>>
>>>> The int64 arithmetics is fresh stuff, so bugs can be expected; still,
>>>> I don't really see what can be wrong here. I hope the debug prints
>>>> could illuminate me.
>>>>
>>>> regards
>>>>
>>>>
>>>>
>>> O.k. I have
>>>
>>> 575 /* Define to 1 if you have the `roundl' function. */
>>> 576 #define HAVE_ROUNDL 1
>>>
>>> Yes I am happy to assist you with some tests, but only tonight or again
>>> next week (sorry I am very busy for the time being).
>>>
>>>
>>
>> OK, then please try the following patch (the simplest way is via
>> mercurial queues),
>> recompile, the run octave in place (./run-octave), type
>> int64(2^63)
>> uint64(2^64)
>> and please report the output...
>>
>>
>>
>>> Kai
>>>
>>>
>>
>>
>>
>>
> After applying your patch recompiling and running ./run-octave
> I get:
>
> octave:1> int64(2^63)
> check1: 2048
> check2: -9.22337e+18
> check3: -2048
> ans = -9223372036854775808
> octave:2> uint64(2^64)
> check1: 9.22337e+18
> check2: 4096
> check3: 9.22337e+18
> ans = 0
> octave:3>
>
> Kai
>

Thanks. I guess compiler optimization is interfering in
octave_base_int<T>::compute_threshold.
Do you use GCC or something else? I'll try to code up something more
robust. If I can have another bit of your time,
I'd like to know the output of the following small program using, if
possible, the same compiler & flags as those you
compile Octave with, and then using no optimization (-O0).

Many thanks.

#include <iostream>
#include <limits>
#include <inttypes.h>

int main ()
{
int64_t orig_val = std::numeric_limits<int64_t>::max ();
double val = orig_val;
if (static_cast<int64_t> (val) != orig_val)
std::cout << "!=\n";
else
std::cout << "==\n";
}

--
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

Re: test failures

2008-10-07T12:09:08Z

Jaroslav Hajek schrieb:

> On Tue, Oct 7, 2008 at 8:34 PM, Kai Habel <kai.habel@...> wrote:
>
>> Jaroslav Hajek schrieb:
>>
>>> On Tue, Oct 7, 2008 at 8:13 PM, Kai Habel <kai.habel@...> wrote:
>>>
>>>
>>>> Jaroslav Hajek schrieb:
>>>>
>>>>
>>>>> On Tue, Oct 7, 2008 at 7:44 PM, Kai Habel <kai.habel@...> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> With today's checkout, I see the following problem:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>>> processing /home/kai/hg-octave/octave/liboctave/oct-inttypes.cc
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>> 63 ***** assert(int64(2**63),intmax("int64"))
>>>>>> 64 !!!!! test failed
>>>>>> 65 assert (int64 (2 ^ 63),intmax ("int64")) expected
>>>>>> 66 9223372036854775807
>>>>>> 67 but got
>>>>>> 68 -9223372036854775808
>>>>>> 69 values do not match ***** assert(uint64(2**64),intmax("uint64"))
>>>>>> 70 !!!!! test failed
>>>>>> 71 assert (uint64 (2 ^ 64),intmax ("uint64")) expected
>>>>>> 72 18446744073709551615
>>>>>> 73 but got
>>>>>> 74 0
>>>>>> 75 values do not match>>>>> processing
>>>>>> /home/kai/hg-octave/octave/scripts/audio/wavwrite.m
>>>>>>
>>>>>> using ./run-octave I get:
>>>>>>
>>>>>> octave:7> int64(2**63)
>>>>>> ans = -9223372036854775808
>>>>>> octave:8> int64(2^63)
>>>>>> ans = -9223372036854775808
>>>>>> octave:9> intmax ("int64")
>>>>>> ans = 9223372036854775807
>>>>>> octave:10> intmax ("uint64")
>>>>>> ans = 18446744073709551615
>>>>>> octave:11> uint64(2**64)
>>>>>> ans = 0
>>>>>> octave:12> uint64(2^64)
>>>>>> ans = 0
>>>>>>
>>>>>> This is on a X86, 64bit system.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> Can you please check your config.h for these macros?
>>>>> (and tell me whether they're defined and if yes, to what)
>>>>> HAVE_FAST_INT_OPS
>>>>> SIZEOF_LONG_DOUBLE
>>>>> HAVE_RANDL
>>>>>
>>>>> thanx
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> Sure,
>>>>
>>>> 248 /* Define if signed integers use two's complement */
>>>> 249 #define HAVE_FAST_INT_OPS 1
>>>>
>>>> 956 /* The size of `long double', as computed by sizeof. */
>>>> 957 #define SIZEOF_LONG_DOUBLE 16
>>>>
>>>> I have no string "HAVE_RANDL" in config.h
>>>>
>>>> Kai
>>>>
>>>>
>>>>
>>> Huh, sorry. It should have been HAVE_ROUNDL. I guess you probably have
>>> it. Still, the part that is failing should work independently of
>>> whether
>>> you have long double (apparently you do, so you should be benefitting
>>> of the faster mixed int64 arithmetics)
>>>
>>> Would you mind if I send you a patch adding a couple of debug prints
>>> that should try to reveal what is wrong? (You will need to recompile
>>> Octave).
>>>
>>> The int64 arithmetics is fresh stuff, so bugs can be expected; still,
>>> I don't really see what can be wrong here. I hope the debug prints
>>> could illuminate me.
>>>
>>> regards
>>>
>>>
>>>
>> O.k. I have
>>
>> 575 /* Define to 1 if you have the `roundl' function. */
>> 576 #define HAVE_ROUNDL 1
>>
>> Yes I am happy to assist you with some tests, but only tonight or again
>> next week (sorry I am very busy for the time being).
>>
>>
>
> OK, then please try the following patch (the simplest way is via
> mercurial queues),
> recompile, the run octave in place (./run-octave), type
> int64(2^63)
> uint64(2^64)
> and please report the output...
>
>
>
>> Kai
>>
>>
>
>
>
>

After applying your patch recompiling and running ./run-octave
I get:

octave:1> int64(2^63)
check1: 2048
check2: -9.22337e+18
check3: -2048
ans = -9223372036854775808
octave:2> uint64(2^64)
check1: 9.22337e+18
check2: 4096
check3: 9.22337e+18
ans = 0
octave:3>

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

Re: test failures

2008-10-07T11:47:35Z

On Tue, Oct 7, 2008 at 8:34 PM, Kai Habel <kai.habel@...> wrote:

> Jaroslav Hajek schrieb:
>> On Tue, Oct 7, 2008 at 8:13 PM, Kai Habel <kai.habel@...> wrote:
>>
>>> Jaroslav Hajek schrieb:
>>>
>>>> On Tue, Oct 7, 2008 at 7:44 PM, Kai Habel <kai.habel@...> wrote:
>>>>
>>>>
>>>>> With today's checkout, I see the following problem:
>>>>>
>>>>>
>>>>>
>>>>>>>>>> processing /home/kai/hg-octave/octave/liboctave/oct-inttypes.cc
>>>>>>>>>>
>>>>>>>>>>
>>>>> 63 ***** assert(int64(2**63),intmax("int64"))
>>>>> 64 !!!!! test failed
>>>>> 65 assert (int64 (2 ^ 63),intmax ("int64")) expected
>>>>> 66 9223372036854775807
>>>>> 67 but got
>>>>> 68 -9223372036854775808
>>>>> 69 values do not match ***** assert(uint64(2**64),intmax("uint64"))
>>>>> 70 !!!!! test failed
>>>>> 71 assert (uint64 (2 ^ 64),intmax ("uint64")) expected
>>>>> 72 18446744073709551615
>>>>> 73 but got
>>>>> 74 0
>>>>> 75 values do not match>>>>> processing
>>>>> /home/kai/hg-octave/octave/scripts/audio/wavwrite.m
>>>>>
>>>>> using ./run-octave I get:
>>>>>
>>>>> octave:7> int64(2**63)
>>>>> ans = -9223372036854775808
>>>>> octave:8> int64(2^63)
>>>>> ans = -9223372036854775808
>>>>> octave:9> intmax ("int64")
>>>>> ans = 9223372036854775807
>>>>> octave:10> intmax ("uint64")
>>>>> ans = 18446744073709551615
>>>>> octave:11> uint64(2**64)
>>>>> ans = 0
>>>>> octave:12> uint64(2^64)
>>>>> ans = 0
>>>>>
>>>>> This is on a X86, 64bit system.
>>>>>
>>>>>
>>>>>
>>>> Can you please check your config.h for these macros?
>>>> (and tell me whether they're defined and if yes, to what)
>>>> HAVE_FAST_INT_OPS
>>>> SIZEOF_LONG_DOUBLE
>>>> HAVE_RANDL
>>>>
>>>> thanx
>>>>
>>>>
>>>>
>>>>
>>> Sure,
>>>
>>> 248 /* Define if signed integers use two's complement */
>>> 249 #define HAVE_FAST_INT_OPS 1
>>>
>>> 956 /* The size of `long double', as computed by sizeof. */
>>> 957 #define SIZEOF_LONG_DOUBLE 16
>>>
>>> I have no string "HAVE_RANDL" in config.h
>>>
>>> Kai
>>>
>>>
>>
>> Huh, sorry. It should have been HAVE_ROUNDL. I guess you probably have
>> it. Still, the part that is failing should work independently of
>> whether
>> you have long double (apparently you do, so you should be benefitting
>> of the faster mixed int64 arithmetics)
>>
>> Would you mind if I send you a patch adding a couple of debug prints
>> that should try to reveal what is wrong? (You will need to recompile
>> Octave).
>>
>> The int64 arithmetics is fresh stuff, so bugs can be expected; still,
>> I don't really see what can be wrong here. I hope the debug prints
>> could illuminate me.
>>
>> regards
>>
>>
> O.k. I have
>
> 575 /* Define to 1 if you have the `roundl' function. */
> 576 #define HAVE_ROUNDL 1
>
> Yes I am happy to assist you with some tests, but only tonight or again
> next week (sorry I am very busy for the time being).
>

OK, then please try the following patch (the simplest way is via
mercurial queues),
recompile, the run octave in place (./run-octave), type
int64(2^63)
uint64(2^64)
and please report the output...

> Kai
>

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

[int64_test_patch.diff]

# HG changeset patch # User Jaroslav Hajek <highegg@...> # Date 1223404913 -7200 # Node ID 27ef2720983da6d0631baf34b6878e64599712fd # Parent 9a0a66f650b179c6af41998e18dd2362cc6bc419 [mq]: int64_test_patch.diff diff -r 9a0a66f650b1 -r 27ef2720983d liboctave/oct-inttypes.h --- a/liboctave/oct-inttypes.h Tue Oct 07 15:49:03 2008 +0200 +++ b/liboctave/oct-inttypes.h Tue Oct 07 20:41:53 2008 +0200 @@ -283,6 +283,9 @@ // Compute proper thresholds. static const S thmin = compute_threshold (static_cast<S> (min_val ()), min_val ()); static const S thmax = compute_threshold (static_cast<S> (max_val ()), max_val ()); + std::cout << "check1: " << (thmax - ldexp (1.0, 63)) << '\n'; + std::cout << "check2: " << (thmax - ldexp (1.0, 64)) << '\n'; + std::cout << "check3: " << (thmin - ldexp (-1.0, 63)) << '\n'; if (lo_ieee_isnan (value)) { fnan = true; @@ -290,11 +293,13 @@ } else if (value <= thmin) { + std::cout << "cutoff low\n"; octave_int_base<T>::ftrunc = true; return min_val (); } else if (value >= thmax) { + std::cout << "cutoff low\n"; ftrunc = true; return max_val (); }

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