John W. Eaton | 1 Dec 2005 21:29
Picon

lognormal distribution defs

On 23-Nov-2005, Ben Barrowes wrote:

| The logn***.m functions in octave are different from their counterparts in ML. Both ML:
| http://www.mathworks.com/access/helpdesk/help/toolbox/stats/lognpdf.html
| and mathworld:
| http://mathworld.wolfram.com/LogNormalDistribution.html
| define this dist not with log(mean), but with the mean itself. 

I agree that it would be best to have the lognXXX functions compatible
with Matlab, since they have the same names.

Since we already have lognormal_XXX functions that look like this:

  function XXX = lognormal_XXX (varargin)

   XXX =  lognXXX (varargin{:});

  endfunction

your patch will also affect those, and break backward compatibility
with Octave.

Can you please suggest a patch that will not break backward
compatibility?  If there is no reasonable way for the old
lognormal_XXX functions to call the new lognXXX funtions to do it,
then I think we will have to do it by copying code (but I think it
would be best to avoid the duplication if possible).

Thanks,

(Continue reading)

John W. Eaton | 1 Dec 2005 21:36
Picon

double should not show usage on cell conversion

On 16-Nov-2005, Bill Denney wrote:

| When I tried to use double to convert a numeric cell array using curly 
| braces {} to a double array, it failed and showed the usage info for 
| double.  I think that it should work like it does for a regular cell, or 
| preferably it should try to convert if it's a simple conversion of either 
| scalars in every cell or a row or column with equal length columns or rows 
| to a matrix.
| 
| Below is the transcript of what happens.
| 
| I know that octave-forge has cell2mat, but I just wasn't thinking of that 
| one at the moment when I tried this.
| 
| Bill
| 
| octave:1> mycells = {1 2 3 4}
| mycells =
| 
| {
|    [1,1] = 1
|    [1,2] = 2
|    [1,3] = 3
|    [1,4] = 4
| }
| 
| octave:2> class(mycells)
| ans = cell
| octave:3> double(mycells)
| error: invalid conversion from cell to matrix
(Continue reading)

John W. Eaton | 1 Dec 2005 21:41
Picon

Re: kruskal_wallis_test() does not handle ties correctly

On  3-Nov-2005, Timo Juhani Lindfors wrote:

| Sorry for the delay. I checked out the CVS version and tested my
| modifications with it. I think everything is ok but where should this
| runlength() be defined? In octave/scripts/general/runlength.m ?

That seems reasonable to me.

jwe

-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------

John W. Eaton | 1 Dec 2005 21:39
Picon

rows and columns (functions)

On 12-Nov-2005, William Poetra Yoga H wrote:

| I find that rows() and columns() are a bit slow, so I saw how it's done:
| 
|   [nr, nc] = size (x);
| 
| I found that this is about 20% faster:
| 
|   nr = size(x,1);
| 
| And:
| 
|   nc = size(x,2);
| 
| So why not use these instead?

Probably because rows and columns were written before Octave's size
command (or even Matlab's) accepted a DIM argument.

| Even better, making them built-in functions would
| speed up the whole thing, I think.

Show me the code.  :-)

jwe

-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
(Continue reading)

John W. Eaton | 3 Dec 2005 20:42
Picon

bug report

You have not provided enough information for anyone to debug the
problem you are seeing.

Please read http://www.octave.org/bugs.html to learn how to submit a
complete bug report that includes enough information so that someone
might be able to debug the problem.

Thanks,

jwe

On  3-Dec-2005, Liu Peng wrote:

| GNU Octave, version 2.1.72 (i486-pc-linux-gnu).
| Copyright (C) 2005 John W. Eaton.
| This is free software; see the source code for copying conditions.
| There is ABSOLUTELY NO WARRANTY; not even for MERCHANTIBILITY or
| FITNESS FOR A PARTICULAR PURPOSE.  For details, type `warranty'.
| 
| Additional information about Octave is available at http://www.octave.org.
| 
| Please contribute if you find this software useful.
| For more information, visit http://www.octave.org/help-wanted.html
| 
| Report bugs to <bug <at> octave.org> (but first, please read
| http://www.octave.org/bugs.html to learn how to write a helpful report).
| 
| *** glibc detected *** free(): invalid pointer: 0x08ab3be8 ***
| panic: Aborted -- stopping myself...
| attempting to save variables to `octave-core'...
(Continue reading)

David Bateman | 5 Dec 2005 16:35

fileattrib.m?

I see in scripts/ChangeLog that the file miscellaneous/fileattrib.m was 
added. However it doesn't appear in the CVS...

Cheers
David

-- 
David Bateman                                David.Bateman <at> motorola.com
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax) 
91193 Gif-Sur-Yvette FRANCE

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary

-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------

Frederick (Rick) A Niles | 7 Dec 2005 21:03
Picon
Favicon

str2num.m can't handle LF character.

I can't believe no one has come across this one.

> str2num('0\r')
ans = [](0x0)

The problem is that str2num.m is implemented using the eval function and
the line feed character seems to confuse that we're asking to be eval'd

Anyway, seems like this would be really common when trying to read in
data from Windows/DOS sources that have "/r" in the line termination.

This there a easy hack to the str2num.m that would make this work for
me?  Should this be fixed in the distro?  I'm running 2.1.72.

Thanks,

Rick Niles.

-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------

Bill Denney | 7 Dec 2005 21:25
Favicon

Re: str2num.m can't handle LF character.

I don't think that this is actually an error.  str2num should just convert 
strings to numbers.  If you give it a string that is not strictly numeric 
(including all numeric notation such as 1e5-3j), it is supposed to return 
empty.

The problem sounds like it is with how your file is being read.

Bill

On Wed, 7 Dec 2005, Frederick (Rick) A Niles wrote:

> I can't believe no one has come across this one.
>
>> str2num('0\r')
> ans = [](0x0)
>
>
> The problem is that str2num.m is implemented using the eval function and
> the line feed character seems to confuse that we're asking to be eval'd
>
> Anyway, seems like this would be really common when trying to read in
> data from Windows/DOS sources that have "/r" in the line termination.
>
> This there a easy hack to the str2num.m that would make this work for
> me?  Should this be fixed in the distro?  I'm running 2.1.72.
>
> Thanks,
>
> Rick Niles.
>
(Continue reading)

Frederick (Rick) A Niles | 7 Dec 2005 21:29
Picon
Favicon

Re: str2num.m can't handle LF character.


> str2num('0\n')
ans = 0

On Wed, 2005-12-07 at 15:25 -0500, Bill Denney wrote:
> I don't think that this is actually an error.  str2num should just convert 
> strings to numbers.  If you give it a string that is not strictly numeric 
> (including all numeric notation such as 1e5-3j), it is supposed to return 
> empty.
> 
> The problem sounds like it is with how your file is being read.
> 
> Bill
> 
> On Wed, 7 Dec 2005, Frederick (Rick) A Niles wrote:
> 
> > I can't believe no one has come across this one.
> >
> >> str2num('0\r')
> > ans = [](0x0)
> >
> >
> > The problem is that str2num.m is implemented using the eval function and
> > the line feed character seems to confuse that we're asking to be eval'd
> >
> > Anyway, seems like this would be really common when trying to read in
> > data from Windows/DOS sources that have "/r" in the line termination.
> >
> > This there a easy hack to the str2num.m that would make this work for
> > me?  Should this be fixed in the distro?  I'm running 2.1.72.
(Continue reading)

John W. Eaton | 7 Dec 2005 21:38
Picon

Re: str2num.m can't handle LF character.

On  7-Dec-2005, Bill Denney wrote:

| I don't think that this is actually an error.  str2num should just convert 
| strings to numbers.  If you give it a string that is not strictly numeric 
| (including all numeric notation such as 1e5-3j), it is supposed to return 
| empty.
| 
| The problem sounds like it is with how your file is being read.

I agree that it would be best if everyone would translate text files
appropriately.  Then Octave would only have to handle '\n' as the
newline character.  Things would be simpler.  But we would also see a
lot of messages from people who don't know (or care) about EOL
translation, and would just complain that Octave sucks because it
can't read their simple files.  There are already a number of checks
for \r\n and \r as EOL characters.  I think the following patch will
help.  I don't see how it could hurt very much, but maybe I'm missing
something.

jwe

src/ChangeLog:

2005-12-07  John W. Eaton  <jwe <at> octave.org>

	* lex.l (NL): Also accept '\r'.

Index: src/lex.l
===================================================================
RCS file: /cvs/octave/src/lex.l,v
(Continue reading)


Gmane