octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Moving functions from octave to octave-forge?


From: David Bateman
Subject: Re: Moving functions from octave to octave-forge?
Date: Wed, 02 May 2007 10:34:44 +0200
User-agent: Thunderbird 1.5.0.7 (X11/20060921)

Shai Ayal wrote:
> I'll just add what's available in octplot/high_level to this list.
> unless stated otherwise, they are matlab compatible with v6 graphics
> -- octplot has no group objects.
>
>> Graphics Stuff:
>>   contourf fill fill3 gtext pareto patch pcolor peaks pie quiver scatter
>>   surf surfc zoom meshc
>>
>> * contourf, fill, fill3, patch, pcolor, pie all need new graphics
>> objects for patches, the current code is just a hack to simulate it.
>
> We now have a working contourf and clabel in octplot/high_level thanks
> to work by Kai Habel. They rely on patch of course. I see now way to
> do this with gnuplot. To the best of my knowledge, nothing even
> approximating patch is not even planned for gnuplot
I think patch is possible with gnuplot. What I meant is that all of
these should wait for patch to be implemented in octave core before
doing much with them.. If you have something working in octplot, perhaps
you can suggest patches to the core to and least get the front-end of
patch objects included in the core..

>
>
>> * pareto and peaks seem just to need the help text texinfo-fied...
>
> pareto is available in octplot/high_level
Ok, we should pick one :-)

>
>> * gtext as it stands can't be ported as it uses some X11 specific hacks.
>> Doing it right with gnuplot requires two way interaction and mouse
>> control in gnuplot..
>>
>> * quiver needs to have a quivergroup object class. The o-f version is a
>> gnuplot specific hack.
>
> Another non-matlab compatible version is in octplot (it uses line
> properties which are not available in matlab, only in octplot, to draw
> arrows)
>
I'd leave quiver as I think the low-level patch type is much more
important. Once we have the high-level plotting functions based on patch
correct we can worry about things like quiver..

In any case the function

bicg brighten ode23 ode45 odeget odephas2 odephas3 odeplot odeprint
odeset imread imwrite psi


should definitely be looked at for importation, though the issue with
the odepkg/mex-files and the Imagemagick dependency on imread/imwrite
needs addressing. The ones in my "too hard" basket depend on someone
going to the effort of importing them.

Cheers
David

-- 
David Bateman                                address@hidden
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob) 
91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax) 

The information contained in this communication has been classified as: 

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]