octave-dev — GNU Octave developers' list

Re: [OctDev] Problem with inputParser and anonymous functions for validators

[Juan P. C. <car...@if...>]

On Sat, Sep 22, 2012 at 11:30 AM, Jose <jos...@aa...> wrote:
> On 09/22/2012 11:44 AM, Juan Pablo Carbajal wrote:
>>
>>
>> @Jose: You know you can edit the help of these functions yourself? Let
>> me know if you do not know and need some help to ge the hands on it.
>
>
> Let's say that I have an intuition about how to do it, but no "official"
> instructions (which I'd like to have, yes).
>
>
>> If we do this, then you can send us the respective correction. In that
>> way you will be helping GNU Octave to get better!
>> At the same time you will getting the hands of how to write
>> documentation and functions for Octave, with some luck we will have
>> you(!) among the usual contributors in no time.
>
>
> Even better than explaining me, it would be nice to write it down in a wiki
> or alike, so it can be used as a reference to others ;). And if that is
> available already, please point me to the right place so that I can read it
> :). Sometimes finding things about octave in the web pages is really tricky
> ;).
>
> BR
> Jose
>
>
>

Hi Jose,

Ok, if the help here helps than I will transcribe it to the wiki...
though you could also do it! ;)

== One shot contribution ==
- All forge packages (name will change as soon we have Agora online
running) are hosted here
http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/
You can look for the package in question, get the latest version that
could be unreleased (that is, it is not yet listed in the OctaveForge
website anmd you will not ge tit by doing >pkg -forge install
my-package). You can use this function if you copy on top of the old
one (or rename the old one to *_old.m), but be careful because it may
require other new functions. Anyway, you can get the latest and
coolest version of any package from that site.
- Once you have the newest version of the function, check if it still
has the bug you found. If it doesn't somebody solved it already. If
the problem still there go on an fix it!
- Once you have fixed the bug, you can send a patch with your changes.
How do you this? Start another thread or read the relevant parts of
the documentation of "diff" and
"patch"(http://www.gnu.org/software/diffutils/manual/diffutils.html).

=== Another way ===
You can also checkout the package in question using svn. For example
if you wan to checkout the general package you would run
> svn co https://octave.svn.sourceforge.net/svnroot/octave/trunk/octave-forge/main general general_to_debug

This will create a folder "general_to_debug" in your current
directory. You can hack away as much as you can and then produce the
patch and send it to the mailing list.

=== New files or buch of files ===
There is a third way of contributing to Octave.Lets say you do not
want to be a developer but you have one or a bunch of functions you
want to share with us. You can use the Features request forum (this
willbe also replaced by Agora when it is up and running)
https://sourceforge.net/tracker/?group_id=2888&atid=352888
Upload your file (compressed if it is more than one) and lets us know
that you did it by sending a mail to the mailing list. If there is
anybody interested they will look at your code and give you
suggestions. Speed up that process by adding a GPL compatible license
(http://en.wikipedia.org/wiki/List_of_FSF-approved_software_licenses)

== Being a Forger ==
If you want to be one of us, you can also request to be a Forge
developer (name may change) following the instructions here
http://octave.sourceforge.net/developers.html

Let us know if there are more questions

Looking forward for your next contribution

-- 
M. Sc. Juan Pablo Carbajal
-----
PhD Student
University of Zürich
http://ailab.ifi.uzh.ch/carbajal/

Re: [OctDev] Problem with inputParser and anonymous functions for validators

[Jose <jos...@aa...>]

On 09/22/2012 11:44 AM, Juan Pablo Carbajal wrote:
>
> @Jose: You know you can edit the help of these functions yourself? Let
> me know if you do not know and need some help to ge the hands on it.

Let's say that I have an intuition about how to do it, but no "official" 
instructions (which I'd like to have, yes).

> If we do this, then you can send us the respective correction. In that
> way you will be helping GNU Octave to get better!
> At the same time you will getting the hands of how to write
> documentation and functions for Octave, with some luck we will have
> you(!) among the usual contributors in no time.

Even better than explaining me, it would be nice to write it down in a 
wiki or alike, so it can be used as a reference to others ;). And if 
that is available already, please point me to the right place so that I 
can read it :). Sometimes finding things about octave in the web pages 
is really tricky ;).

BR
Jose

Re: [OctDev] Problem with inputParser and anonymous functions for validators

[Juan P. C. <car...@if...>]

On Fri, Sep 21, 2012 at 10:09 PM, Ben Abbott <bpa...@ma...> wrote:
> On Sep 21, 2012, at 2:59 PM, Jose wrote:
>
>> Hello.
>>
>> On 09/21/2012 09:33 PM, Ben Abbott wrote:
>>
>>> What you need to do is either
>>>
>>> (1) addRequired (p, "pack", val)
>>>
>>> or
>>>
>>> (2) addRequired (p, "pack", @(x)ischar(x))
>>>
>>> or
>>>
>>> (3) addRequired (p, "pack", @ischar)
>>
>> Thanks Ben. It works.
>>
>> It seems then that the documentation is not correct (See the example in "help inputParser" and
>> http://octave.sourceforge.net/general/function/@inputParser/inputParser.html ).
>>
>> BR
>> Jose
>>
>
> I think you are correct. There appears to be a problem with the documentation.  I've cc'd the author.
>
>
> Ben
>
> _______________________________________________
> Help-octave mailing list
> Hel...@oc...
> https://mailman.cae.wisc.edu/listinfo/help-octave

Problem fixed.

Thank you for reporting it! :D

@Jose: You know you can edit the help of these functions yourself? Let
me know if you do not know and need some help to ge the hands on it.
If we do this, then you can send us the respective correction. In that
way you will be helping GNU Octave to get better!
At the same time you will getting the hands of how to write
documentation and functions for Octave, with some luck we will have
you(!) among the usual contributors in no time.

Cheers


-- 
M. Sc. Juan Pablo Carbajal
-----
PhD Student
University of Zürich
http://ailab.ifi.uzh.ch/carbajal/

[OctDev] ODBC coupling in Octave...

[Gustaf M. <gu...@me...>]

Hello all,

I was trying to get the database package running on my Octave istallation on a windows 7 (64-bit) system. I received a number of strange dependency errors and was wondering if anyone had any tips about this? Could it be a 64-bit issue? I've had some similar issues concerning the 64-bit configuration and access databases earlier.

pax,

Gustaf

su...@kt...

Re: [OctDev] Dicom package / isdicom function

[adam a. <ada...@ho...>]

I probably won't have a chance to send it before Sunday (the files are on my laptop which I don't have with me this weekend).  But I should be able to send it next week, so the following release should be no problem.Thanks,Adam

 


> From: car...@gm...
> Date: Fri, 21 Sep 2012 13:53:56 +0200
> Subject: Re: [OctDev] Dicom package / isdicom function
> To: ada...@ho...
> CC: and...@gm...; oct...@li...
> 
> On 21 September 2012 10:18, adam aitkenhead <ada...@ho...> wrote:
> > The underlying read function has a different calling syntax from Matlab, as
> > it reads both the header and the image in one go (I wrote it like that
> > before I realized there were similar functions in Matlab).  However I've
> > also written functions which call it using the same format as analyze75info
> > and analyze75read.  This does mean that it runs slower than Matlab, but it
> > shouldn't be difficult to change it to read only the appropriate parts if
> > needed.
> 
> It's ok to do more than the matlab functions, there's plenty of
> examples where that is the case. It's just not very good to have
> conflicts with their API. So if your analyze75read works as in
> "[image, header] = analyze75read (fname)", it's still matlab
> compatible while being more useful at the same time. It seems to me
> that matlab also has a analyze75info function, maybe you'd like to
> make it compatible? I'm planning on making a release of the image
> package Sunday in case you are interested in having your functions
> included now. Otherwise they can still be included on the next
> release.
> 
> Carnë
 		 	   		  

[OctDev] signal 1.2.0 released

[Carnë D. <car...@gm...>]

Hi everyone

a new release of signal package is out, version 1.2.0, by Carnë Draug.
Enjoy Octave responsibly.

Carnë

Re: [OctDev] Dicom package / isdicom function

[Carnë D. <car...@gm...>]

On 21 September 2012 10:18, adam aitkenhead <ada...@ho...> wrote:
> The underlying read function has a different calling syntax from Matlab, as
> it reads both the header and the image in one go (I wrote it like that
> before I realized there were similar functions in Matlab).  However I've
> also written functions which call it using the same format as analyze75info
> and analyze75read.  This does mean that it runs slower than Matlab, but it
> shouldn't be difficult to change it to read only the appropriate parts if
> needed.

It's ok to do more than the matlab functions, there's plenty of
examples where that is the case. It's just not very good to have
conflicts with their API. So if your analyze75read works as in
"[image, header] = analyze75read (fname)", it's still matlab
compatible while being more useful at the same time. It seems to me
that matlab also has a analyze75info function, maybe you'd like to
make it compatible? I'm planning on making a release of the image
package Sunday in case you are interested in having your functions
included now. Otherwise they can still be included on the next
release.

Carnë

Re: [OctDev] Dicom package / isdicom function

[adam a. <ada...@ho...>]

Hi all,
I see what you mean about the dicom package's dependencies, sounds like the image package is a better place for it.
The underlying read function has a different calling syntax from Matlab, as it reads both the header and the image in one go (I wrote it like that before I realized there were similar functions in Matlab).  However I've also written functions which call it using the same format as analyze75info and analyze75read.  This does mean that it runs slower than Matlab, but it shouldn't be difficult to change it to read only the appropriate parts if needed.
I've only been able to test it with my own Analyze files, so it's not been tested using other files with different orientations or anything like that.
Adam

 


> From: car...@gm...
> Date: Thu, 20 Sep 2012 12:33:35 +0200
> Subject: Re: [OctDev] Dicom package / isdicom function
> To: ada...@ho...
> CC: and...@gm...; oct...@li...
> 
> On 19 September 2012 20:00, Andy Buckle <and...@gm...> wrote:
> >>> Date: Thu, 13 Sep 2012 14:57:29 +0100
> >>
> >>> Subject: Re: [OctDev] Dicom package / isdicom function
> >>> From: and...@gm...
> >>> To: ada...@ho...
> >>>
> >>> > I have access to Matlab too, and it recognises the non-standard DICOM
> >>> > file.
> >>> > (Just to note, although I have tested the ML behaviour for a some test
> >>> > files, I didn't use Matlab as a basis for the code.)
> >>>
> >>> Excellent. That is the way to do it. We are careful about copyright.
> >>>
> >>> Andy
> > On 19 September 2012 17:26, adam aitkenhead <ada...@ho...> wrote:
> >>
> >> Hi Andy,
> >>
> >> I've attached an updated version of the isdicom function which can now check
> >> a list of files (in a cell array) in one go, which is much quicker than
> >> checking each file separately.  Again, no rush for releasing a new version
> >> of the toolbox - just some changes I was making for my own code anyway.
> >>
> >> Also on a different note, I've written functions which read/write the
> >> Analyze format, giving functions equivalent to Matlab's analyze75info and
> >> analyze75read.  Would you rather keep the Dicom toolbox purely for the Dicom
> >> format, or are you interested in expanding it to become a general Medical
> >> File Format toolbox?  No worries if not, just thought I'd see what you
> >> thought before I see where else they could fit into Octave-forge.
> >>
> >> Adam
> >
> > Note that I have included the list for further discussion, and edited
> > older text to chronological order.
> >
> > I have not used analyze75. If it is just m-files, then the image
> > package is probably a good place. The main reason dicom is on its own
> > is that it has burdensome dependencies.
> 
> I agree with Andy. The analyze75read/write functions would fit better
> on the image package. Are their API matlab compatible?
> 
> Carnë
 		 	   		  

Re: [OctDev] Dicom package / isdicom function

[Carnë D. <car...@gm...>]

On 19 September 2012 20:00, Andy Buckle <and...@gm...> wrote:
>>> Date: Thu, 13 Sep 2012 14:57:29 +0100
>>
>>> Subject: Re: [OctDev] Dicom package / isdicom function
>>> From: and...@gm...
>>> To: ada...@ho...
>>>
>>> > I have access to Matlab too, and it recognises the non-standard DICOM
>>> > file.
>>> > (Just to note, although I have tested the ML behaviour for a some test
>>> > files, I didn't use Matlab as a basis for the code.)
>>>
>>> Excellent. That is the way to do it. We are careful about copyright.
>>>
>>> Andy
> On 19 September 2012 17:26, adam aitkenhead <ada...@ho...> wrote:
>>
>> Hi Andy,
>>
>> I've attached an updated version of the isdicom function which can now check
>> a list of files (in a cell array) in one go, which is much quicker than
>> checking each file separately.  Again, no rush for releasing a new version
>> of the toolbox - just some changes I was making for my own code anyway.
>>
>> Also on a different note, I've written functions which read/write the
>> Analyze format, giving functions equivalent to Matlab's analyze75info and
>> analyze75read.  Would you rather keep the Dicom toolbox purely for the Dicom
>> format, or are you interested in expanding it to become a general Medical
>> File Format toolbox?  No worries if not, just thought I'd see what you
>> thought before I see where else they could fit into Octave-forge.
>>
>> Adam
>
> Note that I have included the list for further discussion, and edited
> older text to chronological order.
>
> I have not used analyze75. If it is just m-files, then the image
> package is probably a good place. The main reason dicom is on its own
> is that it has burdensome dependencies.

I agree with Andy. The analyze75read/write functions would fit better
on the image package. Are their API matlab compatible?

Carnë

Re: [OctDev] Dicom package / isdicom function

[Kris T. <kri...@gm...>]

> From: Andy Buckle 
> Sent: 19 September 2012 19:01
> >
> > From adamaitkenhead

> > Also on a different note, I've written functions which read/write the
> > Analyze format, giving functions equivalent to Matlab's analyze75info
and
> > analyze75read.  Would you rather keep the Dicom toolbox purely for the
> Dicom
> > format, or are you interested in expanding it to become a general
Medical
> > File Format toolbox?  No worries if not, just thought I'd see what you
> > thought before I see where else they could fit into Octave-forge.
> >
> > Adam
> 
> I have not used analyze75. If it is just m-files, then the image
> package is probably a good place. The main reason dicom is on its own
> is that it has burdensome dependencies.
> 

I'd keep it out of the dicom package as well. 

Note that there's a number of packages out there to read nifti files (which
is a superset of analyze75, see http://nifti.nimh.nih.gov/nifti-1/), not all
with very clear license though. One that seems ok is
http://www.nitrc.org/projects/cbinifti/, but I haven't used it (it might
rely on unix pipes) . Then there's http://niftilib.sourceforge.net/ which
also provides matlab support, but as it's the IO basis for SPM, and a lot of
SPM works on Octave, it might work.

Of course, there's still a place for analyze75info etc compatible functions.
I have no idea if that already exists somewhere else.

Kris

Re: [OctDev] Discussion about Wiki entries

[Juan P. C. <car...@if...>]

On Thu, Sep 20, 2012 at 7:58 AM, Reza Housseini <rez...@gm...> wrote:
> Hello
>
> Just as the subject mentions it, where should the discussion about Wiki
> entries go? I sometimes want to add some suggestions or question to an enty
> and I'm not sure if it's appreciated. Is it alright when I just change it?
> For example in the main menu there is missing a chapter about debugging,
> should I just insert it? Or there is often missing a clear link where am I
> in the wiki (like breadcrumbs in the bottom bar) is there someone to talk to
> for adding such features?
> (I hope I posted this on the right list)
>
> Best wishes
> Reza

Hi Reza,
(I copy your message to the other lists)

The wiki pages have their "discussion" page. Check the tabs on the
top. If red it means the page has no discussion. Just open one. It is
always good to send a mail to the list when you do it, just to make
sure people look at it.

Cheers


-- 
M. Sc. Juan Pablo Carbajal
-----
PhD Student
University of Zürich
http://ailab.ifi.uzh.ch/carbajal/

[OctDev] Free IDE for Octave exploration and development

[Alex K. <ale...@gm...>]

Hi ,

Could you please advise for the good free IDE for octave core code
exploration ?


Thanks in advance ,
Alex

Re: [OctDev] Dicom package / isdicom function

[Andy B. <and...@gm...>]

>> Date: Thu, 13 Sep 2012 14:57:29 +0100
>
>> Subject: Re: [OctDev] Dicom package / isdicom function
>> From: and...@gm...
>> To: ada...@ho...
>>
>> > I have access to Matlab too, and it recognises the non-standard DICOM
>> > file.
>> > (Just to note, although I have tested the ML behaviour for a some test
>> > files, I didn't use Matlab as a basis for the code.)
>>
>> Excellent. That is the way to do it. We are careful about copyright.
>>
>> Andy
On 19 September 2012 17:26, adam aitkenhead <ada...@ho...> wrote:
>
> Hi Andy,
>
> I've attached an updated version of the isdicom function which can now check
> a list of files (in a cell array) in one go, which is much quicker than
> checking each file separately.  Again, no rush for releasing a new version
> of the toolbox - just some changes I was making for my own code anyway.
>
> Also on a different note, I've written functions which read/write the
> Analyze format, giving functions equivalent to Matlab's analyze75info and
> analyze75read.  Would you rather keep the Dicom toolbox purely for the Dicom
> format, or are you interested in expanding it to become a general Medical
> File Format toolbox?  No worries if not, just thought I'd see what you
> thought before I see where else they could fit into Octave-forge.
>
> Adam

Note that I have included the list for further discussion, and edited
older text to chronological order.

I have not used analyze75. If it is just m-files, then the image
package is probably a good place. The main reason dicom is on its own
is that it has burdensome dependencies.

-- 
/* andy buckle */

Re: [OctDev] On the union of two communities - The GNU Octave atmosphere

[<luk...@gm...>]

On 09/19/2012 06:45 PM, Juan Pablo Carbajal wrote:
> On Wed, Sep 19, 2012 at 12:12 PM, Júlio Hoffimann
> <jul...@gm...> wrote:
>> No advances here? We'll stay broken in two pieces?
>>
>> Ok, that's sad.
> 
> Julio,
> 
> I do not feel there are two communities. Join us in the next OctConf
> and you will see it for yourself.
> What you may be feeling is activity distribution self-organized by
> expertise. There are people who are good and enjoy doing low-level
> development (or general GNU Octave) like Rik, Daniel, John, Jordi, etc
> (along etc!) and there are others who are more into the domain/field
> specific code, me, Carlo, Carnë, Lukas, and many more. Of course most
> of these participate in both sides.
> 
> The communication between the two groups is quite fluid. Besides we
> are bringing together Agora (former Octave-Forge) and core, with the
> website development. What exactly is what you find fragmented?
> 
> Cheers
> 

>From the perspective of a user, I don't see any gap between the two
groups, if there are really two groups. :-)

One more observation from the point of view of a user seeking help.
While the separation of core (interpreter + basic things) and packages
(applications) for development makes sense, it's not that easy or clear
for a (newbie) user to know which list (octave-help or oct-dev) to go to
for help. There's in fact a lot of help content in the oct-dev list.
Maybe this aspect (of oct-dev) can be merged with the main octave-help,
that is, one octave-user (or whatever is a better name) list?

Just my 2 cents,
ST
-- 

Re: [OctDev] On the union of two communities - The GNU Octave atmosphere

[Jacob D. <jac...@gm...>]

>
>
> 1. Is the community fragmented? I think not and gave my reasons before.
>

In real life not. On the internet: Yes. And this is what people from
outside perceive.


> 2. Are we using good tools to collaborate? I think the tolls where ok
> until recently and now it is a phase of changes. Carnë have been
> talking about migrating the package/module development and bug/feature
> tracking for a while already. I tihnk if we want to do this
> effectively we need a task force (a small group of people) that know
> what they are talking about (this rules e out! :D) and implement the
> changes using their criteria.


I am okay with that, but I have a please for these people: You should
really decide objectively. If you dismiss OA by default because you don't
like php, this is not a real discussion to me. I really don't like php that
much, too, but let's face it: It does the job and it fulfills our ethical
criteria (it is not only free software, but also GPL). The same applies for
the server this thing could be running on.

Jacob

Re: [OctDev] On the union of two communities - The GNU Octave atmosphere

[Juan P. C. <car...@if...>]

On Wed, Sep 19, 2012 at 1:37 PM, Jacob Dawid <jac...@gm...> wrote:
> I proposed to use collaboration platform like Open Atrium (free software
> licensed under GPL) already some time ago. It would fit this scenario
> perfectly, because users can register on such a platform, write something
> about themselves and then join workgroups dedicated to a certain task. So,
> we would have been a single community on a member level, but at some point
> working isolated in groups (each group has it's own bugtracker and wiki)
> depending on our interests. You can be a member of several groups, if you
> wish.
>
> On the website of a friend and me we were setting up an atrium instance for
> our own, accumulated free software projects. You may take a look there to
> get a feel of what I mean: http://community.moon-studios.com/
>
> The reason this proposal did not get any grip was that the octave site is
> hosted on Savannah and they only allow static pages. Open Atrium requires
> php.
>
> I think there are valid points in having a separation as well as having
> unity.

There are also two levels of discussion.

1. Is the community fragmented? I think not and gave my reasons before.

2. Are we using good tools to collaborate? I think the tolls where ok
until recently and now it is a phase of changes. Carnë have been
talking about migrating the package/module development and bug/feature
tracking for a while already. I tihnk if we want to do this
effectively we need a task force (a small group of people) that know
what they are talking about (this rules e out! :D) and implement the
changes using their criteria.


-- 
M. Sc. Juan Pablo Carbajal
-----
PhD Student
University of Zürich
http://ailab.ifi.uzh.ch/carbajal/

Re: [OctDev] On the union of two communities - The GNU Octave atmosphere

[Jacob D. <jac...@gm...>]

I proposed to use collaboration platform like Open Atrium (free software
licensed under GPL) already some time ago. It would fit this scenario
perfectly, because users can register on such a platform, write something
about themselves and then join workgroups dedicated to a certain task. So,
we would have been a single community on a member level, but at some point
working isolated in groups (each group has it's own bugtracker and wiki)
depending on our interests. You can be a member of several groups, if you
wish.

On the website of a friend and me we were setting up an atrium instance for
our own, accumulated free software projects. You may take a look there to
get a feel of what I mean: http://community.moon-studios.com/

The reason this proposal did not get any grip was that the octave site is
hosted on Savannah and they only allow static pages. Open Atrium requires
php.

I think there are valid points in having a separation as well as having
unity.

Re: [OctDev] On the union of two communities - The GNU Octave atmosphere

[Juan P. C. <car...@if...>]

On Wed, Sep 19, 2012 at 12:12 PM, Júlio Hoffimann
<jul...@gm...> wrote:
> No advances here? We'll stay broken in two pieces?
>
> Ok, that's sad.

Julio,

I do not feel there are two communities. Join us in the next OctConf
and you will see it for yourself.
What you may be feeling is activity distribution self-organized by
expertise. There are people who are good and enjoy doing low-level
development (or general GNU Octave) like Rik, Daniel, John, Jordi, etc
(along etc!) and there are others who are more into the domain/field
specific code, me, Carlo, Carnë, Lukas, and many more. Of course most
of these participate in both sides.

The communication between the two groups is quite fluid. Besides we
are bringing together Agora (former Octave-Forge) and core, with the
website development. What exactly is what you find fragmented?

Cheers

-- 
M. Sc. Juan Pablo Carbajal
-----
PhD Student
University of Zürich
http://ailab.ifi.uzh.ch/carbajal/

Re: [OctDev] On the union of two communities - The GNU Octave atmosphere

[Júlio H. <jul...@gm...>]

No advances here? We'll stay broken in two pieces?

Ok, that's sad.

Re: [OctDev] PKG statistics: dendogram

[JuanPi <aj...@gm...>]

On Tue, Sep 18, 2012 at 11:38 PM, JuanPi <aj...@gm...> wrote:
> Hi all,
>
> I committed the function dendogram to the statistics package. I
> couldn't manage to order the leafs of the linkage to avoid crossing of
> the edges in the plot.
>
> If anybody knows how to do it, please go ahead or send me some info so
> I can do it.
>
> Cheers
>
>
> --
> JuanPi Carbajal
> -----
> "The bad economist pursues a small present good, which will be
> followed by a great evil to come, while the true economist pursues a
> great good to come, at the risk of a small present evil." - Frédéric
> Bastiat
> -----
> http://ailab.ifi.uzh.ch/carbajal/

Hi all,

I manged to fix the order of the leafs (I think, please check). I am
using DFS to order the leafs, there might be better ways of doing it.
http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/main/statistics/inst/dendogram.m?revision=11050&view=markup

Cheers

-- 
JuanPi Carbajal
-----
"The bad economist pursues a small present good, which will be
followed by a great evil to come, while the true economist pursues a
great good to come, at the risk of a small present evil." - Frédéric
Bastiat
-----
http://ailab.ifi.uzh.ch/carbajal/

[OctDev] PKG statistics: dendogram

[JuanPi <aj...@gm...>]

Hi all,

I committed the function dendogram to the statistics package. I
couldn't manage to order the leafs of the linkage to avoid crossing of
the edges in the plot.

If anybody knows how to do it, please go ahead or send me some info so
I can do it.

Cheers


-- 
JuanPi Carbajal
-----
"The bad economist pursues a small present good, which will be
followed by a great evil to come, while the true economist pursues a
great good to come, at the risk of a small present evil." - Frédéric
Bastiat
-----
http://ailab.ifi.uzh.ch/carbajal/

[OctDev] statistics-1.1.3: kmeans

[JuanPi <aj...@gm...>]

Hi all,

I was checking the k-means algorithm implemented in statistics-1.1.3.
The docstring needs some work. Is anybody working on this? @Daniel?
I can give it a try if nobody is doing it.

Thx

-- 
JuanPi Carbajal
-----
"The bad economist pursues a small present good, which will be
followed by a great evil to come, while the true economist pursues a
great good to come, at the risk of a small present evil." - Frédéric
Bastiat
-----
http://ailab.ifi.uzh.ch/carbajal/

[OctDev] statistics-1.1.3: squareform

[JuanPi <aj...@gm...>]

Hi,

What is the difference (in terms of what they do) between squareform.m
and the core function vech.m (and the linear-algebra function
unvech.m)?

Thanks


-- 
JuanPi Carbajal
-----
"The bad economist pursues a small present good, which will be
followed by a great evil to come, while the true economist pursues a
great good to come, at the risk of a small present evil." - Frédéric
Bastiat
-----
http://ailab.ifi.uzh.ch/carbajal/

Re: [OctDev] Visual Studio 2010 feval problems

[Lukas F. <luk...@io...>]

Thanks a lot, these where exactly the things i was looking for.
I got it working now with the explaination in

http://www.gnu.org/software/octave/doc/interpreter/Standalone-Programs.html#Standalone-Programs

http://octave.1599824.n4.nabble.com/Getting-started-with-Octave-and-Visual-C-td1636630.html

and

http://stackoverflow.com/questions/11100220/octave-c-and-vs2010

tricky things to know with Visual Studio 2010:

Compiles only with the /MD compiler flag
Has to be compiled in "Release" target (???)
octave_main()  has to be called to init the parser (and dirs)

Thanks , especially to Jordi

Re: [OctDev] Visual Studio 2010 feval problems

[Jordi G. H. <jo...@oc...>]

On 17 September 2012 10:54, Jordi Gutiérrez Hermoso <jo...@oc...> wrote:
> On 17 September 2012 09:20, Lukas Fischer <luk...@io...> wrote:
>> Is there a better documentation of using the C++ API than the
>> Doxygen or the Da Coda Al Fine documents?
>
> I don't find the bare-bones Doxygen output to be that useful, but some
> people say it is. I personally am more used to just reading Octave
> header files to find what I want. ;-)
>
> As for Da Coda Al Fine, this is fairly obsolete. The Octave manual
> is better:
>
>     http://www.gnu.org/software/octave/doc/interpreter/Oct_002dFiles.html
>
> The source distribution also contains these examples in the examples/
> directory.

I forgot to say, I also like this:

    http://wiki.octave.org/Tips_and_tricks#C.2B.2B

- Jordi G. H.