On 12/13/2009 octave-dev-requ...@lists.sourceforge.net wrote:
> Date: Sun, 13 Dec 2009 13:41:32 -0500
> From: Eugeniy Mikhailov
> Subject: Re: [OctDev] optim/leasqr.m style changes, diff
> To: octave-dev@lists.sourceforge.net
> Message-ID: <20091213184132.ga26...@beam>
> Content-Type: text/plain;
On 11/22/2009 octave-dev-requ...@lists.sourceforge.net wrote:
> Date: Sun, 22 Nov 2009 21:38:07 -0500 From: "Steven G. Johnson"
>
> Well, it depends what you mean by "integrate". Certainly,
> licensewise I think there should be no problem (LGPL), and as I said
> NLopt already comes with an Octa
On 11/22/2009 octave-dev-requ...@lists.sourceforge.net wrote:
> Date: Sun, 22 Nov 2009 22:20:38 +0100
> From: S?ren Hauberg
> Subject: Re: [OctDev] Release system / web page generation
> To: Carlo de Falco
> Cc: Octave Forge
> Message-ID: <1258924838.2637.78.ca...@hauberg-laptop>
> Content-Type
Esteban Voehringer-Martinez wrote:
> Jonathan Stickel wrote:
>> Esteban Voehringer-Martinez wrote:
>>> Jonathan Stickel wrote:
>>
>> OK, let's try to figure out what part is broken and see if we can
>> correct it for your 3.0.1 installation. Removing an
Esteban Voehringer-Martinez wrote:
> Jonathan Stickel wrote:
>> On 9/16/09 help-octave-requ...@octave.org wrote:
>>> Date: Tue, 15 Sep 2009 13:14:25 -0700 (PDT)
>>> From: esteban1
>>> Subject: regdatasmooth
>>> To: help-oct...@octave.org
>>> M
On 9/16/09 help-octave-requ...@octave.org wrote:
> Date: Tue, 15 Sep 2009 13:14:25 -0700 (PDT)
> From: esteban1
> Subject: regdatasmooth
> To: help-oct...@octave.org
> Message-ID: <25461009.p...@talk.nabble.com>
> Content-Type: text/plain; charset=us-ascii
>
>
> Hi,
>
> I have a problem with th
On 7/23/09 Jaroslav Hajek wrote:
>> BTW, I find it confusing that optimization functions are split
>> between
>>> Octave and the octave-forge package. At one point, I thought
>>> there was a plan to keep associated functions together, either
>>> all in Octave or in the appropriate octave-forge pac
Jaroslav Hajek wrote:
> On Wed, Jul 22, 2009 at 5:54 PM, Jonathan Stickel wrote:
>> I just checked in a small bug fix to the nelder_mead_min function
>> regarding some trouble with parsing the list or cell arguments. Someone
>> more familiar with the function might want t
I just checked in a small bug fix to the nelder_mead_min function
regarding some trouble with parsing the list or cell arguments. Someone
more familiar with the function might want to check that I didn't
break anything. I did check that the test script test_nelder_mead_min_1
passes all test
On 5/8/09 octave-dev-requ...@lists.sourceforge.net wrote:
> The practical consequence is that I won't be able to make a release in
> the very near future. I hope to some time on Friday (which is a holiday
> in Denmark), and during next week. So hopefully, I'll be able to have
> the new system ready
Søren Hauberg wrote:
> tir, 23 12 2008 kl. 07:56 -0700, skrev Jonathan Stickel:
>> On 12/22/08 octave-dev-requ...@lists.sourceforge.net wrote:
>>> What I suggest is that package maintainers makes the releases. The
>>> only thing they wont be able to do is to upload the
orzcatna (matrix1,matrix2,...)
%%
%% Return the horizontal concatenation of the provided matrices. For
%% matrices with different numbers of rows, NA values are inserted
%% into the empty elements.
%% author: Jonathan Stickel
%% created: 11/14/08
%% modified: 12/5/08
function retvar = horz
I am the data-smoothing maintainer. I am on vacation until Monday and
will probably not be reading email to the list carefully.
Jonathan
>> Von: so...@hauberg.org
>> Datum: 17.02.2009 19:58
>> An:
>> Betreff: [OctDev] Looking for maintainers
>>
>> Hi All
>>
>> I would like to move us to a rel
On 12/22/08 octave-dev-requ...@lists.sourceforge.net wrote:
> What I suggest is that package maintainers makes the releases. The
> only thing they wont be able to do is to upload the packages and web
> pages to Sourceforge. That is, when a maintainer decides to make a
> release he/she creates the
Soren
I just noticed that the data-smoothing package seems to be have been
dropped from the package list and function reference on the Octave-forge
website. Can this be fixed?
Thanks,
Jonathan
P.S.
I've been watching the web-hosting discussion on the lists, and I guess
this is the sort of tr
, but
now future improvements should only be the addition of new options.
Jonathan
[EMAIL PROTECTED] wrote:
> Quoting Jonathan Stickel <[EMAIL PROTECTED]>:
>> I am rewriting the functions in the data-smoothing package. The code is
>> done and bug-checked as best I could. I
I am rewriting the functions in the data-smoothing package. The code is
done and bug-checked as best I could. I just need to rewrite the help
and demos. If you could give me until the end of the week, that would
be great.
Thanks,
Jonathan
On 8/18/08 [EMAIL PROTECTED] wrote:
> Date: Mon, 18
I found the help text for svn import to be a little confusing. I think
the example should rather read:
$ cd package/..
$ svn import package \
https://octave.svn.sourceforge.net/svnroot/octave/trunk/octave-forge/main/package
Jonathan
David Bateman wrote:
> Jonathan Stickel wrote:
>> Firstly, I would like to ask about the spline-gcvspl package, which
>> provides a nice way to smooth data. What is the origin of the non-free
>> license? I looked at the source link for the fortran dependency and
>>
Jaroslav Hajek wrote:
> On Mon, Mar 31, 2008 at 5:38 PM, Jonathan Stickel <[EMAIL PROTECTED]> wrote:
>> Firstly, I would like to ask about the spline-gcvspl package, which
>> provides a nice way to smooth data. What is the origin of the non-free
>> license? I looked
Firstly, I would like to ask about the spline-gcvspl package, which
provides a nice way to smooth data. What is the origin of the non-free
license? I looked at the source link for the fortran dependency and
performed a google search, but I cannot find the posted license
anywhere. Does the no
David Bateman wrote:
> Jonathan Stickel wrote:
>> David Bateman wrote:
>>> Jonathan Stickel wrote:
>>>> Can I delete octave-forge/main/io/inst/dlmread.m ?
>>>>
>>> Please don't as this isn't in octave 3.0 either..
>>>
>> B
David Bateman wrote:
> Jonathan Stickel wrote:
>> Can I delete octave-forge/main/io/inst/dlmread.m ?
>>
> Please don't as this isn't in octave 3.0 either..
>
But why do we want both m-file and an oct-file dlmread functions when
they conflict with each other?
David Bateman wrote:
> Jonathan Stickel wrote:
>> Yes, I think dlmread should move into core octave. Might as well move
>> csvread into core octave also since it is just a wrapper to dlmread.
>> There still exists another dlmread m-file in octave-forge. Unless
>> there
David Bateman wrote:
> Jonathan Stickel wrote:
>> I just checked in an improved dlmread function (dlmreadnew.cc) into the
>> io/src folder. It should properly respect your delimiter, converting
>> empty fields to zero. Unequal row lengths are allowed. Since it is a
>
I just checked in an improved dlmread function (dlmreadnew.cc) into the
io/src folder. It should properly respect your delimiter, converting
empty fields to zero. Unequal row lengths are allowed. Since it is a
compiled oct-file, it is very fast. I made an effort to be compatible
with Matlab
> Date: Tue, 29 Jan 2008 03:46:35 +0100
> From: Olivier Lefevre <[EMAIL PROTECTED]>
> Subject: Re: [OctDev] Probable xlsread bug
> To: octave-dev@lists.sourceforge.net
> Message-ID: <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Yes, the problem is that str2d
> Date: Mon, 28 Jan 2008 20:41:17 +0100
> From: Olivier Lefevre <[EMAIL PROTECTED]>
> Subject: Re: [OctDev] Probable xlsread bug
> To: octave-dev@lists.sourceforge.net
> Message-ID: <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Yes, to address the speed issu
Date: Sun, 27 Jan 2008 20:24:11 +0100
> From: Olivier Lefevre <[EMAIL PROTECTED]>
> Subject: [OctDev] Probable xlsread bug
> To: octave-dev@lists.sourceforge.net
> Message-ID: <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> NB: This is a repost of a month-old p
'dlmread' (the oct version) works fairly well as long as your delimiter
is not a tab character. A little hack:
if (nargin > 1) {
sep = args(1).string_value();
cout << "a" << sep << "b" << "\n";
//if (sep.length() != 1) error("separator must be a single character");
}
allows
There are conflicting dlmread functions in the io package: an m-file
version written by Paul Kienzle in 2001 and an oct version written by
Kai Habel in 2003. I have been writing my own function to read
delimited text files that is in many ways similar to the existing
dlmread m-file but with a f
31 matches
Mail list logo
