octave-dev — GNU Octave developers' list

Re: [OctDev] Re: new release

[Quentin S. <qsp...@ie...>]

John W. Eaton wrote:

>On 29-Dec-2005, David Bateman wrote:
>
>| > I think decrufting and supporting older versions of octave at the same 
>| > time is not practical, so I'm arguing for a clean break.
>
>Sorry, I was traveling for a week, then out of commission with some
>flu-like thing, then traveling again.  I have a backlog of patches
>(including the code for the package system) that I will try to work
>through as soon as possible.
>  
>

While we're still discussing a new release sometime soon, I'd like to 
repeat a request I made a while ago. Can we remove the nonfree directory 
from octave-forge and make it a separate package? Even though it's not 
installed by default, I am required to use a modified version of the 
source package to comply with Fedora Extras policies. When I brought 
this up before, I believe the Debian maintainer said they should 
technically be doing the same thing as well.

-Quentin

[OctDev] Re: new release

[John W. E. <jw...@be...>]

On 29-Dec-2005, David Bateman wrote:

| > I think decrufting and supporting older versions of octave at the same 
| > time is not practical, so I'm arguing for a clean break.

Sorry, I was traveling for a week, then out of commission with some
flu-like thing, then traveling again.  I have a backlog of patches
(including the code for the package system) that I will try to work
through as soon as possible.

jwe

Re: [OctDev] Patch for making octave-forge buidl with GNU make 3.81

[Rafael L. <ra...@de...>]

* David Bateman <Dav...@mo...> [2006-01-02 10:31]:

> Paul Kienzle wrote:
> 
> >Feel free to make changes as necessary.
> >
> >You should put a comment in the Makefile about why the seemingly
> >pointless ;\ is there so that we don't clean it up later.
> >
> They appear to be my files... I consider myself informed :-). Make the 
> changes...

As you have probably seen, it is a bug in GNU make, apparently fixed by
the upstream author already (cf
http://lists.gnu.org/archive/html/help-make/2006-01/msg00005.html).  The
fix will appear in the forthcoming release of GNU make and I gave up on
making the changes in CVS.

-- 
Rafael

[OctDev] Re: Pattern rule defined multiple times

[Rafael L. <rla...@us...>]

* Paul D. Smith <ps...@gn...> [2006-01-03 12:22]:

> Never mind about reporting this on Savannah, I've fixed this bug.

Thanks for fixing the bug.  

> The fix will be available in the next release.

Do you know when the next release will happen?
 
-- 
Rafael

Re: [OctDev] Installing into $DESTDIR instead of /

[Quentin S. <qsp...@ie...>]

William Poetra Yoga Hadisoeseno wrote:

>Hi, I think it would be nice if we can install to $DESTDIR instead of
>/, just like those projects with automake. This patch should do the
>job :)
>  
>

I really like this feature--it is useful for packaging systems such as 
rpm or deb that require installation into a temporary directory tree. I 
have tested it and it appears to work correctly, so I applied the patch.

-Quentin

[OctDev] Re: strfind.m

[William P. Y. H. <wil...@gm...>]

On 1/3/06, Alois Schloegl <alo...@tu...> wrote:
> I prefer the recursive version. It gives cleaner and shorter code and
> needs less temporary variables.
>

I see your point. Actually our point of views are different: you view
it from the "cellstr as an extra functionality" viewpoint, while I
view it from the "cellstr as a generalization of string" viewpoint.
Well, I don't know, but I'm sometimes reluctant to do something
recursively unless absolutely neccessary. And our approaches both have
advantages and disadvantages.

Your code's advantage is: char matrix is handled as fast as before;
disadvantage: uses recursion.

My code's advantage is: no recursion; disadvantage: char matrix is
handled a bit slower.

Actually there's another way to do it; I first thought of this idea,
but later preferred my current code: handle char matrix and cellstr
differently (like your code), but don't use recursion for cellstr.
Instead, use a loop (like mine) for cellstr. This has the advantage
that simple arguments (char matrices) are handled without loss of
speed (inherited from your code) and that cellstr is handled without
recursion (inherited from my code). The disadvantage is that the
searching code is duplicated, which might cause maintenance problems
later on.

I still prefer my code, though :p

> >>I'll check in the changes into Octave-forge. You can post it to
> >>bug-octave and ask John to include it.
> >>
> source-octave (instead of bug-octave) would be more appropriate.
>

I've never posted to source-octave, and it seems that the list is very quie=
t...

--
William Poetra Yoga Hadisoeseno

[OctDev] Re: Pattern rule defined multiple times

[Paul D. S. <ps...@gn...>]

Never mind about reporting this on Savannah, I've fixed this bug.  The
fix will be available in the next release.


If you want to test the fix, apply this patch:

--- read.c      14 Dec 2005 13:11:18 -0000      1.155
+++ read.c      3 Jan 2006 17:21:02 -0000
@@ -1177,10 +1177,12 @@
             /* Put all the prerequisites here; they'll be parsed
             later.  */
             deps = (struct dep *) xmalloc (sizeof (struct dep));
             deps->next = 0;
-            deps->name = xstrdup (beg);
+            deps->name = savestring (beg, end - beg + 1);
+            deps->file = 0;
+            deps->changed = 0;
+            deps->ignore_mtime = 0;
             deps->staticpattern = 0;
             deps->need_2nd_expansion = 0;
-            deps->file = 0;
           }
         else
           deps = 0;

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <ps...@gn...>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.paulandlesley.org
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist

[OctDev] Re: strfind.m

[Alois S. <alo...@tu...>]

illiam Poetra Yoga Hadisoeseno wrote:

>On 1/2/06, Alois Schloegl <alo...@tu...> wrote:
>  
>
>>William Poetra Yoga Hadisoeseno wrote:
>>
>>Concering the additional support of cellstrings, I suggest to changes as
>>attached. Moreover, the result in
>> IDX = strfind(STR,PATTERN) should return a vector, not a cell with an
>>vector element. The attached version does this.
>>
>>    
>>
>
>Actually, my version returns a vector. 
>
Ok. I see, you need an extra "if" and a flag variable.

>It works by 'generalizing' the
>input, like this:
>1. If the first arg is a string or char matrix, then put it into a
>cell array and take note of this.
>2. Now the object we have is a cellstr (otherwise an error would be
>generated). For every element in the cellstr, check for PATTERN and
>put the starting indexes in IDX.
>3. If the first arg was a string or char matrix, then take the vector
>inside IDX and assign it to IDX.
>This way, we can avoid recursion of strfind(). What do you think?
>  
>
I prefer the recursive version. It gives cleaner and shorter code and 
needs less temporary variables.

>>I'll check in the changes into Octave-forge. You can post it to
>>bug-octave and ask John to include it.
>>
>>    
>>
source-octave (instead of bug-octave) would be more appropriate.

>
>OK :)
>
>I fixed the help message and changed isstr to ischar in my version
>(attached). What do you think about it?
>  
>
I changed isstr to ischar, too.

>--
>William Poetra Yoga Hadisoeseno
>  
>

Best,
   Alois

[OctDev] Re: strfind.m

[William P. Y. H. <wil...@gm...>]

On 1/2/06, Alois Schloegl <alo...@tu...> wrote:
> William Poetra Yoga Hadisoeseno wrote:
>
> Concering the additional support of cellstrings, I suggest to changes as
> attached. Moreover, the result in
>  IDX =3D strfind(STR,PATTERN) should return a vector, not a cell with an
> vector element. The attached version does this.
>

Actually, my version returns a vector. It works by 'generalizing' the
input, like this:
1. If the first arg is a string or char matrix, then put it into a
cell array and take note of this.
2. Now the object we have is a cellstr (otherwise an error would be
generated). For every element in the cellstr, check for PATTERN and
put the starting indexes in IDX.
3. If the first arg was a string or char matrix, then take the vector
inside IDX and assign it to IDX.
This way, we can avoid recursion of strfind(). What do you think?

> I'll check in the changes into Octave-forge. You can post it to
> bug-octave and ask John to include it.
>

OK :)

I fixed the help message and changed isstr to ischar in my version
(attached). What do you think about it?

--
William Poetra Yoga Hadisoeseno

[OctDev] Installing into $DESTDIR instead of /

[William P. Y. H. <wil...@gm...>]

Hi, I think it would be nice if we can install to $DESTDIR instead of
/, just like those projects with automake. This patch should do the
job :)

--
William Poetra Yoga Hadisoeseno

Re: [OctDev] tests failing 2.1.72 on FC4

[David B. <Dav...@mo...>]

Paul Kienzle wrote:

> I'm trying to build and test octave-forge against 2.1.72 on FC4.
>
> Any idea why the following test doesn't work?
>
> Thanks,
>
>     - Paul
>
> octave> fixedpoint("test");
> ...
> << Fixed Point Functions >>
>   Rounding Functions:                       error: scalar cannot be 
> indexed with .
> error: evaluating binary operator `-' near line 1694, column 23
> error: evaluating argument list element number 1
> error: evaluating binary operator `>' near line 1694, column 37
> error: evaluating binary operator `||' near line 1694, column 44
> error: if: error evaluating conditional expression
> error: evaluating if command near line 1694, column 5
> error: evaluating if command near line 1691, column 3
> error: called from `fixedpoint:_fixedpoint_test_function' in file 
> `/home/NCNRWIN/pkienzle/cvs/octave-forge/main/fixed/fixedpoint.m'
> error: evaluating binary operator `||' near line 483, column 55
> error: evaluating binary operator `||' near line 484, column 49
> error: if: error evaluating conditional expression
> error: evaluating if command near line 483, column 7
> error: evaluating if command near line 94, column 3
> error: called from `fixedpoint' in file 
> `/home/NCNRWIN/pkienzle/cvs/octave-forge/main/fixed/fixedpoint.m'

I'm not sure this is a bug. The problem command is

f = fixed(7,2,1.00);
x = real(f).x;

What is happening is that the PKG_ADD for the fixed directory adds the 
dispatch

dispatch ("real", "freal", "fixed scalar")
dispatch ("real", "freal", "fixed matrix")
dispatch ("real", "freal", "fixed complex")
dispatch ("real", "freal", "fixed complex matrix")

so that real(f) returns another fixed-point number. However, it seems 
that you have installed before testing and the dispatch commands aren't 
available so the normal version of real is being called and is returning 
a scalar rather than a fixed-point, which of course then can't be 
indexed with ".x"....

Two solutions; 1) Install the PKG_ADD prior to testing... 2) Change the 
use of generic functions in fixedpoint.m to their undispatched versions 
where needed... I believe the patch attached is sufficient to do this (I 
can't apply this at the moment)..

Regards
David

-- 
David Bateman                                Dav...@mo...
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

Re: [OctDev] regress and rcoplot (partially written, please help)

[William P. Y. H. <wil...@gm...>]

On 1/2/06, Paul Kienzle <pki...@us...> wrote:
>
> On Jan 1, 2006, at 4:20 AM, William Poetra Yoga Hadisoeseno wrote:
>
> > OK, today I finally finished the function (I think). I used Paul's
> > notes at the end of wsolve.m. Take a look at the attachment ;)
>
> You are not using the economy QR decomposition.  This can lead to
> very large matrices for over determined systems.
>
> Also, you should generally avoid computing the full inverse as
> part of solving a system.  It is more expensive and I believe
> less stable than working directly off the QR decomposition that
> you have already computed.
>
> Any reason you did not use my wsolve code as it stands?
>
> Similarly, do you have a reason for not using the code I sent
> for computing confidence intervals, which also avoids direct
> computation of the inverse?
>
> If there is some reason to prefer your code I would like
> to know what it is.
>

No reason, it's just that I didn't study my linear algebra course well
(never went to class, for example :( ), and I haven't retaken it yet,
so that part of Mathematics is my "blurry spot" (not quite a blind
spot...). As such, I don't really understand your code well; for my
dataset, my code works, so for the time being I haven't used your code
yet.

I'm having my exams now, so I wouldn't have too much time for that.
But I'll look at it again (so don't include it first). Alternatively,
if you would like to modify the function, I don't mind :) (although it
wouldn't be very educative for me).

--
William Poetra Yoga Hadisoeseno

[OctDev] Re: Pattern rule defined multiple times

[Paul D. S. <ps...@gn...>]

This is definitely a bug.

Please report this on Savannah:

    https://savannah.gnu.org/bugs/?func=additem&group=make

Thank you.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <ps...@gn...>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.paulandlesley.org
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist

[OctDev] tests failing 2.1.72 on FC4

[Paul K. <pki...@us...>]

I'm trying to build and test octave-forge against 2.1.72 on FC4.

Any idea why the following test doesn't work?

Thanks,

	- Paul

octave> fixedpoint("test");
...
<< Fixed Point Functions >>
   Rounding Functions:                       error: scalar cannot be 
indexed with .
error: evaluating binary operator `-' near line 1694, column 23
error: evaluating argument list element number 1
error: evaluating binary operator `>' near line 1694, column 37
error: evaluating binary operator `||' near line 1694, column 44
error: if: error evaluating conditional expression
error: evaluating if command near line 1694, column 5
error: evaluating if command near line 1691, column 3
error: called from `fixedpoint:_fixedpoint_test_function' in file 
`/home/NCNRWIN/pkienzle/cvs/octave-forge/main/fixed/fixedpoint.m'
error: evaluating binary operator `||' near line 483, column 55
error: evaluating binary operator `||' near line 484, column 49
error: if: error evaluating conditional expression
error: evaluating if command near line 483, column 7
error: evaluating if command near line 94, column 3
error: called from `fixedpoint' in file 
`/home/NCNRWIN/pkienzle/cvs/octave-forge/main/fixed/fixedpoint.m'

[OctDev] Re: strfind.m

[Alois S. <alo...@tu...>]

William Poetra Yoga Hadisoeseno wrote:

>The strfind function is well written, so I had little trouble updating
>it to be compatible with Matlab. Now I think it's quite ready for
>submission into Octave, so I would like Alois, as the original author,
>and others to comment. If there are no comments, I will post it to
>bu...@oc... and let John include it in Octave.
>
>The file is attached.
>
>--
>William Poetra Yoga Hadisoeseno
>  
>


I forgot the attachment, here is it.

Alois

-----


Thanks for including the docu and test functions and converting it to
octave style.

Concering the additional support of cellstrings, I suggest to changes as
attached. Moreover, the result in
IDX = strfind(STR,PATTERN) should return a vector, not a cell with an
vector element. The attached version does this.

I'll check in the changes into Octave-forge. You can post it to
bug-octave and ask John to include it.


Alois

[OctDev] Re: strfind.m

[Alois S. <alo...@tu...>]

William Poetra Yoga Hadisoeseno wrote:

>The strfind function is well written, so I had little trouble updating
>it to be compatible with Matlab. Now I think it's quite ready for
>submission into Octave, so I would like Alois, as the original author,
>and others to comment. If there are no comments, I will post it to
>bu...@oc... and let John include it in Octave.
>
>The file is attached.
>
>--
>William Poetra Yoga Hadisoeseno
>  
>


Thanks for including the docu and test functions and converting it to 
octave style.

Concering the additional support of cellstrings, I suggest to changes as 
attached. Moreover, the result in
 IDX = strfind(STR,PATTERN) should return a vector, not a cell with an 
vector element. The attached version does this.

I'll check in the changes into Octave-forge. You can post it to 
bug-octave and ask John to include it.


Alois

Re: [OctDev] Patch for making octave-forge buidl with GNU make 3.81

[David B. <Dav...@mo...>]

Paul Kienzle wrote:

> Rafael,
>
> Feel free to make changes as necessary.
>
> You should put a comment in the Makefile about why the seemingly
> pointless ;\ is there so that we don't clean it up later.
>
> It is polite to inform the author of the file that you have
> made the change.  The rest of us can pick it up from the
> excellent one-line description you give when you post the update
> to CVS.
>
> Thanks,
>
>     - Paul
>
They appear to be my files... I consider myself informed :-). Make the 
changes...

D.


-- 
David Bateman                                Dav...@mo...
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

[OctDev] Re: Sudoku solver

[Etienne G. <et...@cs...>]

On Sat, Dec 31, 2005 at 09:28:58PM -0500, Paul Kienzle wrote:
# Hmmm... That's the second posted sudoku solver.  Does that mean it is

  Right! 

http://www.octave.org/mailing-lists/help-octave/2005/2722

I had missed that one - didn't know about sudoku until last week.
I'll try Pasquale's code - so much for my "utility" good resolution!

  Cheers,

  Etienne

# time to add it to octave-forge/main/games?
# 
# - Paul
# 
# On Dec 31, 2005, at 2:55 PM, Etienne Grossmann wrote:
# 
# >
# >  Hi All,
# >
# >here is a sudoku solver I wrote recently. I tried it on just 3 probs,
# >the last ones from The Providence Journal, which it seems to solve.
# >
# >## [output,feasible] = sudoku (input) - Try to solve a sudoku problem
# >##
# >## This function applies brutish force and may or may not work 
# >properly. The
# >## method (1) excludes impossible values of cells within each group 
# >(row,
# >## column and 3x3 block), (2) deduces the value of a cell that is the 
# >only
# >## one to be able to assume that value within a group and (3) makes 
# >guesses
# >## and sees where they lead (depth-first search). Does not check for
# >## unicity. May or may not detect unsolvalble cases properly.
# >##
# >## Please report success/failure to me <et...@la...>.
# >##
# >## input   : 9 x 9 : initial grid w/ unknown values set to 0.
# >##
# >## output  : 9 x 9 : final grid.
# >## feasible: true if a solution was found, 0 otherwise.
# >
# >  Good resolution for 2006: Do more useful things than the above!
# >
# >  Cheers,
# >
# >  Etienne
# >
# >-- 
# >Etienne Grossmann ------ http://www.cs.uky.edu/~etienne
# ><sudoku.m>
# 

-- 
Etienne Grossmann ------ http://www.cs.uky.edu/~etienne

Re: [OctDev] regress and rcoplot (partially written, please help)

[Paul K. <pki...@us...>]

On Jan 1, 2006, at 4:20 AM, William Poetra Yoga Hadisoeseno wrote:

> OK, today I finally finished the function (I think). I used Paul's
> notes at the end of wsolve.m. Take a look at the attachment ;)

You are not using the economy QR decomposition.  This can lead to
very large matrices for over determined systems.

Also, you should generally avoid computing the full inverse as
part of solving a system.  It is more expensive and I believe
less stable than working directly off the QR decomposition that
you have already computed.

Any reason you did not use my wsolve code as it stands?

Similarly, do you have a reason for not using the code I sent
for computing confidence intervals, which also avoids direct
computation of the inverse?

If there is some reason to prefer your code I would like
to know what it is.

- Paul

Re: [OctDev] regress and rcoplot (partially written, please help)

[William P. Y. H. <wil...@gm...>]

On 12/31/05, William Poetra Yoga Hadisoeseno <wil...@gm...> wrot=
e:
> On 12/31/05, Paul Kienzle <pki...@us...> wrote:
> > Here's what I wrote in wsolve:
> >
> ...
> >
> > Here's what I wrote in polyconf:
> >
>
> Thanks, I'll take a look ;)
>

OK, today I finally finished the function (I think). I used Paul's
notes at the end of wsolve.m. Take a look at the attachment ;)

Paul, do you want to have it in octave-forge, or should I submit it
for inclusion in Octave instead?

--
William Poetra Yoga Hadisoeseno

[OctDev] str*cmp* functions

[William P. Y. H. <wil...@gm...>]

I've done the following:
1. Changed the help text of the strcmp function to reflect its ability
to accept cell arrays as arguments.
2. Simplified the strcmpi and strncmp functions.
3. Imported strncmpi from octave-forge and simplified it.
4. Written the strtrunc function.

Explanation:
1. strcmp is actually already compatible with Matlab's strcmp, so I
just added the help text.
2. The implementations of strcmpi, strncmp, and strncmpi
(octave-forge) are too complex, IMO, so I simplified them.
3. But the changes made to strncmp and strncmpi needs strtrunc, so I wrote =
it.
4. strtrunc takes a string or cellstr as its first argument (s), then
truncates it to the value of the second argument (n).

Although strtrunc is not present in Matlab, I think this is useful, so
I'm sending it here. I hope John would accept this.

The attachments:
1. str2.diff.txt: diff for strcmp, strcmpi, strncmp
2. str2.ChangeLog.src.txt: changelog entry for strcmp
3. str2.ChangeLog.scripts.txt: changelog entry for strcmpi, strncmp,
strncmpi and strtrunc
4. strncmpi.m.txt, strtrunc.m.txt: the corresponding functions

--
William Poetra Yoga Hadisoeseno

Re: [OctDev] Octave interface to GNU units

[James R. P. <ant...@ya...>]

--- Paul Kienzle  wrote:
> I wonder if the 125 M$ Mars Climate Orbiter could have afforded the 
> extra
> processing cost of carrying units with every quantity?  Perhaps not, but
> clearly it couldn't afford to drop them either.
> 
> Carrying units is an aid to producing correct code, so having the 
> facility
> available in a prototyping environment would by helpful.  Whether they 
> can
> be handled efficiently enough to be used in a production environment
> is a separate question.
> 
> - Paul
> 

I don't disagree with the concept of having units carried and checked in a
prototyping environment.  I always thought that the units facilities provided
by MathCad were about right.  I was an early and enthusiastic adopter of
MathCad (when it was affordable); but haven't used it in probably five years
now.

Re: [OctDev] regress and rcoplot (partially written, please help)

[William P. Y. H. <wil...@gm...>]

On 12/31/05, Paul Kienzle <pki...@us...> wrote:
> You should just be able to use errorbar.
>
> Assuming you don't want to because you don't like how it looks, can you
> set the symbol size larger instead of drawing circles yourself?
>
>     __gnuplot_set__('pointsize 2'); plot(rand(5,1),'o;;');
>
> I would suggest plotting using:
>
>    plot(cx,cy,'o;;',lx,ly,'-;;')
>
> where cx,cy are the points and lx,ly are matrices with three columns
> and two rows for each r defining the end points of the error bars and
> the caps respectively.
>
> If you decide to draw the circles yourself, change this to:
>
>    plot(cx,cy,'o;;',lx,ly,'-;;')
>
> where cx,cy contain one column per circle.
>
> No for loops needed, and a small number of separate matrices being
> plotted should improve your performance a lot.
>

OK, I was at first a bit confused because your code generates '+'
style points on the graph; but then I think it's a bug in octave.
Well, it seems I would have to look at the plotting commands...

Thanks anyway, I'll see what I can use ;)

--
William Poetra Yoga Hadisoeseno

Re: [OctDev] Patch for making octave-forge buidl with GNU make 3.81

[Rafael L. <ra...@de...>]

* Paul Kienzle <pki...@us...> [2005-12-31 03:53]:

> Feel free to make changes as necessary.

I will do, but I will wait for a reply to my recent post in
hel...@gn..., which was Cc:ed here.

-- 
Rafael

Re: [OctDev] regress and rcoplot (partially written, please help)

[Paul K. <pki...@us...>]

You should just be able to use errorbar.

Assuming you don't want to because you don't like how it looks, can you 
set the symbol size larger instead of drawing circles yourself?

    __gnuplot_set__('pointsize 2'); plot(rand(5,1),'o;;');

I would suggest plotting using:

   plot(cx,cy,'o;;',lx,ly,'-;;')

where cx,cy are the points and lx,ly are matrices with three columns 
and two rows for each r defining the end points of the error bars and 
the caps respectively.

If you decide to draw the circles yourself, change this to:

   plot(cx,cy,'o;;',lx,ly,'-;;')

where cx,cy contain one column per circle.

No for loops needed, and a small number of separate matrices being 
plotted should improve your performance a lot.

- Paul

On Dec 31, 2005, at 3:06 AM, William Poetra Yoga Hadisoeseno wrote:

> For rcoplot:
> 1. The round circles in the middle are ugly
> 2. It's a bit slow, but that's the fastest I can get. I've tried
> looping the plot command (and using hold on/off), but that's slower.