[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
lost bug tracker updates
From: |
John W. Eaton |
Subject: |
lost bug tracker updates |
Date: |
Wed, 8 Dec 2010 02:16:06 -0500 |
The following updates that were sent from the bug tracker appear to be
missing from the web. In some cases, the bug report numbers are
wrong, so I guess those bug reports were completely lost. In other
cases, there are just some updates to a report that are missing. I
already stripped out some messages, for example updates for reports
that have been closed or for which later updates were posted that made
the old ones irrelevant.
Would someone like to look at these remaining messages and post new
reports or updates based on them?
Or should we just send these messages back to the submitter and ask
them to resubmit?
Thanks,
jwe
This is an RFC 1153 digest.
(22 messages)
----------------------------------------------------------------------
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
From: Marco Caliari <address@hidden>
Reply-To: address@hidden
To: Marco Caliari <address@hidden>, address@hidden
Cc:
Subject: [Octave-bug-tracker] [bug #31740] Empty assignement to empty index
Date: Tue, 23 Nov 2010 15:12:37 +0000
Please use the bug tracker to post updates to a bug report. The mailing list
is intended as a read-only notification stream. Info posted to this mailing
list address won't appear in the tracker database where it is most useful.
URL:
<http://savannah.gnu.org/bugs/?31740>
Summary: Empty assignement to empty index
Project: GNU Octave
Submitted by: caliari
Submitted on: Tue 23 Nov 2010 03:12:36 PM GMT
Category: None
Severity: 3 - Normal
Priority: 5 - Normal
Item Group: Incorrect Result
Status: None
Assigned to: None
Originator Name:
Originator Email:
Open/Closed: Open
Discussion Lock: Any
Release: 3.3.53
Operating System: GNU/Linux
_______________________________________________________
Details:
Dear all,
the last line of the following code
x = 0;
ind = 1;
x(ind) = ones (1, 1);
ind = [];
x(ind) = [] % this works
x = 0;
ind = 1;
x(ind,1) = ones (1, 1);
ind = [];
x(ind,1) = []; % this does not works
give me "A null assignment can only have one non-colon index", but it should
be equivalent to the 5th line (and works in ml).
Best regards,
Marco
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?31740>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
------------------------------
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
From: anonymous <address@hidden>
Reply-To: address@hidden
To: address@hidden
Subject: [Octave-bug-tracker] [bug #31745] dlmread syntax change or
nonfunctional
Date: Tue, 23 Nov 2010 17:15:11 +0000
Please use the bug tracker to post updates to a bug report. The mailing list
is intended as a read-only notification stream. Info posted to this mailing
list address won't appear in the tracker database where it is most useful.
URL:
<http://savannah.gnu.org/bugs/?31745>
Summary: dlmread syntax change or nonfunctional
Project: GNU Octave
Submitted by: None
Submitted on: Tue 23 Nov 2010 05:15:10 PM UTC
Category: Interpreter
Severity: 3 - Normal
Priority: 5 - Normal
Item Group: Incorrect Result
Status: None
Assigned to: None
Originator Name: KeithG
Originator Email:
Open/Closed: Open
Discussion Lock: Any
Release: dev
Operating System: GNU/Linux
_______________________________________________________
Details:
dlmread does not work as per the help. Works correctly in 3.2.4, does not in
3.3.54. In 3.3.54, it seems to assume that it is complex numbers where it is
actually a column of data
Data looks like this:
1000.000
-0.016 0.000
-0.028 0.000
-0.022 0.000
-0.016 0.000
-0.016 0.000
-0.003 0.000
-0.016 0.000
-0.016 0.000
...
>data=dlmread("data1.txt",0,2,0);
>data
data =
-0.02800 + 0.00000i
-0.02200 + 0.00000i
-0.01600 + 0.00000i
-0.01600 + 0.00000i
...
In 3.2.4 the same command looks like this:
>data
data =
-0.02800 0.00000
-0.02200 0.00000
-0.01600 0.00000
-0.01600 0.00000
-0.00300 0.00000
-0.01600 0.00000
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?31745>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
------------------------------
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
From: Olaf Till <address@hidden>
Reply-To: address@hidden
To: Olaf Till <address@hidden>, address@hidden
Cc:
Subject: [Octave-bug-tracker] [bug #31747] sqp: incorrect order of removal
of Inf bounds
Date: Tue, 23 Nov 2010 21:25:18 +0000
Please use the bug tracker to post updates to a bug report. The mailing list
is intended as a read-only notification stream. Info posted to this mailing
list address won't appear in the tracker database where it is most useful.
URL:
<http://savannah.gnu.org/bugs/?31747>
Summary: sqp: incorrect order of removal of Inf bounds
Project: GNU Octave
Submitted by: i7tiol
Submitted on: Tue 23 Nov 2010 09:25:18 PM GMT
Category: None
Severity: 3 - Normal
Priority: 5 - Normal
Item Group: None
Status: None
Assigned to: None
Originator Name: Olaf Till
Originator Email:
Open/Closed: Open
Discussion Lock: Any
Release: dev
Operating System: GNU/Linux
_______________________________________________________
Details:
This bug was reported to the former bug-list, together with a patch, in
february 2010, but the patch was never applied. I would have brought the issue
to the tracker earlier, but I thought I had tested that some later changes by
Rik fixed it --- but there was obviously some mistake in my testing, since I
see now that the bug and the respective parts of the code are the same as
before. So here is it again:
There is a bug in the order in which sqp removes never-active Inf bounds,
triggered e.g. by (I had moved the file to a non-standard directory for
testing):
octave:3> [x, objf] = sqp ([1; 1], @ (x) sumsq ([1, 2, 4, 8, 20] - x(1) * exp
(x(2) * (1:5))), [], [], [-1; -inf], [2; 2])
error: operator *: nonconformant arguments (op1 is 2x4, op2 is 3x1)
error: called from:
error: /home/olaf/devel/octave/optim/sqp.m at line 478, column 9
A patch is attached (also includes a minor correction:
if (__sqp_lb__ > __sqp_ub__) ->
if (any (__sqp_lb__ > __sqp_ub__))
).
_______________________________________________________
File Attachments:
-------------------------------------------------------
Date: Tue 23 Nov 2010 09:25:18 PM GMT Name: sqp-inf-bounds-removal.changeset
Size: 3kB By: i7tiol
<http://savannah.gnu.org/bugs/download.php?file_id=22090>
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?31747>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
------------------------------
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
From: Rik <address@hidden>
Reply-To: address@hidden
To: Marco Caliari <address@hidden>, address@hidden
Cc:
Subject: [Octave-bug-tracker] [bug #31731] Test failed for sqp
Date: Wed, 24 Nov 2010 03:32:22 +0000
Please use the bug tracker to post updates to a bug report. The mailing list
is intended as a read-only notification stream. Info posted to this mailing
list address won't appear in the tracker database where it is most useful.
Follow-up Comment #3, bug #31731 (project octave):
Strange. Your machine is obviously converging to a slightly different value.
For comparison, when I run the test I get
x =
-1.71714346231343e+00
1.59570956502671e+00
1.82724595374969e+00
-7.63643097800157e-01
-7.63643082600814e-01
and
phi(x)
ans = 5.39498477702777e-02
and finally
norm(x-x_opt,inf)
ans = 7.36525367361907e-08
It's interesting that the part of the test which is failing is
all (abs (x-x_opt) < 5*sqrt (eps))
but your result of 1.8e-8 is smaller than my result of 7e-8 and my test still
passes. Maybe it's worth splitting the test into two separate assert
statements to guarantee that nothing odd is happening.
%! assert (all (abs (x-x_opt) < 5*sqrt (eps)))
%! assert (abs (obj-obj_opt) < sqrt (eps))
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?31731>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
------------------------------
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
From: Rik <address@hidden>
Reply-To: address@hidden
To: Marco Caliari <address@hidden>, address@hidden
Cc:
Subject: [Octave-bug-tracker] [bug #31740] Empty assignement to empty index
Date: Wed, 24 Nov 2010 04:10:56 +0000
Please use the bug tracker to post updates to a bug report. The mailing list
is intended as a read-only notification stream. Info posted to this mailing
list address won't appear in the tracker database where it is most useful.
Update of bug #31740 (project octave):
Status: None => Confirmed
_______________________________________________________
Follow-up Comment #1:
This is confirmed. The difference in behavior showed up between Octave 3.0.5
and Octave 3.2.3.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?31740>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
------------------------------
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
From: Marco Caliari <address@hidden>
Reply-To: address@hidden
To: Rik <address@hidden>, Marco Caliari <address@hidden>,
address@hidden
Cc:
Subject: [Octave-bug-tracker] [bug #31731] Test failed for sqp
Date: Wed, 24 Nov 2010 07:51:48 +0000
Please use the bug tracker to post updates to a bug report. The mailing list
is intended as a read-only notification stream. Info posted to this mailing
list address won't appear in the tracker database where it is most useful.
Follow-up Comment #4, bug #31731 (project octave):
Dear Rik,
I got my result with
tol = eps
If I run the test with the standard tolerance sqrt (eps), I get
norm(x-x_opt,inf)
ans = 9.87475148317429e-08
which is greater than
5*sqrt(eps)
So, nothing strange here. Can you please run
[x, obj, info, iter, nf, lambda] = sqp (x0, @phi, @g,
[],-realmax,realmax,100,eps);
and compare the result with x_opt?
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?31731>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
------------------------------
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
From: Rik <address@hidden>
Reply-To: address@hidden
To: Marco Caliari <address@hidden>, address@hidden
Cc:
Subject: [Octave-bug-tracker] [bug #31731] Test failed for sqp
Date: Wed, 24 Nov 2010 20:16:45 +0000
Please use the bug tracker to post updates to a bug report. The mailing list
is intended as a read-only notification stream. Info posted to this mailing
list address won't appear in the tracker database where it is most useful.
Follow-up Comment #5, bug #31731 (project octave):
with
[x, obj, info, iter, nf, lambda] = sqp (x0, @phi, @g,
[],-realmax,realmax,100,eps);
x =
-1.71714348089298e+00
1.59570958654167e+00
1.82724591922751e+00
-7.63643091793199e-01
-7.63643084476455e-01
max(abs(x-x_opt))
ans = 3.91303500713036e-08
So, it is better than when using the default of sqrt(eps). I re-ran the
command with sqrt(eps) as the tolerance and it reproduces exactly the same
result as the shorter form of the command where the bounds, iterations, and
tolerance were not specified.
As a side note, what is the return value of info? Is it 101 which indicates
success? Even if it is 101, there are two ways to get that return value.
Either, all the constraints are met which is tested at line 428. OR, the
stepsize has become too small which is tested at line 483. Maybe try changing
line 484 to "info = 104;" and re-running the basic test. This would help
isolate why the algorithm is stopping.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?31731>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
------------------------------
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
From: David Bateman <address@hidden>
Reply-To: address@hidden
To: David Bateman <address@hidden>, Ben Abbott <address@hidden>,
Rik <address@hidden>, address@hidden
Cc:
Subject: [Octave-bug-tracker] [bug #31468] multi-line text objects
Date: Wed, 24 Nov 2010 21:15:18 +0000
Please use the bug tracker to post updates to a bug report. The mailing list
is intended as a read-only notification stream. Info posted to this mailing
list address won't appear in the tracker database where it is most useful.
Follow-up Comment #2, bug #31468 (project octave):
Am I missing something, but can't this be fixed by adding something like
if (iscellstr (txt))
## Treat cell string array as multi-line text
txt(1:2:2*numel(txt)) = txt;
txt(2:2:2*numel(txt)) = "n";
txt = [txt{:}];
endif
to the top of the __axis_label__ function? The "text" function already treat
cell string arrays as multiple calls to the text function with different
values of "x", "y" and "z". Therefore "x", "y" and "z" are expected to have as
many elements as there are elements in the cell string array.
So as far as I can tell __axis_label__ is the only function that needs to be
treated in this way. Does it make sense to treat multiline strings in tick
labels? If so then we'd need to treat this feature request in graphics.cc as
the ticklabels might be set directly from the handle.
Can Matlab set multiline text in the handle directly? What does matlab give
for something like
h = title('One Line');
set (h, 'string', {'Two','lines'})
give in matlab. If the above works, maybe the text objects themselves should
be adapted to handle cell string arrays.
D.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?31468>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
------------------------------
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
From: Rik <address@hidden>
Reply-To: address@hidden
To: David Bateman <address@hidden>, Ben Abbott <address@hidden>,
address@hidden
Cc:
Subject: [Octave-bug-tracker] [bug #31468] multi-line text objects
Date: Wed, 24 Nov 2010 22:09:43 +0000
Please use the bug tracker to post updates to a bug report. The mailing list
is intended as a read-only notification stream. Info posted to this mailing
list address won't appear in the tracker database where it is most useful.
Follow-up Comment #3, bug #31468 (project octave):
We do need to know how Matlab handles cell string arguments to title. In
addition, there is still a problem of using inserted newlines with the FLTK
backend which doesn't interpret 'n'. My suggested hack of
title("hellonworld") only works with gnuplot.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?31468>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
------------------------------
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
From: Ben Abbott <address@hidden>
Reply-To: address@hidden
To: David Bateman <address@hidden>, Ben Abbott <address@hidden>,
Rik <address@hidden>, address@hidden
Cc:
Subject: [Octave-bug-tracker] [bug #31468] multi-line text objects
Date: Thu, 25 Nov 2010 00:19:26 +0000
Please use the bug tracker to post updates to a bug report. The mailing list
is intended as a read-only notification stream. Info posted to this mailing
list address won't appear in the tracker database where it is most useful.
Follow-up Comment #4, bug #31468 (project octave):
In Matlab I tried ...
>> h = title('One Line');
set (h, 'string', {'Two','lines'})
>> get (h, 'horizontalalignment')
ans = center
The result is a two line title with each line justified to the center. With
activepositionproperty == "outerposition" the position property is modified to
accomodate the additional line.
AFAIK Matlab treats the title, xlabel, ylabel, and zlabel as all other text
objects on the parent axis. The differences are their handles are hidden in
the list of children, but are listed in the properties of the axis.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?31468>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
------------------------------
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
From: anonymous <address@hidden>
Reply-To: address@hidden
To: address@hidden, address@hidden
Cc:
Subject: [Octave-bug-tracker] [bug #31764] Datetick missing ;
and compatibility
Date: Thu, 25 Nov 2010 06:47:30 +0000
Please use the bug tracker to post updates to a bug report. The mailing list
is intended as a read-only notification stream. Info posted to this mailing
list address won't appear in the tracker database where it is most useful.
URL:
<http://savannah.gnu.org/bugs/?31764>
Summary: Datetick missing ; and compatibility
Project: GNU Octave
Submitted by: None
Submitted on: Thu 25 Nov 2010 06:47:29 AM UTC
Category: Plotting
Severity: 3 - Normal
Priority: 5 - Normal
Item Group: None
Status: None
Assigned to: None
Originator Name: A. M. Forbes
Originator Email: address@hidden
Open/Closed: Open
Discussion Lock: Any
Release: 3.2.4
Operating System: GNU/Linux
_______________________________________________________
Details:
A ; is missing at the end of line 116 in datetick.m the correct code should
be
ticks = get (gca (), strcat (ax, "tick"));
Also, MATLAB uses the parameter "keepticks" whereas Octave uses "keeptick".
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?31764>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
------------------------------
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
From: Marco Caliari <address@hidden>
Reply-To: address@hidden
To: Rik <address@hidden>, Marco Caliari <address@hidden>,
address@hidden
Cc:
Subject: [Octave-bug-tracker] [bug #31731] Test failed for sqp
Date: Thu, 25 Nov 2010 07:41:08 +0000
Please use the bug tracker to post updates to a bug report. The mailing list
is intended as a read-only notification stream. Info posted to this mailing
list address won't appear in the tracker database where it is most useful.
Follow-up Comment #6, bug #31731 (project octave):
Yes, it exits because the stepsize has become too small. Nevertheless, with
my solution (tol = eps)
x =
-1.71714349589853e+00
1.59570960391797e+00
1.82724589134608e+00
-7.63643086466522e-01
-7.63643086466523e-01
I get
phi(x)
ans = 5.39498477702744e-02
and
g(x)
ans =
5.32907051820075e-15
-8.88178419700125e-16
-1.77635683940025e-15
while with yours
phi(x_Rik)
ans = 5.39498477702752e-02
and
g(x_Rik)
ans =
2.48689957516035e-14
7.99360577730113e-15
-7.99360577730113e-15
So, I'm satisfied with my solution. Still, there is a difference around
single precision (or sqrt(eps)) between my and your solution.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?31731>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
------------------------------
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
From: Jaroslav Hajek <address@hidden>
Reply-To: address@hidden
To: Jaroslav Hajek <address@hidden>, Rik <address@hidden>,
address@hidden, address@hidden
Cc:
Subject: [Octave-bug-tracker] [bug #31287] Certain assignments of empty
arrays give errors (Matlab incompatibility)
Date: Thu, 25 Nov 2010 21:09:31 +0000
Please use the bug tracker to post updates to a bug report. The mailing list
is intended as a read-only notification stream. Info posted to this mailing
list address won't appear in the tracker database where it is most useful.
Update of bug #31287 (project octave):
Assigned to: None => highegg
_______________________________________________________
Follow-up Comment #2:
I'm OK to fix this, but I have adopted the stance that I want to derive a
general rule first. Fixing incompatibilities on an ad hoc basis is useless. I
suppose the rule may be something like
"A(I,J,...) = B always works if B is 0x0 and at least one of I,J,... is
empty."
So, if you want to fix it, find a general rule like this (you can try this
one, if it works) and then provide a test script, as detailed as possible,
that works in Matlab some way (e.g. success/errors + different results if
applicable) and should work in Octave the same way.
This has to be done by someone with Matlab (which I'm not) and is actually
the bulk of the work, fixing the Octave code is then easy.
I'll be glad to do the latter part.
regards
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?31287>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
------------------------------
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
From: Jaroslav Hajek <address@hidden>
Reply-To: address@hidden
To: Jaroslav Hajek <address@hidden>, Rik <address@hidden>,
Marco Caliari <address@hidden>, address@hidden
Cc:
Subject: [Octave-bug-tracker] [bug #31740] Empty assignement to empty index
Date: Thu, 25 Nov 2010 21:11:34 +0000
Please use the bug tracker to post updates to a bug report. The mailing list
is intended as a read-only notification stream. Info posted to this mailing
list address won't appear in the tracker database where it is most useful.
Update of bug #31740 (project octave):
Status: Confirmed => Duplicate
_______________________________________________________
Follow-up Comment #2:
This is probably a duplicate of #31287.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?31740>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
------------------------------
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
From: Konstantinos Poulios <address@hidden>
Reply-To: address@hidden
To: Ben Abbott <address@hidden>, Rik <address@hidden>,
Konstantinos Poulios <address@hidden>,
David Bateman <address@hidden>, address@hidden,
address@hidden
Cc:
Subject: [Octave-bug-tracker] [bug #31610] Text in subplot overlaps
Date: Fri, 26 Nov 2010 13:47:58 +0000
Please use the bug tracker to post updates to a bug report. The mailing list
is intended as a read-only notification stream. Info posted to this mailing
list address won't appear in the tracker database where it is most useful.
Follow-up Comment #5, bug #31610 (project octave):
Actually the subplot command in octave misses two options comparing it with
ML: 'align' and 'replace'
Interestingly, what we see in this bug is that Octave behaves like ML but
with both this options enabled. That means, octave's subplot(r,c,n)
corresponds to ML's subplot(r,c,n, 'align', 'replace') which causes axis
labels to overlap.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?31610>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
------------------------------
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
From: marco atzeri <address@hidden>
Reply-To: address@hidden
To: marco atzeri <address@hidden>, address@hidden
Cc:
Subject: [Octave-bug-tracker] [bug #31776] gamma for negative integers values
Date: Fri, 26 Nov 2010 15:10:52 +0000
Please use the bug tracker to post updates to a bug report. The mailing list
is intended as a read-only notification stream. Info posted to this mailing
list address won't appear in the tracker database where it is most useful.
URL:
<http://savannah.gnu.org/bugs/?31776>
Summary: gamma for negative integers values
Project: GNU Octave
Submitted by: matzeri
Submitted on: Fri 26 Nov 2010 03:10:51 PM GMT
Category: None
Severity: 3 - Normal
Priority: 5 - Normal
Item Group: Incorrect Result
Status: None
Assigned to: None
Originator Name:
Originator Email:
Open/Closed: Open
Discussion Lock: Any
Release: dev
Operating System: Microsoft Windows
_______________________________________________________
Details:
>From Mathematical point gamma(-1) should be Inf
as gamma(0). Matlab provides gamma(-1)=Inf
The same for the other integer negative values.
The test is expecting NaN as on same systems
tgamma(-n)=NaN
as the NaN value is allowed on
http://www.opengroup.org/onlinepubs/009695399/functions/tgamma.html
The test fails on system were tgamma(-1)=Inf
---------------------------------------------
>>>>> processing /pub/hg/octave/src/mappers.cc
***** test
x = [-1, 0, 1, Inf];
v = [NaN, Inf, 1, Inf];
assert (gamma(x), v);
assert (gamma(single (x)), single (v));
!!!!! test failed
assert (gamma (x),v) expected
NaN Inf 1 Inf
but got
Inf Inf 1 Inf
NaNs don't match
-----------------------------------------------
The attached patch provides
gamma(-n)=Inf
for all systems and amends test expectation
Reference
http://en.wikipedia.org/wiki/Gamma_function
discussed:
https://www-old.cae.wisc.edu/pipermail/octave-maintainers/2010-October/017501.html
https://www-old.cae.wisc.edu/pipermail/octave-maintainers/2010-November/017796.html
_______________________________________________________
File Attachments:
-------------------------------------------------------
Date: Fri 26 Nov 2010 03:10:51 PM GMT Name: changeset_gamma.patch Size: 2kB
By: matzeri
<http://savannah.gnu.org/bugs/download.php?file_id=22129>
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?31776>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
------------------------------
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
From: Ben Abbott <address@hidden>
Reply-To: address@hidden
To: Ben Abbott <address@hidden>, Rik <address@hidden>,
Konstantinos Poulios <address@hidden>,
David Bateman <address@hidden>, address@hidden,
address@hidden
Cc:
Subject: [Octave-bug-tracker] [bug #31610] Text in subplot overlaps
Date: Fri, 26 Nov 2010 17:32:04 +0000
Please use the bug tracker to post updates to a bug report. The mailing list
is intended as a read-only notification stream. Info posted to this mailing
list address won't appear in the tracker database where it is most useful.
Follow-up Comment #6, bug #31610 (project octave):
Looking at Matlab's documentation for what "align" does …
SUBPLOT(m,n,p,'align') places the axes so that the plot boxes are aligned,
but does not prevent the labels and ticks from overlapping.
My first thought was that "align" implies that activepositionproperty is set
to "position", and that the default would be "outerposition".
However, the commands below …
>> h1 = subplot(2,2,1);
>> h2 = subplot(2,2,1,'align');
>> get (h1, 'ActivePositionProperty')
ans = position
>> get (h2, 'ActivePositionProperty')
ans = position
… indicate that, for Matlab, the activepositionproperty is always set to
"position". I think this implies that callbacks are used to set the position
of the plot box and that the position is dependent upon the position and
extents of the tick and axes labels.
Unfortunately, we don't have a reliable method to determine the position and
extents of text for gnuplot (David Batemann recently tried, so I've cc'd him).
I see three options.
0 item 1 Patch gnuplot to provide the needed text information.
0 item 2 Make another attempt to calculate the position and extents in
Octave.
0 item 3 Interpret "align" to imply the activepositionproperty is "position",
and "outerposition" otherwise.
The first two options are in need of a volunteer. Once/if the text extends
are available the axes properties "position", "outerposition", and
"tightinset" will need to be properly determined. Legends are also impacted
(others that are slipping my mind?). This would require a lot of effort, which
I think would be better invested in the OpenGL backends.
The third option is a trivial fix. This will only produce the intended
effect if all subplots have same activepositionproperty. In that case, the
effect of _not_ specifying "align" would be identical to the commands below.
demo ("subplot", 1);
set (findobj (gcf, "type", "axes"), "activepositionproperty",
"outerposition")
If the third approach is acceptable, I can implement it.
Matlab's documentation for subplot describes the effect of "replace" as ...
If a SUBPLOT specification causes a new axes to overlap an existing axes, the
existing axes is deleted - unless the position of the new and existing axes
are identical. For example, the statement SUBPLOT(1,2,1) deletes all existing
axes overlapping the left side of the Figure window and creates a new axes on
that side - unless there is an axes there with a position that exactly matches
the position of the new axes (and 'replace' was not specified), in which case
all other overlapping axes will be deleted and the matching axes will become
the current axes.
It looks to me like Octave is behaving correctly when "replace" is _not_
specified.
octave:1> h = subplot (2,2,1)
h = -1.2334
octave:2> h = subplot (2,2,1)
h = -1.2334
octave:3> h = subplot (1,2,1)
h = -5.0747
Specifying "replace" would return a new axes handle for the second subplot
command. This should be a simple fix.
I'll take a look at adding support for the "replace" option and will wait for
feedback on "align".
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?31610>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
------------------------------
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
From: Ben Abbott <address@hidden>
Reply-To: address@hidden
To: Ben Abbott <address@hidden>, Rik <address@hidden>,
Konstantinos Poulios <address@hidden>,
David Bateman <address@hidden>, address@hidden,
address@hidden
Cc:
Subject: [Octave-bug-tracker] [bug #31610] Text in subplot overlaps
Date: Fri, 26 Nov 2010 18:00:10 +0000
Please use the bug tracker to post updates to a bug report. The mailing list
is intended as a read-only notification stream. Info posted to this mailing
list address won't appear in the tracker database where it is most useful.
Update of bug #31610 (project octave):
Status: Confirmed => Ready For Test
_______________________________________________________
Follow-up Comment #7:
I've attached a proposed changedset for both the "align" and "replace"
options.
(file #22133)
_______________________________________________________
Additional Item Attachment:
File name: changeset.patch Size:2 KB
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?31610>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
------------------------------
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
From: Jay K <address@hidden>
Reply-To: address@hidden
To: Tatsuro MATSUOKA <address@hidden>, Nathan Hopkins <address@hidden>,
Jay K <address@hidden>, address@hidden
Cc:
Subject: [Octave-bug-tracker] [bug #31684] GNU plot window freezes with
click on titlebar
Date: Fri, 26 Nov 2010 23:46:46 +0000
Please use the bug tracker to post updates to a bug report. The mailing list
is intended as a read-only notification stream. Info posted to this mailing
list address won't appear in the tracker database where it is most useful.
Follow-up Comment #2, bug #31684 (project octave):
I'm having a similar problem to Nathan with a clean install of Octave 3.2.4
on XP Pro SP3. I haven't tried the lengthy delay at the end of plt.m, but I
have tried the three suggestions documented here:
http://wiki.octave.org/wiki.pl?OctaveForWindows. If I start Octave and then
do, say, plot([1 2 3],[2 3 4]), I get the expected plot window and it works
normally (I can resize, etc.). If I then do ALT-TAB it takes me back to the
Octave command window and another ALT-TAB selects the plot window but doesn't
bring it to the front. At this point the plot window is dead - it won't
refresh or resize; all I can do is close it, but after that I can't open any
new plot windows until I restart Octave.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?31684>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
------------------------------
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
From: Jay K <address@hidden>
Reply-To: address@hidden
To: Tatsuro MATSUOKA <address@hidden>, Nathan Hopkins <address@hidden>,
Jay K <address@hidden>, address@hidden
Cc:
Subject: [Octave-bug-tracker] [bug #31684] GNU plot window freezes with
click on titlebar
Date: Sat, 27 Nov 2010 00:34:44 +0000
Please use the bug tracker to post updates to a bug report. The mailing list
is intended as a read-only notification stream. Info posted to this mailing
list address won't appear in the tracker database where it is most useful.
Follow-up Comment #3, bug #31684 (project octave):
Another detail - if I close the window by typing 'close' from the Octave
command window, the window closes and I can create new plot windows without a
restart. Still, something is funky with ALT-TAB.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?31684>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
------------------------------
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
From: Thorsten Meyer <address@hidden>
Reply-To: address@hidden
To: Thorsten Meyer <address@hidden>, address@hidden
Cc:
Subject: [Octave-bug-tracker] [bug #31779] mesh changes edgecolor when
switching to logarithmic scale
Date: Sat, 27 Nov 2010 09:25:10 +0000
Please use the bug tracker to post updates to a bug report. The mailing list
is intended as a read-only notification stream. Info posted to this mailing
list address won't appear in the tracker database where it is most useful.
URL:
<http://savannah.gnu.org/bugs/?31779>
Summary: mesh changes edgecolor when switching to
logarithmic scale
Project: GNU Octave
Submitted by: tmeyier
Submitted on: Sat 27 Nov 2010 09:25:01 AM UTC
Category: Plotting with gnuplot
Severity: 3 - Normal
Priority: 5 - Normal
Item Group: Incorrect Result
Status: None
Assigned to: None
Originator Name:
Originator Email:
Open/Closed: Open
Discussion Lock: Any
Release: dev
Operating System: GNU/Linux
_______________________________________________________
Details:
I see this bug on debian testing with gnuplot version 4.4 patchlevel 0, but
not with the fltk backend.
example to reproduce the bug:
x = logspace(1,3,30);
y = logspace(1,3,30);
z = y'*x;
mesh (x,y,z);
pause;
set(gca, "xscale", "log", "yscale", "log", "zscale", "log");
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?31779>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
------------------------------
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
From: Thorsten Meyer <address@hidden>
Reply-To: address@hidden
To: Thorsten Meyer <address@hidden>, address@hidden
Cc:
Subject: [Octave-bug-tracker] [bug #31780] edgecolors broken for two mesh
plots in one axes
Date: Sat, 27 Nov 2010 09:59:29 +0000
Please use the bug tracker to post updates to a bug report. The mailing list
is intended as a read-only notification stream. Info posted to this mailing
list address won't appear in the tracker database where it is most useful.
URL:
<http://savannah.gnu.org/bugs/?31780>
Summary: edgecolors broken for two mesh plots in one axes
Project: GNU Octave
Submitted by: tmeyier
Submitted on: Sat 27 Nov 2010 09:59:28 AM UTC
Category: Plotting with gnuplot
Severity: 3 - Normal
Priority: 5 - Normal
Item Group: Incorrect Result
Status: None
Assigned to: None
Originator Name:
Originator Email:
Open/Closed: Open
Discussion Lock: Any
Release: dev
Operating System: GNU/Linux
_______________________________________________________
Details:
I see the following strange color effects on debian testing with gnuplot 4.4
patchlevel 0 but not with the fltk backend.
x = logspace(1,3,30);
y = logspace(1,3,30);
z = (1001-y')*(1001-x);
h1 = mesh (x, y, z);
hold on
h2 = mesh (x, y, 2*z);
hold off
# up to here everything is fine.
pause
set (h1, 'edgecolor', 'blue');
# now the first mesh is white on white
pause
set (h2, 'edgecolor', 'red');
# now both meshes have the same colors, blue from above
# and red from below
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?31780>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
------------------------------
End of this Digest
******************
- lost bug tracker updates,
John W. Eaton <=