octave-dev — GNU Octave developers' list

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

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

Here's what I wrote in wsolve:

   [nr,nc] = size(A);
   if nc > nr, error("underdetermined system"); end

   ## system solution: A x = y => x = inv(A) y
   ## QR decomposition has good numerical properties:
   ##   AP = QR, with P'P = Q'Q = I, and R upper triangular
   ## so
   ##   inv(A) y = P inv(R) inv(Q) y = P inv(R) Q' y = P (R \ (Q' y))
   ## Note that b is usually a vector and Q is matrix, so it will
   ## be faster to compute (y' Q)' than (Q' y).
   [Q,R,p] = qr(A,0);
   x = R\(y'*Q)';
   x(p) = x;

   s.R = R;
   s.R(:,p) = R;
   s.df = nr-nc;
   s.normr = norm(y - A*x);

Here's what I wrote in polyconf:

## Confidence intervals for linear system are given by:
##    x' p +/- sqrt( Finv(1-a,1,df) var(x' p) )
## where for confidence intervals,
##    var(x' p) = sigma^2 (x' inv(A'A) x)
## and for prediction intervals,
##    var(x' p) = sigma^2 (1 + x' inv(A'A) x)
##
## Rather than A'A we have R from the QR decomposition of A, but
## R'R equals A'A.  Note that R is not upper triangular since we
## have already multiplied it by the permutation matrix, but it
## is invertible.  Rather than forming the product R'R which is
## ill-conditioned, we can rewrite x' inv(A'A) x as the equivalent
##    x' inv(R) inv(R') x = t t', for t = x' inv(R)
## Since x is a vector, t t' is the inner product sumsq(t).
## Note that LAPACK allows us to do this simultaneously for many
## different x using sqrt(sumsq(X/R,2)), with each x on a different row.
##
## Note: sqrt(F(1-a;1,df)) = T(1-a/2;df)

function [y,dy] = confidence(A,p,S,alpha,typestr)
   if nargin < 4, alpha = []; end
   if nargin < 5, typestr = 'ci'; end
   y = A*p(:);
   switch typestr,
     case 'ci', pred = 0; default_alpha=erfc(1/sqrt(2));
     case 'pi', pred = 1; default_alpha=0.05;
     otherwise, error("use 'ci' or 'pi' for interval type");
   end
   if isempty(alpha), alpha = default_alpha; end
   s = t_inv(1-alpha/2,S.df)*S.normr/sqrt(S.df);
   dy = s*sqrt(pred+sumsq(A/S.R,2));


Can you use these two functions to do what you need?

    - Paul

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

> In the Matlab documentation from www.mathworks.com (for regress),
> it mentions QR factorization (using QR factorization instead of
> computing an inverse matrix). Can anyone explain to me about this?

[OctDev] Pattern rule defined multiple times

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

I apologize if the issue I discuss below has already been discussed here.  I
do not have much time to browse the mailing list archives.

I noticed a difference in behavior between v3.80 and v3.81 of make regarding
multiple defined pattern rules.  Consider the following Makefile:

####################################################################
all:
        @touch foo.x
        @$(MAKE) foo.y
		
%.y : %.x ; @echo first
		
%.y : %.x
        @echo second		
####################################################################

The behavior I would expect is the one of v3.80, in which the second rule
override the first:

    $ make --version
    GNU Make 3.80
    Copyright (C) 2002  Free Software Foundation, Inc.
    This is free software; see the source for copying conditions.
    There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
    PARTICULAR PURPOSE.
    $ make -s
    second

However, v3.81 behaves differently:

    $ make --version
    GNU Make 3.81beta4
    Copyright (C) 2003  Free Software Foundation, Inc.
    This is free software; see the source for copying conditions.
    There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
    PARTICULAR PURPOSE.

    This program built for i486-pc-linux-gnu
    $ make -s
    first

Is this an intended feature or a bug?  If the former, could you please
explain to me the rationale of having syntactically equivalent forms with
different semantics?

-- 
Rafael

[OctDev] strfind.m

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

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

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

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

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


On Dec 30, 2005, at 6:33 PM, Rafael Laboissiere wrote:

> The following bug report has been filed against the octave-forge
> Debian package:
>
>     http://bugs.debian.org/344995
>
> Joaquim Ortega has investigated the problem and traced it down to a
> change in the way GNU make version 3.81 treats multiple defined pattern
> rules.
>
> Briefly, the problem is the following: the top srcdir Makeconf defines 
> the
> following default pattern rule:
>
>     %.o: %.cc ; $(MKOCTFILE) -c $<
>
> Makefiles like main/comm/Makefile have the following:
>
>     sinclude ../../Makeconf
>     [...]
>     %.o:%.cc
>            @echo "Compiling $@"; \
>            $(MKOCTFILE) $(MOFLAGS) $(DEFINES) -c $<
>
> With GNU make 3.80 or earlier, the second pattern rule overrode the one
> defined in Makeconf.  However, GNU make 3.81 interprets these two rules
> as two unrelated rules.  Frankly, I do not undertand the rationale for
> this change in the GNU make behavior because using the semicolon should
> make no semantic difference in the rule interpretaion.
>
> At any rate, it seems that changing the second rule to:
>
>     %.o:%.cc ; @echo "Compiling $@"; \
>            $(MKOCTFILE) $(MOFLAGS) $(DEFINES) -c $<
>
> fixes the problem.
>
> I just uploaded a new version of the octave-forge package to debian
> unstable which contains a patch for fixing the above problem.  This 
> patch
> is attached below.
>
> I am a member of the octave-forge project @ SF.  If you think the patch
> below is okay, I would gladly apply it to CVS.
>
> P.S.: I am also attaching below a patch to extra/pdb/Makefile which 
> fixes a
> minor problem, namely that make clean fails in extra/pdb when Makeconf 
> does
> not exist at the top srcdir.
>
> -- 
> Rafael
> <50_make-pattern-rules.dpatch><50_extra-pdb-sinclude.dpatch>

Re: [OctDev] Octave interface to GNU units

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

On Dec 30, 2005, at 5:03 PM, James R. Phillips wrote:

>
> --- Andy Adler  wrote:
>
>> I think that this is a much more important feature than
>> unit conversions. I would like to have software that gives
>> me an error when I say "1 apple + 2 oranges" rather
>> much more than one that tries to automatically find
>> the apple/orange conversion factor.
>>
>> One good way to do this in a strongly typed language
>> would be to create classes for each unit.
>>
>
> I must respectfully disagree with this approach (I've been a 
> dimensional
> analysis maven for years).  I think this concept is practical and 
> efficient
> only for high-level symbolic analyses, not for production numerical 
> analysis
> codes.
>
> IMHO, a better approach is to confine unit conversions, as much as 
> possible, to
> input and output routines, while the core internal calculations are 
> carried out
> in standard textbook-style equations that are correct in any 
> dimensionally
> homogeneous unit system.
>
> If this is done properly, than the actual "base" unit system for the
> calculations is irrelevant (within roundoff).  One way to check for 
> unit errors
> in the equations is then to switch the base unit system, and see if it 
> affects
> the results.
>
> To reiterate, each quantity is converted into the base system on 
> input, and
> into desired output units on output.  The "units" function provided 
> here could
> be used for that, but isn't as convenient as it could be if it were 
> possible to
> set a desired default set of base units.  Then the function could just 
> be
> interrogated for the necessary conversion from any unit into the 
> desired base
> system.
>
> Admittedly there are some fields of endeavor (econometrics) where the 
> standard
> equations of physics are not in much evidence, and can't be used to 
> check the
> correctness of the core calculations.  Again, however, I think that 
> symbolic
> analyses of the core equations are a better way to flush out unit 
> errors than
> embedding this sort of check into every numerical operation.

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

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

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

When doing my homework, I needed regress and rcoplot. So I've written
them, but they're far from completed. The problems I have are:

For regress:

1. In the Matlab documentation from www.mathworks.com (for regress),
it mentions QR factorization (using QR factorization instead of
computing an inverse matrix). Can anyone explain to me about this and
maybe modify the code?

2. The confidence interval for beta as returned by regress differs
from the one returned by Matlab's regress (I compared my results with
my friend's results, and also another set of data from my textbook).
I've implemented the formulas on my textbook (don't ask -- it's in
Chinese, but if you would like to know the formulas, I can post it
here), but I still don't know what went wrong. A note: for any
particular dataset, the intervals seem to be scaled with a factor
which is dependent on the dataset. So if Matlab's interval is
[b-m,b+m], then mine would be [b-qm,b+qm], with q < 1. But I don't
know where this q comes from, and for every dataset it is different.

3. The p value calculated is different from my friend's calculation
(using Matlab).

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.

Note that I'm using % for my comments, because I was comparing it with
my friend's data, and he only knows Matlab. When the problems above
are solved, I'll tidy up the functions and submit them (to
octave-forge? or to Octave?). Please help :)

--
William Poetra Yoga Hadisoeseno

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

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

The following bug report has been filed against the octave-forge
Debian package:

    http://bugs.debian.org/344995
    
Joaquim Ortega has investigated the problem and traced it down to a
change in the way GNU make version 3.81 treats multiple defined pattern
rules.

Briefly, the problem is the following: the top srcdir Makeconf defines the
following default pattern rule:

    %.o: %.cc ; $(MKOCTFILE) -c $<

Makefiles like main/comm/Makefile have the following:

    sinclude ../../Makeconf
    [...]
    %.o:%.cc
           @echo "Compiling $@"; \
           $(MKOCTFILE) $(MOFLAGS) $(DEFINES) -c $< 

With GNU make 3.80 or earlier, the second pattern rule overrode the one
defined in Makeconf.  However, GNU make 3.81 interprets these two rules
as two unrelated rules.  Frankly, I do not undertand the rationale for
this change in the GNU make behavior because using the semicolon should
make no semantic difference in the rule interpretaion.

At any rate, it seems that changing the second rule to:

    %.o:%.cc ; @echo "Compiling $@"; \
           $(MKOCTFILE) $(MOFLAGS) $(DEFINES) -c $< 

fixes the problem.

I just uploaded a new version of the octave-forge package to debian
unstable which contains a patch for fixing the above problem.  This patch
is attached below.

I am a member of the octave-forge project @ SF.  If you think the patch
below is okay, I would gladly apply it to CVS.

P.S.: I am also attaching below a patch to extra/pdb/Makefile which fixes a
minor problem, namely that make clean fails in extra/pdb when Makeconf does
not exist at the top srcdir.

-- 
Rafael

Re: [OctDev] Octave interface to GNU units

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

--- Andy Adler  wrote:

> I think that this is a much more important feature than
> unit conversions. I would like to have software that gives
> me an error when I say "1 apple + 2 oranges" rather
> much more than one that tries to automatically find
> the apple/orange conversion factor.
> 
> One good way to do this in a strongly typed language
> would be to create classes for each unit.
> 

I must respectfully disagree with this approach (I've been a dimensional
analysis maven for years).  I think this concept is practical and efficient
only for high-level symbolic analyses, not for production numerical analysis
codes.

IMHO, a better approach is to confine unit conversions, as much as possible, to
input and output routines, while the core internal calculations are carried out
in standard textbook-style equations that are correct in any dimensionally
homogeneous unit system.

If this is done properly, than the actual "base" unit system for the
calculations is irrelevant (within roundoff).  One way to check for unit errors
in the equations is then to switch the base unit system, and see if it affects
the results.

To reiterate, each quantity is converted into the base system on input, and
into desired output units on output.  The "units" function provided here could
be used for that, but isn't as convenient as it could be if it were possible to
set a desired default set of base units.  Then the function could just be
interrogated for the necessary conversion from any unit into the desired base
system.

Admittedly there are some fields of endeavor (econometrics) where the standard
equations of physics are not in much evidence, and can't be used to check the
correctness of the core calculations.  Again, however, I think that symbolic
analyses of the core equations are a better way to flush out unit errors than
embedding this sort of check into every numerical operation.

Jim Phillips

Re: [OctDev] Octave interface to GNU units

[Andy A. <an...@an...>]

SSB0aGluayB0aGF0IHRoaXMgaXMgYSBtdWNoIG1vcmUgaW1wb3J0YW50IGZlYXR1cmUgdGhhbgp1
bml0IGNvbnZlcnNpb25zLiBJIHdvdWxkIGxpa2UgdG8gaGF2ZSBzb2Z0d2FyZSB0aGF0IGdpdmVz
Cm1lIGFuIGVycm9yIHdoZW4gSSBzYXkgIjEgYXBwbGUgKyAyIG9yYW5nZXMiIHJhdGhlcgptdWNo
IG1vcmUgdGhhbiBvbmUgdGhhdCB0cmllcyB0byBhdXRvbWF0aWNhbGx5IGZpbmQKdGhlIGFwcGxl
L29yYW5nZSBjb252ZXJzaW9uIGZhY3Rvci4KCk9uZSBnb29kIHdheSB0byBkbyB0aGlzIGluIGEg
c3Ryb25nbHkgdHlwZWQgbGFuZ3VhZ2UKd291bGQgYmUgdG8gY3JlYXRlIGNsYXNzZXMgZm9yIGVh
Y2ggdW5pdC4KCkl0IG1heSBiZSBwb3NzaWJsZSB0byBkbyB0aGlzIHdpdGggY2xhc3NlczoKICAg
aWU6ICAgc3BlZWQ9IGNsYXNzKCAxMDAsICJrbV9wZXJfaCIpOwp0aGVuIGVhY2ggY2xhc3Mgd2ls
bCBuZWVkIG9wZXJhdG9ycyBkZWZpbmVkIHRvIGRvIHRoZSByaWdodAp0aGluZy4gaWUgc3BlZWQg
KiB0aW1lID0gZGlzdGFuY2UuCgpNb3N0IGZ1bmN0aW9ucyAoc2luLCBleHAsIGV0Yykgc2hvdWxk
IG9ubHkgd29yayBvbgp1bml0bGVzcyBxdWFudGl0aWVzLCBzbyB0aGV5IHNob3VsZCBmYWlsIG9u
IHRoZXNlIGNsYXNzZXMuCgpBbmR5CgpPbiAxMi8yOS8wNSwgQWRyaWFuIE1hcmlhbm8gPHJhZGlh
bkBjb3gubmV0PiB3cm90ZToKPiBXaGlsZSB0aGVyZSBpcyBubyBleHBsaWNpdCBzdXBwb3J0IGZv
ciBsaW5raW5nIGFnYWluc3QgYSBsaWJyYXJ5IGluCj4gdW5pdHMsIEkga25vdyBvZiBvbmUgZGV2
ZWxvcGVyIHdobywgd2l0aCB2ZXJ5IHNsaWdodCBtb2RpZmljYXRpb25zLCBpcwo+IGNvbXBpbGlu
ZyB0aGUgZXhpc3RpbmcgdW5pdHMgY29kZSBhcyBhIGxpYnJhcnkgYW5kIGxpbmtpbmcgYWdhaW5z
dAo+IHRoYXQuCj4KPiBPbiBUaHUsIERlYyAyOSwgMjAwNSBhdCAwNjo0ODoxM1BNIC0wODAwLCBD
YXJsIE9zdGVyd2lzY2ggd3JvdGU6Cj4gPiBJIGFncmVlIHRoYXQgdGhpcyBpcyBub3QgYW4gaWRl
YWwgc29sdXRpb24gYnV0IGl0IGlzIGEgc2ltcGxlIHN0ZXAgaW4KPiA+IHRoZSByaWdodCBkaXJl
Y3Rpb24uCj4gPgo+ID4gTXkgSFAgY2FsY3VsYXRvciB1c2VzIHRoZSB1bmRlcnNjb3JlIGNoYXJh
Y3RlciB0byBzZXBhcmF0ZSBhIHZhbHVlIGZyb20KPiA+IGl0cyB1bml0cyAoOS44MV9tL3NeMikg
YW5kIEkgc3VzcGVjdCB0aGF0IHNvbWV0aGluZyBzaW1pbGFyIGNvdWxkIGJlCj4gPiBhZGRlZCB0
byBPY3RhdmUgYnV0IG5vdCBlYXNpbHkuICBUaGUgdW5pdHMgcHJvZ3JhbSBoYXMgZXhjZWxsZW50
Cj4gPiBzdXBwb3J0IGZvciBwYXJzaW5nIHRoZSB1bml0cyBidXQgSSBkb24ndCB0aGluayB0aGVy
ZSBpcyBhIGxpYnJhcnkgdG8KPiA+IGxpbmsgYWdhaW5zdC4KPiA+Cj4gPiAtQ2FybAo+ID4KPiA+
IC0tLSBQYXVsIEtpZW56bGUgPHBraWVuemxlQHVzZXJzLnNmLm5ldD4gd3JvdGU6Cj4gPgo+ID4g
PiBJJ3ZlIGFkZGVkIHRoaXMgZXZlbiB0aG91Z2ggaXQgaXMgbm90IGlkZWFsLgo+ID4gPgo+ID4g
PiBBbiBpZGVhbCBzb2x1dGlvbiB3b3VsZCBhbGxvdyB5b3UgdG8gc2F5IGUuZy4sICI0IGtnICog
MiBtIC8gOCBzIiBhbmQKPiA+ID4KPiA+ID4gcmV0dXJuIGEgdmFsdWUgb2YgIjEga2cgbS9zIi4K
PiA+ID4KPiA+ID4gSSBkb3VidCBhbiBpZGVhbCBzb2x1dGlvbiBpcyBwb3NzaWJsZSwgc2luY2Ug
bWF0aCBsYXlvdXQgaXMgdHdvCj4gPiA+IGRpbWVuc2lvbmFsLCBkZXBlbmRlbnQgb24gZm9udCBh
bmQgb24gZmluZSBkZXRhaWxzIG9mIHNwYWNpbmcgYmV0d2Vlbgo+ID4gPgo+ID4gPiB0b2tlbnMu
ICBFdmVuIHRoZW4gaXQgaXMgc3RpbGwgYW1iaWd1b3VzLgo+ID4gPgo+ID4gPiBZb3UgY291bGQg
YWRkIGEgdW5pdHMgdHlwZSB3aGljaCBpcyBhIG51bWJlciwgbmFtZSBwYWlyLiAgQnkgd3JpdGlu
Zwo+ID4gPiAiNCprZyoyKm0vKDgqcykiIHdpdGgga2csbSxzIGFzIHByZWRlZmluZWQgdW5pdCB2
YXJpYWJsZXMgdGhlCj4gPiA+IGFtYmlndWl0eQo+ID4gPiBnb2VzIGF3YXkuICBVbmZvcnR1bmF0
ZWx5IHRoaXMgY29uc3VtZXMgYSBsYXJnZSBudW1iZXIgb2YgZGVzaXJhYmxlCj4gPiA+IHZhcmlh
YmxlIG5hbWVzIHN1Y2ggYXMgbSBhbmQgcy4gIEVhY2ggdW5pdCB3b3VsZCBuZWVkIG11bHRpcGxl
Cj4gPiA+IHZlcnNpb25zCj4gPiA+IHRvIGFsbG93IGZvciBldmVyeSBwb3NzaWJsZSBzdGFuZGFy
ZCBTSSBwcmVmaXguCj4gPiA+Cj4gPiA+IFlvdSBjb3VsZCBpbnN0ZWFkIHJld3JpdGUgb2N0YXZl
J3MgcmVhZGVyIHRvIHJlcXVpcmUgYSBjb21tYSBiZXR3ZWVuCj4gPiA+IG1hdHJpeCBlbGVtZW50
cywgYW5kIHRyZWF0IGEgbnVtYmVyIGZvbGxvd2VkIGJ5IHRleHQgYXMgc3BhY2UsIGJ1dAo+ID4g
PiB5b3UKPiA+ID4gaGF2ZSBhcHByb3guIHplcm8gY2hhbmNlIG9mIHRoYXQgcGF0Y2ggYmVpbmcg
YWNjZXB0ZWQuCj4gPiA+Cj4gPiA+IFlvdSBjb3VsZCB3cml0ZSB1bml0cyBhcyBhIHNlcGFyYXRl
IHR5cGUgd2l0aCBhIGNvbnN0cnVjdG9yIHRoYXQKPiA+ID4gcGFyc2VzCj4gPiA+IHN0cmluZyBl
eHByZXNzaW9ucyBhbmQgcmV0dXJucyB2YWx1ZS11bml0IHBhaXJzLgo+ID4gPgo+ID4gPiBBbnkg
b3RoZXIgc3VnZ2VzdGlvbnM/Cj4gPiA+Cj4gPiA+IC0gUGF1bAo+ID4gPgo+ID4gPiBPbiBEZWMg
MjksIDIwMDUsIGF0IDk6MzUgQU0sIENhcmwgT3N0ZXJ3aXNjaCB3cm90ZToKPiA+ID4KPiA+ID4g
PiBIZXJlJ3MgYSB2ZXJzaW9uIHdpdGggYSBtb3JlIGltcHJlc3NpdmUgZGVtbyBpbnZvbHZpbmcg
bWFzcy4gIExldAo+ID4gPiBtZQo+ID4gPiA+IGtub3cgaWYgdW5pdHMgdmVyc2lvbiAxLjAgZG9l
cyBub3QgaGF2ZSBsYiwgb3osIGFuZCBrZy4KPiA+ID4gPgo+ID4gPiA+IC1DYXJsCj4gPiA+ID4K
PiA+ID4gPiAtLS0gUGF1bCBLaWVuemxlIDxwa2llbnpsZUB1c2Vycy5zZi5uZXQ+IHdyb3RlOgo+
ID4gPiA+Cj4gPiA+ID4+IEZvciBzb21lIHJlYXNvbiB0aGUgTWFjT1MgMTAuMyB2ZXJzaW9uIG9m
IHVuaXRzIGlzIG1pc3NpbmcgdGhpbmdzCj4gPiA+ID4+IHN1Y2gKPiA+ID4gPj4gYXMKPiA+ID4g
Pj4gUGEgZm9yIHBhc2NhbHMgKGl0IHRoaW5rcyBpdCBpcyBQZXRhLWF0dG8pIGFuZCBKIGZvciBq
b3VsZXMsIHNvCj4gPiA+IHRoZQo+ID4gPiA+PiBkZW1vCj4gPiA+ID4+IGRvZXNuJ3Qgd29yayB2
ZXJ5IHdlbGwuICBJIGRvbid0IGtub3cgd2h5IHRoZXkgdXNlIGFuIGFuY2llbnQKPiA+ID4gPj4g
dmVyc2lvbi4KPiA+ID4gPj4KPiA+ID4gPj4gJCB1bml0cyAtdgo+ID4gPiA+Pgo+ID4gPiA+PiAg
ICB1bml0cyB2ZXJzaW9uIDEuMCAgQ29weXJpZ2h0IChjKSAxOTkzIGJ5IEFkcmlhbiBNYXJpYW5v
Cj4gPiA+ID4+Cj4gPiA+ID4+Cj4gPiA+ID4+IE9uIERlYyAyOCwgMjAwNSwgYXQgMTA6MDIgQU0s
IENhcmwgT3N0ZXJ3aXNjaCB3cm90ZToKPiA+ID4gPj4KPiA+ID4gPj4+IEhlbGxvLAo+ID4gPiA+
Pj4KPiA+ID4gPj4+IEhlcmUgaXMgbXkgc3VibWlzc2lvbiBmb3IgYW4gb2N0YXZlIGludGVyZmFj
ZSB0byB0aGUgR05VIHVuaXRzCj4gPiA+ID4+IHByb2dyYW0KPiA+ID4gPj4+IChodHRwOi8vd3d3
LmdudS5vcmcvc29mdHdhcmUvdW5pdHMpIHdoaWNoIGlzIGltbWVuc2VseSB1c2VmdWwgaW4KPiA+
ID4gPj4+IGVuZ2luZWVyaW5nIGNhbGN1bGF0aW9ucyB0byBjb252ZXJ0IGZyb20gb25lIG1lYXN1
cmVtZW50IHRvCj4gPiA+ID4+IGFub3RoZXIuCj4gPiA+ID4+PiBUaGUgYmVuZWZpdCBvZiB1c2lu
ZyB0aGlzIG9jdGF2ZSBmdW5jdGlvbiBvdmVyIGhhcmQgY29kZWQKPiA+ID4gY29uc3RhbnQKPiA+
ID4gPj4+IGNvbnZlcnNpb24gZmFjdG9ycyBpcyBjbGVhbmVyLCBtb3JlIG1haW50YWluYWJsZSBj
b2RlLgo+ID4gPiA+Pj4KPiA+ID4gPj4+IEkgaGF2ZSBpbmNsdWRlZCBkZW1vIGFuZCB0ZXN0IHBy
b2NlZHVyZXMgYXQgdGhlIGJvdHRvbS4gIFRoaXMKPiA+ID4gPj4gc2hvdWxkCj4gPiA+ID4+PiBm
aXQgbmljZWx5IGluIHRoZSAibWFwcGluZyIgc3ViZGlyZWN0b3J5IG9mIG9jdGF2ZS1mb3JnZSB3
aGljaAo+ID4gPiA+PiBhbHJlYWR5Cj4gPiA+ID4+PiBjb250YWlucyBmdW5jdGlvbnMgdG8gY29u
dmVydCBiZXR3ZWVuIGFuZ3VsYXIgbWVhc3VyZW1lbnRzLgo+ID4gPiA+Pj4KPiA+ID4gPj4+IFBs
ZWFzZSBsZXQgbWUga25vdyBpZiB5b3UgaGF2ZSBhbnkgY29tbWVudHMgb3IgcXVlc3Rpb25zLgo+
ID4gPiA+Pj4gLUNhcmwKPiA+ID4gPj4+Cj4gPiA+ID4+Pgo+ID4gPiA+Pj4KPiA+ID4gPj4+Cj4g
PiA+ID4+Pgo+ID4gPiA+Pj4KPiA+ID4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXwo+ID4gPiA+Pj4gWWFob28hIERTTCCWIFNvbWV0aGluZyB0byB3cml0ZSBo
b21lIGFib3V0Lgo+ID4gPiA+Pj4gSnVzdCAkMTYuOTkvbW8uIG9yIGxlc3MuCj4gPiA+ID4+PiBk
c2wueWFob28uY29tCj4gPiA+ID4+PiA8dW5pdHMubT4KPiA+ID4gPj4KPiA+ID4gPgo+ID4gPiA+
Cj4gPiA+ID4KPiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18KPiA+ID4gPiBZYWhvbyEgRFNMIJYgU29tZXRoaW5nIHRvIHdyaXRlIGhvbWUgYWJvdXQuCj4g
PiA+ID4gSnVzdCAkMTYuOTkvbW8uIG9yIGxlc3MuCj4gPiA+ID4gZHNsLnlhaG9vLmNvbQo+ID4g
PiA+IDx1bml0cy5tPgo+ID4gPgo+ID4KPiA+Cj4gPgo+ID4gX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fCj4gPiBZYWhvbyEgRFNMIJYgU29tZXRoaW5nIHRvIHdyaXRl
IGhvbWUgYWJvdXQuCj4gPiBKdXN0ICQxNi45OS9tby4gb3IgbGVzcy4KPiA+IGRzbC55YWhvby5j
b20KPgo+Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLQo+IFRoaXMgU0YubmV0IGVtYWlsIGlzIHNwb25zb3JlZCBieTogU3BsdW5rIEluYy4g
RG8geW91IGdyZXAgdGhyb3VnaCBsb2cgZmlsZXMKPiBmb3IgcHJvYmxlbXM/ICBTdG9wISAgRG93
bmxvYWQgdGhlIG5ldyBBSkFYIHNlYXJjaCBlbmdpbmUgdGhhdCBtYWtlcwo+IHNlYXJjaGluZyB5
b3VyIGxvZyBmaWxlcyBhcyBlYXN5IGFzIHN1cmZpbmcgdGhlICB3ZWIuICBET1dOTE9BRCBTUExV
TkshCj4gaHR0cDovL2Fkcy5vc2RuLmNvbS8/YWRfaWQ9NzYzNyZhbGxvY19pZD0xNjg2NSZvcD1j
bGljawo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4g
T2N0YXZlLWRldiBtYWlsaW5nIGxpc3QKPiBPY3RhdmUtZGV2QGxpc3RzLnNvdXJjZWZvcmdlLm5l
dAo+IGh0dHBzOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL29jdGF2ZS1k
ZXYKPgo=

Re: [OctDev] Octave interface to GNU units

[Adrian M. <ra...@co...>]

While there is no explicit support for linking against a library in
units, I know of one developer who, with very slight modifications, is
compiling the existing units code as a library and linking against
that.

On Thu, Dec 29, 2005 at 06:48:13PM -0800, Carl Osterwisch wrote:
> I agree that this is not an ideal solution but it is a simple step in
> the right direction.
> 
> My HP calculator uses the underscore character to separate a value from
> its units (9.81_m/s^2) and I suspect that something similar could be
> added to Octave but not easily.  The units program has excellent
> support for parsing the units but I don't think there is a library to
> link against.
> 
> -Carl
> 
> --- Paul Kienzle <pki...@us...> wrote:
> 
> > I've added this even though it is not ideal.
> > 
> > An ideal solution would allow you to say e.g., "4 kg * 2 m / 8 s" and
> > 
> > return a value of "1 kg m/s".
> > 
> > I doubt an ideal solution is possible, since math layout is two 
> > dimensional, dependent on font and on fine details of spacing between
> > 
> > tokens.  Even then it is still ambiguous.
> > 
> > You could add a units type which is a number, name pair.  By writing 
> > "4*kg*2*m/(8*s)" with kg,m,s as predefined unit variables the
> > ambiguity 
> > goes away.  Unfortunately this consumes a large number of desirable 
> > variable names such as m and s.  Each unit would need multiple
> > versions 
> > to allow for every possible standard SI prefix.
> > 
> > You could instead rewrite octave's reader to require a comma between 
> > matrix elements, and treat a number followed by text as space, but
> > you 
> > have approx. zero chance of that patch being accepted.
> > 
> > You could write units as a separate type with a constructor that
> > parses 
> > string expressions and returns value-unit pairs.
> > 
> > Any other suggestions?
> > 
> > - Paul
> > 
> > On Dec 29, 2005, at 9:35 AM, Carl Osterwisch wrote:
> > 
> > > Here's a version with a more impressive demo involving mass.  Let
> > me
> > > know if units version 1.0 does not have lb, oz, and kg.
> > >
> > > -Carl
> > >
> > > --- Paul Kienzle <pki...@us...> wrote:
> > >
> > >> For some reason the MacOS 10.3 version of units is missing things
> > >> such
> > >> as
> > >> Pa for pascals (it thinks it is Peta-atto) and J for joules, so
> > the
> > >> demo
> > >> doesn't work very well.  I don't know why they use an ancient
> > >> version.
> > >>
> > >> $ units -v
> > >>
> > >>    units version 1.0  Copyright (c) 1993 by Adrian Mariano
> > >>
> > >>
> > >> On Dec 28, 2005, at 10:02 AM, Carl Osterwisch wrote:
> > >>
> > >>> Hello,
> > >>>
> > >>> Here is my submission for an octave interface to the GNU units
> > >> program
> > >>> (http://www.gnu.org/software/units) which is immensely useful in
> > >>> engineering calculations to convert from one measurement to
> > >> another.
> > >>> The benefit of using this octave function over hard coded
> > constant
> > >>> conversion factors is cleaner, more maintainable code.
> > >>>
> > >>> I have included demo and test procedures at the bottom.  This
> > >> should
> > >>> fit nicely in the "mapping" subdirectory of octave-forge which
> > >> already
> > >>> contains functions to convert between angular measurements.
> > >>>
> > >>> Please let me know if you have any comments or questions.
> > >>> -Carl
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> 		
> > >>> __________________________________________
> > >>> Yahoo! DSL – Something to write home about.
> > >>> Just $16.99/mo. or less.
> > >>> dsl.yahoo.com
> > >>> <units.m>
> > >>
> > >
> > >
> > > 		
> > > __________________________________________
> > > Yahoo! DSL – Something to write home about.
> > > Just $16.99/mo. or less.
> > > dsl.yahoo.com
> > > <units.m>
> > 
> 
> 
> 		
> __________________________________________ 
> Yahoo! DSL – Something to write home about. 
> Just $16.99/mo. or less. 
> dsl.yahoo.com 

Re: [OctDev] Octave interface to GNU units

[Carl O. <cos...@ya...>]

I agree that this is not an ideal solution but it is a simple step in
the right direction.

My HP calculator uses the underscore character to separate a value from
its units (9.81_m/s^2) and I suspect that something similar could be
added to Octave but not easily.  The units program has excellent
support for parsing the units but I don't think there is a library to
link against.

-Carl

--- Paul Kienzle <pki...@us...> wrote:

> I've added this even though it is not ideal.
> 
> An ideal solution would allow you to say e.g., "4 kg * 2 m / 8 s" and
> 
> return a value of "1 kg m/s".
> 
> I doubt an ideal solution is possible, since math layout is two 
> dimensional, dependent on font and on fine details of spacing between
> 
> tokens.  Even then it is still ambiguous.
> 
> You could add a units type which is a number, name pair.  By writing 
> "4*kg*2*m/(8*s)" with kg,m,s as predefined unit variables the
> ambiguity 
> goes away.  Unfortunately this consumes a large number of desirable 
> variable names such as m and s.  Each unit would need multiple
> versions 
> to allow for every possible standard SI prefix.
> 
> You could instead rewrite octave's reader to require a comma between 
> matrix elements, and treat a number followed by text as space, but
> you 
> have approx. zero chance of that patch being accepted.
> 
> You could write units as a separate type with a constructor that
> parses 
> string expressions and returns value-unit pairs.
> 
> Any other suggestions?
> 
> - Paul
> 
> On Dec 29, 2005, at 9:35 AM, Carl Osterwisch wrote:
> 
> > Here's a version with a more impressive demo involving mass.  Let
> me
> > know if units version 1.0 does not have lb, oz, and kg.
> >
> > -Carl
> >
> > --- Paul Kienzle <pki...@us...> wrote:
> >
> >> For some reason the MacOS 10.3 version of units is missing things
> >> such
> >> as
> >> Pa for pascals (it thinks it is Peta-atto) and J for joules, so
> the
> >> demo
> >> doesn't work very well.  I don't know why they use an ancient
> >> version.
> >>
> >> $ units -v
> >>
> >>    units version 1.0  Copyright (c) 1993 by Adrian Mariano
> >>
> >>
> >> On Dec 28, 2005, at 10:02 AM, Carl Osterwisch wrote:
> >>
> >>> Hello,
> >>>
> >>> Here is my submission for an octave interface to the GNU units
> >> program
> >>> (http://www.gnu.org/software/units) which is immensely useful in
> >>> engineering calculations to convert from one measurement to
> >> another.
> >>> The benefit of using this octave function over hard coded
> constant
> >>> conversion factors is cleaner, more maintainable code.
> >>>
> >>> I have included demo and test procedures at the bottom.  This
> >> should
> >>> fit nicely in the "mapping" subdirectory of octave-forge which
> >> already
> >>> contains functions to convert between angular measurements.
> >>>
> >>> Please let me know if you have any comments or questions.
> >>> -Carl
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> 		
> >>> __________________________________________
> >>> Yahoo! DSL – Something to write home about.
> >>> Just $16.99/mo. or less.
> >>> dsl.yahoo.com
> >>> <units.m>
> >>
> >
> >
> > 		
> > __________________________________________
> > Yahoo! DSL – Something to write home about.
> > Just $16.99/mo. or less.
> > dsl.yahoo.com
> > <units.m>
> 


		
__________________________________________ 
Yahoo! DSL – Something to write home about. 
Just $16.99/mo. or less. 
dsl.yahoo.com 

Re: [OctDev] Octave interface to GNU units

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

I've added this even though it is not ideal.

An ideal solution would allow you to say e.g., "4 kg * 2 m / 8 s" and=20
return a value of "1 kg m/s".

I doubt an ideal solution is possible, since math layout is two=20
dimensional, dependent on font and on fine details of spacing between=20
tokens.  Even then it is still ambiguous.

You could add a units type which is a number, name pair.  By writing=20
"4*kg*2*m/(8*s)" with kg,m,s as predefined unit variables the ambiguity=20=

goes away.  Unfortunately this consumes a large number of desirable=20
variable names such as m and s.  Each unit would need multiple versions=20=

to allow for every possible standard SI prefix.

You could instead rewrite octave's reader to require a comma between=20
matrix elements, and treat a number followed by text as space, but you=20=

have approx. zero chance of that patch being accepted.

You could write units as a separate type with a constructor that parses=20=

string expressions and returns value-unit pairs.

Any other suggestions?

- Paul

On Dec 29, 2005, at 9:35 AM, Carl Osterwisch wrote:

> Here's a version with a more impressive demo involving mass.  Let me
> know if units version 1.0 does not have lb, oz, and kg.
>
> -Carl
>
> --- Paul Kienzle <pki...@us...> wrote:
>
>> For some reason the MacOS 10.3 version of units is missing things
>> such
>> as
>> Pa for pascals (it thinks it is Peta-atto) and J for joules, so the
>> demo
>> doesn't work very well.  I don't know why they use an ancient
>> version.
>>
>> $ units -v
>>
>>    units version 1.0  Copyright (c) 1993 by Adrian Mariano
>>
>>
>> On Dec 28, 2005, at 10:02 AM, Carl Osterwisch wrote:
>>
>>> Hello,
>>>
>>> Here is my submission for an octave interface to the GNU units
>> program
>>> (http://www.gnu.org/software/units) which is immensely useful in
>>> engineering calculations to convert from one measurement to
>> another.
>>> The benefit of using this octave function over hard coded constant
>>> conversion factors is cleaner, more maintainable code.
>>>
>>> I have included demo and test procedures at the bottom.  This
>> should
>>> fit nicely in the "mapping" subdirectory of octave-forge which
>> already
>>> contains functions to convert between angular measurements.
>>>
>>> Please let me know if you have any comments or questions.
>>> -Carl
>>>
>>>
>>>
>>>
>>>
>>> 	=09
>>> __________________________________________
>>> Yahoo! DSL =96 Something to write home about.
>>> Just $16.99/mo. or less.
>>> dsl.yahoo.com
>>> <units.m>
>>
>
>
> 	=09
> __________________________________________
> Yahoo! DSL =96 Something to write home about.
> Just $16.99/mo. or less.
> dsl.yahoo.com
> <units.m>=

Re: [OctDev] Octave interface to GNU units

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

That worked.

- Paul

On Dec 29, 2005, at 9:35 AM, Carl Osterwisch wrote:

> Here's a version with a more impressive demo involving mass.  Let me
> know if units version 1.0 does not have lb, oz, and kg.
>
> -Carl
>
> --- Paul Kienzle <pki...@us...> wrote:
>
>> For some reason the MacOS 10.3 version of units is missing things
>> such
>> as
>> Pa for pascals (it thinks it is Peta-atto) and J for joules, so the
>> demo
>> doesn't work very well.  I don't know why they use an ancient
>> version.
>>
>> $ units -v
>>
>>    units version 1.0  Copyright (c) 1993 by Adrian Mariano
>>
>>
>> On Dec 28, 2005, at 10:02 AM, Carl Osterwisch wrote:
>>
>>> Hello,
>>>
>>> Here is my submission for an octave interface to the GNU units
>> program
>>> (http://www.gnu.org/software/units) which is immensely useful in
>>> engineering calculations to convert from one measurement to
>> another.
>>> The benefit of using this octave function over hard coded constant
>>> conversion factors is cleaner, more maintainable code.
>>>
>>> I have included demo and test procedures at the bottom.  This
>> should
>>> fit nicely in the "mapping" subdirectory of octave-forge which
>> already
>>> contains functions to convert between angular measurements.
>>>
>>> Please let me know if you have any comments or questions.
>>> -Carl
>>>
>>>
>>>
>>>
>>>
>>> 	=09
>>> __________________________________________
>>> Yahoo! DSL =96 Something to write home about.
>>> Just $16.99/mo. or less.
>>> dsl.yahoo.com
>>> <units.m>
>>
>
>
> 	=09
> __________________________________________
> Yahoo! DSL =96 Something to write home about.
> Just $16.99/mo. or less.
> dsl.yahoo.com
> <units.m>=

Re: [OctDev] Octave interface to GNU units

[Carl O. <cos...@ya...>]

Here's a version with a more impressive demo involving mass.  Let me
know if units version 1.0 does not have lb, oz, and kg.

-Carl

--- Paul Kienzle <pki...@us...> wrote:

> For some reason the MacOS 10.3 version of units is missing things
> such 
> as
> Pa for pascals (it thinks it is Peta-atto) and J for joules, so the
> demo
> doesn't work very well.  I don't know why they use an ancient
> version.
> 
> $ units -v
> 
>    units version 1.0  Copyright (c) 1993 by Adrian Mariano
> 
> 
> On Dec 28, 2005, at 10:02 AM, Carl Osterwisch wrote:
> 
> > Hello,
> >
> > Here is my submission for an octave interface to the GNU units
> program
> > (http://www.gnu.org/software/units) which is immensely useful in
> > engineering calculations to convert from one measurement to
> another.
> > The benefit of using this octave function over hard coded constant
> > conversion factors is cleaner, more maintainable code.
> >
> > I have included demo and test procedures at the bottom.  This
> should
> > fit nicely in the "mapping" subdirectory of octave-forge which
> already
> > contains functions to convert between angular measurements.
> >
> > Please let me know if you have any comments or questions.
> > -Carl
> >
> >
> >
> >
> >
> > 		
> > __________________________________________
> > Yahoo! DSL – Something to write home about.
> > Just $16.99/mo. or less.
> > dsl.yahoo.com
> > <units.m>
> 


		
__________________________________________ 
Yahoo! DSL – Something to write home about. 
Just $16.99/mo. or less. 
dsl.yahoo.com 

[OctDev] Re: new release

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

Paul Kienzle wrote:

>
> As I understand it, we currently don't build and install properly on 
> either 2.1.72 or 2.9.5.  I think the fastest route is bring us up to a 
> 2.1.72 release then decruft and support only 2.9.x.  If ever there is 
> a 2.1.73 release that requires changes to octave-forge for 2.1.72, we 
> can branch from R20060101 revision to support it.  Since 2.1.x is in 
> critical fix only mode, I don't see that happening.
>
> I think decrufting and supporting older versions of octave at the same 
> time is not practical, so I'm arguing for a clean break.
>
> - Paul
>
Paul,

Fine with me. However, I believe the decrufting should go hand in hand 
with repackaging everything with Soren's package manager for 2.9.x. That 
being the case, we are waiting for it to be included in octave to 
proceed with the decrufting. John, what is that status of Soren's 
package manager being included in octave? Is there any critical issue 
with it that you'd like addressed first?

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

[OctDev] Re: new release

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

On Dec 28, 2005, at 9:12 AM, David Bateman wrote:

> Paul Kienzle wrote:
>
>>
>> On Dec 28, 2005, at 8:14 AM, David Bateman wrote:
>>
>>> Paul Kienzle wrote:
>>>
>>>> This sounds familiar and may already be fixed in CVS, so hopefully 
>>>> it  is just a matter of releasing a new version.
>>>>
>>>> I think the hordes of octave-forge developers can manage this 
>>>> before  the new year.
>>>>
>>>> The steps are as usual:
>>>>
>>>> (1) post all outstanding changes to your packages
>>>> (2) address outstanding bugs on the bug tracker
>>>> (3) address outstanding bugs on the list, or add them to the bug 
>>>> tracker
>>>> (4) purge functions which have made it into 2.1.72
>>>> (5) test build on windows, os x, linux
>>>>
>>>> Please help out where you can.
>>>>
>>>> Also for all the octave-forge functions you are using, add some 
>>>> test  cases at the end if there are none there already so that we 
>>>> can release  with more confidence.
>>>>
>>>> - Paul
>>>
>>>
>>> Paul,
>>>
>>> Can we delay a little bit. My reasoning is that I'd like the new 
>>> autoload function in 2.9.x to be used by octave-forge if available 
>>> to allow me to significantly reduce the size of my MinGW build by 
>>> removing all of the symbolic links in octave-forge. The easiest way 
>>> to do this would be to have "make install" diff all of the binary 
>>> files in the directory being installed and see if they are the same 
>>> and if so don't install it but add an autoload command to the 
>>> PKG_ADD file.  You can't just check if it is a symbolic link, as 
>>> they aren't under MinGW (which is the problem).
>>>
>>> I'll try and write a script for this rapidly so that it doesn't hold 
>>> up the release too much. As for purging functions, it is a little 
>>> bit more complex than that, as most of the functions merged into 
>>> octave from octave-forge went into 2.9.x release only, and so rather 
>>> than purging these functions, they will need a conditional 
>>> installation. I can attack some of these as well if someone doesn't 
>>> get there first...
>>
>>
>> Do you need a 2.1.72 MinGW release?  After a branch we can do a 
>> further purge for the 2.9.x release, and add the appropriate autoload 
>> statements for symlinked functions.
>>
>> While automatically checking for shadowed functions on install would 
>> be a good thing, I want to minimize effort because I don't have a 
>> whole lot of time to put into this.  Also, we should be moving to 
>> Soren's packaging system, and this feature should be added to the 
>> packaging system rather than the octave-forge installer.
>>
>> - Paul
>>
> If the goal is a specific 2.1.72 release this this is an appropriate 
> action. However, if you want the release to also be viable for the 
> latest 2.9.x releases then you need the conditional 
> building/installing of functions like regexp there are imported into 
> 2.9.x and not 2.1.72... It seems to me that is a bigger task than 
> writing the script in sh to check for similar binary files..
>
> Its your call Paul, do you want a 2.1.72 specific release or a 
> 2.1.72/2.9.5 release?

As I understand it, we currently don't build and install properly on 
either 2.1.72 or 2.9.5.  I think the fastest route is bring us up to a 
2.1.72 release then decruft and support only 2.9.x.  If ever there is a 
2.1.73 release that requires changes to octave-forge for 2.1.72, we can 
branch from R20060101 revision to support it.  Since 2.1.x is in 
critical fix only mode, I don't see that happening.

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

- Paul

Re: [OctDev] Octave interface to GNU units

[Adrian M. <ra...@co...>]

The only reason I can imagine why they would use version 1.0 is that
later versions are under the GNU license, which is more restrictive
than the license on version 1.0.  (Technically speaking, I suppose
this means units 1.0 is not actually GNU units.)  

Adrian Mariano
Author of GNU units


On Wed, Dec 28, 2005 at 09:51:05PM -0500, Paul Kienzle wrote:
> For some reason the MacOS 10.3 version of units is missing things such 
> as
> Pa for pascals (it thinks it is Peta-atto) and J for joules, so the demo
> doesn't work very well.  I don't know why they use an ancient version.
> 
> $ units -v
> 
>   units version 1.0  Copyright (c) 1993 by Adrian Mariano
> 
> 
> On Dec 28, 2005, at 10:02 AM, Carl Osterwisch wrote:
> 
> >Hello,
> >
> >Here is my submission for an octave interface to the GNU units program
> >(http://www.gnu.org/software/units) which is immensely useful in
> >engineering calculations to convert from one measurement to another.
> >The benefit of using this octave function over hard coded constant
> >conversion factors is cleaner, more maintainable code.
> >
> >I have included demo and test procedures at the bottom.  This should
> >fit nicely in the "mapping" subdirectory of octave-forge which already
> >contains functions to convert between angular measurements.
> >
> >Please let me know if you have any comments or questions.
> >-Carl
> >
> >
> >
> >
> >
> >		
> >__________________________________________
> >Yahoo! DSL ? Something to write home about.
> >Just $16.99/mo. or less.
> >dsl.yahoo.com
> >
> ><units.m>

Re: [OctDev] Octave interface to GNU units

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

For some reason the MacOS 10.3 version of units is missing things such=20=

as
Pa for pascals (it thinks it is Peta-atto) and J for joules, so the demo
doesn't work very well.  I don't know why they use an ancient version.

$ units -v

   units version 1.0  Copyright (c) 1993 by Adrian Mariano


On Dec 28, 2005, at 10:02 AM, Carl Osterwisch wrote:

> Hello,
>
> Here is my submission for an octave interface to the GNU units program
> (http://www.gnu.org/software/units) which is immensely useful in
> engineering calculations to convert from one measurement to another.
> The benefit of using this octave function over hard coded constant
> conversion factors is cleaner, more maintainable code.
>
> I have included demo and test procedures at the bottom.  This should
> fit nicely in the "mapping" subdirectory of octave-forge which already
> contains functions to convert between angular measurements.
>
> Please let me know if you have any comments or questions.
> -Carl
>
>
>
>
>
> 	=09
> __________________________________________
> Yahoo! DSL =96 Something to write home about.
> Just $16.99/mo. or less.
> dsl.yahoo.com
> <units.m>=

[OctDev] Re: SIFT image descriptor patch

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

  Hi Stefan,

On Wed, Dec 28, 2005 at 04:51:33PM +0200, Stefan van der Walt wrote:
# Thanks, Etienne.  It's good to be able to run those demos under Octave.
# 
# David Lowe's research might have been more popular with me if he
# hadn't submitted a patent on the work:
[snip]
# 
# His algorithm is very relevant to the research that I am doing, but I
# am not going to invest time in emplementing an algorithm that cannot
# be released under a free license.
# 
[snip]

  And you don't have to, since he provides linux/win binaries and a
Matlab wrapper; which you can use too under Octave, w/ the patch I
sent.

  Hth,

  Etienne

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

Re: [OctDev] Re: [Pkg-octave-devel] Bug#344995: octave-forge: FTBFS (ia64, mips, .../unstable): fixed.h: No such file or directory

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

Stefan van der Walt wrote:

>On Wed, Dec 28, 2005 at 02:14:11PM +0100, David Bateman wrote:
>  
>
>>Can we delay a little bit. My reasoning is that I'd like the new 
>>autoload function in 2.9.x to be used by octave-forge if available to 
>>allow me to significantly reduce the size of my MinGW build by removing 
>>all of the symbolic links in octave-forge. The easiest way to do
>>    
>>
>
>What exactly does the new autoload function do?
>
>Stefan
>  
>

If you look in the PKG_ADD file installed with 2.9.4 you'll see commands 
like

autoload ("airy", strcat (__octfiledir__, filesep, "besselj.oct"));

This allows octave to find the "airy" function that is in the 
besselj.oct file, without needing to have airy.oct as a symbolic link to 
besselj.oct. The desperate need for this under MinGW is that as MinGW 
doesn't have symbolic links a copy was made instead. As the oct-files 
are also significantly larger under MinGW this means that a distribution 
of octave and octave-forge might have over 400MB of oct-files that are 
just copies of each other. Removing these extraneous copies is essential 
to allow a real MinGW release (or at least one that doesn't take massive 
amounts of disk space)... This has been done for octave in 2.9.4, but 
not for octave-forge.

Note there is a bug in autoload in 2.9.4 and the CVS in that "airy" etc 
are no longer listed in summary of the functions when you type "help" 
and is not available as a line completion (hit TAB). I believe John has 
thought about the means of fixing these bug in a future 2.9.5 release 
though hasn't included them yet.

Cheers
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] Re: [Pkg-octave-devel] Bug#344995: octave-forge: FTBFS (ia64, mips, .../unstable): fixed.h: No such file or directory

[Stefan v. d. W. <st...@su...>]

On Wed, Dec 28, 2005 at 02:14:11PM +0100, David Bateman wrote:
> Can we delay a little bit. My reasoning is that I'd like the new 
> autoload function in 2.9.x to be used by octave-forge if available to 
> allow me to significantly reduce the size of my MinGW build by removing 
> all of the symbolic links in octave-forge. The easiest way to do

What exactly does the new autoload function do?

Stefan

[OctDev] Octave interface to GNU units

[Carl O. <cos...@ya...>]

Hello,

Here is my submission for an octave interface to the GNU units program
(http://www.gnu.org/software/units) which is immensely useful in
engineering calculations to convert from one measurement to another. 
The benefit of using this octave function over hard coded constant
conversion factors is cleaner, more maintainable code.

I have included demo and test procedures at the bottom.  This should
fit nicely in the "mapping" subdirectory of octave-forge which already
contains functions to convert between angular measurements.

Please let me know if you have any comments or questions.
-Carl





		
__________________________________________ 
Yahoo! DSL – Something to write home about. 
Just $16.99/mo. or less. 
dsl.yahoo.com 

Re: [OctDev] Re: [Pkg-octave-devel] Bug#344995: octave-forge: FTBFS (ia64, mips, .../unstable): fixed.h: No such file or directory

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

Paul Kienzle wrote:

>
> On Dec 28, 2005, at 8:14 AM, David Bateman wrote:
>
>> Paul Kienzle wrote:
>>
>>> This sounds familiar and may already be fixed in CVS, so hopefully 
>>> it  is just a matter of releasing a new version.
>>>
>>> I think the hordes of octave-forge developers can manage this 
>>> before  the new year.
>>>
>>> The steps are as usual:
>>>
>>> (1) post all outstanding changes to your packages
>>> (2) address outstanding bugs on the bug tracker
>>> (3) address outstanding bugs on the list, or add them to the bug 
>>> tracker
>>> (4) purge functions which have made it into 2.1.72
>>> (5) test build on windows, os x, linux
>>>
>>> Please help out where you can.
>>>
>>> Also for all the octave-forge functions you are using, add some 
>>> test  cases at the end if there are none there already so that we 
>>> can release  with more confidence.
>>>
>>> - Paul
>>
>>
>> Paul,
>>
>> Can we delay a little bit. My reasoning is that I'd like the new 
>> autoload function in 2.9.x to be used by octave-forge if available to 
>> allow me to significantly reduce the size of my MinGW build by 
>> removing all of the symbolic links in octave-forge. The easiest way 
>> to do this would be to have "make install" diff all of the binary 
>> files in the directory being installed and see if they are the same 
>> and if so don't install it but add an autoload command to the PKG_ADD 
>> file.  You can't just check if it is a symbolic link, as they aren't 
>> under MinGW (which is the problem).
>>
>> I'll try and write a script for this rapidly so that it doesn't hold 
>> up the release too much. As for purging functions, it is a little bit 
>> more complex than that, as most of the functions merged into octave 
>> from octave-forge went into 2.9.x release only, and so rather than 
>> purging these functions, they will need a conditional installation. I 
>> can attack some of these as well if someone doesn't get there first...
>
>
> Do you need a 2.1.72 MinGW release?  After a branch we can do a 
> further purge for the 2.9.x release, and add the appropriate autoload 
> statements for symlinked functions.
>
> While automatically checking for shadowed functions on install would 
> be a good thing, I want to minimize effort because I don't have a 
> whole lot of time to put into this.  Also, we should be moving to 
> Soren's packaging system, and this feature should be added to the 
> packaging system rather than the octave-forge installer.
>
> - Paul
>
If the goal is a specific 2.1.72 release this this is an appropriate 
action. However, if you want the release to also be viable for the 
latest 2.9.x releases then you need the conditional building/installing 
of functions like regexp there are imported into 2.9.x and not 2.1.72... 
It seems to me that is a bigger task than writing the script in sh to 
check for similar binary files..

Its your call Paul, do you want a 2.1.72 specific release or a 
2.1.72/2.9.5 release?

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] Re: [Pkg-octave-devel] Bug#344995: octave-forge: FTBFS (ia64, mips, .../unstable): fixed.h: No such file or directory

[H. <so...@ha...>]

ons, 28 12 2005 kl. 08:34 -0500, skrev Paul Kienzle:
> While automatically checking for shadowed functions on install would be=
=20
> a good thing, I want to minimize effort because I don't have a whole=20
> lot of time to put into this.  Also, we should be moving to Soren's=20
> packaging system, and this feature should be added to the packaging=20
> system rather than the octave-forge installer.
I guess I should mention that I'm going to be pretty busy until
february. Everbody should really feel free to alter the package system
as I don't have the time until february.

> - Paul
/S=C3=B8ren

Re: [OctDev] Re: [Pkg-octave-devel] Bug#344995: octave-forge: FTBFS (ia64, mips, .../unstable): fixed.h: No such file or directory

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

On Dec 28, 2005, at 8:14 AM, David Bateman wrote:

> Paul Kienzle wrote:
>
>> This sounds familiar and may already be fixed in CVS, so hopefully it 
>>  is just a matter of releasing a new version.
>>
>> I think the hordes of octave-forge developers can manage this before  
>> the new year.
>>
>> The steps are as usual:
>>
>> (1) post all outstanding changes to your packages
>> (2) address outstanding bugs on the bug tracker
>> (3) address outstanding bugs on the list, or add them to the bug 
>> tracker
>> (4) purge functions which have made it into 2.1.72
>> (5) test build on windows, os x, linux
>>
>> Please help out where you can.
>>
>> Also for all the octave-forge functions you are using, add some test  
>> cases at the end if there are none there already so that we can 
>> release  with more confidence.
>>
>> - Paul
>
> Paul,
>
> Can we delay a little bit. My reasoning is that I'd like the new 
> autoload function in 2.9.x to be used by octave-forge if available to 
> allow me to significantly reduce the size of my MinGW build by 
> removing all of the symbolic links in octave-forge. The easiest way to 
> do this would be to have "make install" diff all of the binary files 
> in the directory being installed and see if they are the same and if 
> so don't install it but add an autoload command to the PKG_ADD file.  
> You can't just check if it is a symbolic link, as they aren't under 
> MinGW (which is the problem).
>
> I'll try and write a script for this rapidly so that it doesn't hold 
> up the release too much. As for purging functions, it is a little bit 
> more complex than that, as most of the functions merged into octave 
> from octave-forge went into 2.9.x release only, and so rather than 
> purging these functions, they will need a conditional installation. I 
> can attack some of these as well if someone doesn't get there first...

Do you need a 2.1.72 MinGW release?  After a branch we can do a further 
purge for the 2.9.x release, and add the appropriate autoload 
statements for symlinked functions.

While automatically checking for shadowed functions on install would be 
a good thing, I want to minimize effort because I don't have a whole 
lot of time to put into this.  Also, we should be moving to Soren's 
packaging system, and this feature should be added to the packaging 
system rather than the octave-forge installer.

- Paul