<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.comp.gnu.octave.general">
    <title>gmane.comp.gnu.octave.general</title>
    <link>http://permalink.gmane.org/gmane.comp.gnu.octave.general</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnu.octave.general/41547"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnu.octave.general/41546"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnu.octave.general/41545"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnu.octave.general/41544"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnu.octave.general/41543"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnu.octave.general/41542"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnu.octave.general/41541"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnu.octave.general/41540"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnu.octave.general/41539"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnu.octave.general/41538"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnu.octave.general/41537"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnu.octave.general/41536"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnu.octave.general/41535"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnu.octave.general/41534"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnu.octave.general/41533"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnu.octave.general/41532"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnu.octave.general/41531"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnu.octave.general/41530"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnu.octave.general/41529"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.gnu.octave.general/41528"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnu.octave.general/41547">
    <title>Re: Tikz backend</title>
    <link>http://permalink.gmane.org/gmane.comp.gnu.octave.general/41547</link>
    <description>&lt;pre&gt;
Hello,

Sorry for the late reply -- I've been very busy.

pgfprint is not automated. The way I use it is as follows. After coding 
my algorithms, running simulations, and generating many plots over 
several iterations, eventually I become satisfied with the results. 
Then, I decide how to plot the results (which results, in how many 
figures, how many curves per figure, ectetera). In other words, I have a 
set of (x,y) coordinate vectors that I want to use to create 
publication-quality graphics.

At this point, I use pgfprint along with the (x,y) coordinates I 
produced before and carefully build the plots I need, according to the 
publication type and format. This process usually takes a few hours, 
maybe even more. I don't believe publication-quality plots can be 
produced automatically (by my standards; I've seen many papers with 
horrible, straight-out-of-matlab plots).

I hope this makes a bit clearer how pgfprint is intended to fit into the 
process of creating a publication. If you need any more hel&lt;/pre&gt;</description>
    <dc:creator>Miguel Bazdresch</dc:creator>
    <dc:date>2012-05-17T02:22:19</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnu.octave.general/41546">
    <title>Re: octave + mkl</title>
    <link>http://permalink.gmane.org/gmane.comp.gnu.octave.general/41546</link>
    <description>&lt;pre&gt;
If people cared much more about performance than about ideology Octave
would simply not exist.

Please be more careful with your wording.  The Octave community does not
like to promote non-free software.


No one said anything different from this.


Not here, please.  This community is mainly interested in free ways to
speed up Octave.

&lt;/pre&gt;</description>
    <dc:creator>Francesco Potortì</dc:creator>
    <dc:date>2012-05-16T21:10:29</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnu.octave.general/41545">
    <title>Re: Octave and gnuplot for Android project makes it onto slashdot</title>
    <link>http://permalink.gmane.org/gmane.comp.gnu.octave.general/41545</link>
    <description>&lt;pre&gt;
Thanks great!
Good luck!
It has been a while since Walking randomly talk about Octave for the last time.

&lt;/pre&gt;</description>
    <dc:creator>Juan Pablo Carbajal</dc:creator>
    <dc:date>2012-05-16T21:54:48</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnu.octave.general/41544">
    <title>Re: octave + mkl</title>
    <link>http://permalink.gmane.org/gmane.comp.gnu.octave.general/41544</link>
    <description>&lt;pre&gt;Sorry I didn't intend to start a fight.  ...Just thought "It was
useful to me and may be useful to others."

Cheers,

Josh

On Wed, May 16, 2012 at 2:10 PM, Francesco Potortì &amp;lt;Potorti&amp;lt; at &amp;gt;isti.cnr.it&amp;gt; wrote:



&lt;/pre&gt;</description>
    <dc:creator>Joshua Dillon</dc:creator>
    <dc:date>2012-05-16T21:55:37</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnu.octave.general/41543">
    <title>Re: 'rgb2gray' undefined</title>
    <link>http://permalink.gmane.org/gmane.comp.gnu.octave.general/41543</link>
    <description>&lt;pre&gt;Of course, sorry.  This code was a download from here: http://www.cs.brown.edu/~dqsun/code/flow_code.zip

explained by:

Secrets of optical flow estimation and their principles
Sun, D., Roth, S., and Black, M. J.,
IEEE Conf. on Computer Vision and Pattern Recog., CVPR, June 2010

http://www.cs.brown.edu/people/dqsun/pubs/cvpr_2010_flow.pdf

--- On Wed, 5/16/12, marco atzeri &amp;lt;marco.atzeri&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:

&amp;gt; &lt;/pre&gt;</description>
    <dc:creator>Nathan Armer</dc:creator>
    <dc:date>2012-05-16T21:36:20</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnu.octave.general/41542">
    <title>Re: 'rgb2gray' undefined</title>
    <link>http://permalink.gmane.org/gmane.comp.gnu.octave.general/41542</link>
    <description>&lt;pre&gt; &amp;gt; "table": 
http://people.csail.mit.edu/celiu/motionAnnotation/database/table.zip

as we I have no clue of "estimate_flow_interface.m" content or of 
flow_code I have no way to help you.

Marco
&lt;/pre&gt;</description>
    <dc:creator>marco atzeri</dc:creator>
    <dc:date>2012-05-16T21:22:07</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnu.octave.general/41541">
    <title>Re: dubious logic in package 'uninstall' function</title>
    <link>http://permalink.gmane.org/gmane.comp.gnu.octave.general/41541</link>
    <description>&lt;pre&gt;


Sergei,

Octave is developed by volunteers. You are just as responsible for fixing bugs and or short-comings as anyone else, and we'd welcome patches from you.

In my opinion, behaving like a troll is an ineffective approach to motivate others to do something for you.

Ben
&lt;/pre&gt;</description>
    <dc:creator>Ben Abbott</dc:creator>
    <dc:date>2012-05-16T21:14:21</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnu.octave.general/41540">
    <title>Octave and gnuplot for Android project makes it onto slashdot</title>
    <link>http://permalink.gmane.org/gmane.comp.gnu.octave.general/41540</link>
    <description>&lt;pre&gt;All,
You might like to know that the Kickstarter campaign to bring Octave and
gnuplot to Android made it onto slashdot today, which has helped it gain a
little steam in terms of funding.
Here is the article:
http://science.slashdot.org/story/12/05/16/0731246/octave-and-gnuplot-coming-to-android
Here is a recent blog about the project:
http://www.walkingrandomly.com/?p=4303
Here is the Kickstarter campaign:
http://www.kickstarter.com/projects/6438588/sombreros-for-the-android-world?ref=category
Take a look at the project if you haven't yet.
Thanks,
Corbin
_______________________________________________
Help-octave mailing list
Help-octave&amp;lt; at &amp;gt;octave.org
https://mailman.cae.wisc.edu/listinfo/help-octave
&lt;/pre&gt;</description>
    <dc:creator>Corbin Champion</dc:creator>
    <dc:date>2012-05-16T21:14:22</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnu.octave.general/41539">
    <title>Re: 'rgb2gray' undefined</title>
    <link>http://permalink.gmane.org/gmane.comp.gnu.octave.general/41539</link>
    <description>&lt;pre&gt;Yes, that worked, but now I'm getting "imfilter: first input argument must be an image":

octave:1&amp;gt; im1=imread('01.jpg');
warning: your version of GraphicsMagick limits images to 16 bits per pixel
octave:2&amp;gt; im2=imread('02.jpg');
octave:3&amp;gt; uv=estimate_flow_interface(im1,im2);
error: imfilter: first input argument must be an image
error: called from:
error:   C:\Octave3.6.1_gcc4.6.2\share\octave\3.6.1\m\image\imfilter.m at line 6
7, column 5
error:   C:\Octave3.6.1_gcc4.6.2\share\octave\3.6.1\m\flow_code\utils\compute_im
age_pyramid.m at line 46, column 5
error:   C:\Octave3.6.1_gcc4.6.2\share\octave\3.6.1\m\flow_code\&amp;lt; at &amp;gt;classic_nl_opti
cal_flow\compute_flow.m at line 93, column 21
error:   C:\Octave3.6.1_gcc4.6.2\share\octave\3.6.1\m\flow_code\estimate_flow_in
terface.m at line 90, column 5
octave:3&amp;gt;

The images are the first and second frames from the MIT test sequence "table": http://people.csail.mit.edu/celiu/motionAnnotation/database/table.zip

--- On Wed, 5/16/12, marco atzeri &amp;lt;marco.atzeri&amp;lt; at &amp;gt;gmail.com&amp;gt; wrot&lt;/pre&gt;</description>
    <dc:creator>Nathan Armer</dc:creator>
    <dc:date>2012-05-16T21:01:01</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnu.octave.general/41538">
    <title>Re: dubious logic in package 'uninstall' function</title>
    <link>http://permalink.gmane.org/gmane.comp.gnu.octave.general/41538</link>
    <description>&lt;pre&gt;
Then post to the maintainers' list.

- Jordi G. H.
&lt;/pre&gt;</description>
    <dc:creator>Jordi Gutiérrez Hermoso</dc:creator>
    <dc:date>2012-05-16T20:57:29</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnu.octave.general/41537">
    <title>Re: dubious logic in package 'uninstall' function</title>
    <link>http://permalink.gmane.org/gmane.comp.gnu.octave.general/41537</link>
    <description>&lt;pre&gt;



----- Original Message -----

No, I'll post here.

I many times wrote here that Octave packaging system is broken. And I am presenting doubts and evidence _here_, so end users can see why, where and how it is broken.

Maybe someone other than you will produce a practical reply.

Regards,
  Sergei.
&lt;/pre&gt;</description>
    <dc:creator>Sergei Steshenko</dc:creator>
    <dc:date>2012-05-16T21:01:53</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnu.octave.general/41536">
    <title>dubious logic in package 'uninstall' function</title>
    <link>http://permalink.gmane.org/gmane.comp.gnu.octave.general/41536</link>
    <description>&lt;pre&gt;Hello,

I am trying to understand what is the intended functionality of 'uninstall' function located in

octave-3.6.1/share/octave/3.6.1/m/pkg/pkg.m

file.

The function code with line numbers is below.

First about the 'global_install' flag - from analyzing full contents of the 'pkg.m' file I came to the conclusion that if the flag set, packages are supposed to be installed into Octave tree and not under user's home directory.


If so, when packages are to be uninstalled, and if 'global_install' is set, packages are to be uninstalled from Octave tree, not from under user's home tree, correct ? If this statement is not correct, then what is the meaning of 'global_install' ?

Looking at the code I see:


    965   if (global_install)
    966     installed_pkgs_lst = {local_packages{:}, global_packages{:}};
    967   else
    968     installed_pkgs_lst = local_packages;
    969   endif


and line #966 looks somewhat suspicious - because local (not inside Octave tree) packages are i&lt;/pre&gt;</description>
    <dc:creator>Sergei Steshenko</dc:creator>
    <dc:date>2012-05-16T20:49:42</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnu.octave.general/41535">
    <title>Re: octave + mkl</title>
    <link>http://permalink.gmane.org/gmane.comp.gnu.octave.general/41535</link>
    <description>&lt;pre&gt;



----- Original Message -----

People often want something (e.g. speed) _now_.

Regards,
  Sergei.
&lt;/pre&gt;</description>
    <dc:creator>Sergei Steshenko</dc:creator>
    <dc:date>2012-05-16T20:53:53</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnu.octave.general/41534">
    <title>Re: octave + mkl</title>
    <link>http://permalink.gmane.org/gmane.comp.gnu.octave.general/41534</link>
    <description>&lt;pre&gt;
Joshua Dillon wrote

ATLAS 3.8.x and OpenBLAS will be slower on your setup, but I'd be interested
to see how ATLAS 3.9.x compares, since they've got the Sandy Bridge AVX
extensions as well.  But IIRC it's nontrivial to build ATLAS correctly,
since the method to disable CPU throttling is not consistent across
different distros and processors.

--
View this message in context: http://octave.1599824.n4.nabble.com/octave-mkl-tp4629823p4629832.html
Sent from the Octave - General mailing list archive at Nabble.com.
&lt;/pre&gt;</description>
    <dc:creator>Luke M</dc:creator>
    <dc:date>2012-05-16T20:47:07</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnu.octave.general/41533">
    <title>Re: octave + mkl</title>
    <link>http://permalink.gmane.org/gmane.comp.gnu.octave.general/41533</link>
    <description>&lt;pre&gt;
What 3.2.4 build are you using? Which BLAS, in particular?

- Jordi G. H.
&lt;/pre&gt;</description>
    <dc:creator>Jordi Gutiérrez Hermoso</dc:creator>
    <dc:date>2012-05-16T20:42:54</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnu.octave.general/41532">
    <title>Re: octave + mkl</title>
    <link>http://permalink.gmane.org/gmane.comp.gnu.octave.general/41532</link>
    <description>&lt;pre&gt;

eigs has little to do with MKL. It's done with ARPACK. Are you really
seeing a lot of difference with eigs?


So probably what we'd like to see is more parallelisation in OpenBLAS,
LAPACK, and fftw?

- Jordi G. H.
&lt;/pre&gt;</description>
    <dc:creator>Jordi Gutiérrez Hermoso</dc:creator>
    <dc:date>2012-05-16T20:37:22</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnu.octave.general/41531">
    <title>Re: octave + mkl</title>
    <link>http://permalink.gmane.org/gmane.comp.gnu.octave.general/41531</link>
    <description>&lt;pre&gt;Also--I'm on a quad core i5 2405 so that probably explains the 4x speed-up.

On Wed, May 16, 2012 at 1:28 PM, Joshua Dillon &amp;lt;jvdillon&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:



&lt;/pre&gt;</description>
    <dc:creator>Joshua Dillon</dc:creator>
    <dc:date>2012-05-16T20:29:12</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnu.octave.general/41530">
    <title>Re: 'rgb2gray' undefined</title>
    <link>http://permalink.gmane.org/gmane.comp.gnu.octave.general/41530</link>
    <description>&lt;pre&gt;

rgb2gray is part of the image package
   http://octave.sourceforge.net/image/function/rgb2gray.html
not of octave core

try "pkg list" and "pkg load image"
&lt;/pre&gt;</description>
    <dc:creator>marco atzeri</dc:creator>
    <dc:date>2012-05-16T20:28:19</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnu.octave.general/41529">
    <title>Re: octave + mkl</title>
    <link>http://permalink.gmane.org/gmane.comp.gnu.octave.general/41529</link>
    <description>&lt;pre&gt;It's no skin off my nose.  I just thought it would be helpful to
others who'd like to match Matlab's speed.

My *VERY* informal timing of MKL+octave shows it to be exactly the
same speed as Matlab for "standard" operations like eig and eigs.
Indeed, matlab uses MKL for these operations.

%Octave 3.7.0+ w/MKL:
Elapsed time is 0.967732 seconds.

%Octave 3.2.4 w/o MKL:
Elapsed time is 4.09906 seconds.

%Matlab r2011b:
Elapsed time is 0.986376 seconds.

I confirmed this over many runs and other operations but didn't save
the results.  As I said, I'm just trying to let others know how to do
this.

Cheers,

Josh


On Wed, May 16, 2012 at 1:16 PM, Sergei Steshenko &amp;lt;sergstesh&amp;lt; at &amp;gt;yahoo.com&amp;gt; wrote:



&lt;/pre&gt;</description>
    <dc:creator>Joshua Dillon</dc:creator>
    <dc:date>2012-05-16T20:28:00</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnu.octave.general/41528">
    <title>'rgb2gray' undefined</title>
    <link>http://permalink.gmane.org/gmane.comp.gnu.octave.general/41528</link>
    <description>&lt;pre&gt;I'm completely new to Octive (and MATLAB, FREEMAT, etc.).  Everything seems
to work, except that I get an error when I try to use rgb2gray:

octave:1&amp;gt; im1=imread('test.jpg');
warning: your version of GraphicsMagick limits images to 16 bits per pixel
octave:2&amp;gt; tmp1 = uint8(im1);
octave:3&amp;gt; tmp2 = rgb2gray(tmp1);
error: `rgb2gray' undefined near line 3 column 8
octave:3&amp;gt;

So, I tried FreeMat and got a similar error.  I'm using Octave3.6.1_gcc4.6.2
in Windows 7 64 bit.  I tried running it as an Admin, and it made no
difference.

--
View this message in context: http://octave.1599824.n4.nabble.com/rgb2gray-undefined-tp4629826.html
Sent from the Octave - General mailing list archive at Nabble.com.
&lt;/pre&gt;</description>
    <dc:creator>4evrplan</dc:creator>
    <dc:date>2012-05-16T20:23:05</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.gnu.octave.general/41527">
    <title>Re: octave + mkl</title>
    <link>http://permalink.gmane.org/gmane.comp.gnu.octave.general/41527</link>
    <description>&lt;pre&gt;



----- Original Message -----

MKL probably works faster.

If so, end users care much more about performance than about ideology.

End users, as long as they don't distribute Octave, have full right to combine free and non-free SW inside their version of Octave (of course, provided non-free SW license doesn't prohibit using it with free SW).

It's very good there are people who promote ways to build faster Octave - despite your ideological objections.

FWIW, 'ffmpeg' developers are much more tolerant - they explicitly allow in 'configure' to choose non-free components, they just remind that such a 'ffmpeg' built with non-free pieces can't be distributed.

Regards,
  Sergei.
&lt;/pre&gt;</description>
    <dc:creator>Sergei Steshenko</dc:creator>
    <dc:date>2012-05-16T20:16:05</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.gnu.octave.general">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.gnu.octave.general</link>
  </textinput>
</rdf:RDF>

