I find it hard to accept that the RREF of the following Matrix , whose condition number is roughly 10^1201, should be taken to be the identity.

> M:=Matrix([[1e600,0,0],[0,1,1],[0,1e-600,0]]);
                           [      601                   ]
                           [0.1 10           0         0]
                           [                            ]
                      M := [    0            1         1]
                           [                            ]
                           [                   -599     ]
                           [    0        0.1 10        0]

> evalf(ReducedRowEchelonForm(convert(M,rational)));
                               [1.    0.    0.]
                               [              ]
                               [0.    1.    0.]
                               [              ]
                               [0.    0.    1.]

On the other hand, it was interesting how the above Matrix made the external NAG function hw_f08mef "go away" when I asked for LinearAlgebra:-Rank(M) at default Digits.

acer

Thanks Will, I can understand that MathML has not taken enough hold.

But isn't it still true, that 2D Math input being displayed here on Mapleprimes posts via gifs makes the whole cut & paste of said input rather too much work?

I see that uploaded .mw files can be displayed (using a client plugin) in such a way that it looks like Maple 2D Math as well as behaves nicely under cut & paste into a separate Maple session. Could not the same technology be used (transparent to the mapleprimes user) to mark up <maple> fragments in posts here, and display them inlined with each using some similar mechanism?

If the math and the maple can't be easily copied into a working Maple session, then something important is missing. Having to resort to uploading a worksheet in order to get that effect isn't much different than having to install extra plugins/fonts/etc. Well, actually, it's more effort since presumably installation of extras is a once-only affair while having to use downloads (or view Properties of embedded objects) to make 2D code easily accessible and transferable is something that currently needs to be done for each occurrence.

acer

Hi John,

While I agree with you that the <maple> tag is not working properly at present, I do wonder why it's an appealing prospect at all.

I mean, suppose you produced a nice post, with all the math input as 2D (converted to gifs here on mapleprimes). Is it easy to cut & paste such input, into a separate Maple session? I would say no, if it means having to resort to the trick (thanks again, Jakubi) of popping up the Properties of the embedded gif image and grabbing the Alternate text.

What I wonder is why it can't be displayed with MathML, that might then further be plonked straight into Maple. It is 2008, after all.

acer

I don't know how the original poster will resolve his separate, unposted questions related to construction of more involved piecewise functions.

But, for the type of problem as originally posted here where the form of the operators' bodies is known in advance, unapply is not a better choice as far as scaled performance goes.

One can benchmark the two, in separate sessions (full exit and relaunch, not just restart).

> for i from 1 to 20000 do
> unapply(t*i,t);
> od:
> quit
bytes used=57567480, alloc=16905192, time=1.56

versus

> f := i -> t -> t*i:
> for i from 1 to 20000 do
> f(i);
> od:
> quit
bytes used=5686424, alloc=4324584, time=0.06

Of course, for small code fragments that are not intended for heavy reuse, the convenience might matter much more than the performance. If piecewise() constructs are being used then performance is (cough) probably not the major goal.

acer

I don't know how the original poster will resolve his separate, unposted questions related to construction of more involved piecewise functions.

But, for the type of problem as originally posted here where the form of the operators' bodies is known in advance, unapply is not a better choice as far as scaled performance goes.

One can benchmark the two, in separate sessions (full exit and relaunch, not just restart).

> for i from 1 to 20000 do
> unapply(t*i,t);
> od:
> quit
bytes used=57567480, alloc=16905192, time=1.56

versus

> f := i -> t -> t*i:
> for i from 1 to 20000 do
> f(i);
> od:
> quit
bytes used=5686424, alloc=4324584, time=0.06

Of course, for small code fragments that are not intended for heavy reuse, the convenience might matter much more than the performance. If piecewise() constructs are being used then performance is (cough) probably not the major goal.

acer

This doesn't have anything to do with the C source question of the OP. It's just another, somewhat shorter, and builtin way to produce and sort such equations of the form (index)=value for an Matrix/Array/Vector.

k := Matrix(3,3,(i,j) -> i*j + i^2 - j^2):
sort([op(rtable_elems(k))],(a,b)->rhs(a)<rhs(b));

acer

This doesn't have anything to do with the C source question of the OP. It's just another, somewhat shorter, and builtin way to produce and sort such equations of the form (index)=value for an Matrix/Array/Vector.

k := Matrix(3,3,(i,j) -> i*j + i^2 - j^2):
sort([op(rtable_elems(k))],(a,b)->rhs(a)<rhs(b));

acer

There are lots of quirks with option inline, on top of what happens when it sees a local or a lexical variable.

> f2 := proc(m, S) option inline; map(s->(s=1,m,s),S); end proc:
> f2(X, 2);

                                  X = 1, X, X

I also find it interesting that one cannot trace() a proc with option inline, while one can use stopat() on it. It's possible that the debugger disables the inlining. For nonsense word `foo`, "option inline, foo" does one thing while "option foo, inline" does another.

acer

It looks as if someone restored a backup breakpoint, or otherwise temporarily removed posts of the past few months. They've been reappearing, in blocks, over the past hour or so. Hopefully all is not lost, although even then google searching could often point one to a cached version. The problem may turn out to be less severe. Attempting to visit some of the missing posts, right now, results in an Access Denied message. The Editor is now behaving differently also. (The toolbar is gone, for example. And signatures appear as source.) Maybe it would be a good idea if the site administrators had another working image of the site, on which to practice the tweaking before making it go live?

acer

I've found that entering and staying in Source mode is the best way to (not) use the new Editor.

For me, it was key to learn to not switch back and forth between Source and non-Source mode -- as tempting as that prepreview was. Switching back and forth can mess things up even more.

acer

A little investigation can show that `print/...` extensions also fail to work properly alongside context-menus in the older Classic GUI.

Jacques has mentioned that the context-sensitive menus are over 10 years old, or so. That's much older than the present Standard (Java) GUI.

So what I wonder is this: why were context-sensitive menus introduced over 10 years ago when it must have been very clear that they did not work with print extensions? Why wouldn't that have been fixed in the immediate years following that?

I don't know exactly how the communication works, between kernel and interface. Clearly it's not fully bidirectional. In particular I don't understand why the GUI doesn't get a handle for all objects that it can adequately use as a reference when passing an instruction back to the kernel.

I also wonder how Matrices (rtables) and some other objects get specialized display in the GUI while also working with context-menus. Is there a central mechanism for it (which might possibly be made extensible), or is it a collection of one-offs?

acer

That's a great look, even in 1D input.

> sin(n*Pi) assuming n in posint;

                                       0

As a consequence of the above, the Open Face palette can be used to get the scripted N as a stand-in for `posint`, in 2D Math input. That looks so Natural.

acer

That's a great look, even in 1D input.

> sin(n*Pi) assuming n in posint;

                                       0

As a consequence of the above, the Open Face palette can be used to get the scripted N as a stand-in for `posint`, in 2D Math input. That looks so Natural.

acer

Good things to know and think about, Jacques. You've shown that display and user-based control is the a contentious part of extensions, and other good stuff besides.

Looking a little harder at that system routine `print/rtable` shows that not only does it query the interface and printlevel, it also stuffs the memory address of the rtable into an RTABLE() call. Presumably that's so that the interfaces can get the sort of handle on the object that you describe their needing. It's interesting too, since each or the Maple interfaces must have their own mechanisms for displaying RTABLE calls to.

I especially like how context-menus in the Standard GUI work on the displayed result of a "bogus" RTABLE() call like RTABLE(32,MATRIX([a]),Matrix). I'm half surprised it doesn't crash. So, the unprotected and undocumented names RTABLE and MATRIX are removed from the space of names fully available for the user.

This produces different unpleasant results in the TTY and Standard interfaces.

MATRIX := proc(x) "hi"; end proc;
<<17>>;

What about Typesetting? I'd like to be able to turn off the default of having subscripts in 2D Math be interpreted as table references. But what about customizing typesetting of named function calls, similar to `print/foo`, etc?

I wonder how people feel about the relative importance of a New & Improved latex() functionality, versus customized typesetting. What about programmatic control of GUI elements -- something else that Mathematica 6 claims to have?

acer

Yes, I agree that the documentation should show much more clearly how to use Statistics:-Sample in the optimal ways possible.

But that example above, where the x in Poisson(x) is an unassigned name and the procedure returned by Sample() uses undeclared name x for a numeric value to an external call, that must be a bug. It has the look of an oversight.

In such a usage case, the procedure returned by Sample() would be better off accepting an additional numeric argument for the distribution's parameter. Or more than one extra argument, in the case of several parameters.

Since the number of parameters might vary according to the particular distribution, the first argument of Sample() should remain the posint that specifies the sample size.

So both the simple and the parametrized cases of calling Sample() repeatedly and efficiently should be clearly documented, and in one of the cases it should document a fixed behaviour.

acer