MaplePrimes Posts

MaplePrimes Posts are for sharing your experiences, techniques and opinions about Maple, MapleSim and related products, as well as general interests in math and computing.

Latest Post
  • Latest Posts Feed
  • 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

     Here is a example of a cesaro sum used when a series fails to converge in the usual sense of a sum.

    sum((-1)^n*(n^(1/n)-a), n = 1 .. infinity) has a cesaro sum of 1/2*(a+2MRB constant-1).

    Proof:

    We are given that                            S=  sum((-1)^n*(n^(1/n)-a), n = 1 .. infinity) .

    Expanding the infinite series we get         S=(a-1)+(2^(1/2)-a)+(a-3^(1/3))+(4^(1/4)-a)+... .

    Collecting the a's and the surds we see that S=a-a+a-a+...+(-1+2^(1/2)-3^(1/3)+4^(1/4)...) .

    By Grandi's series  we know that             S=1/2*a+(-1+2^(1/2)-3^(1/3)+4^(1/4)...) .

    Collecting the infinite series we get        S=1/2*a+ sum((-1)^n*(n^(1/n)), n = 1 .. infinity).

    Which can be shown to be                     S=1/2*a+ sum((-1)^n*(n^(1/n)-1), n = 1 .. infinity)-1/2 .

    Thus, by factoring out the 1/2, we get           S=1/2*(a+2 sum((-1)^n*(n^(1/n)-1), n = 1 .. infinity)-1) .

    Therefore,                                   S=1/2*(a+2MRB constant-1) .

     

    In order to give symbolic results for that familly of sums Maple shouldmake this identify an integral part of maple in future versions!

    Marvin Ray Burns

    Original investigator of the MRB constant.

    Mapleprimes page order is out. 

    Okay, I decided to dig back into the beginning of mapleprimes pages.  So one would logically think to go to the last page here on mapleprimes ... that would be page 200.  So off I went and to my surprise, nothing is in order.  I expected to find posts in a logical order from first to last at least from 2006 or so but instead I'm finding pages labelled as new as 2009 there. 

    Maybe we could have a button...

    I found this great post on Twitter today. Two fans of Maple dress up as Maple and MATLAB for halloween:

    @pastelpastel @snowangelzz Math costumes from last year! Matl... on Twitpic

    I know that lots of you are big fans of Maple, but how many of you would consider going out in public dressed as Maple?

    ____

    William Spaetzel
    MaplePrimes Administrator
    Software Developer, Maplesoft 

    Hello all,

    I have encountered a curious bug in the EigenConditionNumbers
    procedure. In particular for a pencil pencil (A,B) with B singular,
    and precision higher than hardware precision.

    The following code for Digits=40 produces a Float(undefined) rather
    than a Float(infinity) for the infinite eigenvalue, but an alpha and
    beta that will produce an infinite eigenvalue.

    Digits:=trunc(evalhf(Digits));
    A:=Matrix([[1,0],[0,2]]);
    B:=Matrix([[1,0],[0,0]]);

    Just looked at the badges pages (clicking on the corresponding tab at the top).

    88 people (including me) earned Tumbs-up badge, but only 50 people are listed there, and it says "page 1 of 1", there is no 2nd page - and unfortunately I didn't find myself there.

    Even more interesting - clicking on most earned badges - such as 1st questions etc. - there are many pages, but only the first page for every badge have people listed - all the other pages are empty.

    A couple of days ago I found out that gzread from the zlib library can be used for fast reading of binary files in Maple from the disk to memory - about 100 times faster than readbytes - something like in the following simplified example, 

    A:=Array(1..2^26,99,datatype=integer[1]):

    time(writebytes("A",A));close("A");

                                    9.360

    B:=Array(1..2^26,1,datatype=integer[1]):
    time(readbytes("A",B));close("A");

                                    8.065
    B[1],B[-1];

                                    99, 99

    myreadbytes:=proc(f)
    local gzopen, gzread, gzclose, n, p, A;
    gzopen:=define_external('gzopen',
        'path'::string,
        'mode'::string,
        'RETURN'::integer[4],
        'LIB'="zlibwapi.dll");
    gzread:=define_external('gzread',
        'file'::integer[4],
        'buf'::REF(ARRAY(datatype=integer[1])),    
        'len'::integer[4],
        'RETURN'::integer[4],
        'LIB'="zlibwapi.dll");
    gzclose:=define_external('gzclose',
        'file'::integer[4],
        'RETURN'::integer[4],
        'LIB'="zlibwapi.dll");
    n:=FileTools:-Size(f);
    A:=Array(1..n,datatype=integer[1]);
    try p:=gzopen(f,"rb");
    if gzread(p,A,n)=n
    then return A end if
    finally gzclose(p)
    end try
    end proc:
    time(assign(C=myreadbytes("A")));

                                    0.062

    C[1],C[-1];

                                    99, 99

    'time(myreadbytes("A"))'$5;


                      0.078, 0.062, 0.046, 0.046, 0.046

    E:=Array(1..2^26,2,datatype=integer[1]):
    time(ArrayTools:-Copy(A,E));

                                    0.093

    That needs some tweaking, because that works only on uncompressed files. If a file ("A" in this example) was gzipped, then the gzread would ungzip n (uncompressed) bytes in it in this example, instead of copying it into the memory - but it is not a big deal, in general.

    Does anybody know about a similar replacement for writebytes? gzwrite doesn't work for copying (it compresses the array.)

    I used the zlibwapi.dll library from http://www.winimage.com/zLibDll/index.html, it is a version of zlib 1.2.5 (written by Jean-Loup Gailly and Mark Adler) built by Gilles Vollant. The code is for a 32-bit system (Windows). That should work in 32-bit Linux after replacing that dll with standard libz.so.1, as well as on 64-bit systems after replacing integer[4] with integer[8] in most places.

    Student's t distribution is named after William Sealy Gosset's pseudonym, Student. He published using this pseudonym because his employer, the Guinness brewery in Ireland, did not allow its employees to publish scientific papers after an incident where trade secrets were disclosed. In this blog...

    First 129 130 131 132 133 134 135 Last Page 131 of 307