octave-maintainers
[Top][All Lists]
Advanced

[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
******************



reply via email to

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