help-octave
[Top][All Lists]
Advanced

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

how to call functions from symbolic package?


From: Aditya Bhagwat
Subject: how to call functions from symbolic package?
Date: Wed, 1 Sep 2010 11:15:14 +0530 (IST)
User-agent: SquirrelMail/1.4.9a

Dear all,

Where can I find more information on how to call the functions from the
octave "symbolic" package?

There is a function reference on 'sourceforge'
http://octave.sourceforge.net/symbolic/overview.html
But, that is defective for some of the (important) functions. For
instance, for the function 'sym' the only information I get is "Create an
object of type symbol", leaving me wondering with which input/output
arguments the function needs to be called.

I tried looking at the 'symbols.oct' file on my system:
/usr/lib/octave/packages/3.2/symbolic-1.0.9/x86_64-pc-linux-gnu-api-v37/symbols.oct
However, I could not read this file (tried reading with vim). I suppose
it's a compiled file.

Therefore, is there any other source of information on how the functions
from the "octave symbolic" package should be called and used?

Thanks a lot for your help!

Aditya


> Send Help-octave mailing list submissions to
>       address@hidden
>
> To subscribe or unsubscribe via the World Wide Web, visit
>       https://www-old.cae.wisc.edu/mailman/listinfo/help-octave
> or, via email, send a message with subject or body 'help' to
>       address@hidden
>
> You can reach the person managing the list at
>       address@hidden
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Help-octave digest..."
>
>
> Today's Topics:
>
>    1. RE: Compiling Octave 3.2.3 with icpc 10.1 fails: more than
>       one     instance of overloaded function "octave_int_cmp_op::mop"
>       (RUSS BRENNAN)
>    2. Re: new to octave, confused about load(), dlmread et cetera
>       (CdeMills)
>    3. RE: make check: src/DLD-FUNCTIONS/eigs.cc
>       .............................. ** On entry to DLASCL parameter
>       number 4        had an illegal value (RUSS BRENNAN)
>    4. plans for single-precision support? (Tim Rueth)
>    5. Re: plans for single-precision support? (Martin Helm)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 31 Aug 2010 12:22:01 -0500
> From: RUSS BRENNAN <address@hidden>
> Subject: RE: Compiling Octave 3.2.3 with icpc 10.1 fails: more than
>       one     instance of overloaded function "octave_int_cmp_op::mop"
> To: <address@hidden>
> Cc: address@hidden
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
> using -gcc-version=410 solved this issue!  I am using gcc4 to compile, but
> intel apparently checks gcc -v for the version.  Overriding this allowed
> me to compile the test.cc program, even with 10.2! Thanks for the advice,
>
> Russell
>
>> Date: Wed, 25 Aug 2010 12:42:30 +0200
>> Subject: Re: Compiling Octave 3.2.3 with icpc 10.1 fails: more than one
>> instance of overloaded function "octave_int_cmp_op::mop"
>> From: address@hidden
>> To: address@hidden
>> CC: address@hidden
>>
>> On Mon, Aug 23, 2010 at 6:27 PM, RUSS BRENNAN <address@hidden>
>> wrote:
>> > I upgraded to 11.1 and the problem persists:
>> >
>> > address@hidden ~]# icpc -v
>> > Version 11.1
>> > address@hidden ~]# icpc -c test.cc
>> > test.cc(9): error: more than one instance of overloaded function
>> "method"
>> > matches the argument list:
>> >             function template "void method<X,T>(double, T)"
>> >             function template "void method<X>(double, long)"
>> >             argument types are: (double, long)
>> >     method<A> (u, v);
>> >     ^
>> >
>> > compilation aborted for test.cc (code 2)
>> >
>> > Is the patch that you refer to applied to octave or the intel
>> compiler?  In
>> > either case, if there's any chance that you can locate it I would much
>> > appreciate it.  I'm pulling my hair out here trying to get this thing
>> to
>> > compile!  Are you on a 64-bit platform by chance?  I'm working on 32
>> bit
>> > right now.
>> >
>> >
>>
>> Yes, I'm on a 64-bit platform. That may explain the difference. I was
>> using a patch to Octave's sources (patching Intel C++ is not even
>> legal). It appears that it's gone, however.
>>
>> --
>> RNDr. Jaroslav Hajek, PhD
>> computing expert & GNU Octave developer
>> Aeronautical Research and Test Institute (VZLU)
>> Prague, Czech Republic
>> url: www.highegg.matfyz.cz
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> https://www-old.cae.wisc.edu/pipermail/help-octave/attachments/20100831/61a5c6e4/attachment-0001.html
>
> ------------------------------
>
> Message: 2
> Date: Tue, 31 Aug 2010 12:16:04 -0700 (PDT)
> From: CdeMills <address@hidden>
> Subject: Re: new to octave, confused about load(), dlmread et cetera
> To: address@hidden
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=us-ascii
>
>
>
> justin.cress wrote:
>>
>> thanks for all the responses everyone, and, I think the general theme is
>> correct, I was trying to use octave too much like stata...
>>
>> So, if I don't know exactly which order the columns are in (in the data)
>> is
>> there an easy way to let
>>
>> Y = load ( .. args ..)    be a Y var
>>
>> and grab a matrix of X vars like
>>
>> X = load ( ... args ..)
>>
>> I guess my question is, if i just wanted to do basic OLS (or something
>> similar) in octave, what's the general approach?
>>
> Octave is mostly used by engineers, so is more oriented towards numerical
> computations, linear algebra, signal processing and the like.
>
> Regarding the problem of identifying columns from their name, this is the
> purpose of the 'dataframe' package I mentionned, which is similar to R
> data.frame.
>
> About OLS, let say that A is your design matrix, X your unknown and B your
> observations,
> you have to solve Ax = B
> which can be computed as x = A\B
> The '\' is a specific operator, and can detect cases of undetermined /
> badly
> scaled systems.
>
> Regards
>
> Pascal
> --
> View this message in context:
> http://octave.1599824.n4.nabble.com/new-to-octave-confused-about-load-dlmread-et-cetera-tp2400902p2402161.html
> Sent from the Octave - General mailing list archive at Nabble.com.
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 31 Aug 2010 15:26:50 -0500
> From: RUSS BRENNAN <address@hidden>
> Subject: RE: make check: src/DLD-FUNCTIONS/eigs.cc
>       .............................. ** On entry to DLASCL parameter number
>       4       had an illegal value
> To: <address@hidden>
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
> Very astute observation!  That indeed solved the issue.  I have applied
> the graphics magick patch to resolve the imread error,  and now all
> test pass except 8 from the data.cc section. I'll paste the output from
> the first failure here.  I have tried compiling octave with -O2 as well
> as no optimization flag in case that was the issue, to no avail.
>
> ==========================
>   ***** test
>  rt2 = sqrt (2);
>  rt3 = sqrt (3);
>  v = single([0, pi/6, pi/4, pi/3, -pi/3, -pi/4, -pi/6, 0]);
>  y = single([0, rt3, 1, rt3, -rt3, -1, -rt3, 0]);
>  x = single([1, 3, 1, 1, 1, 1, 3, 1]);
>  assert(atan2 (y, x), v, sqrt (eps('single')));
>   ***** error <Invalid call to atan2.*> atan2 ();
>   ***** error <Invalid call to atan2.*> atan2 (1, 2, 3);
>   ***** assert (size (hypot (zeros (0, 2), zeros (0, 2))), [0, 2])
>   ***** assert (size (hypot (rand (2, 3, 4), zeros (2, 3, 4))), [2, 3, 4])
>   ***** assert (size (hypot (rand (2, 3, 4), 1)), [2, 3, 4])
>   ***** assert (size (hypot (1, rand (2, 3, 4))), [2, 3, 4])
>   ***** assert (size (hypot (1, 2)), [1, 1])
>   ***** assert (hypot (1:10, 1:10), sqrt(2) * [1:10], 16*eps)
>   ***** assert (hypot (single(1:10), single(1:10)), single(sqrt(2) *
> [1:10]));
>   ***** assert(log2 ([1/4, 1/2, 1, 2, 4]), [-2, -1, 0, 1, 2]);
>   ***** assert(log2(Inf), Inf);
>   ***** assert(isnan(log2(NaN)));
>   ***** assert(log2(4*i), 2 + log2(1*i));
>   ***** assert(log2(complex(0,Inf)), Inf + log2(i));
> !!!!! test failed
> assert (log2 (complex (0, Inf)),Inf + log2 (i)) expected
> Inf + 2.266i
> but got
> NaN - NaNi
> NaNs don't matchoctave:2>
>
> ==========================
>
>> Date: Tue, 31 Aug 2010 17:08:09 +0200
>>
> Subject: Re: make check: src/DLD-FUNCTIONS/eigs.cc
> .............................. ** On entry to DLASCL parameter number 4
> had an illegal value
>> From: address@hidden
>> To: address@hidden
>> CC: address@hidden
>>
>> On Tue, Aug 31, 2010 at 4:29 PM, RUSS BRENNAN <address@hidden>
>> wrote:
>> > Ok, first let me note that compiling with --without-qrupdate bypasses
>> this
>> > error, as expected.
>> >
>> > Here is the output of test qr.cc verbose.  Note that there are a few
>> errors,
>> > as well as the seg fault near the end.
>> >
>> > If I go through the final test line by line, this is the command that
>> seg
>> > faults:
>> >  [Q,R] = qrupdate(Q,R,single(uc),single(vc))
>> >
>> > The singles() calls alone are ok so it must be qrupdate that does it.
>> I am
>> > using qrupdate v1.1.1, built from source using the following Makeconf:
>> > ================================================================
>> > # set this to your compiler's executable name (e.g. gfortran, g77)
>> > FC=gfortran
>> > # requested flags
>> > FFLAGS=-O0 -funroll-loops
>> > # set if you need shared library
>> > FPICFLAGS=-fPIC
>> >
>>
>> Hi Brennan,
>>
>> you reported earlier that you needed -ff2c to link MKL with
>> gcc/gfortran, which means that your MKL uses the f2c/g77 convention
>> interface. In that case, you almost surely need it here (for qrupdate)
>> as well. Using -O0 should not be necessary. MKL usually comes with
>> multiple interfaces; there should be one for gfortran convention as
>> well.
>>
>> hth
>>
>> --
>> RNDr. Jaroslav Hajek, PhD
>> computing expert & GNU Octave developer
>> Aeronautical Research and Test Institute (VZLU)
>> Prague, Czech Republic
>> url: www.highegg.matfyz.cz
>
>> Date: Tue, 31 Aug 2010 17:08:09 +0200
>> Subject: Re: make check: src/DLD-FUNCTIONS/eigs.cc
>> .............................. ** On entry to DLASCL parameter number 4
>> had an illegal value
>> From: address@hidden
>> To: address@hidden
>> CC: address@hidden
>>
>> On Tue, Aug 31, 2010 at 4:29 PM, RUSS BRENNAN <address@hidden>
>> wrote:
>> > Ok, first let me note that compiling with --without-qrupdate bypasses
>> this
>> > error, as expected.
>> >
>> > Here is the output of test qr.cc verbose.  Note that there are a few
>> errors,
>> > as well as the seg fault near the end.
>> >
>> > If I go through the final test line by line, this is the command that
>> seg
>> > faults:
>> >  [Q,R] = qrupdate(Q,R,single(uc),single(vc))
>> >
>> > The singles() calls alone are ok so it must be qrupdate that does it.
>> I am
>> > using qrupdate v1.1.1, built from source using the following Makeconf:
>> > ================================================================
>> > # set this to your compiler's executable name (e.g. gfortran, g77)
>> > FC=gfortran
>> > # requested flags
>> > FFLAGS=-O0 -funroll-loops
>> > # set if you need shared library
>> > FPICFLAGS=-fPIC
>> >
>>
>> Hi Brennan,
>>
>> you reported earlier that you needed -ff2c to link MKL with
>> gcc/gfortran, which means that your MKL uses the f2c/g77 convention
>> interface. In that case, you almost surely need it here (for qrupdate)
>> as well. Using -O0 should not be necessary. MKL usually comes with
>> multiple interfaces; there should be one for gfortran convention as
>> well.
>>
>> hth
>>
>> --
>> RNDr. Jaroslav Hajek, PhD
>> computing expert & GNU Octave developer
>> Aeronautical Research and Test Institute (VZLU)
>> Prague, Czech Republic
>> url: www.highegg.matfyz.cz
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> https://www-old.cae.wisc.edu/pipermail/help-octave/attachments/20100831/37948710/attachment-0001.html
>
> ------------------------------
>
> Message: 4
> Date: Tue, 31 Aug 2010 14:26:47 -0700
> From: "Tim Rueth" <address@hidden>
> Subject: plans for single-precision support?
> To: <address@hidden>
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset="us-ascii"
>
> Does anyone know when single-precision data types, i.e., single(), will be
> supported?
>
> --Tim
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> https://www-old.cae.wisc.edu/pipermail/help-octave/attachments/20100831/f7d4ba27/attachment-0001.html
>
> ------------------------------
>
> Message: 5
> Date: Wed, 1 Sep 2010 00:20:03 +0200
> From: Martin Helm <address@hidden>
> Subject: Re: plans for single-precision support?
> To: address@hidden, address@hidden
> Message-ID: <address@hidden>
> Content-Type: Text/Plain;  charset="iso-8859-15"
>
> Am Dienstag, 31. August 2010, 23:26:47 schrieb Tim Rueth:
>> Does anyone know when single-precision data types, i.e., single(), will
>> be
>> supported?
>>
>> --Tim
>
> Maybe I do not understand your question, single() is available in octave
> 3.2.4.
>
>
> ------------------------------
>
> _______________________________________________
> Help-octave mailing list
> address@hidden
> https://www-old.cae.wisc.edu/mailman/listinfo/help-octave
>
>
> End of Help-octave Digest, Vol 53, Issue 90
> *******************************************
>
>


-- 
Aditya Bhagwat

Ph.D student
Ghent University (Belgium)
Dept. Appl. Math., Biometrics and Process Control

Currently Erasmus Mundus visiting fellow
University of Pune (India)
Center for Modeling and Simulation


reply via email to

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