A Half-Life table of the Isotopes

** edit change a[i,j]:=0 to a[i,j]:=1

I was about to post this as a "How-do-I" question, but while composing my question, I stumbled upon the solution.  In case this "discovery" would be useful, I'm posting it here.

For some coursework, I'm developing fitting sinusoids to experimental data (poor-man's Fourier Analysis).  At one point, I do a "brute-force-least-squares" computation, one step of which involves computing the sum of a sine over N equally-spaced intervals around the circle.  This...

Just a small issue with how you insert a ^ (caret, wedge, circumflex, arrow, hat, what have you), / (forward slash), or * (star, asterisk) as a literal in a comment in Maple.

In regular code, it works fine;

Typing \_ produces _
Typing \^ produces ^
Typing \/ produces /
Typing \* produces *

In a comment, only underscores work as expected.  The caret, asterisk and slash leave behind the escaping backslash, which you will have to go back and delete yourself.

In previous version  "e" was recognised as the constant.. Now, it is needed to write in special way to get

the digits of "e" ( to use "expression palette")

I really do not know if that is a progress or regression for Maple.

JJ

As some of you know, I'm hoping to, some day, find a closed form expression for the MRB constant.

 Here is my latest little nugget.

Let x=MRB constant.

 = log(x) with an error< ...

I ran an advanced search in the application center at maplesoft and I'm not sure that it works properly.

Under advanced search I left the search field blank and selected MapleV to find all applications submitted for MapleV.  The first thing that happens is that it comes up with applications rated for newer versions of Maple.  Then it asks to click here to search our archived Maple-related applications (prior to Maple 10).

So I do that but it only produces...

(This is a reply to PatrickT, who asked about a certain ArrayTools:-Copy example.)

Suppose that you need to do a computation which requires, in part, a certain subportion of a Vector V. Let's call the routine which does the work as `f`. Let's suppose that `f` is a system command and not something that we write ourselves. One natural way to call `f` and supply the subvector is to call `f` like so:

   f( V[a..b] );

Here the inner range a..b denotes...

At http://www.maplesoft.com/applications/view.aspx?SID=97879 there seems to be a quite
interesting contribution by Rob Corless, Erik Postma and David Stoutemyer.

It would be helpfull and interesting to provide the according paper as well (through a link?).
Hope this message is read by Eric Postma.

PS: I wanted to drop an according message at the center as comment, but failed to log in,

Aren't the acceptance numbers for various badges just way too high? Mapleprimes has only had 2 (one each) Good Posts at this date. And no Good Answers or Great ones of either type. But that's clearly not right, as the new site has had lots of great posts and answers. This same issue was raised long ago, and the admin response of long ago was that it would be revisited.

And there...

@John Fredsted

This thread is 3 years old, I don't wish to upset anyone by "reviving" it, forgive me.

I came to this thread as I was searching for information on how to write efficient procedures.

I learned a great deal by looking at how others write a proc.

Now the LinearAlgebra package implements a KroneckerProduct so the need for user-written procedures to...

Stop ordering posts based on the number of thumbs up. 

It's certainly not fair when someone comes up with an original idea that causes a flurry of other great ideas only to have yours shoved to end because it got less up votes.  It gives someone else all the credit and I'm not a happy camper.  My post got deleted because it had a down vote and got shoved to the very end. 

A new release of MapleSim is now available.

MapleSim 4.5 Highlights

• Enhanced Modelica support, including the ability to access new collections of components using the Modelica import feature
  
  
• Increased speed and modeling capabilities for continuous systems with discrete events. The enhanced engine handles a far greater class of these systems than earlier versions, and shows significant...

Maple 14.01 is now available. It provides updates in many areas, including:

• Mathematics: Updates to the VectorCalculus, DifferentialAlgebra, MathematicalFunctions, and Student packages, the convert command, and tools for solving differential equations
• Interface: Enhancements to context menus, tables, embedded components, document blocks, and the start-up code region
• Plotting:

External calling functions from Windows dlls in Maple uses __stdcall calling convention.

Most Windows dlls including <windows.h> are using that convention (called also WINAPI). However, C runtime dll (msvcrt.dll) and most mathematical dlls - such as gsl, PARI, etc. which would be very useful, are using __cdecl calling convention and functions from them can not be easily called from Maple. One has to create a wrapper dll with __stdcall calling convention for that. In particular, Axel Vogt did that for a part of PARI.

Would that be possible for Maplesoft developers to add option CDECL in define_external in Maple 15 allowing calling C library functions and functions from gsl, PARI, etc. directly from Maple, without a burden of writing __stdcall wrappers for them first?

Perhaps you have heard the terms "ordering difference" or "session dependent" applied to results of some Maple computation. It used to get heard more often back before Maple 12, when elements of sets in Maple were ordered according to address.

What would typically happen would be something like this. A computation gets done by looping either over the variables (symbol indets) of an expression, or over named elements of some set. And the computation happens to be very sensitive to which variables get chosen and used first. But the order in which they get chosen is according to the rule by which the elements of Maple sets are ordered. So if the address in memory of some of the variable names just happens to be different, then they get selected in an different order, and an entirely different computation path might get taken.

Now, merely using a name at some apparently unrelated earlier point in the Maple session can cause that name to get a different memory address than if the name is first used later on. The upshot was that apparently innocuous and unrelated use of variables at some earlier stage in a session could actually completey change a later result of an algorithm which happened to be sensitive to the order of set member access.

Since the difference in the final result in such cases would depend on ostensibly harmless earlier activity in the session, the whole effect was labelled "session dependence". And it caused a lot of grief.

As a wild (ficticious) example, you merely enter the name `x` early in a worksheet, and somehow the later result of an integral has a totally different (valid, but more complicated or unsimplified) form.

But since Maple 12 sets' entries are "ordered" (internally, by Maple's kernel) and a reduction in the appearance of session dependence has come about. But I was reminded recently (on usenet) that ordering differences can also apply to adding and multiplying expressions. And by coincidence this also ties in to something else that I've been thinking about: roundoff error.

Here's the simple example that came up. When you enter x/y you form a Maple expression whose internal representation (DAG) stores it as the product of x and of y^(-1). But which of those two multiplicands is stored first? It matters! When x and y get evaluated at floating-point values then it matters which is evaluated first. If y^(-1) gets evaluated first then roundoff error may occur. But if x is evaluated first then the float division might happen to occur without roundoff error.

Let's look closely at the example that came up.

> restart:

> ee := x/y;
                               x
                               -
                               y

> eval(ee, [x=2.1, y=2.4]);
                          0.8750000000

> restart:

> invee:=y/x:

> ee:=1/invee;
                               x
                               -
                               y

> eval(ee, [x=2.1, y=2.4]);
                          0.8750000001

In both sessions above, ee equals x/y. But only the second incurs roundoff error. The second result differs from the first, in the last decimal digit. It turns out that the order in which x and y^(-1) get stored in the product DAG is different in these two examples. If y^(-1) gets evaluated at y=2.4 before x gets evaluated, then Maple computes the intermediary term 1/2.4 = 0.4166666667 which of course has roundoff error. But if x gets evaluated first them Maple sees 2.1/2.4 as the division to compute, and that can get done with no roundoff due to fortuitous cancelation of factors of 3, ie. it is the same as 0.7/0.8=0.875.

You can see the internal storage distinction, as follows. I'll repeat the above pair of examples, but this time also dismantling `ee` to show its structure. Notice the order of `x` and y^(-1) insides the printed DAG.

> restart:
> ee := x/y;
                               x
                               -
                               y
> dismantle(ee);

PROD(5)
   NAME(4): x
   INTPOS(2): 1
   NAME(4): y
   INTNEG(2): -1

> eval(ee, [x=2.1,y=2.4]);
                          0.8750000000

> restart:
> invee:=y/x:
> ee:=1/invee;
                               x
                               -
                               y

> dismantle(ee);

PROD(5)
   NAME(4): y
   INTNEG(2): -1
   NAME(4): x
   INTPOS(2): 1

> eval(ee, [x=2.1,y=2.4]);
                          0.8750000001

Ok, so perhaps you are thinking: who cares, the difference is tiny. Well, small differences are easily isolated and magnified if they occur inside compound expressions. And so the ensuing results might be entirely different.

Take just a slightly more involved example,

> restart:
> ee := 1/(sqrt(0.8750001 - x/y)) - 3162;

                           1                 
                  -------------------- - 3162
                                 (1/2)       
                  /            x\            
                  |0.8750001 - -|            
                  \            y/            

> eval(ee, [x=2.1,y=2.4]);

                            0.277660

> restart:
> invee:=y/x:
> ee := 1/(sqrt(0.8750001 - 1/invee)) - 3162;

                           1                 
                  -------------------- - 3162
                                 (1/2)       
                  /            x\            
                  |0.8750001 - -|            
                  \            y/            

> eval(ee, [x=2.1,y=2.4]);
                            1.859986

Look at what caused the difference. All I did was assign y/x to invee and then re-use that to form `ee`. The expression `ee` looks the same on the surface. But inside it, the term x/y is stored with a different order of its multiplicands. And the final results are really different.

I suspect that an improvement might be had if evaluation at a point (2-argument eval) were instead done by substituting floats into numerator terms (positive integer exponent) before denominator terms (negative integer exponent). But investigation would have to precede that.

Finally, you might wonder what can be done with the errant version of `ee` from the last example. Simplification may or may not help,

> eval(simplify(ee), [x=2.1,y=2.4]);

                          0.2776606276

> eval(fnormal(ee), [x=2.1,y=2.4]);
                            0.277660

Are either of those last two results correct to ten places, you might ask? Well, no.

> Digits:=5000:

> eval(ee, [x=2.1,y=2.4]): evalf[10](%);
                          0.2776601684

acer