octave-maintainers
[Top][All Lists]
Advanced

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

Re: PKG: miscellanoues


From: Juan Pablo Carbajal
Subject: Re: PKG: miscellanoues
Date: Mon, 15 Apr 2013 10:49:27 +0200

On Mon, Apr 15, 2013 at 9:34 AM, Olaf Till <address@hidden> wrote:
> On Mon, Apr 15, 2013 at 02:05:16AM +0100, Carnë Draug wrote:
>> On 13 April 2013 19:12, Juan Pablo Carbajal <address@hidden> wrote:
>> > I think the functions *poly (as in legendre, chebyshev, etc...) in the
>> > miscellaneous package (1.2.0) should be merged with their not
>> > completely equivalent specfun package siblings or, even easier just
>> > move them over cause there is no naming conflict.
>> >
>> > What do you think?
>>
>> I have another thought about the miscellaneous package. Removing it
>> completely. Miscellaneous functions is the type of thing that belongs
>> to Agora. Or in core if they're useful.
>>
>> Here's my suggestion:
>>
>> 1 - good useful pieces of code - move to core (publish() is part of matlab 
>> core)
>> 2 - functions that fit in another package - move to that package
>> 3 - the rest - move to Agora as individual functions or small bundles
>> (I think some could actually be turned into sections of the Octave
>> cookbook)
>>
>> Carnë
>
> There is at least one difficulty with this: read_options.m, an option
> passing system by Etienne Grossmann. It is used by his optimization
> functions within optim and by his vrml package. Since recenently,
> publish.m in miscellaneous uses it, too. Most other optimization
> functions, in particular some in Octave core, have adopted the
> optimset mechanism instead. Moving read_options to Octave core would
> require a discussion on whether a different option passing mechanism
> is reasonable, and if yes, on possible changes and refinements of this
> mechanism. My personal opinion is that though optimset (et al.) might
> not be ideal, it is no use discussing it since it is Matlabs mechanism
> and also already established in Octave, and it would be an unnecessary
> complexity to maintain a second option passing mechanism. But 3
> different packages currently depend on read_options.
>
> Olaf
>
> --
> public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQIcBAEBCAAGBQJRa61vAAoJEMDkvsXq/gWR820P/0QI1YhqL/2+9r4LUy9iXwUd
> /ZMuPVbbj6dzj821NQnJ6Fr2beWSHJPX2jSRBGycPlHV4fFEyUpYFPKQS485NiE5
> mGINbppjP6O9uExMAd9Mnf9fTeASqdpji816kJ1MAXe6xq2r0FZ1WvrgvBMy/eYk
> FGOp/ADKhSqR6wn4EEOBKUgKiqkTDpMcc0alnjd8BR4UBJObzi8oQDglRXSLhp7V
> oC/fKaU0XMX77l4qA+gRN+wbqMkonLEtuwZfjg7PxB6+1w3l4rz/WVpQ/Bb4DY6T
> YU52KvgAR4CSL1st+TR0FJjYOPl8FPOYHO/dqqxnn/1D3y+4FDoWzUgALl5HXX5m
> NA4UgbA9ShlsmVb/BHFTa33HF6e8/PrTcFy1eV+9r+9MfFonbKaxpnGKBx8m8mf8
> AwqnGbp5wdkaiVoxrxO0jEURQbwYDuPbdueWZgSPNixcaaJlRBpSeiHru4YTTs1g
> PvOgXyqSPlzpebWU/BMpvMsWM/t7uPuAFz2mBH008BjeWLj7nlyTW50+XpME4Edm
> wHQZ1tSJZ6UkEk+JwqBg029FSAQc/ICb1Sh3bXofX+/yb+zaAjyMVLKUH6nhuJJX
> i+5zFMs4BqHE/DTmnSa3gdlS7ngsQdO9ac1crSj0b+rDzhLZ+bdh0bubBTAwylAX
> ffX+eMjJ7la9Sv7/aY2r
> =FE+K
> -----END PGP SIGNATURE-----
>

The miscellaneous package as a very good reason to be, quote form its
description
"Miscellaneous tools that don't fit somewhere else."

We have to make sure that when a function in miscellaneous fits in
another place then it is moved there.


reply via email to

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