[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: hyperg_0F1 doesn't work
From: |
David Bateman |
Subject: |
Re: hyperg_0F1 doesn't work |
Date: |
Mon, 04 Dec 2006 12:09:05 +0100 |
User-agent: |
Thunderbird 1.5.0.7 (X11/20060921) |
Ok, I think I understand what is happening here. Consider the autoload
lines used in the gsl package (and in fact in all of the packages) are
of the form
autoload ("hyperg_0F1", which ("gsl_sf"));
now which("gsl_sf") will return something like
which: `gsl_sf' is the script file
/usr/share/octave/packages//gsl-1.0.0/gsl_sf
where as which("fftn") returns
fftn is the dynamically-linked function from the file
/usr/lib/octave/2.9.9/oct/i586-mandriva-linux-gnu/fftn.oct
The issue is that help.cc(do_which) calls
symbol_record *sym_rec = lookup_by_name (name, 0);
The file is found, however as there is no gsl_sf function in gsl_sf.oct,
the function is not defined and in help.cc(do_which) we fall through to
std::string path = fcn_file_in_path (name);
which incorrectly finds the file without the extension, again because it
finds gsl_sf.oct, but then
const file_info& fi = *i;
int t = fi.types;
(t & load_path::M_FILE)
is not true and the ".oct" is not added in load_path::do_find_fcn,
though the retval maintains the string for the find when it shouldn't.
It doesn't make sense to have lookup_by_name not find the file and then
have fcn_file_in_path find the oct-file, and so I believe the correct
behavior should be to have fcn_file_in_path also fail, and then we need
to adapt gsl_sf to have a dummy gsl_sf function, that should probably
just give a help string..
So, the attached patch to octave, and a second patch for gsl as attached
will completely address this issue.
Regards
David
Peter Soendergaard wrote:
> Try something like
>
> autoload('hyperg_0F1','/usr/lib/octave/site/oct/api-v22/i686-suse-linux/octave-forge/gsl_sf.oct');
>
> I reported this on the bug list, but noone has found out why the loading
> fails for gsl_sf.oct.
>
> The problem seems to be that
>
> which gsl_sf
>
> incorrectly indentifies gsl_sf as a script file, and not as a .oct file.
> Explicitly loading the function corrects the problem.
> This affects all the functions is the gsl library.
>
> Cheers,
>
> Peter.
>
> On Mon, 4 Dec 2006, Torben Mikael Hansen wrote:
>
>
>> Hi
>>
>> I alread posted this on the octave-dev list but it doesn't seem vary active
>> so
>> I'll repost it here. Sorry, if you receive it twice.
>>
>> I have built and installed octave 2.9.9 and octave-forge 2006.07.09 (also
>> called 2006-07-10) and tried to use the "hyperg_0F1" function. However it
>> seems not to be installed.
>>
>> the "gsl_sf.oct" seems to be build correctly
>>
>> nm /usr/lib/octave/site/oct/api-v22/i686-suse-linux/octave-forge/gsl_sf.oct\
>>
>> | grep hyperg
>>
>> 00011860 T FShyperg_0F1_gnu_v3
>> U gsl_sf_hyperg_0F1
>> U gsl_sf_hyperg_0F1_e
>> 00058950 T _Z11Fhyperg_0F1RK17octave_value_listi
>>
>> Looking at the build.log seems to me a bit strage, but honestly I don't
>> really understand it. It seems that the octlink's for gsl are processed
>> before the "gsl_sf.oct" is built. Is that the correct order?
>>
>> "coupling_3j", "coupling_6j", "coupling_9j" are there, but they also have
>> their own cc-file.
>>
>> Regards
>> Torben
>>
>> -------------------------------------------------------------------------
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to share your
>> opinions on IT & business topics through brief surveys - and earn cash
>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________
>> Octave-dev mailing list
>> address@hidden
>> https://lists.sourceforge.net/lists/listinfo/octave-dev
>>
>> -------------------------------------------------------
>> _______________________________________________
>> Help-octave mailing list
>> address@hidden
>> https://www.cae.wisc.edu/mailman/listinfo/help-octave
>>
>>
> _______________________________________________
> Help-octave mailing list
> address@hidden
> https://www.cae.wisc.edu/mailman/listinfo/help-octave
>
>
--
David Bateman address@hidden
Motorola Labs - Paris +33 1 69 35 48 04 (Ph)
Parc Les Algorithmes, Commune de St Aubin +33 6 72 01 06 33 (Mob)
91193 Gif-Sur-Yvette FRANCE +33 1 69 35 77 01 (Fax)
The information contained in this communication has been classified as:
[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary
*** src/load-path.cc.~1.12.~ 2006-11-15 20:52:46.000000000 +0100
--- src/load-path.cc 2006-12-04 11:58:23.745104816 +0100
***************
*** 727,732 ****
--- 727,735 ----
else
error ("load_path::do_find_fcn: %s: invalid type code = %d",
fcn.c_str (), type);
+
+ // Reset the return string, in case the above fails
+ retval = std::string();
}
}
*** main/gsl/src/precode.cc.template.orig 2006-12-04 12:07:08.828971701
+0100
--- main/gsl/src/precode.cc.template 2006-12-04 12:04:43.467123936 +0100
***************
*** 27,32 ****
--- 27,43 ----
error("GSL error %d at %s, line %d: %s\n", gsl_errno, file, line, reason);
}
+ DEFUN_DLD (gsl_sf, args, nargout,
+ "-*- texinfo -*-\n\
+ @deftypefn {Loadable Function} {} gsl_sf ()\n\
+ \n\
+ Octave bindings to the GNU Scientific Library. All GSL functions can be\n\
+ called with by the GSL names within octave.\n\
+ @end deftypefn")
+ {
+ usage("gsl_sf");
+ }
+
/*
;;; Local Variables: ***
;;; mode: C++ ***