Thread Subject: Wishlist for R2007b

This thread will be used to indicate the community's requests for
features/bug-fixes for the upcoming Matlab release (R2007b, Sep 1
2007). This is in lieu of an official votable wishlist (see separate
thread on this: Yair Altman, "Proposed Matlab votable wishlist" #, 16 May 2007 11:13 am </WebX?14@@.ef5718f>
# ).

Here are some items I would like to see:
- fix the "clear java" bug (also clears globals as side-effect)
- try-catch should also catch Java exceptions, not just Matlab ones
- add an Excel-like iff function to the basic ML language (equivalent
to C's a?b:c construct) - highly important in anonymous functions
- enable multi-thread use of the Matlab computation engine from
external C++/C#/Java threads
- finally (after who knows how many years) fix the stupid zoom and
similar problems with plotyy

More to follow later - I think this is enough for now to start a
healthy discussion. Please pitch in with your wishlist items.

Yair Altman

In article <ef57195.-1@webcrossing.raydaftYaTP>, Yair Altman wrote:
> - finally (after who knows how many years) fix the stupid zoom and
> similar problems with plotyy

That's got my vote!

On Wed, 16 May 2007 11:24:33 -0400, Yair Altman wrote:

> This thread will be used to indicate the community's requests for
> features/bug-fixes for the upcoming Matlab release (R2007b, Sep 1 2007).
> This is in lieu of an official votable wishlist (see separate thread on
> this: Yair Altman, "Proposed Matlab votable wishlist" #, 16 May 2007
> 11:13 am </WebX?14@@.ef5718f> # ).
>
> Here are some items I would like to see: - fix the "clear java" bug
> (also clears globals as side-effect) - try-catch should also catch Java
> exceptions, not just Matlab ones - add an Excel-like iff function to the
> basic ML language (equivalent to C's a?b:c construct) - highly important
> in anonymous functions - enable multi-thread use of the Matlab
> computation engine from external C++/C#/Java threads
> - finally (after who knows how many years) fix the stupid zoom and
> similar problems with plotyy

1. Allow toggle to turn off file overwrite message with uiputfile
2. Officially support uitable.
3. Support handle objects again.
4. Make boolean functions such as intersect, union, etc. builtin so they
operate faster.
5. Fix listbox highlighted items turning gray when focus shifts to a
different uicontrol.

Dan

Kelvin Hales wrote:
>
>
> In article <ef57195.-1@webcrossing.raydaftYaTP>, Yair Altman
wrote:
>> - finally (after who knows how many years) fix the stupid zoom
> and
>> similar problems with plotyy
>
> That's got my vote!
>
>
>

Agree with the above and please include the "Serial port fprintf
sporatic time out" that has been around for the last 6 releases.

Reed

In article <ef57195.-1@webcrossing.raydaftYaTP>,
altmanyDEL@gmailDEL.comDEL says...
> This thread will be used to indicate the community's requests for
> features/bug-fixes for the upcoming Matlab release (R2007b, Sep 1
> 2007). This is in lieu of an official votable wishlist (see separate
> thread on this: Yair Altman, "Proposed Matlab votable wishlist" #, 16 May 2007 11:13 am </WebX?14@@.ef5718f>
> # ).
>
> Here are some items I would like to see:
> - fix the "clear java" bug (also clears globals as side-effect)
> - try-catch should also catch Java exceptions, not just Matlab ones
> - add an Excel-like iff function to the basic ML language (equivalent
> to C's a?b:c construct) - highly important in anonymous functions
> - enable multi-thread use of the Matlab computation engine from
> external C++/C#/Java threads
> - finally (after who knows how many years) fix the stupid zoom and
> similar problems with plotyy
>
> More to follow later - I think this is enough for now to start a
> healthy discussion. Please pitch in with your wishlist items.
>
> Yair Altman
>

I hate to hassle all of you who are enthusiastic and have great
suggestions. But it would be far more helpful if you would each put in
bug/enhancement requests here, one per bug/feature:

http://www.mathworks.com/support/service_request/login_servicerequests.h
tml?targetURL=/support/service_requests/contact_support.do

We do keep track of the frequency of reported issues and that can figure
into decisions on what to work on.

-- Loren
http://blogs.mathworks.com/loren/

> I hate to hassle all of you who are enthusiastic and have great
> suggestions. But it would be far more helpful if you would each put in
> bug/enhancement requests here, one per bug/feature:

I've been requesting at least one of mine since 1999, and it still hasn't
been addressed.

And I have requested the other ones each release since about Matlab 7.0.
All I get back from tech support is "that is not supported".

Dan

Dan Hensley wrote:
>
>
>> I hate to hassle all of you who are enthusiastic and have great
>> suggestions. But it would be far more helpful if you would
each
> put in
>> bug/enhancement requests here, one per bug/feature:
>
> I've been requesting at least one of mine since 1999, and it still
> hasn't
> been addressed.
>
> And I have requested the other ones each release since about Matlab
> 7.0.
> All I get back from tech support is "that is not supported".
>
> Dan
>
  

The one I refered to "Serial port fprintf sporadically times out";
report ID 250986 has been shown as open since release 7.0.1 Should I
report it again?
Reed

Just out of curiosity, who voted for the "nag me about my code"
colored tags that started to appear in the editor? I would happily
vote that out again ;)

That effort could have been put into bug fixing instead, e.g. sort out
Copy Figure, update all the legacy 'double only' functions and fully
optimize the math operations: mixed real-complex multiplication,
sparse complex. It amazes me The Mathworks needs us to vote to work on
basic stuff like that. Bah humbug!

In article <1179378005.215820.316490@u30g2000hsc.googlegroups.com>,
spasmous@gmail.com says...
> Just out of curiosity, who voted for the "nag me about my code"
> colored tags that started to appear in the editor? I would happily
> vote that out again ;)
>
> That effort could have been put into bug fixing instead, e.g. sort out
> Copy Figure, update all the legacy 'double only' functions and fully
> optimize the math operations: mixed real-complex multiplication,
> sparse complex. It amazes me The Mathworks needs us to vote to work on
> basic stuff like that. Bah humbug!
>
>

several things come to mind, most/all of which you probably know
already:

1) you can turn off mlint in the editor by unchecking a box for the
mlint preferences
2) developers are not entirely interchangeable. those that work on the
math typically have different skills and knowledge base than those who
work on graphics, and they again tend to differ from those who work
directly on the user interface

just some perspective. I believe we need the full breadth of knowledge
and expertise of all these development groups and MATLAB would be the
worse for wear if we concentrated in only one domain.

-- Loren
http://blogs.mathworks.com/loren/

spasmous wrote:
...
> update all the legacy 'double only' functions and fully
> optimize the math operations: mixed real-complex multiplication,
> sparse complex...

MATLAB relies on the BLAS for its performance for dense matrix
operations (and it uses the BLAS for the x=A\b in the sparse case as
well). The BLAS are far faster than what mere mortals writing in
C/C++ can get, so using them is an imperative (i.e, the Intel MKL on
the Intel cpu's, the AMD has their own etc). Each BLAS is optimized
for that particular architecture.

However, the BLAS doesn't support mixed real/complex. It's either
all real or all complex. To do C=A*B when A is real and B is
complex, my guess is that MATLAB does (and this is purely a guess):

C = A*real(B) + 1i*A*imag(B)

since MATLAB stores its matrices with the real and imaginary parts in
different arrays (thus the "+" above doesn't really occur, neither
does the "1i*"). Then this would become two calls to DGEMM.

If The MathWorks does that, my guess is that that's as best it will
get. If they instead do C=A*B by coercing A into complex (appending
a complex part) then it would be slower than the above, I would
predict.

The BLAS stores complex matrices with real/imaginary values
interleaved. So in memory, the BLAS sees real(A(1,1)), imag(A(1,1)),
real(A(2,1)), imag(A(2,1)), etc. But MATLAB stores the real part of
A and the imaginary part of A in 2 different real arrays. So there
will often be a copy made when passing complex matrices to the BLAS,
and I doubt that will ever change.

I could say lots about how sparse complex should be done, but that's
another story and quite a long one at that ...

And, if I were The MathWorks (and I'm not so I know nothing), it's
unlikely I'd be adding new features to a release just a few months
away. So this thread should be entitled "wish list for R2008x"
instead.

On May 17, 10:35 am, "Tim Davis" <d...@cise.ufl.edu> wrote:
> spasmouswrote:
>
> ...
>
> > update all the legacy 'double only' functions and fully
> > optimize the math operations: mixed real-complex multiplication,
> > sparse complex...
>
> MATLAB relies on the BLAS for its performance for dense matrix
> operations (and it uses the BLAS for the x=A\b in the sparse case as
> well). The BLAS are far faster than what mere mortals writing in
> C/C++ can get, so using them is an imperative (i.e, the Intel MKL on
> the Intel cpu's, the AMD has their own etc). Each BLAS is optimized
> for that particular architecture.
>
> However, the BLAS doesn't support mixed real/complex. It's either
> all real or all complex. To do C=A*B when A is real and B is
> complex, my guess is that MATLAB does (and this is purely a guess):
>
> C = A*real(B) + 1i*A*imag(B)
>
> since MATLAB stores its matrices with the real and imaginary parts in
> different arrays (thus the "+" above doesn't really occur, neither
> does the "1i*"). Then this would become two calls to DGEMM.
>
> If The MathWorks does that, my guess is that that's as best it will
> get. If they instead do C=A*B by coercing A into complex (appending
> a complex part) then it would be slower than the above, I would
> predict.
>
> The BLAS stores complex matrices with real/imaginary values
> interleaved. So in memory, the BLAS sees real(A(1,1)), imag(A(1,1)),
> real(A(2,1)), imag(A(2,1)), etc. But MATLAB stores the real part of
> A and the imaginary part of A in 2 different real arrays. So there
> will often be a copy made when passing complex matrices to the BLAS,
> and I doubt that will ever change.
>
> I could say lots about how sparse complex should be done, but that's
> another story and quite a long one at that ...
>
> And, if I were The MathWorks (and I'm not so I know nothing), it's
> unlikely I'd be adding new features to a release just a few months
> away. So this thread should be entitled "wish list for R2008x"
> instead.

Hi Tim, thank you for your input. Just for the record I'm basing my
own comments on comparisons of A * B and A .* B (different
operations). Whereas A * B is BLAS and The Mathworks is probably wise
to stay away, A .* B is definitely within their scope. When one is
complex and the other is real, the operation is more expensive than
pure complex-complex. I'm not really complaining as much as
explaining ;) Bug reports were submitted a year or two ago...

Well, since Loren has already said our pleas are falling on deaf
ears:
a girlfriend. It would be a bonus if she knew MatLab but I'll take
whatever you send.

 Tim Davis wrote:
>
>
> spasmous wrote:
> ...
>> update all the legacy 'double only' functions and fully
>> optimize the math operations: mixed real-complex
multiplication,
>> sparse complex...
>
> MATLAB relies on the BLAS for its performance for dense matrix
> operations (and it uses the BLAS for the x=A\b in the sparse case
> as
> well). The BLAS are far faster than what mere mortals writing in
> C/C++ can get, so using them is an imperative (i.e, the Intel MKL
> on
> the Intel cpu's, the AMD has their own etc). Each BLAS is
> optimized
> for that particular architecture.
>
> However, the BLAS doesn't support mixed real/complex. It's either
> all real or all complex. To do C=A*B when A is real and B is
> complex, my guess is that MATLAB does (and this is purely a guess):
>
> C = A*real(B) + 1i*A*imag(B)
>
> since MATLAB stores its matrices with the real and imaginary parts
> in
> different arrays (thus the "+" above doesn't really occur, neither
> does the "1i*"). Then this would become two calls to DGEMM.
>
> If The MathWorks does that, my guess is that that's as best it will
> get. If they instead do C=A*B by coercing A into complex
> (appending
> a complex part) then it would be slower than the above, I would
> predict.
>
> The BLAS stores complex matrices with real/imaginary values
> interleaved. So in memory, the BLAS sees real(A(1,1)),
> imag(A(1,1)),
> real(A(2,1)), imag(A(2,1)), etc. But MATLAB stores the real part
> of
> A and the imaginary part of A in 2 different real arrays. So there
> will often be a copy made when passing complex matrices to the
> BLAS,
> and I doubt that will ever change.
>
> I could say lots about how sparse complex should be done, but
> that's
> another story and quite a long one at that ...
>
> And, if I were The MathWorks (and I'm not so I know nothing), it's
> unlikely I'd be adding new features to a release just a few months
> away. So this thread should be entitled "wish list for R2008x"
> instead.

1. Sparse matrices of dimension greater than 2.

2. Support for running Matlab in emacs under Windows. This is
possible using workarounds, but after much searching I have not found
a clean implementation.

spasmous wrote:
>...
> Hi Tim, thank you for your input. Just for the record I'm basing my
> own comments on comparisons of A * B and A .* B (different
> operations). Whereas A * B is BLAS and The Mathworks is probably
> wise
> to stay away, A .* B is definitely within their scope. When one is
> complex and the other is real, the operation is more expensive than
> pure complex-complex. I'm not really complaining as much as
> explaining ;) Bug reports were submitted a year or two ago...

Oh, I see. A dot-times B (A.*B) doesn't exist since it's not linear
algebra ;-) so I know nothing about how it should work. You're
right, A.*B is BLAS-less.

In MATLAB 7.4, A.*B when A and B are both real take 0.4 seconds on
my laptop. When A is real and B is complex, the time goes up to 0.7
seconds. B.*A takes the same time (both A and B are 3000-by-3000).
The real-complex case runs at 25 MFlops, which is slow but then the
operation is memory-bound. When both are complex, the time is 0.8
seconds. These times sound reasonable to me. Am I wrong?

I have a 2Ghz Pentium 4 Mobile, with 1GB of memory.

Trevor wrote:
>
>
> 1. Sparse matrices of dimension greater than 2.

What do you want to do with them?

The sparse data structure for the 2D case is optimized for linear
algebra, not as a "data bucket". Thus, A(i,j) = whatever and
whatever=A(i,j) are not terribly fast ... Although they could be
better they will never be truly speedy.

ND matrices come up in tensor calculations, I think.

What the ND sparse case should look like depends strongly on what you
want to do with the beasts. If you want just sparse sub referencing
and sub assignment, that's one thing. If you want tensors, that's
another. (I'm not a tensor specialist, except in the morning when
I've had one two many tenser products via my morning coffee... ;-)

I want a scale arrow feature for use with the quiver function (ie, a
little arrow on the side of the plot that indicates the scale of the
arrow vectors). This is an absolute necessity when generating figures
for publication or presentations. Right now, I have a hacked version
of quiver that can be messily and painfully used to implement a scale
arrow (by pulling the scaling factor from quiver, overlaying a
separate axis on top of the first quiver plot, drawing a single arrow
to a set scale, and labeling it with text), but it leaves much to be
desired.

To have a switch on sparse matrices such that when an element is set
to zero, the inernal storage is not reset. Quite often I zero a row
in preparation for recomputing the non-zero elements, and the
internal resetting of the storage is needlessly time-consuming.

Richard Hindmarsh (remove '1's in e-mail)

This is, I think, impossible to achieve in R2007b but I hope it'll
come in R2008:

TMW, please, make Simulink for Mac look like the Windows version!

The Mac (unix) version looks ugly (choppy icons and fonts), has no
toolbar and no status bar (you can't tell if the simulation is
running!), and the load/save masks are terrible and not even coherent
with the Matlab ones. I'm sure there is a reason for this... but is
it so difficult to use graphics the Simulink interface?

In article <ef57195.10@webcrossing.raydaftYaTP>,
aggieinmissouri_DUDE@hotmail.com says...
> Well, since Loren has already said our pleas are falling on deaf
> ears:
> a girlfriend. It would be a bonus if she knew MatLab but I'll take
> whatever you send.
>

I deinitely did NOT say that. I just said we have a system for tracking
customer input and the way to use it best is to submit items via the web
form. As for a girlfriend, I am afraid that request will not go into
our queue :-)

-- Loren
http://blogs.mathworks.com/loren/

Richard Hindmarsh wrote:
>
>
> To have a switch on sparse matrices such that when an element is
> set
> to zero, the inernal storage is not reset. Quite often I zero a row
> in preparation for recomputing the non-zero elements, and the
> internal resetting of the storage is needlessly time-consuming.
>
> Richard Hindmarsh (remove '1's in e-mail)

That would be tricky to have a switch. Better one way or the other
with no switch. There are too many repercusions of this change to
make it easy to have a user-settable switch.

It would be better if MATLAB never dropped zeros due cancellation, in
my sparse opinion. Then if you really want them to go away, just do
A=sparse(A), which should be the only function that drops zeros (so
that the result A is the same regardless of whether or not the input
A is full or sparse.

S = alpha*A where alpha is a scalar should "never" drop zeros. But
then you would have odd cases like S = 0*A, which in my mind should
return spones(S) == spones(A), but then ... maybe that's a little
bizarre. I like it, though. It's a nice way of creating numerically
zero entry placeholders (if it existed). (OK, maybe my brain is
bizarre).

Regarding zeroing out a row, though. That's really slow. Try to
operate on columns as much as possible, since the matrices are stored
by column, not by row. Try timing x=A(i,:) and x=A(:,i) for a large
sparse A. The latter is much faster.

In article <ef57195.-1@webcrossing.raydaftYaTP>,
altmanyDEL@gmailDEL.comDEL says...
> This thread will be used to indicate the community's requests for
> features/bug-fixes for the upcoming Matlab release (R2007b, Sep 1
> 2007). This is in lieu of an official votable wishlist (see separate
> thread on this: Yair Altman, "Proposed Matlab votable wishlist" #, 16 May 2007 11:13 am </WebX?14@@.ef5718f>
> # ).
>
> Here are some items I would like to see:
> - fix the "clear java" bug (also clears globals as side-effect)
> - try-catch should also catch Java exceptions, not just Matlab ones
> - add an Excel-like iff function to the basic ML language (equivalent
> to C's a?b:c construct) - highly important in anonymous functions
> - enable multi-thread use of the Matlab computation engine from
> external C++/C#/Java threads
> - finally (after who knows how many years) fix the stupid zoom and
> similar problems with plotyy
>
> More to follow later - I think this is enough for now to start a
> healthy discussion. Please pitch in with your wishlist items.
>
> Yair Altman
>

I know some on this thread have mentioned that they requested a bug fix
and haven't seen it yet. Are you aware that you can now track bugs of
interest to you from the support web site?

http://www.mathworks.com/accesslogin/watchList.do

-- Loren
http://blogs.mathworks.com/loren/

On Fri, 18 May 2007 10:52:33 -0400, Loren Shure wrote:

> In article <ef57195.10@webcrossing.raydaftYaTP>,
> aggieinmissouri_DUDE@hotmail.com says...
>> Well, since Loren has already said our pleas are falling on deaf ears:
>> a girlfriend. It would be a bonus if she knew MatLab but I'll take
>> whatever you send.
>>
>>
> I deinitely did NOT say that. I just said we have a system for tracking
> customer input and the way to use it best is to submit items via the web
> form. As for a girlfriend, I am afraid that request will not go into
> our queue :-)

I think that many people have the impression that even submitting
requests to the system will be a waste of time because Mathworks won't
respond to them (which gives the impression of deaf ears). So many
people are voicing this ("I've been requesting this or reporting this for
the last 6 releases...").

I know that's my impression. I continue to request the same features
each release, but it's disappointing to continually get "that's not
supported and we have no plans for future support, or we won't tell you
if we do".

I even had a recent case where I could easily produce a Matlab crash with
about 3 lines of code. I was told that the functionality I was using
(figure handle) was unsupported. And not only that, because it was
unsupported, Mathworks would NOT even fix the crash. That's pathetic IMO.

Dan

> I know that's my impression. I continue to request the same
> features
> each release, but it's disappointing to continually get "that's not
>
> supported and we have no plans for future support, or we won't tell
> you
> if we do".

<rant>
That's certainly my impression too. I submitted a request for the
ability to rotate image axes with out the image disappearing. The
workaround of using a surf with Z ranging from 0 to 0 was not
practical because it is too slow for large images. I did receive an
email in response, basically saying "Oh, that's not supported". I
sort of got the impression that the person responding to me didn't
fully understand that the reason for requesting new features is that
the feature would be new, so just reminding us that it isn't
supported isn't much of a response.
</rant>

That said, I'd also like to see a couple of new uicontrols. A table,
similar to that used in the UI Property Inspector window, would be
nice. I'd also like to see real UI tabs.

On Fri, 18 May 2007 12:18:33 -0400, Gary wrote:

> That said, I'd also like to see a couple of new uicontrols. A table,
> similar to that used in the UI Property Inspector window, would be nice.
> I'd also like to see real UI tabs.

There's uitable which is extremely functional, but difficult to use
because "it's unsupported". We ended up writing a lot of code to make it
usable and act somewhat like the other uicontrols. And in the process we
ran into a number of bugs (some as simple as typos in the attributes),
but every time we sent in a bug report all we got was "it's unsupported,
so too bad and don't bother us". I've thought about putting it on Matlab
Central but haven't had any free time to select a license, etc. and get
it through company approval.

I think there is or at least used to be a tab capability too that's been
available for a long time, but "it's unsupported".

Dan

Dan Hensley wrote:
>
>
> On Fri, 18 May 2007 10:52:33 -0400, Loren Shure wrote:
>
>> In article <ef57195.10@webcrossing.raydaftYaTP>,
>> aggieinmissouri_DUDE@hotmail.com says...
>>> Well, since Loren has already said our pleas are falling on
deaf
> ears:
>>> a girlfriend. It would be a bonus if she knew MatLab but
I'll
> take
>>> whatever you send.
>>>
>>>
>> I deinitely did NOT say that. I just said we have a system for
> tracking
>> customer input and the way to use it best is to submit items
via
> the web
>> form. As for a girlfriend, I am afraid that request will not
go
> into
>> our queue :-)
>
> I think that many people have the impression that even submitting
> requests to the system will be a waste of time because Mathworks
> won't
> respond to them (which gives the impression of deaf ears). So many
>
> people are voicing this ("I've been requesting this or reporting
> this for
> the last 6 releases...").
>
> I know that's my impression. I continue to request the same
> features
> each release, but it's disappointing to continually get "that's not
>
> supported and we have no plans for future support, or we won't tell
> you
> if we do".
>
> I even had a recent case where I could easily produce a Matlab
> crash with
> about 3 lines of code. I was told that the functionality I was
> using
> (figure handle) was unsupported. And not only that, because it was
>
> unsupported, Mathworks would NOT even fix the crash. That's
> pathetic IMO.
>
> Dan
>

Dan, that sounds odd.

Can you post the lines of code?

Regards,
Eric Sampson
The MathWorks, Inc.

> ...I think there is or at least used to be a tab capability too
that's
> been
> available for a long time, but "it's unsupported".
>
> Dan
>

How do you locate/find out about these "unsupported" features?

Yair Altman wrote:
> finally (after who knows how many years) fix the
> stupid zoom and similar problems with plotyy

> That's got my vote!
> Kelvin Hales <khales@khace.com>

Yair and Kelvin - I'm curious to know which "stupid" plotyy problems
are annoying you. I'd also be curious what you think of my "plt"
alternative to plotyy and whether it avoids these stupid problems.

You can find plt here:
www.mathworks.com/matlabcentral/fileexchange/loadFile.do?objectId=4936
&objectType=file

Or if you want to check out the documentation first go here:
www.mennen.org/plt/plthome.htm

Although plt represents a modest shift in graphical and coding style
I'd like to think of plt as a viable alternative to plotyy for most
applications.

Perhaps the most significant advantage of plt may be its
documentation. From the many newsgroup questions about plotyy, it
seems few people can figure out how to get plotyy to do what they
want. I get practically no similar questions about plt. Maybe that is
because of the clear and extensive help file and breadth of the
example programs, or maybe it is because nobody is using it. (plt was
once Doug's "pick of the week" and has been downloaded over 2600
times, so I hope it's the former.)

~Paul
paul@m_e_n_n_e_n.org
(remove underscores from my email address)

Just to throw my 2 cents in:

Printing in deployed applications has been an enormous pain in the
a** since R14. The deployprint 'solution' has been a complete kludge
since then . It's painfully slowly improving but I'd like to see a
complete overhaul of this. And yes, I have submitted numerous tech
support/ enhancement requests for this over the years and had to get
a little ugly a couple of times.

Also why can't we get more documentation on the Java underpinnings of
Matlab. There's huge functionality waiting to be tapped there. I know
it's not for newbies but heck I'd even consider paying for the
documentation. We shouldn't have to rely on intrepid explorers like
Yair Altman (the 'Magellan' of Matlab?) to reveal these untapped
riches.

And please can we finally get a usable OOP system released. We see
hints of it using classdef the last couple of releases. See
memmapfile and a few other functions.

I would dearly like to see 64 bit support on Mac OS X. Can someone
from MathWorks comment about whether we will see this in 2007b or not?

Loren Shure wrote:

> I know some on this thread have mentioned that they requested a bug
> fix
> and haven't seen it yet. Are you aware that you can now track bugs
> of
> interest to you from the support web site?
>
> <http://www.mathworks.com/accesslogin/watchList.do>

You can track some bugs of interest, but not all. Of the six bug
reports I've submitted (all of which were confirmed as bugs in my
correspondence with the Mathworks following each report), only three
are listed on the site. Of those three, two were fixed in R2007a
(although I still take issue with the behavior of bufferm; I suppose
it now falls into the category of enhancement rather than bug though)
but one remains open. The three unlisted bugs (in ltlon2val,
setpostn, and polyxpoly) have remained untouched through the last few
releases.

Out of curiosity, how does the Mathworks decide which bugs to list on
the site? And which ones to fix? I do understand that the bugs I've
reported are part of the Mapping Toolbox, which is not one of your
most popular toolboxes, but shouldn't bug fixes be a priority even
before enhancements?

-Kelly

On Fri, 18 May 2007 12:43:38 -0400, Eric Sampson wrote:

>> I even had a recent case where I could easily produce a Matlab crash
>> with
>> about 3 lines of code. I was told that the functionality I was using
>> (figure handle) was unsupported. And not only that, because it was
>>
>> unsupported, Mathworks would NOT even fix the crash. That's pathetic
>> IMO.
>>
>> Dan
>>
>>
> Dan, that sounds odd.
>
> Can you post the lines of code?

Here is the code (I compressed my original example into one line):

uicontrol('parent',handle(uibuttongroup(figure)));

It crashes on both Win32 and Linux64.

On a related note: Please, please make handle objects supported!! They
are so useful! I use them all the time even though they aren't
officially supported. Consider this:

hb=handle(uicontrol(...));
hb.Position(3)=200;

Compared to the official way, which is bloated and harder to read:

hb=uicontrol(...);
pos=get(hb,'Position');
pos(3)=200;
set(hb,'Position',pos);

Dan

On Fri, 18 May 2007 12:50:05 -0400, Gary wrote:

>> ...I think there is or at least used to be a tab capability too
> that's
>> been
>> available for a long time, but "it's unsupported".
>>
>> Dan
>>
>>
> How do you locate/find out about these "unsupported" features?

I don't remember how I found them. It's probably from various sources.
You can learn about a lot of them here (there are many posts about how to
use uitable, which is a pretty popular unsupported feature).

You can also stumble on them using 'lookfor', for example 'lookfor tab'.
You run across one function called 'tabdlg' that looks rather interesting.

And of course if you peruse the toolbox folders in your installation, you
will also run across files that look kind of interesting.

Dan

Dan Hensley <somewhere@somewhere.withnospam> wrote in
news:pan.2007.05.18.18.09.30@somewhere.withnospam:

> uicontrol('parent',handle(uibuttongroup(figure)));

>> uicontrol('parent',handle(uibuttongroup(figure)));
??? Error using ==> uitools.uibuttongroup.uibuttongroup
Invalid input arguments

Error in ==> uibuttongroup at 22
h = uitools.uibuttongroup(varargin{:});

--
Scott
Reverse name to reply

On Fri, 18 May 2007 18:49:54 +0000, Scott Seidman wrote:

> uicontrol('parent',handle(uibuttongroup(figure)));

Oops, I missed a part. Try this:

uicontrol('parent',handle(uibuttongroup('parent',figure)));

It crashes on R2006a, R2006b, and R2007a. Sometimes I get the segfault
display in the Matlab window, sometimes Matlab just disappears. Actually
Matlab always just disappeared until just now when I tried it, and now
sometimes it manages to stay up.

Dan

In article <ef57195.21@webcrossing.raydaftYaTP>,
Gary <grubin698@gmail.com> wrote:
>That said, I'd also like to see a couple of new uicontrols. A table,
>similar to that used in the UI Property Inspector window, would be
>nice. I'd also like to see real UI tabs.

I would really like to be able to write

vc_mainplot.YLim = ylims*0.5;
ylims = vc_mainplot.YLim;

instead of

set(handles.vc_mainplot,'YLim',ylims*0.5);
ylims=get(handles.vc_mainplot,'YLim');

like I can in Delphi.

Francis

Samar Khatiwala wrote:
>
>
> I would dearly like to see 64 bit support on Mac OS X. Can someone
> from MathWorks comment about whether we will see this in 2007b or
> not?

I've been begging for this for quite a while, most of the answers
I've received point to the lack of 64-bit java, and other libraries
within Mac OS X. I'm hoping that this will be solved with the release
of Leopard - which is supposed to have 64-bit everything.

On Fri, 18 May 2007 14:12:19 -0500, Dan Hensley wrote:

> On Fri, 18 May 2007 18:49:54 +0000, Scott Seidman wrote:
>
>> uicontrol('parent',handle(uibuttongroup(figure)));
>
> Oops, I missed a part. Try this:
>
> uicontrol('parent',handle(uibuttongroup('parent',figure)));

Note that if you split the original line I posted into separate lines,
you don't need the 'parent' qualifier for uibuttongroup. Apparently
Matlab parses this differently. Try

hf=figure;
uicontrol('parent',handle(uibuttongroup(hf)));

Dan

On Fri, 18 May 2007 19:27:04 +0000, Francis Burton wrote:

> I would really like to be able to write
>
> vc_mainplot.YLim = ylims*0.5;
> ylims = vc_mainplot.YLim;


You can, if you turn your handle into a handle object.

vc_mainplot=handle(vc_mainplot);

Of course "it's unsupported".

Dan

I'll have you guys know that I was at a meeting this week at
Mathworks for a couple of days. Believe it or not Cleve Moller
(Matlab inventor/chairman/chief scientist) still responds to some bug
reports (he actually was looking at one during our meeting).

Also know that quality control is very important to Mathworks.
However, you must remember that Mathworks like anyone else only has
so many resources and their priorities may not be the same as yours.

For example, if you're interested in parallel computing, Mathworks is
making great strides at developing and improving the DCT. This is
one of their priorities.

Though, I do feel that bug fixes should be a higher priority than
developing new product.

Loren - I must echo Kelly and others' frustration. You're referring
us to the online buglist, but this list is incomplete at best. Just
in the past year I submitted over a dozen confirmed bugs, none of
which (except one) appear in the list (I just rechecked). I can send
you the internal issue IDs if you want. And these are all in fully
documented territory - I don't normally bother submitting issues in
undocumented areas. I'm actually very pleased with the promptness and
professionalism of your tech support staff, but if bugs are not
published, and if bugs are not fixed over a very long time (e.g., the
plotyy zoom bug, which is still unlisted BTW), then this effort is
only half-done and submitters like me get dishearted and frustrated.

Regarding the requested new features, these can't be seen anywhere.

As you can see from this highly active thread, there's an enormous
willingness by ML users to help TMW improve ML, and a frustration
that this willingness appears unanswered by TMW. Perhaps my original
suggestion of a votable wishlist is not the best mechanism. But
surely something can be found to improve the interaction with the ML
community and increase our participation in the dev-roadmap process.
We're all on the same side after all.

We're offering our help and advise willingly and freely - please use
it.

Yair Altman

Yair Altman:
<SNIP wish-list evergreen...

> This thread will be used to indicate the community's requests for
features/bug-fixes for the upcoming Matlab release...

i've been somewhat active in CSSM since its birth in 1993 (under
various names/aliases)...
very well-meant requests (similar to this OP) have come up
periodically - they NEVER EVER yielded anything substantial...

...NOR does TMW's official, mind-soothing placebo bug-site, which was
mentioned earlier in this thread...

unfortunately, the very founders of ML (little/moler) have come of
age (like all of us) and - by law of nature - lost touch with the
daily operations of their own domain... (i do remember the days when
both of them vividly and visibly participated in this NG)

anyhow ,this thread is a good vessel to vent your hopes for a better
(ML) world, frustration, or even anger...

us

Dear <us> wrote:

> Yair Altman:
> <SNIP wish-list evergreen...
> ...
> very well-meant requests (similar to this OP) have come up
> periodically - they NEVER EVER yielded anything substantial...

Well, I more than rarely have the same feeling. But, at a second
look, over time many good suggestions have been included in new
versions, but not necessarily in the order and pace that I/we/user(s)
would have wished (which typically is pronto if not yesterday :-).
Having said that, there are some rather long-standing requests that
tend to come up again and again here at CSSM.

One example, that currently causes much problem for me is the
unfortunate mixture of graph rendering and display engine that forces
me to do any serious plotting in interactive mode (suggestions in a
threadlast summer did not work out). Searching CSSM ("batch plotting"
etc) we find that this is a decadal-long story:
<342B416D.D2DBAEB6@mirinz.org.nz> is the earliest I found in a
quick check.

I aired my "batch plotting" problems last summer here at CSSM
<ef3c3ec.-1@webcrossing.raydaftYaTP> and was interacting with
TMW Support (and through them, I take it, with the developers). The
submitted bug/RFE is not even visible in
> ... TMW's official, mind-soothing placebo bug-site,

On the other hand, I understand that there is a completely new
graphical engine on its way (question is whether this is soon enough)
...

> anyhow ,this thread is a good vessel to vent your hopes for a
> better
> (ML) world, frustration, or even anger...

And for 2007b, I wish for a
TMW official, mind-blowing, pleasantly accurate bug-site,
that I will not need to use anyway...

Best,
Lars

Dan Hensley wrote:
> And of course if you peruse the toolbox folders in your
> installation, you
> will also run across files that look kind of interesting.
>
> Dan
>
  
Dan,
Thanks for pointing these out. It is nice to see that the uitab and
uitable do exist (sort of). I would still like to see uitab as a
GUIDE object.

In article <ef57195.25@webcrossing.raydaftYaTP>, Paul Mennen wrote:
> Yair Altman wrote:
> > finally (after who knows how many years) fix the
> > stupid zoom and similar problems with plotyy
>
> > That's got my vote!
> > Kelvin Hales <khales@khace.com>
>
> Yair and Kelvin - I'm curious to know which "stupid" plotyy problems
> are annoying you. I'd also be curious what you think of my "plt"
> alternative to plotyy and whether it avoids these stupid problems.

The fact that zoom does not work simultaneously on both axes (zooms only
on the currently selected axis).

I've not tried your "plt" alternative. The alternative 'zoom' function
<http://www.mathworks.com/matlabcentral/fileexchange/loadFile.do?objectI
d=1137> solved the problem; but has not been updated for a long time
now.

Kelvin Hales wrote:
>
>
> In article <ef57195.25@webcrossing.raydaftYaTP>, Paul Mennen
wrote:
>> Yair Altman wrote:
>> > finally (after who knows how many years) fix the
>> > stupid zoom and similar problems with plotyy
>>
>> > That's got my vote!
>> > Kelvin Hales <khales@khace.com>
>>
>> Yair and Kelvin - I'm curious to know which "stupid" plotyy
> problems
>> are annoying you. I'd also be curious what you think of my
"plt"
>> alternative to plotyy and whether it avoids these stupid
> problems.
>
> The fact that zoom does not work simultaneously on both axes (zooms
> only
> on the currently selected axis).
>
> I've not tried your "plt" alternative. The alternative 'zoom'
> function
> <http://www.mathworks.com/matlabcentral/fileexchange/loadFile.do?objectI
> d=1137> solved the problem; but has not been updated for a long
> time
> now.

For whomever is interested, the simple fix to the plotyy-zoom problem
is to call linkaxes for the two axes handles returned by the plotyy
function (see below). So it works for me, but this should be placed
within Matlab's zoom.m so that *everyone* enjoys the fix. For old
Matlab versions that don't have linkaxes, there are other solutions -
one of which Kelvin pointed out above. I just used this bug to point
out that MathWork's bug-list is, well, buggy...

[BTW, MathWorks finally added a comment line about linkaxes to the
bottom of plotyy's help comment, but never bothered to fix the code
itself...]

linkaxes(axout,'xy');
set(ax,'YTickMode','auto');

Yair Altman

Yair Altman wrote:
> [BTW, MathWorks finally added a comment line about linkaxes to the
> bottom of plotyy's help comment, but never bothered to fix the code
> itself...]

scrap this side-note: I mixed up two unrelated issues. I stand behind
the rest of what I posted.

Yair Altman

I suppose it depends on how you want to define threads, but I would
like to make a couple of comments. A Mathworks person might tell you
that Matlab is already multithreaded. Of course what you're really
interested in is multiple computational threads.

Of course you could just start multiple Matlab sessions. I don't
like this method either.

Another alternative is the distributed processing toolbox. With
2007a, you now have the option of having 4 workers on your local
machine without having to buy the computing engine.

 ryan kelly wrote:
>
>
> I want THREADS!!!!!!!!!!!
>
> Yair Altman wrote:
>>
>>
>> Kelvin Hales wrote:
>>>
>>>
>>> In article <ef57195.25@webcrossing.raydaftYaTP>, Paul
>> Mennen
>> wrote:
>>>> Yair Altman wrote:
>>>> > finally (after who knows how many years) fix the
>>>> > stupid zoom and similar problems with plotyy
>>>>
>>>> > That's got my vote!
>>>> > Kelvin Hales <khales@khace.com>
>>>>
>>>> Yair and Kelvin - I'm curious to know which "stupid"
> plotyy
>>> problems
>>>> are annoying you. I'd also be curious what you think of
> my
>> "plt"
>>>> alternative to plotyy and whether it avoids these
stupid
>>> problems.
>>>
>>> The fact that zoom does not work simultaneously on both
axes
>> (zooms
>>> only
>>> on the currently selected axis).
>>>
>>> I've not tried your "plt" alternative. The alternative
'zoom'
>>> function
>>> <http://www.mathworks.com/matlabcentral/fileexchange/loadFile.do?objectI
>>> d=1137> solved the problem; but has not been updated for
a
>> long
>>> time
>>> now.
>>
>> For whomever is interested, the simple fix to the plotyy-zoom
>> problem
>> is to call linkaxes for the two axes handles returned by the
> plotyy
>> function (see below). So it works for me, but this should be
> placed
>> within Matlab's zoom.m so that *everyone* enjoys the fix. For
old
>> Matlab versions that don't have linkaxes, there are other
> solutions
>> -
>> one of which Kelvin pointed out above.