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

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

Just to be clear, if the candidate form of the nonlinear equation is good then there doesn't seem to be much reason to prefer stats[fit] over Statistics[Fit] here.

The following produced a curve nearly ideantical to the rhs(c3) returned by stats[fit] in the above post.

Statistics[Fit](a+b*x+c*x^2+d*x^3,data,x);

acer

Just to be clear, if the candidate form of the nonlinear equation is good then there doesn't seem to be much reason to prefer stats[fit] over Statistics[Fit] here.

The following produced a curve nearly ideantical to the rhs(c3) returned by stats[fit] in the above post.

Statistics[Fit](a+b*x+c*x^2+d*x^3,data,x);

acer

The strange digits at the very end of the displayed numbers in the results are merely artefacts and can be safely ignored.

If you lprint() the results you will see that the Vector (or Matrix) in question has a float[8] datatype. That means hardware double precision, and comes about because those floating-point results are computed using a precompiled library (external to the main Maple kernel). Now, hardware double precision is a base-2 (binary) representation, but Maple shows the results in base-10 so that we can recognize them.

Those training strange digits are artefacts of the conversion from the underlying base-2 stored value to the (nearest possible) base-10 number. Notice how those artefacts lie in decimal digits places even beyond the 14th or 15th, despite that being past trunc(evalhf(Digits)). Personally, I would prefer that those digits weren't displayed at all, and that only trunc(evalhf(Digits)) digits were shown for float[8] datatype Vector/Matrix/Array objects.

acer

The strange digits at the very end of the displayed numbers in the results are merely artefacts and can be safely ignored.

If you lprint() the results you will see that the Vector (or Matrix) in question has a float[8] datatype. That means hardware double precision, and comes about because those floating-point results are computed using a precompiled library (external to the main Maple kernel). Now, hardware double precision is a base-2 (binary) representation, but Maple shows the results in base-10 so that we can recognize them.

Those training strange digits are artefacts of the conversion from the underlying base-2 stored value to the (nearest possible) base-10 number. Notice how those artefacts lie in decimal digits places even beyond the 14th or 15th, despite that being past trunc(evalhf(Digits)). Personally, I would prefer that those digits weren't displayed at all, and that only trunc(evalhf(Digits)) digits were shown for float[8] datatype Vector/Matrix/Array objects.

acer