The Standard GUI is written in Java, the Maple kernel is written in ANSI C, and the Maple library is written in Maple. Some of the external components might be written in other languages, I don't know for sure. Amusing historical tidbit: before being translated to ANSI C [not C99 yet AFAIK, but it would be nice to be wrong here], the kernel was pure K&R C, before that was written in 'margay', and in BCPL before that. 'margay' was the name of a homegrown macro processor which could generate either BCPL or K&R C. This homegrown macro processor survived for a very long time, making writing kernel code a serious art that very few mastered.

The Standard GUI is written in Java, the Maple kernel is written in ANSI C, and the Maple library is written in Maple. Some of the external components might be written in other languages, I don't know for sure. Amusing historical tidbit: before being translated to ANSI C [not C99 yet AFAIK, but it would be nice to be wrong here], the kernel was pure K&R C, before that was written in 'margay', and in BCPL before that. 'margay' was the name of a homegrown macro processor which could generate either BCPL or K&R C. This homegrown macro processor survived for a very long time, making writing kernel code a serious art that very few mastered.

I have Javascript enabled, but I had disabled some of the options (allowing Javascript to move windows, etc).  Now that I have reset that, I get the editor showing.  So those options apparently make a big difference!  It would be a good FAQ to pin down which options are necessary.

this is indeed a rather low priority bug. But it is easily reproducible, so it is amusing.

I have posted 2 things now, and my points seem to be 'stuck' at 1197. I guess the system is trying to tell me something...

Same setup, I do not see a WYSIWYG editor or buttons (other than "preview comment" and "post comment"). I have not configured my browser away from the defaults either! Otherwise the site update is very nice, it has a nicer look. There are a few new bugs (should I file them in this thread or another?), but nothing ghastly.

My preferred method would be to use polymorphism. In this case, juxtaposition could be a new operator whose meaning could be fixed whenever there is enough information available. Rather like what happens with =, as we discussed in recently. At least, that would be a Maple-compatible way of doing things. In a completely new system, the possibilities are much bigger still. Nevertheless, I might still favour the polymorphic solution.

My preferred method would be to use polymorphism. In this case, juxtaposition could be a new operator whose meaning could be fixed whenever there is enough information available. Rather like what happens with =, as we discussed in recently. At least, that would be a Maple-compatible way of doing things. In a completely new system, the possibilities are much bigger still. Nevertheless, I might still favour the polymorphic solution.

The issue is that this does not really solve the problem. Posting suggestions leads to potentially good discussions, but not an SCR; creating an SCR is like sending something off into a black hole. What is needed is an easy tool that does both in one go. Note that good discussions can often be quite helpful to the developers too, to help them figure out what is really needed and what the root of the problem might be.

Will these SCRs also show up as posts on primes? Quite often various reports (suggestions, bugs, etc) engender some interesting discussion, so it is important that these generate posts as well as generating an automatic SCR for Maplesoft.

If you read page 3 of Caviness's article in detail (classes R and R_1), you will see the source of the confusion. Basically, we were both confused! The theorems (and proofs) in those two papers are quite precise. Note how sin(Pi*x_i) is used precisely to transfer properties between arbitrary reals and integers. Without Pi, or a means of getting Pi, the proof really falls apart. Basically sin(Pi*x) is a nice proxy for detecting integers, because sin is uniformly continuous.

Take a look at HSXML, a typed variant of XML. Because the syntactic restrictions of XML are embedded in a strong type system, the underlying language will give you very precise error messages as to what the problem was. Plus the syntax is much more pleasant than raw XML (or HTML). On the other hand, I do think that some of the fancier XML editors can do that. As you say, the underlying technology (just set theory) isn't rocket science!

In a more helpful vein, if you have a particular set of rewrite rules for trigonometrics, then it is quite easy to implement these in Maple. Then you can implement a proof search routine on top of that, following whatever heuristics you like. If your search finds an identity, then you can simply look at the path taken by the search to find your proof. This is more-or-less what some simplistic automated theorem proving systems do [and not at all what the advanced ones do]. But that should be sufficient for trig identities.

that at least Richardson's results also required the abs function to be in that set (at least according to MathWorld). Plus, it doesn't say that it's undecidable, but that it is recursively undecidable. Frequently a semi-decision procedure is much more useful that a total predicate [and hence true/false/FAIL in Maple]. Note that this undecidability result only says that arbitrary identities cannot be checked, it does not say that there are not large sub-classes of expressions for which zero-equivalence is decidable. So undecidability results always have to be taken with a large grain of salt, since they rarely stated in 'effective' terms (ie all expressions that contain all these symbols and larger than a specific side are all undecidable, for example; the results are all existential). I believe that buried in one of Joris van der Hoeven's papers is an algorithm which would indeed decide trigonometric identities such as the ones the original poster asked about. Richardson's trick to get undecidability was to show how to 'encode' tough diophantine problems (already shown undecidable) into a zero-decision problem for the class of functions in the MathWorld article. The point is that it is not a 'new' undecidability result, but really an encoding of an old one in a new guise. If you stick to trig functions and rational coefficients, I do believe the class is quite well-behaved.

If you have no entry in A (because it is sparse) but a non-zero entry in B, what does that mean? That seems inconsistent. Could you show us a larger part of what you are trying to do? I think we will be better to help you if we understand the context of what you are trying to achieve.